Re: [Cfrg] RFC 5297 and absent vs. zero-length nonces

[Dan Harkins <[e-mail]>]

   Hi Daniel,

On 2/23/17 3:12 PM, Daniel Franke wrote:
> The IANA considerations section of RFC 5297 (Synthetic Initialization
> Vector (SIV) Authenticated Encryption Using the Advanced Encryption
> Standard (AES)) gives N_MIN as 1. However, S2V is perfectly capable of
> accepting zero-length arguments. Furthermore, passing a zero-length
> argument to S2V is distinct from not passing that argument at all (as
> done in the case deterministic encryption). How should an
> implementation behave when provided with a zero-length nonce?

The registry that RFC 5297 updated with its IANA Considerations was
created by RFC 5116 to specify parameters for nonce-based AEAD modes. So
when using RFC 5297 through that interface you're saying you want to
use a nonce. RFC 5297 places the most minimal of requirements on such
use: N_MIN of 1 octet.

   The registry does not say what to do if someone tries to use the
mode in a way that is not defined for the registry so officially I
don't know what the answer is. We can evaluate your suggestions though.

(As an example, AES-GCM can take a nonce of 16 octets but the registry
makes N_MIN = N_MAX = 12. What do you do if you send 16 octets to
AES-GCM through this interface? Got me.)

> Should it return an error, since its length is under N_MIN?

   That would seem like the prudent thing to do since it is in violation
of the registry parameters.
>
> Should it pass it along to S2V just like any other nonce input?

   Since the registry mandates N_MIN as 1 then passing a zero length
nonce "just like any other nonce input" seems wrong. So I'd say don't
do that.

>
> Or should it treat this as a request for deterministic encryption and
> not pass any nonce to S2V?

   Well the registry is not for deterministic encryption so I would
say using it that way is not appropriate and would not think this
is correct.

   Seems to me that if you want to use AES-SIV (or any of the AEAD
modes from RFC 5116) in a way that is not defined by RFC 5116 then
use them through some raw interface and not the constrained one
created by RFC 5116. You'll note that the RFC 5116 interface also
assumes that all AAD is a single blob and does not support AES-SIV's
vector of AAD. What do you do with this registry if you need/want
to pass a vector of AAD to AES-SIV? Well, I'd say you don't use this
registry as your interface.

   Hope this helps,

   Dan.