bip32_ed25519

Description:

bip32 ed25519

bip32-ed25519-dart #

The Dart implementation of the BIP32-Ed25519 the deterministic key generation scheme for Edward25519 curve
API Interfaces #
TBD
Key Types #

ED25519 (RFC 8032) Keys

the generated ed25519 signing key is 64-byte long and is created by the concatenation of the ED25519 seed (private key) and the generated public key.
the private key a.k.a seed is a 32-byte long cryptographically secure random data.


ED25519 Extended Keys

the private key is a 64-byte long cryptographically secure random data, and it can be interpreted as the SHA512 hashed and clear/set bit of an ED25519 seed or the first 32-byte (the seed part) of the ED25519 secret/private key.
they also can be interpreted as standalone keys, though brute-force is required for retrieving the ED25519 seed from an extended key.
The clears are set based on the RFC8032 specification.
an Extended key's left 32-byte is equivalent /w a X25519 (for EcDH) private key.


BIP32-ED25519 Keys

BIP32-ED25519 derivation requires that the 3rd bit of the 31th bytes of an ED25519 Extended key must be cleared.
This means that every BIP32-ED2559 signing key is valid Extended ED25519 key,
but half of the ED25519 Extended and therefore half of the ED25519 keys are not compatible /w BIP32-ED25519 keys.






Key ID
Constructors
Comment
Constraints




ed25519e_sk
ExtendedPrivateKey.generate()
All keys are valid, and will set the bits based on RFC8032
N/A



ExtendedPrivateKey.fromSeed(32)
All keys are valid, and will set the bits based on RFC8032
check length



ExtendedPrivateKey.decode('ed25519e_sk')
Will throw excpetions if the bits are not set.
check length and bits



ExtendedPrivateKey(64)
Will throw excpetions if the bits are not set.
check length and bits



public => _public()
returns /w an ed25519_pk verifying key
It's an expensive operation and should be created when it's first referenced



sign(message)
returns /w a signature
N/A



verify(sm, sig)
Simply verify by it's public key.
check sm messages and signature length


ed25519_pk
VerifyKey(32)
All keys are valid.
check length



verify(sm, sig)

check length(s)



verify(sm || sig)

check length(s)


ed25519bip32_sk
ExtendedBip32PrivateKey.generate()
All keys are valid, and will set the bits based on Bip32-Ed25519
N/A



ExtendedBip32Private.normalizeBytes(96)
All keys are valid, and will set the bits based on Bip32-Ed25519
check length



ExtendedBip32Private.fromVerifiedBytes(96)
All keys should be valid but we cannot validate it.
It's expensive to check the public key



ExtendedBip32PrivateKey.decode('ed25519bip32_sk')
Will throw excpetions if the bits are not set.
check length and bits



ExtendedBip32PrivateKey(96)
Will throw excpetions if the bits are not set.
check length and bits



ExtendedBip32Private.fromExtended(sk64, cc32)
Will throw excpetions if the bits are not set.
check length and bits



public => _public()
Inherited from ExtendedPrivateKey
It's an expensive operation and should be created when it's first referenced



sign(message)
Inherited from ExtendedPrivateKey
check length(s)



verify(sm, sig)
Inherited from ExtendedPrivateKey
check sm messages and signature length



verify(sm || sig)
Inherited from ExtendedPrivateKey
check length(s)



derive(index)
Inherited from ExtendedPrivateKey
check index



chainCode => ChainCode(suffix)
Returns /w a chain code value object
check length(s)



getExtended => ExtendedPrivateKey.fromValidBytes(64)
Returns and extended key as every Bip32-Ed25519 is a valid Extended Ed25519 key



ed25519bip32_pk
ExtendedBip32PublicKey(64)
All keys are valid
check length(s)



ExtendedBip32PublicKey.fromKey(pk32, cc32)
All keys are valid
check length(s)



verify(sm, sig)
Inherited from VerifyKey
check length(s)



verify(sm || sig)
Inherited from VerifyKey
check length(s)



derive(index)
Inherited from VerifyKey
check index range



chainCode => ChainCode(suffix)
Returns /w a chain code value object
check length



