Re: [Cfrg] Streaming AEAD

[Mridul Nandi <[e-mail]>]

Dear ALL,

When we have limited buffer or we need to release the computation of
message and ciphertext in a regular interval, we can go for AEAD which
supports intermediate tag.  You may have a look on section 6 of our paper
http://eprint.iacr.org/2013/767.pdf
which talks about intermediate tag. Computation of intermediate tag in our
construction is very less.


Thanks and regards,
Mridul Nandi
 Assistant Professor
Indian Statistical Institute
Kolkata



On Wed, Feb 19, 2014 at 9:29 AM, Manger, James <
[e-mail]> wrote:

> > >> What is needed is a way to use an AEAD algorithm to secure a message
> in
> > >> chunks. Streaming-AEAD would allow a recipient to know they have
> received an
> > >> authentic prefix of a message. It would allow crypto APIs to support
> > >> streaming modes while never returning unauthentic plaintext.
>
> > > I think the means of doing this is going to be protocol-specific,
> since it
> > > depends on the PDU format being used.
>
> Not necessarily.
> I was thinking we could define a new alg identifier such as
> "AEAD_AES_128_OCB_TAGLEN96/10K", meaning OCB on 10 KB chunks.
> Once the 10228th byte (10KB - 96 bits) of plaintext is streamed
> to the encrypt function, it finishes the first AEAD operation and
> inserts a 96-bit tag into the ciphertext. A decryption function
> caches the ciphertext it is streamed until it reaches a 10KB
> boundary then it returns 10228 bytes of plaintext.
>
> An app sees a different alg id, but doesn't need to notice that
> the ciphertext PDU is actually ct tag ct tag ct tag...
> [It might need to know which nonces have been used internally though!]
>
>
> > I think that's right.   It still makes sense to consider what should be
> > going on above the AEAD layer, in a generic sense.
> >
> > > For things like SSL/TLS and SSH the
> > > problem is already solved since data amounts are quantised to the
> > protocol
> > > data packet size,
> >
> > I hope that's right.   I am not sure that SSL/TLS implementers would be
> > comfortable if they could never use the decryptUpdate function though.
> >
> > > for store-and-forward protocols like PGP and S/MIME you'd
> > > need to add a mechanism for it in a PGP/SMIME-specific manner, but
> > then you'd
> > > also need to figure out how to communicate it to the other side...
> > and then
> > > you're back to relying on ad-hoc mechanisms.
> > >
> > > When I had to do this years ago I used something like:
> > >
> > > len1 || data1 || h1 = HMAC( len1 || data1 ),
> > > len2 || data2 || h2 = HMAC( h1 || len2 || data2 ),
> > > len3 || data3 || h3 = HMAC( h2 || len3 || data3 ),
> > > ...
> > >
> > > A length of 0 indicated end-of-contents.
> >
> > Interesting, is there a writeup?
>
>
> So for packetizing plaintext for ~AEAD chunks:
> * TLS puts a sequence number in the AAD;
> * Peter (sort of) puts a tag for the previous prefix in the AAD;
> * I suggested using sequential nonces and a start/middle/end flag;
> * AERO hides the details in state;
> * Pipelineable On-Line Encryption randomizes unauthentic plaintext.
>
>
> My only concern with putting state (eg sequence number, byte count,
> previous hash) into AAD is that you need something at a higher layer to
> ensure that AEAD(X||Y,P) is always interpreted as "chunk mode with state=X,
> user-provided-AAD=Y", and never as "non-chunk mode with
> user-provided-AAD=X||Y". You probably cannot safely use 1 key in chunk and
> non-chunk modes.
>
> --
> James Manger
> _______________________________________________
> Cfrg mailing list
> [e-mail]
> http://www.irtf.org/mailman/listinfo/cfrg
>