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