On Mon, Feb 10, 2014 at 10:45 AM, Niels Möller <ni...@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 _______________________________________________ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
