[prev in list] [next in list] [prev in thread] [next in thread] 

List:       bugtraq
Subject:    IMPORTANT: deslogin fixkit weakness
From:       *Hobbit* <hobbit () avian ! org>
Date:       1995-12-04 16:05:46
[Download RAW message or body]

[If you are reading this and didn't get it via bugtraq, you are on a
scatter-shot list assembled from various sources including old FTP
transfer records and my own personal knowledge of who had been playing
with deslogin.  This mailing is necessarily overbroad and will undoubtedly
generate several errors and misdirected messages, so if you have no idea
what I'm talking about herein then simply ignore this.]

                IMPORTANT       IMPORTANT       IMPORTANT
                ---------       ---------       ---------
While recently looking through "deslogin" in search of something completely
unrelated, it suddenly hit me that I had MAJORLY fucked up in my fixkit for
it.  This is an excerpt from the tentative doc for the next kit, if I even
bother doing one.  If you are using my "dl133" fixkit, STOP USING IT
IMMEDIATELY and at the very least switch back to the original.  It might make
more sense for you to switch to something stronger like SSH anyway.

Version 1.2 of this so-called fixkit changed the challenge/response protcol
and in so doing, introduced a weakness that effectively sends the session key
over the network.  The ORIGINAL protocol is as follows, where (E) is an
encryption using the user's secret key and (D) is a decryption:

        time & PID --> (E) --> challenge "plaintext", or P
        P --> (E) --> challenge, which is sent to the incoming client
        challenge --> (E) --> session key

The client receives the challenge, and does

        challenge --> (D) --> P, which is the response sent back to the daemon
        challenge --> (E) --> session key

The daemon checks that its notion of P matches the client's notion of P to
authenticate the connection, and both sides enter encrypted mode using the
mutual session key.

I naively thought that sending the challenge and then the direct decryption of
the challenge was a bad idea, and changed the protocol to do

        time & PID --> (E) --> plaintext, or P1
        P1 --> (E) --> challenge, sent to the client
        P1 --> end-bytes-flip --> permuted plaintext, or P2
        client response --> (D) --> compared against P2
        P2 --> (E) --> session key

The client would then do

        challenge --> (D) --> P1
        P1 --> end-bytes-flip --> P2
        P2 --> (E) --> response, sent back to the daemon
        P2 --> (E) --> session key

Note that the client just sent the *raw session key* back as the response!!!

While the original protocol still sends ciphertext and then its plaintext
across the wire, it is obviously much stronger than my scheme.  At the time
I hatched the replacement scheme I did not look deep enough into the guts
to realize that the sessionKey() routine was doing one more (E) of the
challenge to derive "keybits" for the session key [the last step in both
sides of the protocol].  I can only hope that the "dl133" fixkit did NOT get
wide distribution, and that anyone currently using it reads this and promptly
builds a new version using the original auth.c from Dave's distribution.

It is very easy to screw up when dealing with cryptographic protocols, and
this is yet one more example of someone who's learned the hard way.  Oops!!

_H*

[prev in list] [next in list] [prev in thread] [next in thread]