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 <[email protected]> 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 > _______________________________________________ nettle-bugs mailing list [email protected] http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
