Re: [Cfrg] IVs in the "authenticated encryption" draft

David McGrew  wrote:
>if you've read the draft, I'd be interested to hear your thoughts on  
>the use of IVs in that document.  Currently, the IV is an *output* of  
>the encryption process, rather than an input to it.  This property  
>puts IV generation into the crypto process, which simplifies the  
>interface for most users and eliminates the risk of security problems  
>due to inappropriate IV generation by the user.   However, this  
>property adds some complexity; in order to support the use of  
>deterministic IVs when a single key is used by multiple encryptors,  
>it was necessary to add an "IV" contribution field.
>
>I very much like the idea of having an interface that is harder to  
>misuse, but I'm now wondering if that goal is "one too many" for the  
>current draft.  Perhaps it would be better to allow the IVs to be  
>inputs, as is more conventional, which would allow this draft to get  
>finished more quickly, and then to consider a user-proof interface in  
>some separate future work, if that would be useful.  I've heard  
>comments on both sides of this issue, and I'd like to gauge the  
>general feeling of the group, so I'd value your opinion.

Have you considered factoring this out into two draft documents?

  Document #1: Documents AEAD modes that take an IV as input.

  Document #2: Documents IV generation processes that take an IV
  contribution as input and produce an IV as output.

This seems like a third option you could consider.  Would it be a
better compromise?  This way, folks could mix-and-match: if they want
or have an AEAD mode that takes an IV as input, they can use
Document #1 for guidance; if they have or want an AEAD mode that
takes an IV contribution as input and produces an IV as output, they
can use the composition of Documents #1 and #2 for guidance.

_______________________________________________
Cfrg mailing list
Cfrg@ietf.org
https://www1.ietf.org/mailman/listinfo/cfrg