smart@ditmela.oz (Robert Smart) (04/16/89)
There is interest in security of access over a TCP/IP network. Here is a simple proposal for your criticism. The objective is minimum change to existing code. This addresses two related security issues: (1) people attempting unauthorized access to your system; (2) the fact that the TCP data stream is easy to snoop on as it passes through insecure parts of a network. The first thing a Secure-TELNET daemon does when it receives a connection is send a random number (say 4 bytes) to the client. The client has to know the servers "magic number". It combines that magic number with the random number to obtain two random number sequences. The server does the same. From then on each byte in the TCP stream is XORed with the low order byte of the appropriate random number sequence. This simultaneously encrypts outgoing bytes and decrypts incoming ones. In fact the encryption/ decryption code should be in the TCP layer so that it is quite easy to modify other applications like ftp to produce secure versions. I think this would have a low overhead and be very hard for someone watching the data stream to decrypt. Any encryption experts like to comment? The nice thing about this scheme is that it can be used in two distinct ways. You can set it up so that machines you trust (on your local subnet, etc) know the "magic number". The users of those machines can log in to your machine via Secure Telnet without having the "magic number". Indeed it is best if the number is held securely so they can't find it out. For the much smaller number of people who use your machine from remote hosts, perhaps while travelling, you can tell those people the magic number and they can tell the secure Telnet client the number when they invoke it. Bob Smart, <smart%ditmelb.oz.au@uunet.uu.net> or <uunet!munnari!ditmelb!smart>
Robert.Smart@ditmela.oz.au (Robert Smart) (04/17/89)
Posting #53 to aus.comms ------------------------------------------------------------------------ There is interest in security of access over a TCP/IP network. Here is a simple proposal for your criticism. The objective is minimum change to existing code. This addresses two related security issues: (1) people attempting unauthorized access to your system; (2) the fact that the TCP data stream is easy to snoop on as it passes through insecure parts of a network. The first thing a Secure-TELNET daemon does when it receives a connection is send a random number (say 4 bytes) to the client. The client has to know the servers "magic number". It combines that magic number with the random number to obtain two random number sequences. The server does the same. From then on each byte in the TCP stream is XORed with the low order byte of the appropriate random number sequence. This simultaneously encrypts outgoing bytes and decrypts incoming ones. In fact the encryption/ decryption code should be in the TCP layer so that it is quite easy to modify other applications like ftp to produce secure versions. I think this would have a low overhead and be very hard for someone watching the data stream to decrypt. Any encryption experts like to comment? The nice thing about this scheme is that it can be used in two distinct ways. You can set it up so that machines you trust (on your local subnet, etc) know the "magic number". The users of those machines can log in to your machine via Secure Telnet without having the "magic number". Indeed it is best if the number is held securely so they can't find it out. For the much smaller number of people who use your machine from remote hosts, perhaps while travelling, you can tell those people the magic number and they can tell the secure Telnet client the number when they invoke it. -- Bob Smart, <smart%ditmelb.oz.au@uunet.uu.net> or <uunet!munnari!ditmelb!smart>
cpj@SUN.COM (Chuck Jerian) (04/17/89)
>Why not use a a four byte key, a magic number and the low byte to xor...
A four byte key is too short. It invites a search of the key space.
Also xoring the data one byte at a time with the low byte is suspect.
A much sounder scheme would be to use cipher block chaining and des.
One problem with telnet is that data is sent out of band for commands,
and this causes trouble keeping a cbc synchronized on both ends.henry@utzoo.uucp (Henry Spencer) (04/18/89)
In article <4814@ditmela.oz> smart@ditmela.oz.au (Robert Smart) writes: >The first thing a Secure-TELNET daemon does when it receives a >connection is send a random number (say 4 bytes) to the client. Why? Since this number is sent over the network and is visible to any snoopers, it adds nothing to security. >The client has to know the servers "magic number". It combines >that magic number with the random number to obtain two random >number sequences. The server does the same. From then on each >byte in the TCP stream is XORed with the low order byte of the >appropriate random number sequence... >I think this would have a low overhead and be very hard for >someone watching the data stream to decrypt... It depends entirely on how good your random-number-sequence generator is. If it's, say, the one from your local C library, you have very little security, because methods of breaking such things are widely known. If it's of crypto quality, okay -- but where are you going to get one like that? What you've invented is the supporting substructure of a cryptosystem -- a secret key known to both ends and XOR-based combination with the plaintext. What you haven't done is to specify the crucial part: how a short key gets turned into a very long sequence of very random-looking bits. The standard sorts of random-number generators used in computing are ridiculous toys by cryptographic standards. -- Welcome to Mars! Your | Henry Spencer at U of Toronto Zoology passport and visa, comrade? | uunet!attcan!utzoo!henry henry@zoo.toronto.edu