Subject: Re: [Ietf-krb-wg] CF2 test vectors for DES and 3DES

From: Sam Hartman <[email-masked]>
Date: Fri, 01 May 2009 04:43:06 -0400

>>>>> "Love" == Love Hörnquist Åstrand <[email-masked]> writes:

    Love> 30 apr 2009 kl. 13:31 skrev Sam Hartman:

    >> I suspec Heimdal does the same thing as MIT here because we
    >> seem to interoperate for PKINIT and this issue comes up there
    >> too.

    Love> I don't think most people use DES with PK-INIT.

    Love> In heimdal DES3 does what you describe (uses 3 * 8), DES
    Love> doesn't (uses 8 bytes).

I thought we had tested DES for pkinit--guess not.

So, if I'm understanding this correctly, unless one of us does
something special,then we will not interoperate for CF2 for DES
enctypes because of this issue, right?  If so, sounds like MIT should
be the one to change because we're the one not following the spec.

--Sam
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Tom Yu <[email-masked]>
Date: Fri, 01 May 2009 17:57:07 -0400

Sam Hartman <[email-masked]> writes:

> Folks, there seems to be yet another inconsistency between RFC 3961
> and MIT regarding DES and presumably 3DES random2key operations.
>
> MIT assumes that DES random bit strings are 7 byte strings that are
> expanded with parity bits.  The RFC 3961 spec assumes that you take an
> eight byte string and do parity fix-up.

Actually, spec assumes both.  RFC 3961 says des-cbc-md5 uses
des_random_to_key, but des-cbc-md4 and des-cbc-crc use
copy-8-bytes-and-fix-parity.  It does say that the key generation seed
length is 8 bytes for all three, which is inconsistent with the use of
des_random_to_key (which takes 56 bits as input).  I suspect a
copy-and-paste error.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Sam Hartman <[email-masked]>
Date: Mon, 04 May 2009 15:22:11 -0400

>>>>> "Tom" == Tom Yu <[email-masked]> writes:

    Tom> Sam Hartman <[email-masked]> writes:
    >> Folks, there seems to be yet another inconsistency between RFC
    >> 3961 and MIT regarding DES and presumably 3DES random2key
    >> operations.
    >> 
    >> MIT assumes that DES random bit strings are 7 byte strings that
    >> are expanded with parity bits.  The RFC 3961 spec assumes that
    >> you take an eight byte string and do parity fix-up.

    Tom> Actually, spec assumes both.  RFC 3961 says des-cbc-md5 uses
    Tom> des_random_to_key, but des-cbc-md4 and des-cbc-crc use
    Tom> copy-8-bytes-and-fix-parity.  It does say that the key
    Tom> generation seed length is 8 bytes for all three, which is
    Tom> inconsistent with the use of des_random_to_key (which takes
    Tom> 56 bits as input).  I suspect a copy-and-paste error.

OK, but the MIT code is still inconsistent with the spec.
We seem to do the same for all the DES enctypes.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Tom Yu <[email-masked]>
Date: Mon, 04 May 2009 18:26:37 -0400

> We seem to do the same for all the DES enctypes.

RFC 3961 section 6.2:

   For generation of a key from a random bitstring, we start with a 56-
   bit string and, as with the string-to-key operation above, insert
   parity bits.  If the result is a weak or semi-weak key, we modify it
   by eXclusive-OR with the constant 0x00000000000000F0:

        des_random_to_key(bitstring) {
             return key_correction(add_parity_bits(bitstring));
        }

I think it is fairly clear that the intent was to use
des_random_to_key as the random-to-key function for all single-DES
enctypes, and the tables defining the individual single-DES enctypes
were not updated to be consistent with that intent.  This is also
consistent with the use of this operation as a component of the
single-DES string_to_key function.

Ken, do you remember the intent of this section?
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg