Nikos Mavrogiannopoulos nmav@gnutls.org writes:
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?
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.
Other nettle functions don't ovewrite any memory, and leaves that for the application. Some examples:
1. AES context. The caller can easily do memset (ctx, 0, sizeof (*ctx)) if desired, and that will overwrite the subkeys. And there's no *_clear function to hang that functionality on.
2. RSA private key. Sensitive data is in mpz_t variables, and one reason nettle's rsa_private_key_clear doesn't try to overwrite them is that I don't think there's any easy GMP interface to do that.
And struct ecc_scalar (and struct ecc_point) is different from both these examples, since the space is explicitly allocated in ecc_scalar_init.
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.
Regards, /Niels
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
struct poly1305_value { union { uint32_t s[4]; uint64_t d[2]; } u; uint32_t hi; };
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.