On Tue, Nov 12, 2013 at 4:56 PM, Niels Möller nisse@lysator.liu.se wrote:
Attached is a patch that allows overwriting values (points and scalars) in the ECC API.
What's the use case? Just to clear sensitive memory, or do you do any operations on these values after zeroize?
The former.
In the former case, maybe it's better to just let the ecc_*_clear functions do that? Cost should be negligible, compared to doing any real ecc operation.
That would be different to practices in other parts of nettle... but would work as well.
And struct ecc_scalar (and struct ecc_point) is different from both these examples, since the space is explicitly allocated in ecc_scalar_init.
Note that from the nettle user's perspective one cannot zeroize the memory, as access to the structure that has the size requires "ecc-internals.h" which isn't installed.
Independently of what nettle does, I imagine you might want to use mp_set_memory_functions to make sure that all memory reallocated or freed by gmp is also overwritten.
That would work if I had full control on the application. If I use mp_set_memory as a library, other parts of the application could crash (we had such issue when gnutls was used together with another library that was setting the gmp allocation functions). Reallocations are not much of an issue to private keys, as they are typically added as a singleton. You've got a point here though.
regards, Nikos
PS. I've started with integrating the poly1305 code. I think we need the internal representation of the key and state to be implementation dependent. The C code you sent me uses 5 uint32_t, with 26 bits used in each. x86_64 assembly most likely wants to use 2 fully used uint64_t and one (smaller) variable for the top two bits, and 32-bit assembly would want 4 full uint32_t + top bits. All variants could be accomodated with something like
[...]
Everything depending on the internel representation would be collected into files poly1305-internal.{c,asm}, both the block processing, and code for installing a key and extracting a digest.
Sounds reasonable.