mirror of
https://github.com/cathugger/mkp224o.git
synced 2025-04-18 21:12:02 +00:00
--combine: regenerate the second half of the key
i think that before this commit the miner could recover your private key after you set the hidden service up. whoops
This commit is contained in:
parent
656502b797
commit
e0244d41da
1 changed files with 15 additions and 0 deletions
15
main.c
15
main.c
|
@ -357,8 +357,23 @@ static void combine(const char *privpath, const char *hs_secretkey)
|
|||
ge25519_scalarmult_base(&A, &a);
|
||||
ge25519_pack(pk, &A);
|
||||
|
||||
// Save secret scalar.
|
||||
sc25519_to32bytes(&secret[32], &a);
|
||||
|
||||
// Compute second half of the key.
|
||||
// See "Pseudorandom generation of r.", page 8 of https://ed25519.cr.yp.to/ed25519-20110926.pdf
|
||||
// You're supposed to generate it together with the secret scalar, but
|
||||
// we can't really do that here. As far as I can tell, it just needs to
|
||||
// be another secret value.
|
||||
// In normal Ed25519 you never have a pair of keys with the same secret
|
||||
// scalar but different second halves (I can't find the proper term for
|
||||
// it...). If I generated them independently from the secret scalar,
|
||||
// someone could run --combine and get such a pair of keys.
|
||||
// I don't know if that would mess anything up, but to err on the side
|
||||
// of caution, I'm setting it to a hash of the secret scalar and the
|
||||
// original generated key.
|
||||
FIPS202_SHAKE256(secret, sizeof secret, &secret[64], 32);
|
||||
|
||||
sc25519_from32bytes(&a, &secret[32]);
|
||||
ge25519_scalarmult_base(&A, &a);
|
||||
ge25519_pack(pk, &A);
|
||||
|
|
Loading…
Add table
Reference in a new issue