Nikos Mavrogiannopoulos <[email protected]> writes: > As it is now AEAD ciphers in nettle are supported with their own API. > AES-CCM provides: > ccm_aes128_set_key > ccm_aes128_set_nonce > ccm_aes128_update > ccm_aes128_encrypt > ccm_aes128_decrypt > ccm_aes128_digest > ccm_aes128_encrypt_message > ccm_aes128_decrypt_message
I've considered ccm odd because it doesn't support a "streaming" mode where the mesage length isn't known up-front. > AES-GCM: > gcm_aes128_set_key > gcm_aes128_update > gcm_aes128_set_iv And gcm is a bit special because it uses pretty large tables which depend on the key but not the nonce. And it would make sense to rename set_iv to set_nonce, for consitency. > chacha-poly1305: > chacha_poly1305_set_key > chacha_poly1305_set_nonce > chacha_poly1305_update > chacha_poly1305_encrypt > chacha_poly1305_decrypt > chacha_poly1305_digest These are the methods I'd expect "most" AEADs to have, and it's what the nettle_aead struct is intended to capture. But maybe there are too many exceptions. It's good to have several examples to consider. > I'm checking the AES-SIV-CMAC mode > which cannot even be put in that abstraction as the MAC in SIV is the > IV and thus the MAC-style API doesn't really suit it. Does that mean that it processes data twice (first mac, then encryption), so that it can't support "streaming" mode at all, even if lenghts are provided up front? > My understanding is that AEAD modes according to RFC5116 need to have 4 > inputs: key, nonce, associated data, plaintext so the CCM encrypt and > decrypt message seem to be the closer to that API. Would it make sense > to standardize on these, and only provide that API for AEAD modes? It would make a lot of sense to have some convenience functions to do that, which are consistent between AEADs. However, I think I'd prefer to at least make the set_key method separate, to avoid redoing all of the key setup per message. So then we'de have something similar to the ccm_*_message functions. Should the nonce length and tag length be variable per message? Would it be useful with a separate area for reading and writing the tag, or should we always attach the tag at the end of the ciphertext, like the current _message functions? > The reason I'm asking is because SIV could benefit of a very custom API > as well because it can take advantage of multiple associated data, but > in the end I believe AEAD is about simplicity. Providing a unique API > per AEAD cipher seems to me quite contradictory to that goal. I think it's nice to support special features of SIV, but using those functions should be optional. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance. _______________________________________________ nettle-bugs mailing list [email protected] http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
