Re: [Cfrg] Discuss/standardize Preview extension to AEAD abstraction?

[Alex Elsayed <[e-mail]>]

On Fri, 26 Feb 2016 11:39:57 -0500, Bryan Ford wrote:

> Hi Alex,
> 
> On Feb 19, 2016, at 2:20 AM, Alex Elsayed <[e-mail]> wrote:
<snip>
>> However, this does leave some options regarding length-hiding on the
>> table.
>> 
>> For one, given an AEAD based on the encode-then-encipher paradigm with
>> variable \tau, one can increase the length of the verifier arbitrarily.
>> This permits essentially padding each message to any extended length
>> and gaining that length as additional integrity protection.
> 
> I’m not sure I follow the details of this suggestion - but definitely
> agree that in general that there are several reasonable approaches to
> length-hiding, with or without the APEAD property.

Basically, for encode-than-encipher MRAE (such as AEZ), encryption works 
in two stages - encode (in AEZ, padding with a 1 bit followed by 0 bits) 
and encipher (actually running AEZ/AEZ-tiny on the encoded plaintext).

The cool part is that, due to MRAE's property of depending on every bit 
of the input, one can exploit any structure in the plaintext to increase 
the effective bits of integrity protection - including the structure of 
the padding.

As a result, every extraneous bit of padding used beyond the necessary 
is, in effect, an additional bit of MAC, with *no upper limit* - 
permitting length-hiding-by-padding that has the beneficial side effect 
of increasing integrity protection.