Re: Checksum (Re: KINK issue list)

On Jan 27, 2005, at 19:07, KAMADA Ken'ichi wrote:
> 1) omit the checksum field (splicing the header and payloads directly),
> 2) zero out the Length and CksumLen fields because we can't know
>    those lengthes in advance.
>
> My consern/questions are
> - 2) makes me nervous because I don't know whether it makes some
>   kinds of attacks easy (e.g. adding junk data at the end of payloads
>   in order to collide the checksum).

How about including length-without-checksum in the calculation of the 
checksum, instead of a zero?

> - Will required-to-implement checksums never change in the future?

I believe that's the case.

The required-to-implement field was intended to deal with the lack of 
checksum negotiation in Kerberos.  We assert that if you know 
encryption type X is supported, then you know that checksum type Y is 
also supported, and thus you're free to use it.  If we go back and 
change it, we'd be retroactively changing the implementation 
requirements of code (theoretically) already deployed.

It might not hurt to include the checksum type anyways.

> - Thinking about 1), placing the checksum at the end of the packet
>   is more reasonable?

It might be, yes.

> BTW, is a statement like "KINK does not support encryption types with
> such variable length checksums" reasonable in the sense of Kerberos?

I would lean towards "no", because it makes things more complex and 
treats Kerberos as less of a black box.  I suppose it's possible, but 
in my opinion should be avoided.

> Is there any such checksums at this moment?

None outside my imagination.  I could write one up if you like. :-)

This one would be easy enough:
   confounder = random 128-bit block
   h = HMAC-SHA512(confounder | key-usage | msg, key)
   len = random multiple of 8 between 128 and 512
   checksum = confounder | h[1..len]

It's non-deterministic, and the length varies from 256 to 640 bits.  
I'd have to check, but offhand I think it would comply with the 
Kerberos checksum requirements.

Ken