Re: Checksum (Re: KINK issue list)

Thank you for your comments.

At Thu, 27 Jan 2005 10:34:03 -0500,
Ken Raeburn <[email protected]> wrote:
> 
> On Jan 27, 2005, at 03:16, KAMADA Ken'ichi wrote:
> > My main concern with this proposal is whether all future etypes
> > will be based on simplified profile (have HMAC, I mean) or not.
> 
> I think it's safe to say that eventually we will see new encryption 
> types that do not use the simplified profile.  We may also see some 
> that do, of course.  But with the variety of authenticated-encryption 
> modes being produced and analyzed, it would make sense for us to stop 
> constructing our own.  So I'd expect some future cryptosystem to be 
> based on EAX, CCM, or some other such mode.
> 
> In order for KINK to not require updates for these future 
> cryptosystems, you'd need to be able to say now how to determine what 
> kind of checksum is to be used.

I agree.

> The only tricky issue in dealing with the required-to-implement 
> checksum type should be the lack of a fixed size output.  Is it that 
> hard to work around?  (Maybe omit the checksum field when computing the 
> checksum?)

I think it's not so hard in itself.  When computing the checksum,
we will need to
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).
- Will required-to-implement checksums never change in the future?
- Thinking about 1), placing the checksum at the end of the packet
  is more reasonable?


BTW, is a statement like "KINK does not support encryption types with
such variable length checksums" reasonable in the sense of Kerberos?
Is there any such checksums at this moment?

-- 
KAMADA Ken'ichi <[email protected]>