Hi,
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
AES-GCM:
gcm_aes128_set_key
gcm_aes128_update
gcm_aes128_set_iv
gcm_aes128_encrypt
gcm_aes128_decrypt
gcm_aes128_digest
chacha-poly1305:
chacha_poly1305_set_key
chacha_poly1305_set_nonce
chacha_poly1305_update
chacha_poly1305_encrypt
chacha_poly1305_decrypt
chacha_poly1305_digest
ccm_aes128_set_nonce takes different parameters from the chacha and gcm
equivalent function.
Furthermore the AEAD modes for block ciphers include an abstract layer
which can be re-used of other ciphers. For example the GCM mode
abstraction is re-used for camellia as well.
So overall there is a kind of "abstract" API followed with the set_key,
set_nonce, update, encrypt/decrypt, however these have not always the
same parameters as in the CCM case. 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.
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?
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.
regards,
Nikos
