[1239] in Kerberos_V5_Development
Re: [lots of stuff]
daemon@ATHENA.MIT.EDU (Sam Hartman)
Sat May 25 01:38:02 1996
To: Marc Horowitz <marc@MIT.EDU>
Cc: krbdev@MIT.EDU
From: Sam Hartman <hartmans@MIT.EDU>
Date: 25 May 1996 01:37:51 -0400
In-Reply-To: Marc Horowitz's message of Fri, 24 May 1996 23:19:38 EDT
>>>>> "Marc" == Marc Horowitz <marc@MIT.EDU> writes:
>>>> Sam says:
>>> <stuff about cryptosystem and checksum compatibility>
Marc> This same argument applies to cryptosystem and salt
Marc> compatibility. This code appears in several places right
Marc> now:
Marc> switch (ktype) { case ENCTYPE_DES_CBC_MD4: case
Marc> ENCTYPE_DES_CBC_MD5: case ENCTYPE_DES_CBC_RAW: ktype =
Marc> ENCTYPE_DES_CBC_CRC; break; default: break; }
Marc> This is a crock. I believe that the encryption types (and
Marc> probably the salt types, too) should have an associated key
Marc> type. This key type never traverses the net, so it's only
Marc> an implementation aid. This allows code which needs to do
Marc> stuff which is based on the key *only* to check for
Marc> compatibility directly, instead of having lists like the one
Marc> above. In the example of checksums, the code would simply
Marc> compare the key types associated with the enctype and the
Marc> cksum, and if they were different, return an error.
First, after to talking to Marc I've become convinced that
this is complex enough that trying to do something before Beta6 would
be premature.
I agree that some mechanism needs to exist to centrally
determine if checksums and salts are appropriate for a particular
enctype. This was only part of the problem I was trying to solve, but
it certainly is a problem.
