Re: [Cfrg] Streaming AEAD

["Manger, James" <[e-mail]>]

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