s2v: zero-length plaintext != no plaintext? about aes-siv HOT 7 CLOSED

You're right, I was assuming that empty plaintext would make n equal to 0 and therefore trigger the AES-CMAC(K, <one>) case. But if that's not what should happen, then I'm not sure how that case could ever occur. This begs the question of why it's in the RFC pseudocode in the first place...

Can you point to other implementation(s) that handle this case differently? I'm definitely interested in having correct code here. (We need more test vectors, too.)

from aes-siv.

I think RFC includes this because they define S2V as a key derivation function (1.3.3), and thus need the complete and self-contained function, which can be implemented separately from SIV.

Here are some implementations I found:

• https://github.com/jacobsa/crypto/blob/master/siv/s2v.go#L36
• http://cvsweb.netbsd.org/bsdweb.cgi/src/external/bsd/wpa/dist/src/crypto/aes-siv.c?rev=1.1.1.1&content-type=text/x-cvsweb-markup&only_with_tag=MAINSIV)
• https://github.com/cozybit/authsae/blob/master/crypto/aes_siv.c#L462
• https://github.com/randombit/botan/blob/master/src/lib/modes/aead/siv/siv.cpp#L100

I agree with you about test vectors, I was looking for more of them myself.

from aes-siv.

This is really interesting. The Go code just panics if there's nothing there:

if numStrings == 0 {
    panic("strings vector must be non-empty.")
}

The NetBSD code actually appears to do the RFC's <one> thing:

if (!num_elem) {
    os_memcpy(tmp, zero, sizeof(zero));
    tmp[AES_BLOCK_SIZE - 1] = 1;
    return omac1_aes_128(key, tmp, sizeof(tmp), mac);
}

Finally, both the authsae code and Botan seem to be unconcerned with the possibility of size zero.

I have no idea what the correct approach is. On one hand, there's the RFC. The <one> reference is present since the first draft. On the other, there's the info from NIST, where I'm not seeing anything like that in any of the SIV links there.

from aes-siv.

NetBSD code has this case, however it's not triggered, as num_elem is never zero, see aes_siv_encrypt:

    if (aes_s2v(k1, num_elem + 1, _addr, _len, v))
        return -1;

Same with other implementations: they all consider zero-length plaintext as the last vector, which is present, and which gets padded with 0x80.

In the linked page (thanks, I didn't see it), there's http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/proposedmodes/siv/keywrap.pdf, which has CMAC* without this case [page 12]:

Edited: the full S2V is NIST document includes this case (when the number of vectors is zero) [page 10]:

But as you can see, they dropped this case in CMAC*, as it's obvious that it's never zero.

from aes-siv.

FYI, here's how RFC algorithm would be written if ported from your code, which is incorrect even for the full S2V:

S2V(K, S1, ..., Sn) {
  if (n-1) = 0 and len(Sn) = 0 then
    return V = AES-CMAC(K, <one>)
  fi
  D = AES-CMAC(K, <zero>)
  for i = 1 to n-1 do
    D = dbl(D) xor AES-CMAC(K, Si)
  done
  if len(Sn) >= 128 then
    T = Sn xorend D
  else
    T = dbl(D) xor pad(Sn)
  fi
  return V = AES-CMAC(K, T)
}

from aes-siv.

That's fair. Do you think I should just get rid of that if clause then?

from aes-siv.

@arktronic yes, and this part should be removed https://github.com/arktronic/aes-siv/blob/master/aes-siv/aes256-siv.cpp#L46:L51

from aes-siv.