Subject: RE: GSSAPI/AES draft

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Thu, 21 Aug 2003 01:16:54 -0700

Nicolas Williams wrote:

>> I.e., section 6.2, second paragraph, second sentence should say

>> {"header" | encrypt("header" | [EC padding] | plaintext-data)}

>> rather than

>> {"header" | encrypt(plaintext-data | "header")}.

Great idea! EC is always 0 for AES of course; this seems to be the best
solution without changing kcrypto.

Larry

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Nicolas
Williams
Sent: Wednesday, August 20, 2003 11:29 AM
To: [email-masked]
Subject: Re: GSSAPI/AES draft

On Wed, Aug 20, 2003 at 09:34:34AM -0400, Sam Hartman wrote:
> I'm not convinced the current draft handles block cipher alignment in
> the general case, but I believe I have personal mail discussing that
> issue.

My interpretation is that the cipher block sizes, or rather, scatter/
gather crypto interface alignment requirements/preferences (where there
are any) would be internally visible to mech implementations of
GSS_Get_MIC() and GSS_Wrap() that use such interfaces.

Implementations of GSS_Verify_MIC() and GSS_Unwrap() would not be
affected, of course, except in so far as they should ignore the EC pad
bytes.

But I'm starting to think that the header shouldn't float on the end of
the app data, but that the app data should float on the end of the
header.  That's so that the EC field can be integrity verified before
running into the EC padding octets.

I.e., section 6.2, second paragraph, second sentence should say

{"header" | encrypt("header" | [EC padding] | plaintext-data)}

rather than

{"header" | encrypt(plaintext-data | "header")}.

Cheers,

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 21 Aug 2003 06:45:41 -0700

> solution without changing kcrypto.

If you're concerned about wasting space with that EC field then maybe we
should have it be optional with a one-bit flag to indicate its
present/absence.  We're dedicating a whole byte to mech token flags
(direction, seal).  Why not treat have a flag field instead which tells
you direction, seal (for wrap tokens) and whether there's an EC field
present?

Nico
--