Nikos Mavrogiannopoulos <[email protected]> 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.
--
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.
_______________________________________________
nettle-bugs mailing list
[email protected]
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
