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
