Subject: Re: comments on draft-ietf-krb-wg-crypto-02.txt

From: Ken Raeburn <[email-masked]>
Date: Mon, 17 Feb 2003 23:02:25 -0500

Back in November, I wrote, in response to Assar:

>>> 5.3.1. Triple DES Key Production (random-to-key, string-to-key)
>>
>>>    No weak-key checking is performed.
>>
>> Why is this?
>
> "Because."
>
> That's the way the triple-DES support was defined.  And I think I
> mentioned in the security considerations section, it doesn't seem like
> a real weakness.

I've just been looking at the MIT and Heimdal code in this area.

The MIT des3 string-to-key does no weak key checking or correction.
However, if any of the three keys is weak, encryption will not work.
Since that should be kind of obvious, I think it's safe to assume that
no one using the MIT code has such a key.  (Or if they do, they've
been unable to use it.)

The Heimdal (0.5) des3 string-to-key does do the weak key checking and
correction.  So it is possible that Heimdal installations have users
with keys generated this way, and changing it could possibly break
them.  (The likelihood is very small -- we're talking about 16 keys
out of 2**56 for each DES key, roughly a 3 in 2**52 chance of any
given triple-DES key containing a weak or semi-weak DES key.)

So, I'm thinking about adding the weak key check to the specification.
Does anyone have triple-DES implemented without any of these checks?
Or any strong objection to adding this?

Between CBC mode and the confounder, I still don't think the weak keys
are anything for us to worry about, even for single-DES.  I'm aware of
the E1(E2(P))=P issue, and CBC + confounder should eliminate that
route.  If there's another cryptographic attack against these keys
that's still effective when CBC mode and a confounder (or random IV)
are used, I'd be interested in hearing about it.

>>>    sha1 (unkeyed)                 14               20
>>
>> 10 seems to also have been used for this
>
> Interesting.  By whom?

Assar, do you have any reference for this?

Any references for the other reserved-but-not-defined values would be
helpful too.

Encryption types:

     [reserved]                       4
     [reserved]                       6
     des3-cbc-sha1                    7   (<== *not* the key
                                           derivation one)

Checksum types:

     rsa-md5-des3                     9
     sha1 (unkeyed)                  10  (Assar?  anyone?)
     hmac-sha1-des3                  13  (<== again, not key deriv)
     sha1 (unkeyed)                  14

Ken