getExtended => ExtendedPublicKey.fromValidBytes(prefix)
Returns and extended key as every Bip32-Ed25519 is a valid Extended Ed25519 key
It's cheap operation



Key Standardization #



KeyPair
key
verifyKey
encryptionKey
publicKey
rawKey
Comment




ed25519
ed25519_sk
ed25519_pk
N/A
verifyKey
ed25519_sk
This is the 32-byte long seed



ed25519_skpk
ed25519_pk
N/A
verifyKey
ed25519_sk
rawKey is the 32-byte long seed



ed25519_pk
ed25519_pk
N/A
verifyKey
ed25519_pk
rawKey is the key itself


Extended Ed25519
ed25519_esk
ed25519_pk
x25519_sk
verifyKey
ed25519_esk
rawKey is the key itself



ed25519_pk
ed25519_pk
x25519_pk
verifyKey
ed25519_pk
rawKey is the key itself


Bip32-Ed25519
ed25519_eskcc
ed25519_pkcc
x25519_sk
verifyKey
ed25519_esk
rawKey a valid extended key



ed25519_pkcc
ed25519_pkcc
x25519_pk
verifyKey
ed25519_pk
rawKeys is a valid Ed25519 signing key


X25519
x25519_sk
N/A
x25519_pk
encryptionKey
x25519_sk
rawKey is the key itself



x25519_pk
N/A
x25519_pk
encryptionKey
x25519_pk
rawKey is the key itself



ED25519 Keys #
The ed25519 is an
Elliptic Curve Digital Signature Algortithm using curve25519 by Dan Bernstein,
Niels Duif,
Tanja Lange,
Peter Schwabe,
and Bo-Yin Yang.
The key is 64-byte long and contains the the 32-byte long seed a.k.a private key that is used for
generate the secret key and public key.
ED25519 Extended keys #
The 64-byte long extended keys contains either
- only the 64-byte long secret key.
- or the 64-byte long extended private key and the 32-byte public key similar to the normal
ED25519 key whihc contains the 32-byte private key (seed) and the 32-byte long private key.
Though, pinenacl-dart's extended interface expecting a concatenated secret and public key.
It's due to the assumption that the public key is already known (no scalar_base multiplication is needed for retrieveing the key)
The message signing and signature verifying is compatible /w ED25519.
BIP32-ED25519 Keys #
The 96-byte long BIP32-ED25519 keys contains a ed25519e_sk and the chain code.
The message signing and signature verifying is compatible /w ED25519.
References #

The Provable Security of Ed25519: Theory and Practice

Restrictions #
In Cardano blockchain, the keys are derived by the BIP32-ED25519 specification.
The BIP32-ED25519, in addition to the ED25519 (RFC 8032), needs the 3rd bit cleared of the 31th byte.
Therefore, the half of the ED25519 Extended secret keys and therefore the half of the ED25519 private keys are not compatible /w BIP32-ED25519.
To overcome of this restriction, different wallet implementation decided to generate their master node/root key differently (as BIP32-ED25519 specification only requires that bit cleared on the master node/root key as the derived keys would have that bit cleared in the derivation functions anyway).
Some of them (such as Yoroi), just clear that additional 3rd bit, while others (such as the old Daedalus) are hashing the corresponding master key until they find a compatible key, and when it's found, they set and clear the bits as specified in the RFC 8032.
Resolution #
There can be different type of resolutions. The most proper way would be: generate only a BIP32-ED25519 compatible 24-word mnemonics and therefore a 256-bit long master secret for new wallets and discard others (as it's is specified in the Bip32-Ed25519 paper).
Then use that 256-bit master secret as k specified in BIP32-ED25519.
Drawback of this is that half of the already existing user's mnemonics are not compatible, therefore
they need either to move to a new wallet or using some out-dated master-key generation algorithm. The other disadvantege of this is that it would impact the plausible-deniability feature, meaning by when a BIP32-ED25519 compatible 256-bit long seed is generated from a 24-word mnemonic with using an additional password/passphrase by BIP-0039, it could happen that the other seed generated from the same mnemonic, but with no or some different passhprase, would not be BIP-ED25519 compatible.