[955] in Kerberos_V5_Development
Re: 3-DES string-to-key algorithm
daemon@ATHENA.MIT.EDU (Richard Basch)
Thu Nov 30 22:29:17 1995
Date: Thu, 30 Nov 1995 22:13:45 -0500
To: "Theodore Ts'o" <tytso@MIT.EDU>
Cc: "Richard Basch" <basch@lehman.com>,
Bill Sommerfeld <sommerfeld@orchard.medford.ma.us>,
Mark Eichin <eichin@cygnus.com>, cvs-krb5@MIT.EDU, krbdev@MIT.EDU
In-Reply-To: <9512010120.AA14269@dcl.MIT.EDU>
From: "Richard Basch" <basch@lehman.com>
On Thu, 30-November-1995, "Theodore Ts'o" wrote to "Richard Basch, Bill Sommerfeld, Mark Eichin, cvs-krb5@MIT.EDU, krbdev@MIT.EDU" saying:
> Date: Wed, 29 Nov 1995 23:01:23 -0500
> From: "Richard Basch" <basch@lehman.com>
>
> Here is an interesting one... the specification for regular DES
> string-to-key calls for checking the key to see if it is a (semi)weak
> key, and XOR the key with 0xF0, if it is. The implementation does not
> do this. I fixed the 3-DES case.
>
> Ted, I wanted you to decide whether we fix the 1-DES case. Since it is
> statistically improbable that this is being hit, it is probably better
> to fix it. Not fixing it will allow the potential compromise of the key
> and the data the key is trying to protect.
>
> My proposal would be that we fix it only for the Kerberos V5
> string-to-key algorithm; in other words, in the string-to-key algorithm,
> only do the check and potential XOR if the salt string is non-zero. The
> chances of our actually hitting a weak or semi-weak key is 1 in 2**52,
> which is relatively low in any case.
>
> By only mandating it for V5-style string-to-keys, it means that people
> who are converting over from V4 wouldn't be affected ---- there's only a
> n in 2*52 chance (where n is the number of users) that a site who is
> using V5 kerberos in production would actually be affected by this
> change. Since there are still many more people using V4 over V5 (at
> least for now), that seems to be the right tradeoff.
>
> In addition, it would be pretty simple to write a program that scanned
> through an existing V5 database (or DCE security server database),
> looking for users with weak keys and identify them to the system
> administrator as part of the upgrade process.
>
> Obviously, this would be a change the krb5 spec, so we'd need to run it
> by the kerberos mailing list and ask for opinions. But I suspect that
> most people wouldn't object.
>
> Comments?
Actually, it isn't a change in the spec. In rfc1510, section 6.3, the
string-to-key algorithm is defined to check for weak/semi-weak keys and
do the XOR. So, the fix would be bringing the implementation in sync
with the published spec.
--
Richard Basch 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
