9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
* /sys/src/libc/port/crypt.c
@ 1995-11-11 15:44 G.David
  0 siblings, 0 replies; 3+ messages in thread
From: G.David @ 1995-11-11 15:44 UTC (permalink / raw)


Because of export restrictions, I assume, the source to the encrypt()
and decrypt() functions (/sys/src/libc/port/crypt.c) are not on the CD-ROM.

I have used the code base that Pace Willisson <pace@blitz.com> made
available for authenication on UNIX to recreate crypt.c.

Even though I was more careful using unsigned declarations throughout
the code, I am concerned about character size problems.  From what I
can tell, the caller of encrypt/decrypt will handle the conversion of
whatever to blocks of bytes for encryption, but is this sufficient?

An added bonus is general purpose encryption in libc.a.  This
provides functionality to enable fast encrypted data streams.  My idea
is to encrypt all data on the wire.  Am I being unreasonable?

For a sanity check, are there any restrictions for routines in libc.a?

One last question, is it possible to get the original code from Bell Labs
if you are a US citizen?

Thanks for your attention.

David Butler
gdb@dbSystems.com






^ permalink raw reply	[flat|nested] 3+ messages in thread

* /sys/src/libc/port/crypt.c
@ 1995-11-12  4:32 G.David
  0 siblings, 0 replies; 3+ messages in thread
From: G.David @ 1995-11-12  4:32 UTC (permalink / raw)


>>An added bonus is general purpose encryption in libc.a.  This
>>provides functionality to enable fast encrypted data streams.  My idea
>>is to encrypt all data on the wire.  Am I being unreasonable?
>
>Probably.

>           What's the encryption algorithm
DES (perhaps with desinit(mode = 1): see des.c)

>how are sessions keys negotiated
I was thinking of using the nonce key created for the ticket.  It is
created for each session and both the client and server know it and
since it was encrypted using their keys, it was never transmitted in
the clear.

>                                  how many bits in each key, etc.
64 (56 used)

>	/r$

I was thinking that this would be a layer for the 9P mnt(3) driver to do
on links that are not private.  This only makes sense for Plan 9 type
devices (terminals, cpu servers, file servers) that are connecting
through public media.

For example if I use a p9 terminal on a serial link through voice lines
to a p9 network, I would not bother since the link is "private".  But if
I was dialed to a ISP via PPP, then I would.

db






^ permalink raw reply	[flat|nested] 3+ messages in thread

* /sys/src/libc/port/crypt.c
@ 1995-11-11 18:33 Rich
  0 siblings, 0 replies; 3+ messages in thread
From: Rich @ 1995-11-11 18:33 UTC (permalink / raw)


>An added bonus is general purpose encryption in libc.a.  This
>provides functionality to enable fast encrypted data streams.  My idea
>is to encrypt all data on the wire.  Am I being unreasonable?

Probably.  What's the encryption algorithm, how often are the keys changed,
how are sessions keys negotiated, how many bits in each key, etc.
	/r$






^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~1995-11-12  4:32 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1995-11-11 15:44 /sys/src/libc/port/crypt.c G.David
1995-11-11 18:33 /sys/src/libc/port/crypt.c Rich
1995-11-12  4:32 /sys/src/libc/port/crypt.c G.David

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).