Checksum (Re: KINK issue list)
"KAMADA Ken'ichi" <[email protected]> Thu, 27 Jan 2005 17:16:45 +0900
| Newsgroups | gmane.ietf.kink |
|---|---|
| Message-ID | <20050127171645FM%[email protected]> |
At Thu, 20 Jan 2005 11:04:48 +0900, "KAMADA Ken'ichi" <[email protected]> wrote: > > [**] etype does not directly indicate checksum type (section 5) > > a key's encryption type does not directly indicate > a checksum type, it indicates an encryption(-with-integrity-protection) > scheme, which does include a required-to-implement checksum type > (Ken Raeburn) > > [**] Kerberos allows variable length checksum (section 5) > > I'd have to go back and check, but I don't think we require that > a given checksum type have a fixed output size, so "leave X amount of > space and fill it with zero for computing the checksum" is questionable > too. (Ken Raeburn) > > [*] Kerberos checksum is not deterministic (section 5) With regard to these three issues, I'd propose using HMAC as a KINK checksum. According to kcrypto, each etype based on simplified profile and etype based on 3DES has a HMAC as its attribute. Let's use it as is. DES-based etypes (des-cbc-md5, des-cbc-md4, and des-cbc-crc) have no HMAC associated with them, so use HMAC-MD5. My main concern with this proposal is whether all future etypes will be based on simplified profile (have HMAC, I mean) or not. -- KAMADA Ken'ichi <[email protected]>