Re: [kitten] History of AES block size issues

Luke Howard <lukeh@padl.com> Wed, 14 August 2013 23:55 UTC

Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Luke Howard <lukeh@padl.com>
In-Reply-To: <tslsiybaldd.fsf@mit.edu>
Date: Thu, 15 Aug 2013 09:55:17 +1000
Content-Transfer-Encoding: quoted-printable
Message-Id: <970B41DA-0AE6-4CC8-9DAB-A4049D8F0A44@padl.com>
References: <tslk3jodwgc.fsf@mit.edu> <5674376E76F88641AD3748A64F0996971AAB7DDE@TK5EX14MBXC285.redmond.corp.microsoft.com> <tslsiybaldd.fsf@mit.edu>
To: Sam Hartman <hartmans-ietf@mit.edu>
Cc: "kitten@ietf.org" <kitten@ietf.org>, Michiko Short <michikos@microsoft.com>
Subject: Re: [kitten] History of AES block size issues
Precedence: list

> If I send you a 9-octet message it's actually 16.
> If I send you a 16-octet message it's still 16 octets.

Is it not 24 octets?

> Greg, am I right that if your application aligns to a block size then
> you'll actually end up expanding more so you can indicate no padding is
> needed?
> If so will DCE RPC be OK with that?

I believe it's fine for the reasons I mentioned in my last mail:

Note "trailer" here means DCE RPC auth trailer, containing the RFC 4121 "header" (which has the EC and checksum rotated into a single token)

* DCE RPC always pads at the application layer, if this it to at least 16 bytes then we will have a constant length trailer (we need to investigate this)

* Even if DCE RPC doesn't pad at the application layer to 16 bytes, [MS-RPCE] allows the trailer to be over-allocated, so as long as it's big enough for the largest value of EC, variable length trailers are OK

-- Luke

[kitten] History of AES block size issues Sam Hartman
Re: [kitten] History of AES block size issues Michiko Short
Re: [kitten] History of AES block size issues Sam Hartman
Re: [kitten] History of AES block size issues Luke Howard
Re: [kitten] History of AES block size issues Sam Hartman
Re: [kitten] History of AES block size issues Tom Yu