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

[Daniel Franke <[e-mail]>]

On 2/24/17, David McGrew (mcgrew) <[e-mail]> wrote:
>Clearly SIV modes can and should set N_MIN to zero.  I guess the N_MIN=1
> got missed during the review of RFC 5297.  (I recall discussing the N_MAX
> guidance during the review process, but I think N_MIN went unnoticed.)
>
>If N_MIN can be changed in RFC 5297 from 1 to 0 with an Errata, that would
> be the best way to go.   Otherwise, I suggest creating new IANA entries
> for the existing SIV modes that reference that RFC, but change N_MIN to
> zero.

If we agree that a change is in order, that I hope we can also agree
that an erratum would suffice. Having two different IANA codepoints
that differ only in the value of N_MIN sounds like it would sow a
hideous amount of confusion.

It sounds like the three of us agree, at least, that my option 3,
treating a zero-length nonce as a request for deterministic
encryption, is the Wrong Thing. For my own purposes, I'm just doing an
RFC 5297 implementation (look for a release announcement RSN) and not
aspiring to create a general RFC 5116 interface, so I think I can go
ahead and allow zero-length nonces regardless of whether it's strictly
RFCily-correct to do so. My function signature looks like this:

int AES_SIV_Encrypt(AES_SIV_CTX *ctx,
                    uint8_t *out, size_t *out_len,
                    uint8_t const* key, size_t key_len,
                    uint8_t const* nonce, size_t nonce_len,
                    uint8_t const* plaintext, size_t plaintext_len,
                    uint8_t const* ad, size_t ad_len);

It'll give you deterministic encryption if the `nonce` argument is
NULL, and encryption with a zero-length nonce if `nonce` is non-NULL
and `nonce_len` is 0.