[Cfrg] Re: Comments on SIV and draft-dharkins-siv-aes-00

["Dan Harkins" <[e-mail]>]

  Hi David,

On Tue, October 23, 2007 2:53 pm, mcgrew wrote:
> Hi Dan,
>
> On 10/19/07 1:23 PM, "Dan Harkins" <[e-mail]> wrote:
>
>>
>>   Hi David,
>>
>> On Thu, October 18, 2007 1:41 pm, mcgrew wrote:
[snip]
>>> First, what's the motivation for key wrapping?   This is an important
>>> question that a lot of people have wrestled with.  I understand from
>>> Section
>>> 1.3.1 that nonceless AEAD is valuable because there are existing
>>> protocols
>>> that do not make use of nonces, so SIV's capability for nonceless AEAD
>>> enables it to be easily adopted by these protocols.   This is a very
>>> good
>>> point.  Nonetheless, it does not address the question of "when should a
>>> user
>>> use nonceless AEAD?" outside of those "legacy" cases.   I would expect
>>> that
>>> we would want to provide guidance that users SHOULD use nonces wherever
>>> possible, but MAY otherwise do without nonces.  (Perhaps there should
>>> be
>>> an
>>> exception for cases in which determinism is essential, e.g. database
>>> applications in which plaintext-to-ciphertext mapping must be
>>> deterministic.
>>> But this is clearly a special case.)
>>
>>   I think the motivation is to provide deterministic authenticated
>> encryption for specialized data, such as cryptographic keys. The
>> American
>> Standards Committee Working Group X9F1 has come up with a draft standard
>> for such a problem. S/MIME has RFCs on that problem. I do mention that
>> in
>> the draft.
>>
>>   I'm a little reluctant to jump into that brier patch though. [DAE]
>> does
>> a very nice treatment of the reasons behind, and requirements for, key
>> wrapping both informally (in the introduction) and formally (in appendix
>> C). I will try to address your comment by pointing readers to [DAE] and
>> X9F1. Would that be acceptable?
>
> Seems to me that normative guidance on when nonces are/aren't needed
> should
> be in the document, since it significantly affects security.  I propose at
> least something like this:

  Suggested text is always welcome :-)

> <quote>
> Applications SHOULD include a nonce in the associated data.  This nonce
> must
> either be generated uniformly at random and be at least as long as the
> key,
> or each nonce value must be distinct for each distinct invocation of the
> SIV
> encrypt function.  Applications MAY do without a nonce in the associated
> data if the plaintext contains data that is unpredictable to an adversary,
> i.e. a secret key.
> </quote>
>
> Details are up to debate, but I *think* that most people who care would
> agree with that guidance.

  The attractive thing about SIV is that nonces need not be random or
distinct for each distinct invocation of the SIV encrypt function. SIV
provides resistance to nonce reuse. While this guidance is appropriate
for cipher modes like GCM or CCM it is overly restrictive for SIV.

  I like the rest of the suggested text (thank you!).

  Does anyone else have an opinion on the topic of nonce reuse and SIV?

> My concern here isn't specific to SIV at all - my concern is that, if we
> define specifications of keywrap algorithms and recommend their use, that
> we
> be very clear where and how we expect for them to be used.

  That's the brier patch I don't want to jump into. The I-D is about SIV
and not a generic treatment of the keywrap problem. I have no problem
explaining when a nonce is not needed in the associated data with SIV
(and your text above will help) but I don't want to deal with the general
case of keywrapping in a I-D about SIV.

> Off topic: OK, now that I have noticed and read Appendix F of [DAE], I
> think
> that it might be a good idea to use that appendix as a source of input
> data
> for the test vectors ;-)

  Excellent idea.

[snip]
>>> Regarding performance, any AEAD algorithm can be made to support a
>>> scatter/gather or init/update/final interface as per RFC1321.  It is a
>>> conventional technique to copy the intermediate state after an update
>>> operation, and then use it to process different suffixes.   Beyond
>>> that,
>>> there are functions that support an "incremental" interface, in the
>>> sense
>>> of
>>> "Incremental Cryptography and Application to Virus Protection" (27th
>>> ACM
>>> Symposium on the Theory of Computing, May 1995).  GMAC, and many other
>>> functions that make use of universal hashing, can be used in this way.
>>> So
>>> it is possible to reap the performance benefit claimed for SIV with
>>> some
>>> existing functions, and it's possible to realize the performance
>>> advantage
>>> without using a vector of inputs.
>>
>>   You seem to be arguing against the novelty of this idea but not
>> against
>> the idea itself.
>
> I was trying to make the point that the performance advantages can be
> realized without changing the user interface, so to speak.
>
>>
>>   It is a natural way to deal with AD. In [AEAD] you say,
>>
>>     "When using an AEAD to secure a network protocol, for example,
>>      this input could include addresses, ports, sequence numbers,
>>      protocol version numbers, and other fields that indicate how the
>>      plaintext or ciphertext should be handled, forwarded, or
>> processed."
>>
>> That's, potentially, several distinct pieces of information. Some may
>> be contiguous (addresses, ports and sequence numbers might all be in a
>> single header) but other might not be. Some AD might not even transit
>> with the authenticated and encrypted data.
>>
>>   I guess I can try to highlight this concept but it seems that what
>> should really be explained is why these multiple distinct pieces of
>> information have to be viewed as a single component input to an AEAD
>> cipher mode.
>
> To play the devil's advocate: why, then, is there a single plaintext input
> in SIV instead of a vector of plaintext inputs?

  Because it's unnatural. Things like ports, sequence numbers, protocol
version numbers, and addresses cannot be encrypted because they need to be
inspected by a network entity or a protocol layer that does not have
access to keying material. It is still valuable to authenticate them
end-to-end though. Also it is perfectly reasonable for a component of AD
to be internal state or something that does not transit with the encrypted
and authenticated packet but there is no reason why one would want to
encrypt that.

  That is not the case with plaintext. In a network protocol data to
encrypt is contiguous. There could be a packet aggregation protocol
similar to the way 802.11n handles MPDU aggregation but if all the
packets are to be encrypted with the same key (not the case for 11n)
then all that's needed is to have enough cleartext header to deliver
the whole bundle of aggregated packets to the crypto engine. There is
no need for multiple disjoint components to plaintext.

  While it would be possible to modify an AEAD algorithm to accept
multiple distinct plaintext inputs (especially if it uses CTR mode for
encryption) it would overly complicate the encryption and decryption
definition with no benefit.

  The benefit of treating AD as multiple and distinct is that that's
the way it starts out. You need only specify the order in which it is
processed (and you need to do that regardless of how your mode handles
AD input). If you additionally require that AD be a single input then
you may also need to encode lengths of the distinct data. In one octet?
Two octets? Four octets? It's additional work to overcome a limitation
in the mode. If a cipher mode does not have a limitation it should not
be required to adopt one.

  You state that any AEAD algorithm can be modified to accept multiple
distinct pieces of AD using scatter/gather or init/update/final techniques.
Great! So AEAD algorithms that only allow a single input for AD have a way
to deal with the more natural case where AD is as you describe in [AEAD]
(you quote above). There seems to be no reason to _require_ all AEAD
algorithms to have a single input for AD.

  Can we please remove the single input AD requirement in [AEAD]? SIV
deals with AD the way it naturally is. It seems wrong to force SIV to deal
with AD in an unnatural way because that's the way other modes handle it.

  Dan.




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