Authentication Using Rotor

[Chad Netzer]

On Fri, 2003-03-14 at 14:43, Ed Young wrote:
> I am writing a distributed application in Python which uses 
> sockets to transfer data.  I would like to authenticate the 
> sender when a socket connection is made.

An enormous topic.

> The best I have come up with so far is to have identical keys
> at both the sender and the receiver.

How do you make sure these keys are kept secret?  Most modern protocols
are based on generating a shared secret *per session*, using public key
exchange protocols (DSA, for example).  If the keys are stored with the
application, then you aren't authenticating users, and anyone who can
get a copy of the application will be able to authenticate with it.  So
it isn't a security measure at all.  At best, it could be a protocol
verification mesaure.

>   The receiver would send
> a random integer challenge to the sender.  The sender would
> encrypt the challenge and return it.  The receiver would also
> encrypt the challenge integer and compare it with what the
> sender returned.  If they compare the connection would be
> allowed to continue.

Is the sender a machine you control, or the receiver?  If the receiver
is not a machine you control, then anyone can authenticate the sender
and talk with it.

There are trivial "man-in-the-middle" attacks (a foe could let the
authentication occur, and then hijack each side of the connection to
send arbitrary messages to each side.)  Also, a malicious "receiver", in
this case, could connect with a sender and send arbitrary plaintext, and
get the resulting ciphertext.  Using this information, they could try
"replay" attacks with another valid receiver, or even try to retrieve
the cipher key by attacking the cipher directly.

> The Python supplied encryption module is 'rotor', which I 
> propose to use for encrypting the challenge.  This mechanism 
> will have to work across all platforms on which Python runs.

Rotor is probably not a good choice if you want a high-level of
security.  While it is most probably more secure than the "Enigma"
systems it was based upon, it is still based upon a system that was
cracked almost BEFORE computers were around.  A determined foe, with
enough data and statistical analysis, may be able to recover the private
keys.  At least, I know of no analysis of python's rotor that says this
is NOT likely to happen with current cipher-cracking techniques.  You
want at least 3DES, if you need a "trusted" encryption cipher.

> Is this a reasonable approach to authentication?

It all depends on how much much security you need.  I would characterize
the above approach as very insecure (disregarding that you don't seem to
care about encrypting the data stream itself, and just want
authentication), because the authentication doesn't happen per
connection, or per user, or even (perhaps) per installation, and once
authenticated, you don't necessarily STAY authenticated (ie. connection
hijacking can occur).

SSL was suggested, which may be the easiest to use method under the
circumstances.  There is also the Python cryptography toolkit.

http://pypgsql.sourceforge.net/misc/python-ssl.html
http://www.amk.ca/python/code/crypto.html

-- 
Bay Area Python Interest Group - http://www.baypiggies.net/

Chad Netzer
(any opinion expressed is my own and not NASA's or my employer's)