Thanks for the review. Nikos Mavrogiannopoulos <n.mavrogiannopou...@gmail.com> writes:
>On Fri, Feb 7, 2014 at 1:01 PM, Niels Möller <ni...@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 -- 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