Hello, Attached is a patch that allows overwriting values (points and scalars) in the ECC API.
regards, Nikos
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.
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.
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? 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.
I've checked it a bit further. Would the following on top of nettle be equivalent? void ecc_point_zeroize (struct ecc_point *p) { memset(p->p, 0, 2*ecc_size(p->ecc)*sizeof(mp_limb_t)); /* or using ecc_size_a() be better here? */ }
void ecc_scalar_zeroize (struct ecc_scalar *s); { memset(s->p, 0, ecc_size(s->ecc)*sizeof(mp_limb_t)); }
Then the only change needed in nettle would be for those sizes to be documented.
regards, Nikos
Nikos Mavrogiannopoulos nmav@gnutls.org writes:
I've checked it a bit further. Would the following on top of nettle be equivalent? void ecc_point_zeroize (struct ecc_point *p) { memset(p->p, 0, 2*ecc_size(p->ecc)*sizeof(mp_limb_t)); /* or using ecc_size_a() be better here? */ }
void ecc_scalar_zeroize (struct ecc_scalar *s); { memset(s->p, 0, ecc_size(s->ecc)*sizeof(mp_limb_t)); }
I think that should work fine. And using ecc_size_a seems to be appropriate for the first function.
Then the only change needed in nettle would be for those sizes to be documented.
Right, it seems all three ecc_size* functions are undocumented, and at least ecc_size () and ecc_size_a () make sense for users.
Regards, /Niels
nettle-bugs@lists.lysator.liu.se