Simo informed me that I didn't update the CMAC file with the new initializer. Instead of spamming the list with numerous patches, my latest version is at:
https://gitlab.com/nmav/nettle/merge_requests/4/
Can be downloaded as patches at: https://gitlab.com/nmav/nettle/merge_requests/4.patch
On Thu, Apr 18, 2019 at 9:00 AM Nikos Mavrogiannopoulos nmav@redhat.com wrote:
On Wed, 2019-04-17 at 20:41 +0200, Niels Möller wrote:
To me, this sounds like a likely source of interop problems. Since RFC 5297 is general and allows the application to decide on the number of elements and meaning of the input vector, it doesn't give much guidance on this, as far as I see. The crucial case is when an application specifies that SIV is used with associated data and/or a nonce, but allows an empty string for either of those.
I agree on that. That's one of the reasons I stuck on the higher level AEAD API (expressed by the message APIs in nettle). I added two sentences in the documentation about it.
The thing is, the AEAD api should allow inputs to be zero-length strings. Then the question is how to treat zero-length inputs in _siv_s2v, and I don't find RFC 5297 crystal clear on this point.
To me, it would make most sense for the AEAD construction to always use the S2V function in the spec with S1 = associated data (possibly zero length), S2 = nonce (possibly zero length), S3 = plaintext (possibly zero length). But we need to do what's needed to make it easy to interoperate with applicatinos and protocols using SIV; if everyone else does this differently, we should probably follow.
I agree. The patch I sent yesterday is towards that. I have verified that this approach interoperates with two implementations. The difference from what you write above is that we don't support at all the case where nonce=empty. That has interop issues (two interpretations, skip the field, or use it as empty), and I think it makes sense to leave it out. It has no use for our interface.
Today's patch adds two more vectors from another implementation and includes Simo's suggestion.
If we do it this way, then the nonce-less "key wrapping" usecase mentioned in RFC5297, with the example in A1, is *not* a special case of the AEAD construction, since this mode uses S1 = associated data, S2 = plaintext.
If we need to support several modes, maybe we should have a context struct that lets us do S2V incrementally, one element at a time,
Let's see if that is needed. For key wrapping I know no practical applications. I'd treat it as a separate algorithm, and we can add it later if needed.
Done. It needed some reorganization, and cmac128_syn is still needed in an ugly simulation of the CMAC structure setup to use the macros. I have kept the union
Maybe it would be easier without using the CMAC macros. They're intended for convenience, so there's little point in using them where it doesn't bring any convenience.
I do not think that avoiding them would change this part.
regards, Nikos