Re: Checksum

kamada-san,

Sorry, this is not a comment for your mail.
However, could you please assign serial number or something identity
to every issue? It helps discussions.

From: "KAMADA Ken'ichi" <[email protected]>
Subject: Checksum (Re: KINK issue list)
Date: Thu, 27 Jan 2005 17:16:45 +0900

> 
> 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.

----- nobuo