Re: [kitten] History of AES block size issues

[Tom Yu <[e-mail]>]

Sam Hartman <[e-mail]> writes:

>>>>>> "Luke" == Luke Howard <[e-mail]> writes:
>
>     >> 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.
>
>     Luke> Is it not 24 octets?
>
> Ah, that depends if you are talking RFC 3961 or RFC 1964.
> Under 3961 I think 16; under 1964 I think 24.
>
>     >> 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?
>
>     Luke> I believe it's fine for the reasons I mentioned in my last
>     Luke> mail:
>
>     Luke> Note "trailer" here means DCE RPC auth trailer, containing the
>     Luke> RFC 4121 "header" (which has the EC and checksum rotated into
>     Luke> a single token)
>
>     Luke> * DCE RPC always pads at the application layer, if this it to
>     Luke> at least 16 bytes then we will have a constant length trailer
>     Luke> (we need to investigate this)
>
> Yeah, although in the obvious implementation we'll have 16 octets of pad
> buffer.
>
> so you might have to modify DCE RPC to deal with that if it doesn't
> already, but I guess that's not a problem if you control both your DCE
> RPC and your GSS.

My interpretation of C706 and MS-RPCE is that it won't be a problem at
a MS-RPC protocol level (except for possibly transmitting
overallocated padding).  Applications that roll their own MS-RPC
implementation rather than using a library might be in trouble,
though.  Applications that can query for the padding and block size,
and pad at the application layer to 16 bytes, can probably get away
with assuming a constant size trailer without overallocating.

I don't have detailed citations for the above at this time, but I
could probably write them up if people feel that it's necessary.