I've still looking at eddsa, and how to design the interface. I think we
need some structs ed25519_sha512_private_key and ed25519_sha512_public_key,
which can keep track of "expanded" keys. And a low-level function,
possibly like
void
_eddsa_sign (const struct ecc_curve *ecc,
const struct nettle_hash *H,
const uint8_t *pub,
void *k1,
const mp_limb_t *k2,
size_t length,
const uint8_t *msg,
uint8_t *signature);
where
ecc is the curve,
H the hash function,
pub is the public key as a string (I don't quite like it, but it is
needed in the hashing, and it seems inefficient to have to recompute
it from the private key)
k1 is a context struct for the hashing, updated with the secret
prefix. And destroyed in the process, so if the caller want's to sing
several messages, it should keep a copy.
k2 is the secret scalar
The output is produced as a string, not a pair of bignums, since that's
how eddsa is specified.
It's possible to also have an all-in-one functions, say,
ed25519_sha512_sign (const uint8_t *key,
size_t length, const uint8_t *msg,
uint8_t *signature);
One thing that's a bit unclear is in which form applications will store
private keys. Will they be *only* the private key (256 bits, according
to the spec), or will they be kept together with the public key? If the
public key is not included, it has to be recomputed (which will be
pretty fast, but I think it's desirable to do it once, when the key is
read, not for each signature created). It could be an optional input
somewhere in the interface.
--
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
