Re: [Cfrg] Streaming AEAD

[David Jacobson <[e-mail]>]

On 2/25/14 7:52 AM, David McGrew wrote:
> Hi James,
>
> On 02/23/2014 09:15 AM, David McGrew wrote:
>> Hi James,
>>
>> On 02/18/2014 10:59 PM, Manger, James 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!]
>>
>
> A thought occurred to me.   Currently, many systems use an 
> init/update/final interface for AEAD decryption.  The streaming AEAD 
> algorithm that you propose would not enable them to continue using 
> this interface as they currently are.   The problem is that the 
> decryptUpdate function is required to provide plaintext when it 
> returns; at least this is the case in some libraries.  If 
> decryptUpdate is not required to provide plaintext when it returns, 
> then the implementation could just buffer the (pre-auth-verification) 
> plaintext until the auth verification is done.
>
> David
[snip]

It is simpler than that.  The decryptUpdate just blocks until it has 
gotten to a verification tag.  If the length parameter to the 
decryptUpdate is less than the plaintext up to the auth tag, it delivers 
the requested amount of plaintext, and buffers the remainder, which can, 
of course, be immediately returned on the next call.

Now like many protocols with chunking, there is the possibility of 
deadlock if such protocols are used interactively. That is something to 
think about.

    --David Jacobson