On Tue, Nov 25, 2014 at 3:49 PM, Niels Möller nisse@lysator.liu.se wrote:
Nikos Mavrogiannopoulos nmav@gnutls.org writes:
The disadvantage here is that I need to define encrypt and decrypt functions for each possible cipher and mode. That was the reason for the usage of cbc_encrypt() and decrypt.
Maybe it's possible with some trickery. For cbc modes, you could allocate a context which is a pointer to the nettle_cipher struct followed by a CBC_CTX with cipher context and iv. Then you could do
I've done something similar at: https://gitorious.org/gnutls/gnutls/source/0a1102311e443720fc0eb7a83f7dc1b58...
The plan is to integrate that to gnutls master once there is a functioning chacha-poly.
btw. I realized that nettle-meta.h lacks definitions for 3des, des and salsa20.
des and des3 (and blowfish) are missing, because their set_key functions have a return value indicating weak keys. Maybe they should be added anyway? Either relying on casting betwen function pointers being safe with and without return value, or using a wrapper function to explicitly remove it.
If the purpose of these structures are to allow uniform access to ciphers, they should apply to all ciphers. In any case I also saw that rc4 was also missing so I avoided using them.
And salsa20 is missing because there is no nettle-meta abstraction for stream ciphers. Internally, I use nettle_aead with NULL ->update and ->digest methods to represent stream ciphers, but I'm not sure if that's suitable for a public interface. BTW, it's of course possible to represent CBC and CTR mode in the same way, as nettle_aead without authentication.
For my purposes I didn't care to differentiate between cbc_encrypt() and stream_encrypt() so I handled them equally. 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.
regards, Nikos