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
nisse@lysator.liu.se (Niels Möller) writes:
Next, AEAD (authenticated encryption with associated data).
Some questions on a general abstraction for this, and my tentative answers:
Q: Should it expose the block size?
A: Yes. The caller must pass data in chunks which are an integral number of blocks. Motivation: (i) Byte-by-byte processing seems to be an obscure usecase, in particular for AEAD where you're not supposed to use the decrypted data for anything until the authentication is properly checked. (ii) This is how related nettle functions already work.
Q: Should we have a separate _digest function, which exposes the structure, of authentication tag appended to the crypto text?
A: Yes. Cons: For decryption, it's easier for the caller to pass the complete message, and not have to call digest and memcmp. Maybe there are some aead construction which doesn't do authentication by appending some kind of MAC at the end, so that is is verified by computing the same value and comparing it? I'm not aware of any, though.
Pro: By having the caller separate ciphertext and tag, we avoid extra buffering in the implementation. And it simplifies the interface if the encrypt and decrypt functions have the same size for input and output, without having to delay processing until it is known that a piece of the data is ciphertext rather than tag.
Q: Should calling set_nonce be mandatory for each message, or should we provide automatically incrementing nonces, starting from zero?
A: Mandatory. Motivation: Some aead algorithms hash the nonce, and then we would need extra storage to be able to increment it. This includes EAX, and GCM with a nonce-size different from 12.
Q: Should the nonce size be fixed?
A: Yes. Motivation: For a given key, fixed nonce size is good enough for RFC 5116. It's unclear if there are use-cases for varying the nonce size, and if needed one can define separate nettle_aead objects differing only in nonce size.
Q: Should we include the rfc 5116 limits P_MAX and A_MAX?
A: No. Motivation: I think it's an obscure use-case to make decisions based on those limits at runtime. I'd expect a human to examine those limits when deciding which aead algorithms should be supported in a protocol or in an application.
Comments highly appreciated. This leads to the following abstraction:
struct nettle_aead { const char *name; unsigned context_size;
unsigned block_size; unsigned key_size; unsigned nonce_size; unsigned digest_size;
nettle_set_key_func *set_encrypt_key; nettle_set_key_func *set_decrypt_key; nettle_set_key_func *set_nonce;
nettle_crypt_func *encrypt; nettle_crypt_func *decrypt;
nettle_hash_update_func *update; nettle_hash_digest_func *digest; };
The sequence of calls would be
aead->set_encrypt_key(...); for (...) { aead->set_nonce(...); for (...) aead->update(...); for (...) aead->encrypt(...); aead->digest(...); }
For convenience maybe one could have a verify helper function which does verify + memcmp. And helper functions for encrypting and decrypting of complete messages, with no streaming, which I'd expect to be sufficient for most aplications. Say,
void aead_encrypt (const struct nettle_aead *aead, void *ctx, const uint8_t *nonce, size_t adata_size, const uint8_t *adata, size_t msg_size, uint8_t *gibberish, const uint8_t *msg);
int aead_decrypt (const struct nettle_aead *aead, void *ctx, const uint8_t *nonce, size_t adata_size, const uint8_t *adata, size_t msg_size, uint8_t *msg, const uint8_t *gibberish);
where gibberish is of size msg_size + aead->digest_size.
Some possible extensions for things which aren't proper aead constructions:
If ->set_nonce is NULL, there's no nonce, and each key can be used for only a single message.
If ->update is NULL, there can be no associated data
If ->digest is NULL, there's no authentication, it's a stream cipher or CTR-mode or the like (but plain CBC doesn't fit, due to its padding needs)
If ->encrypt and ->decrypt is NULL, it's a MAC mechanism
I think it may be a good idea to implement chacha-poly1305 before doing this abstraction, so there's at least three different aead mechanism to test it with.
Regards, /Niels
I'm continuing to reply to myself... It's the recurring question on fixed size versus varying size of certain inputs and outputs.
nisse@lysator.liu.se (Niels Möller) writes:
Q: Should the nonce size be fixed?
A: Yes. Motivation: For a given key, fixed nonce size is good enough for RFC 5116. It's unclear if there are use-cases for varying the nonce size, and if needed one can define separate nettle_aead objects differing only in nonce size.
If it's fixed, then the abstraction can't be used as is in the testsuite, because there are testcases at least for gcm, which try varying the nonce size. Could be solved by passing an extra function pointer for those tests (or define a nettle_aead struct for each tested size, but that seems a bit awkward).
nettle_hash_digest_func *digest;
Using nettle_hash_digest_func implies a size argument, since nettle's digest functions allow truncation. And, e.g., eax is specified with the "tag length" tau as a security parameter, so the underlying eax_digest function ought to have a size parameter. But varying the size is a bit questionable in the context of an "abstract" aead algorithm; there the digest size ought to be fixed, toghether with nonce size and key size, as an "instantiation" of a more general algorithm.
So should we have a separate type,
typedef void nettle_aead_digest_func(void *ctx, uint8_t *dst);
for this digest function pointer?
I think it may be a good idea to implement chacha-poly1305 before doing this abstraction, so there's at least three different aead mechanism to test it with.
I've started on this, and it seems nice and easy. But I stumbled on the above interface issues.
Regards, /Niels
On Fri, Feb 7, 2014 at 1:01 PM, Niels Möller nisse@lysator.liu.se wrote:
Next, AEAD (authenticated encryption with associated data).
Some questions on a general abstraction for this, and my tentative answers: Q: Should it expose the block size? A: Yes. The caller must pass data in chunks which are an integral number of blocks. Motivation: (i) Byte-by-byte processing seems to be an obscure usecase, in particular for AEAD where you're not supposed to use the decrypted data for anything until the authentication is properly checked. (ii) This is how related nettle functions already work.
I'd say no because the whole purpose of AEAD (or at least my understanding of rfc5116) is to simplify the process of encryption. If the details need to be known another interface than AEAD can be used.
I agree with the rest of the points.
regards, Nikos
Thanks for the review.
Nikos Mavrogiannopoulos n.mavrogiannopoulos@gmail.com writes:
On Fri, Feb 7, 2014 at 1:01 PM, Niels Möller nisse@lysator.liu.se wrote:
Q: Should it expose the block size?
I'd say no because the whole purpose of AEAD (or at least my understanding of rfc5116) is to simplify the process of encryption.
But that interface says nothing about the case of processing a message incrementally, one piece of a time.
For ease of use, do you think it's sufficient to have helper functions for the common case of processing a complete message? Like the proposed
void aead_encrypt (const struct nettle_aead *aead, void *ctx, const uint8_t *nonce, size_t adata_size, const uint8_t *adata, size_t msg_size, uint8_t *gibberish, const uint8_t *msg);
int aead_decrypt (const struct nettle_aead *aead, void *ctx, const uint8_t *nonce, size_t adata_size, const uint8_t *adata, size_t msg_size, uint8_t *msg, const uint8_t *gibberish);
To do incremental processing with aead, without exposing internal structure, what would you prefer? encrypt and decrypt functions which take n bytes of input and produce n bytes output (for any n), plus some digest function to do the final processing for authentication (on decrypt, that implies that the application still has to split off the final digest/tag bytes from the rest of the encrypted message) ?
Or something more in spirit with zlib, where the caller provides input and output buffers, and the implementation does as much processing as possible with the given input and available output space?
Regards, /Niels
On Mon, Feb 10, 2014 at 10:45 AM, Niels Möller nisse@lysator.liu.se wrote:
Thanks for the review.
Q: Should it expose the block size?
I'd say no because the whole purpose of AEAD (or at least my understanding of rfc5116) is to simplify the process of encryption.
But that interface says nothing about the case of processing a message incrementally, one piece of a time.
Indeed, but its spirit is about simplification of the encryption process and having to know details such as the block size doesn't help. Let's say for example that someone wants to encrypt a message that consists of a header (5) bytes and indefinite data provided by some other layer. With the API that needs to know the block size, the code to encrypt would be quite complex, while the blocksize-agnostic code would be straight forward to use.
I realized this issue when I added support for salsa20 from nettle that required the knowledge of the salsa20 block size in order to do partial encryption.
For ease of use, do you think it's sufficient to have helper functions for the common case of processing a complete message? Like the proposed void aead_encrypt (const struct nettle_aead *aead, void *ctx, const uint8_t *nonce, size_t adata_size, const uint8_t *adata, size_t msg_size, uint8_t *gibberish, const uint8_t *msg); int aead_decrypt (const struct nettle_aead *aead, void *ctx, const uint8_t *nonce, size_t adata_size, const uint8_t *adata, size_t msg_size, uint8_t *msg, const uint8_t *gibberish);
That would work if you have the whole message in a buffer, but I've noticed that this isn't often the case. Of couse one could get a new buffer, but I'd prefer a clean incremental encryption.
To do incremental processing with aead, without exposing internal structure, what would you prefer? encrypt and decrypt functions which take n bytes of input and produce n bytes output (for any n), plus some digest function to do the final processing for authentication (on decrypt, that implies that the application still has to split off the final digest/tag bytes from the rest of the encrypted message) ?
I think the digest/tag function for final processing are unavoidable when allowing incremental encryption, but I find them quite reasonable. There will be some issue however, when there will be an AEAD algorithm that introduced padding.
regards, Nikos
Nikos Mavrogiannopoulos n.mavrogiannopoulos@gmail.com writes:
Let's say for example that someone wants to encrypt a message that consists of a header (5) bytes and indefinite data provided by some other layer. With the API that needs to know the block size, the code to encrypt would be quite complex, while the blocksize-agnostic code would be straight forward to use.
I'm been thinking a bit more. I'm leaning towards the nettle_aead struct as an interface to the aead primitives. Then, additional buffering should be done in the same way (ok, parameterized by the block size) regardless of the underlying algorithm, hence it's not a primitive at that level.
For ease of use, I think we could have a family of aead_* functions which lets the application treat the nettle_aead as opaque objects. I think one could add functions for incremental processing too, not only the complete-message functions already sketched.
How should the easy-to-use interface for incremental encryption/decryption look like? I see two alternatives:
Either provide some macro or function, which, given an aead algorithm and the input size, returns the largest possible output size. Then the application should arrange to pass a large enough buffer, call the encrypt/decrypt function, which returns the amount of output actually produced.
Or use struct nettle_buffer for the destination operand, possibly in combination with some macro/function to query the needed space.
Regards, /Niels
nisse@lysator.liu.se (Niels Möller) writes:
Or use struct nettle_buffer for the destination operand, possibly in combination with some macro/function to query the needed space.
I have now tried this approach. For those have haven't used nettle_buffer, it's struct with a data pointer, allocation size, and current size. It can be setup to either use a fix buffer provided by the application, or it can grow as needed, using realloc, xrealloc, or any custom realloc function provided by the application.
A totally untested implementation in the aead-api branch. There actually two interfaces, defined in aead.h.
First question is whether or not this is useful. If it is useful, maybe the interfaces need tweaking. A first test (besides regular test cases) would be to rewrite examples/rsa-encrypt.c and examples/rsa-decrypt.c to use some aead mechanism for the bulk encryption, rather than aes-cbc + hmac-sha1.
First, an interface for processing complete messages. These use the same context as the lower-level algorithm. More or less the same as I have sketched on this list previously.
-----8<---------
/* Interface for processing a complete message at a time. Application must allocate the context and call the set_key function before using this interface. */ size_t aead_encrypt_msg_size (const struct nettle_aead *aead, size_t size); void aead_encrypt_msg (const struct nettle_aead *aead, void *ctx, const uint8_t *nonce, size_t ad_size, const uint8_t *ad, size_t plaintext_size, uint8_t *gibberish, const uint8_t *plaintext);
size_t aead_decrypt_msg_size (const struct nettle_aead *aead, size_t size); int aead_decrypt_msg (const struct nettle_aead *aead, void *ctx, const uint8_t *nonce, size_t ad_size, const uint8_t *ad, size_t gibberish_size, uint8_t *plaintext, const uint8_t *gibberish);
-----8<---------
Second interface is for streaming operation, hiding the block size. Here, the context is the context of the underlying aead algorithm, but with a small extra buffer added at the end (aead->block_size for encryption, and aead->block_size + aead->digest_size for decryption).
-----8<---------
/* Streaming interface, including buffering. Uses a context struct corresponding to the aead algorithm, with additional buffers added at the end. Hence, the context can be passed to algorithm-specific functions. Applications should call set_key and set_nonce before using these functions. */
#define aead_update(aead, ctx, size, data) \ ((aead)->update((ctx), (size), (data)))
size_t aead_encrypt_ctx_size (const struct nettle_aead *aead);
void aead_encrypt_init (const struct nettle_aead *aead, void *ctx, const uint8_t *nonce);
/* Attempts to grow the destination buffer as needed. Returns the amount of plaintext that could be processed. */ size_t aead_encrypt (const struct nettle_aead *aead, void *ctx, struct nettle_buffer *buffer, size_t size, const uint8_t *plaintext);
/* Maximum output size for aead_encrypt_final. */ size_t aead_encrypt_final_size (const struct nettle_aead *aead);
/* Returns 1 on success, 0 if buffer was too small and growing it failed. On failure, some output may still be generated, and the function can be called again with more output space. */ int aead_encrypt_final (const struct nettle_aead *aead, void *ctx, struct nettle_buffer *buffer);
size_t aead_decrypt_ctx_size (const struct nettle_aead *aead);
void aead_decrypt_init (const struct nettle_aead *aead, void *ctx, const uint8_t *nonce);
/* Attempts to grow the destination buffer as needed. Returns the amount of plaintext that could be processed. */ size_t aead_decrypt (const struct nettle_aead *aead, void *ctx, struct nettle_buffer *dst, size_t size, const uint8_t *gibberish);
/* Maximum output size for aead_decrypt_final. */ size_t aead_decrypt_final_size (const struct nettle_aead *aead);
/* Returns 1 on success, 0 if buffer is too small or authentication failed. FIXME: Distinguish between failure cases? */ int aead_decrypt_final (const struct nettle_aead *aead, void *ctx, struct nettle_buffer *dst);
-----8<---------
In particular the decrypt function is quite messy, which makes me think that it's a good idea to implement this at one place, on a level between the application and the implementation of each specific aead mechanism.
Regards, /Niels
nisse@lysator.liu.se (Niels Möller) writes:
Q: Should the nonce size be fixed?
A: Yes. Motivation: For a given key, fixed nonce size is good enough for RFC 5116. It's unclear if there are use-cases for varying the nonce size, and if needed one can define separate nettle_aead objects differing only in nonce size.
I'm still having some difficulty figuring out what really is the Right Thing here. I think there are two usecases, with somewhat different requirements.
1. General code which is written to work with any aead algorithm. This has to use nonces of size aead->nonce_size, because there's no interface to query what other nonce sizes might be valid (we have the option of adding some n_min and n_max values, though). So here, a length argument for set_nonce is useless.
2. Code which uses a single aead algorithm, say eax-aes128, but uses the nettle_aead abstraction in order to use the user-friendly to-be-defined aead_* functions, say, a aead_encrypt_message to do all work for processing one message. That code may well know that eax supports arbitrary nonce sizes. Then it would either need a way to pass a length argument to set_nonce, or a supported way to call some other algorithm specific function to set the nonce.
For now, I'm leaving it as fixed size, but I might change my mind before release.
Related question is the length for the digest method. I'm leaning towards leaving that in, even though I'd expect that to be useless for almost all applications using aead. The reason is consistency with other nettle functions; all other hash and mac algorithms support a length argument, to truncate the digest to any desired smaller size.
I've pushed my aead changes to the repo now. Currently defined instances are
nettle_gcm_aes128 nettle_gcm_aes192 nettle_gcm_aes256 nettle_chacha_poly1305 nettle_eax_aes128
Comments highly appreciated.
For chacha_poly1305, we really need additional testcases, in particular for corner cases like empty plaintext or empty authenticated data.
Regards, /Niels
Hi,
On Thu, 13 Feb 2014 09:38:30 +0100 nisse@lysator.liu.se (Niels Möller) wrote:
nisse@lysator.liu.se (Niels Möller) writes:
Q: Should the nonce size be fixed?
A: Yes. Motivation: For a given key, fixed nonce size is good enough for RFC 5116. It's unclear if there are use-cases for varying the nonce size, and if needed one can define separate nettle_aead objects differing only in nonce size.
[...]
The RFC explicitly supports a range of nonce sizes; I think the overhead of supporting them is so small that I don't see why not to just add it and be done with it :)
Related question is the length for the digest method. I'm leaning towards leaving that in, even though I'd expect that to be useless for almost all applications using aead. The reason is consistency with other nettle functions; all other hash and mac algorithms support a length argument, to truncate the digest to any desired smaller size.
The RFC says:
Each AEAD algorithm MUST provide a description relating the length of the plaintext to that of the ciphertext. This relation MUST NOT depend on external parameters, such as an authentication strength parameter (e.g., authentication tag length). That sort of dependence would complicate the use of the algorithm by creating a situation in which the information from the AEAD registry was not sufficient to ensure interoperability.
I'm not sure I'm reading this correctly, but to me this means that an AEDA algorithm could have an "authentication tag length" parameter, but would have to pad it to the maximum tag length it supports, as otherwise the length of the ciphertext would depend on that parameter, making such parameter completely useless.
Also the RFC doesn't specify an interface for such tags ("digests") at all - they are part of the ciphertext.
So the "RFC way" would be renaming "digest" to "finish" and have some way to signal a larger output buffer is needed; perhaps similar to the z_stream interface. I'm not saying that would be a good idea :)
Also the RFC doesn't specify a "streaming" interface (afaik); for example an AEAD algorithm could process the plain text data before the additional data.
To handle such algorithms well it may be necessary to ask for a fixed AD buffer in the beginning, which has to be valid while the plain/cipher text is processed.
Also some algorithms may need to know the length of the plain text in advance (CCM for example).
regards, Stefan
Stefan Bühler nettle-bugs@stbuehler.de writes:
The RFC explicitly supports a range of nonce sizes; I think the overhead of supporting them is so small that I don't see why not to just add it and be done with it :)
Maybe. We'd then need all of a minimun, a maximum, and a default/recommended value. I don't think we should have what the rfc calls randomized or stateful algorithms at this level.
What should the minimum value be? Both eax and gcm could have minimum value 0 and maximum value UINT_MAX, since they both hash the nonce as needed. Actually using an empty nonce means that one can process only a single message with each key.
The gcm spec allows arbitrary nonce size, and with size != 12 the nonce is hashed. But I don't know if this is a feature anyone is using? RFC 5116 specifies a fix size of 12 bytes for gcm. (Restricting to 12 bytes would make it natural to support auto-increment of the nonce).
I'm not sure I'm reading this correctly, but to me this means that an AEDA algorithm could have an "authentication tag length" parameter, but would have to pad it to the maximum tag length it supports, as otherwise the length of the ciphertext would depend on that parameter, making such parameter completely useless.
I think that with different tag lengths, you would have a separate aead algorithms in the rfc definition for each possible tag size. At least, that's one way to make sense of it.
Also the RFC doesn't specify a "streaming" interface (afaik); for example an AEAD algorithm could process the plain text data before the additional data.
Algorithms of interest do support streaming mode, though, and I think it's viewed as a desirable feature.
Also some algorithms may need to know the length of the plain text in advance (CCM for example).
I'm not really familiar with ccm, I've only read the critique of it in the eax paper. But that sounds like it's killing streaming operations.
Regards, /Niels
On 02/13/2014 09:38 AM, Niels Möller wrote:
I've pushed my aead changes to the repo now. Currently defined instances are nettle_gcm_aes128 nettle_gcm_aes192 nettle_gcm_aes256 nettle_chacha_poly1305 nettle_eax_aes128
It would be good to have camellia as well (I had sent a patch some time ago). In gnutls I use it as the backup cipher to AES.
regards, Nikos
Nikos Mavrogiannopoulos nmav@gnutls.org writes:
It would be good to have camellia as well (I had sent a patch some time ago). In gnutls I use it as the backup cipher to AES.
Hmm, let me see... I find one patch from you in my mailbox (not on list), including test vectors, dated October 24. Thanks for the reminder.
Do you need all of gcm-camellia128, gcm-camellia192, gcm-camellia256, or only some? (Your test program seems to only test the 128-bit variant, but you also attacked a file with test data for the other sizes).
Regards, /Niels
On 02/15/2014 07:28 PM, Niels Möller wrote:
Nikos Mavrogiannopoulos nmav@gnutls.org writes:
It would be good to have camellia as well (I had sent a patch some time ago). In gnutls I use it as the backup cipher to AES.
Hmm, let me see... I find one patch from you in my mailbox (not on list), including test vectors, dated October 24. Thanks for the reminder. Do you need all of gcm-camellia128, gcm-camellia192, gcm-camellia256, or only some? (Your test program seems to only test the 128-bit variant, but you also attacked a file with test data for the other sizes).
In rfc6367 only the 128 and 256 bit variants are defined, so having those would be enough for me.
regards, Nikos
Nikos Mavrogiannopoulos nmav@gnutls.org writes:
In rfc6367 only the 128 and 256 bit variants are defined, so having those would be enough for me.
gcm-camellia128 added now. Need to prepare additional testcases (based on camellia_gcm_tv.txt) before adding the 256-bit variant. I hope I can get that done soon.
Regards, /Niels
nisse@lysator.liu.se (Niels Möller) writes:
Need to prepare additional testcases (based on camellia_gcm_tv.txt) before adding the 256-bit variant. I hope I can get that done soon.
Done now. Nikos: From where did you get camellia_gcm_tv.txt? It would be good to document the source in gcm-test.c.
/Niels
On 02/16/2014 09:54 AM, Niels Möller wrote:
nisse@lysator.liu.se (Niels Möller) writes:
Need to prepare additional testcases (based on camellia_gcm_tv.txt) before adding the 256-bit variant. I hope I can get that done soon.
Done now. Nikos: From where did you get camellia_gcm_tv.txt? It would be good to document the source in gcm-test.c.
It was provided to me by the authors of RFC6367.
regards, Nikos
nettle-bugs@lists.lysator.liu.se
-
Nikos Mavrogiannopoulos -
Nikos Mavrogiannopoulos -
nisse＠lysator.liu.se -
Stefan Bühler