Maybe it's time to specify some nettle-meta.h types for stream ciphers
and algorithms for authenticated encryption.
Currently we have nettle_hash, which I don't think needs any changes,
and nettle_cipher, where I'm considering the following changes:
1. Drop the length argument from nettle_set_key_func.
2. Make the context argument of nettle_crypt_func const.
3. Previous point implies that we can no longer have struct
nettle_cipher nettle_arcfour128. nettle_cipher will then be limited
to block ciphers only.
Then there are some minor variations. Maybe nettle_crypt_func should be
left unmodified, and we should have a new type, say nettle_cipher_func,
for block ciphers with a const context.
What should the right abstraction look like for stream ciphers?
Currently, arcfour, salsa20, and (soon) chacha. Consider
struct nettle_stream_cipher
{
const char *name;
unsigned context_size;
unsigned key_size;
unsigned nonce_size;
nettle_set_key_func *set_key;
nettle_set_key_func *set_nonce;
nettle_crypt_func *crypt;
};
Here, nettle_crypt_func should be the current definition without const.
This assumes encryption and decryption are identical, which is the case
for out current stream cipher list (and anything else xoring a stream to
the plaintext). For arcfour, set_nonce would be NULL. Not sure how
useful that really is to applications, ciphers with a nonce might not be
used interchangably with a cipher that has no nonce.
So lacking features in that definition are
* Support for stream ciphers with different processing for encryption
and decryption.
* Support for the random-access possibilities in salsa20 and chacha.
* Support for algorithms with arbitrary nonce size.
Also, internal block size is not visible. To use salsa20 with this
interface, one would need a one-block buffer, and new logic to handle
partial blocks.
For applications of stream ciphers, as well as ctr mode, is it important
to be able to process a message byte by byte? Or is it sufficient to do
like the current ctr and salsa20 code, to require that if a message is
processed using several calls to the crypt function, all but the last
must be an integral number of blocks? If we keep that requirement, we'd
have to add a block_size field to struct nettle_stream_cipher.
Next, AEAD (authenticated encryption with associated data). Currently
implemented algorithms are GCM and EAX. For internal use,
nettle-internal.h currently defines
/* Tentative interface for "authenticated encryption with associated
data" algorithms. Should be moved to nettle-meta.h when stable. */
struct nettle_aead
{
const char *name;
size_t context_size;
/* Block size of the input, and the size of the output digest */
size_t block_size;
/* Suggested key size; other sizes are sometimes possible. */
size_t key_size;
nettle_set_key_func *set_key;
nettle_set_key_func *set_iv;
nettle_hash_update_func *update;
nettle_crypt_func *encrypt;
nettle_crypt_func *decrypt;
nettle_hash_digest_func *digest;
};
Like for stream ciphers, nettle_crypt_func is the variant without const;
the context *is* modified as the message is processed.
Limitations:
* Assumes identical key setup for encrypt and decrypt, which is true for
GCM and AEX (both based on CTR mode for the encryption). Do we need
separate set_encrypt_key and set_decrypt_key functions?
* Assumes block size and digest size are identical. They might not be.
* set_iv should be renamed to set_nonce. Can the nonce be restricted to
fixed size here? Both gcm and eax are specified for arbitrary nonce
size. We may need two nettle_set_* function typedefs, one without
length argument (used for set_key in all these abstractions), and one
with a length argument, used for arbitrary size nonces, as well as any
interfaces supporting variable key size.
One might use the same abstraction for constructions with no associated
data (say, aes128-ctr-hmac-sha256) by setting update to NULL, or for
schemes with no authentication at all, like aes 128-ctr, by also setting
digest to NULL. Or for methods to provide authentication but no
encryption, like hmac-sha256 or poly1305. But I doubt that's very
useful.
Regards,
/Niels
--
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.
_______________________________________________
nettle-bugs mailing list
nettle-bugs@lists.lysator.liu.se
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
