Re: [Cfrg] new authenticated encryption draft

[David McGrew <[e-mail]>]

Hi John,

On Aug 22, 2006, at 7:05 PM, John Wilkinson wrote:
>
> David, while I've only briefly skimmed your draft, Hal and Gregg's
> comments make me wonder about the way you're treating IVs in your
> specification.

I've heard from others that the motivation for why IVs are handled in  
the document is not clear.  Thanks for your comments; I clearly have  
more explaining to do :-)

> Why do you feel that IVs must be an _output_ of the
> encryption algorithm, rather than a purely internal value?

There is a rationale given in Section 2, but I'll try to amplify it -  
here's a rewrite of that part.  Please let me know what you think.

<new>
Rationale.  Proper IV generation is a crucial for security, and the  
requirements on how IVs are generated are different for different  
algorithms.  By making the IV an output of the AEAD algorithm rather  
than an input, the IV is put under the control of that algorithm.   
This use of the 'information hiding' design principle frees the user  
from needing to understand the particulars of IV generation, thus  
making the interface easier to use correctly.  Also, because IV  
generation is a security-critical operation, it makes sense to  
include it with the algorithm, which will typically be implemented in  
a crypto module.  Including IV generation in this module makes it  
more self-contained and easier to test and to validate.

Several security issues have arisen due to improper use of block  
cipher modes of operation.  Several standards have suggested  
incorrect uses of cipher block chaining (CBC) encryption (e.g. using  
a previous ciphertext block as an IV, which allows an adversary to  
predict the IV).  Modes that require distinct IVs, such as counter  
mode, are especially sensitive to misuse of IVs, which can void the  
security services that they provide.  Giving the AEAD algorithm the  
responsibility for generating its own IV helps to avoid these  
security issues.
</new>

> Further,
> what, exactly, do you mean by the requirement that "A deterministic
> AEAD encryption algorithm MUST accept an additional input, and that
> value [the IV contribution] MUST be included _verbatim_ [emphasis
> added] in the IV."

Several crypto algorithms, including CCM and GCM as used in ESP, form  
their IVs by prepending a value that is fixed (for the lifetime of  
the key) to a sequence number that increments once per packet.  The  
IV contribution is needed in order to support these algorithms, and  
it is needed in order to allow CTR-based modes (like CCM, GCM, and  
EAX) to be useable in a situation in which there are multiple devices  
doing encryption with a single key.  The IV contribution provides a  
place within which each encryptor can put a distinct value, to ensure  
that the IVs are distinct over all uses of that key.

>
> It seems to me that it would be a better abstraction of the AEAD
> mechanism if the IV is used purely internally to the algorithm, so
> that the only input required is a nonce, and that the same nonce is
> used for encryption and decryption.

Here we've gotten stuck on the terminological thicket.  What you're  
calling a nonce is what the draft calls an IV.  I should add  
definitions I guess.

> Furthermore, the requirement that
> the "IV contribution" must be used "verbatim" in the IV could be read
> to exclude, for example, Bellare, Rogaway, and Wagner's EAX mode. EAX
> uses a user-supplied nonce, which may be of any length, and computes a
> MAC on this nonce to generate the initial counter for counter-mode
> encryption.
>

The GCM mode of operation has the same property (it will accept an IV  
of any length, though it is optimized to handle 96-bit IVs).   
However, there does not seem to be any significant use for this  
facility in practice, so I decided to use a simpler and more  
consistent interface for the AEAD algorithms.  EAX could certainly be  
added, but obviously we'd need to mandate a particular IV format.

David

_______________________________________________
Cfrg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/cfrg