On Dec 27, 2016, at 1:29 AM, Niels Möller <[email protected]> wrote: > Ron Frederick <[email protected]> writes: >> One other thought on this: Since the sender and receiver of a message >> need to both know the nonce, I think it would be useful for Nettle to >> provide a get_nonce() function if it is going to auto-increment the >> nonce. > > One can access it directly from the nonce field of the context struct, > but it makes some sense to provide a more abstract method. If we want to > do this consistently, the details are not entirely obvious, though: > > 1. Should it return a pointer to the nonce, assuming that it is present > in raw form in the context, so that it can be returned cheaply, or > should it make a copy into an area provided by the caller?
I would have this always copy into a buffer provided by the caller similar to how the digest() method works, to avoid concerns about memory lifetime. Callers who had access to the members of the struct could always use that instead to avoid the copy cost, but they’d now be required to make sure the version of the library they linked against matched the version of the header file they compiled against. > 2. Should a get_nonce method be added to the nettle_aead struct? Since that has a set_nonce() function, this could make sense, but it’s really only needed in the case where something like an auto-increment is occurring. If the library is never modifying the nonce provided by the caller, there’s probably no need for a function to return the currently set nonce. Do any of the AEAD functions modify the nonce after it is set? >> If a receiver is receiving an explicit nonce >> with each message, there’s no reason for them to pay the cost of doing >> the increment function every time they call digest() to verify a >> message, as they’re just going to reset the nonce to something else >> when the next message arrives. > > It's true that the auto-increment is unnecessary in that case, but it is > such a small cost that I don't think it's a good tradeoff to optimize > for. (It's an invocation of the INCREMENT macro in macros.h). I think > it's going to be negligible compared to all other processing done by > digest(). Making it optional (via a flag in the context, or an extra > function) will increase the code size for a performance gain (in some > use cases) which is hardly measurable. Fair enough. I consider this more of a minor side benefit that we’d get in the process of supporting the digest_pure() capability than an independent reason to do this. While the benefit of this would be small, the ability to avoid the full copy of the context and especially to avoid an additional memory allocation associated with that is a much more compelling reason. -- Ron Frederick [email protected] _______________________________________________ nettle-bugs mailing list [email protected] http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
