.png%3Falt%3Dmedia%26token%3Df1ef2478-f284-4273-ae02-1278d11f049e)
.png%3Falt%3Dmedia%26token%3Df1ef2478-f284-4273-ae02-1278d11f049e)
Comment on page
Keys & Key Derivation
In Nocturne's MetaMask Snap, we derive theusing thesnap_getBip44Entropymethod at derivation pathm / 44' / 6789'.
Let
denote the generator of Baby Jubjub's prime-order subgroup. The user's spending public key, which we will refer to as
, is an element of Baby Jubjub defined as
(
means "0th through 32nd byte"). This is only used to verify signatures in-circuit. It never appears on-chain or leaves the client.
What we refer to as the "generator" is often called the "base point" in order to differentiate between generator of Baby Jubjub's curve group and the generator of Baby Jubjub's prime-order subgroup. Since all operations are performed in the prime-order subgroup, we're ignoring this distinction and using the word "generator" to refer to the generator of the prime-order subgroup.
The user's viewing key is an element of
defined as
, where
are the x and y coordinates of
respectively,
, and
must be chosen such that the output of the hash is an element of
.
That last provision is needed because
returns an element of
, but we need an element of
. A reduction modulo
would bias the key generation, and using Poseidon over
would be prohibitively expensive in-circuit. But this approach suffers from neither issue - during key generation, we can increment
vkNonce and try again if the output of the hash is not an element of .
In theory, rejection sampling like this comes small performance cost. ~91% of the possible, so we expect that, on average, it will take 10-11 tries to find a "good" nonce. In practice, the cost is negligible - 11 attempts takes ~30ms with a very naive implementation.