Nikos Mavrogiannopoulos <[email protected]> writes: > I've done something similar at: > https://gitorious.org/gnutls/gnutls/source/0a1102311e443720fc0eb7a83f7dc1b587e55379:lib/nettle/cipher.c
Looks reasonable. You get a pretty large nettle_cipher_st to support all variations, I see. Some comments: _ccm_aes_encrypt looks like it supports ccm with any cipher, right? If the aead_*crypt_func functions are intended as the primary interface for aead, I guess you'd want to either retire the auth and tag functions (and you may want additonal helper functions in nettle to make that easy?). Or implement the aead_*crypt functions in terms of the auth and tag functions for everything but ccm. For the _gcm functions, do you see any obstacles to implementing generic _gcm functions (like you do with cbc), which passes the encrypt_block function to nettle's general gcm functions? Note that GCM_CTX intentionally puts the cipher-specific context last, so the offset should always be the same. For function typedefs, in nettle I've chosen to let these types be non-pointers. This is a question of style, of course. If you did the same, you would be able do use them to declare functions like static encrypt_func _cbc_encrypt; and then the compiler will check that the definition of _cbc_encrypt matches the declaration. Which I think is nice. Your auth_func, tag_func, set_key_func and setiv_func seem to duplicate nettle_hash_update, nettle_set_key_func and nettle_hash_digest_func. If they are intended to work with nettle's context structs (which they are, I think?), maybe it's clearer to use nettle's names for these types, to differentiate them from the function types which work with your more abstract nettle_cipher_ctx. > My impression is that > there are two high level abstractions: AEAD ciphers (cipher+mode+tag), > and non-aead cipher+mode (just encryption). Stream ciphers are simply > ciphers with a fixed mode. And nettle currently lacks an abstraction (of the nette-meta.h style) for the second type. nettle_cipher is for "raw" block ciphers, ECB-mode, no state. Using struct nettle_aead could work. The update and digest methods would be NULL. The set_nonce method would be NULL for arcfour and any other traditional stream cipher, and non-NULL for block cipher modes like cbc and ctr, as well as for salsa20 and chacha. (Supporting cbc in this way has padding issues, though, not sure how to deal with that). But using nettle_aead is not ideal naming. Maybe it should be done differently. (And I don't think nettle should include meta objects for all possible combinations of ciphers and modes, but it could include the most important ones, and make it easy for an application to define additional combinations). Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. _______________________________________________ nettle-bugs mailing list [email protected] http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
