Hello,
I've updated the MR with the new functions definitions and added test cases based on the test vectors from the RFC.
https://git.lysator.liu.se/nettle/nettle/-/merge_requests/19
Le 2021-02-04 à 01 h 48, Niels Möller a écrit :
It was designed to wrap key data, but not necessarily AES only. The kek must be an AES key though. The key data to wrap can be any data, as long as it's a set of 64 bits blocks.
If it doesn't add a lot of complexity, I think it would be nice to be able to substitute at least other 16-byte block ciphers (e.g., any other AES finalist, serpent and twofish being the once currently implemented in Nettle).
No problem, as long as cleartext is an array of 64bits, the function will wrap it, not matter what is is.
We can also replace the uint8_t with uint64_t as well in the input values?
It would be nice if we could have that alignment on input and output, but I think it's not a good idea to have uint64_t in this interface. We'd force alignment requirement on callers (who may be forced to make an extra copy to be able to call the function), and we'd also need to document endianness of the input. In short, since the specification defines the mechanism as operating on byte strings, the Nettle api should too.
I suspect that using byte strings in the interface and uint64_t internally makes it a bit difficult to allocate storage for internal state, since one can't just reuse the output buffer for working storage. Is the size needed for internal state same as the message size, or is if fixed size? I think it's doable but tricky to make it work without separate allocation for working storage.
After testing with uint64_t arrays for ciphertext and cleartext, I'd prefer getting back to uint8_t arrays instead. there are no iunt64_t data blocks used elsewhere in the library so one would have to convert all uint8_t to uint64_t and vice-versa, I think this change could be avoided.
Do you agree?
I was pointed to RFC 5649 (AES Key Wrap with Padding), is that relevant?
I'm not sure, the JOSE specification don't mention it so I wasn't aware of its existence before. I'll have a look but since it's an addon to RFC 3394, it may be implemented as an additional function.
/Nicolas