[1201] in Kerberos_V5_Development
Re: CVS report: src/lib/crypto ChangeLog cryptoconf.c des3_sha.c des_crc.c des_md5.c
daemon@ATHENA.MIT.EDU (Richard Basch)
Thu May 16 17:00:17 1996
Date: Thu, 16 May 1996 16:59:16 -0400
To: Marc Horowitz <marc@MIT.EDU>
Cc: "Richard Basch" <basch@lehman.com>, cvs-krb5@MIT.EDU, krbdev@MIT.EDU
In-Reply-To: <9605161931.AA16048@beeblebrox.MIT.EDU>
From: "Richard Basch" <basch@lehman.com>
On Thu, 16-May-1996, "Marc Horowitz" wrote to "Richard Basch, cvs-krb5@MIT.EDU, krbdev@MIT.EDU" saying:
> In message <199605161736.NAA28744@badger.lehman.com>, "Richard Basch" <basch@lehman.com> writes:
>
> >> Larger confounders don't hurt... and it helps when it comes to the SHA
> >> algorithm, so that there is less chance you will be able to do splicing
> >> or replays. For 3-DES CBC, 8 bytes was sufficient, and that was why I
> >> had originally chose that value. But for the SHA piece, 24 bytes probably
> >> improves the SHA digest that is encrypted within.
>
> Richard, you're playing amateur cryptographer again. Unfortunately,
> that's all I can do in response. Really, none of us should be making
> changes like this at all without consulting a Real Cryptographer.
You are correct... The main change was not to do the larger
confounder... I was merely using Schneir's text as a reference for this
change. We still need to discuss this to see what the proper confounder
size should be... remember -- that is one of the open issues...
However, the bulk of the change was to switch things over to using
des3-sha and making it so that I only have to change one #define to
affect the entire source file (this sure wasn't possible before). For
now, don't consider des3-sha a facility that should be used in
Kerberos... I still have to get the appropriate buy-in. I recognize
that I may not have covered all the bases, and I will be posting a query
to various cryptographers shortly.
> Larger confounders mean more overhard. 3des-sha with a 24-byte
> confounder (and a 20 byte checksum, padded) would mean 48 bytes of
> overhead per encryption. (That's almost a whole ATM frame! :-) This
> is way too much.
As though ASN.1 isn't enough overhead... 16 bytes is nothing by
comparison, if it makes any difference to the strength of the system
(which has yet to be determined). I was looking at it from two points
of view... the SHA and the DES3. Now, I have to confirm my suspicion.
> The checksum which is encrypted within is there to make sure that the
> encrypted block was not tampered. If you can splice or otherwise
> arrange to have differnet plaintext, then you're obviously able to
> deal with the encryption in real-time, in which case it's all over,
> anyway. Can you describe an attack which actually makes use of the
> shorter confounder? I think eight bytes is fine.
Now, who's playing amateur cryptographer?
--
Richard Basch
Sr. Developer/Analyst URL: http://web.mit.edu/basch/www/home.html
Lehman Brothers, Inc. Email: basch@lehman.com, basch@mit.edu
101 Hudson St., 33rd Floor Fax: +1-201-524-5828
Jersey City, NJ 07302-3988 Voice: +1-201-524-5049
