[bootstrap] Key Generation for Unstaked Access Nodes #1180
Conversation
huitseeker
force-pushed
the
unstaked-an-key
branch
3 times, most recently
from
2436f2d
to
023e006
Compare
This introduces a generator for the unstaked Access Nodes, which by convention only have positive secp256k1 keys.
huitseeker
force-pushed
the
unstaked-an-key
branch
from
023e006
to
44c7a67
Compare
| @@ -18,6 +23,63 @@ func GenerateMachineAccountKey(seed []byte) (crypto.PrivateKey, error) { | |||
| return keys[0], nil | |||
| } | |||
|
|
|||
| // The unstaked nodes have special networking keys, in two aspects: | |||
| // - they use crypto.ECDSASecp256k1 keys, not crypto.ECDSAP256 keys, | |||
| // - they use only positive keys (in the sense that the elliptic curve point of their public key is positive) | |||
There was a problem hiding this comment.
I didn't find a definition that uses the terms "positive" and "negative" points. It would be good to add a link to definitions using these terms since they are not self explanatory.
I am more familiar with the "parity" term used in this context, or to not use any adjective and just give a definition (like 0x02 if y mod p is even, and 0x3 otherwise).
There was a problem hiding this comment.
- I agree that connecting this bit with a notion of sign requires the reader to be familiar with curves defined in Weierstrass form & with p>3 (and then the notion of sign is apparent from the definition of point inverse and the square in the equation). We could indeed reformulate that part.
- I'm confused about where the notion of parity comes from here: it seems to me standards specify both little-endianness and the ỹ bit as a MSB ? (whereas a parity bit would be a LSB?) e.g.:
- IEEE 1363 ( doi 10.1109/ieeestd.2000.92292 ) section A.9.6
- SEC 1 v2 section 2.3.3
- X9.62 section 4.2-4.3
There was a problem hiding this comment.
- I think even considering prime fields with p>3, it's still not clear which point should be called positive between (x,y) and (x,p-y). In some other cases (like the Zcash definition for BLS12-381) the sign of a point is defined as the comparison of y with
(p-1)/2. This is why I thought we had to specify what definition we are referring to in our case.
Regarding the second point:
- IEEE 1363 defines ỹ as (y mod 2) with y seen as an integer less than p (because strictly speaking, y is a field element). It also uses the "rightmost" bit of the integer y.
- SEC 1 uses the "rightmost" bit of y. Looking at the definition of octet strings, "rightmost" represents the LSB.
- X9.62 uses (y mod 2)
There was a problem hiding this comment.
I think even considering prime fields with p>3, it's still not clear which point should be called positive between (x,y) and (x,p-y)
OK, I get your point better, now.
SEC 1 uses the "rightmost" bit of y. Looking at the definition of octet strings, "rightmost" represents the LSB.
Yep, there's one step between the bit string and the octet sting I missed.
And of course, looking at a mod 2 over a field element, rather than backtracking from bytes, the notion of parity makes sense.
I'll issue a PR to reformulate comments.
There was a problem hiding this comment.
There is no rush to create a specific PR for this. Including the X9.62 link as you did was good.
We can just update the references to positive and negative keys in a future libp2p related PR.
|
bors merge |
This introduces a generator for the unstaked Access Nodes, which by convention only have positive secp256k1 keys.
The keys in question have a specific format (positive ECDSA Secp256k1 keys) because:
For this bijection, see [network] Validate Unstaked ID translation #1165 and [network, crypto] Compressed serialization, key conversions and message signing #1129.
This is to be used in a bootstrap of the unstaked Access Node post #1133.
For now, having this in master allows the direct bootstrapping of network in tests by creating suitable libp2p peers.