Re: [kitten] History of AES block size issues

[Sam Hartman <[e-mail]>]

>>>>> "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.