Private keys can be used to sign arbitrary data. If you have the public key, you can verify the data was signed by the owner of the private key. This is how transaction signing works internally but its utility is not limited to transactions. This document tries to set a standard for how to represent and verify signed messages for Cardano.
5 Likes
Would love if someone could add graphics to this CIP - it’s technically very fleshed out but might be a bit hard to wrap one’s head around if anyone is able to step up!
Currently live in the CIP repository here.
1 Like
Hi @SebastienGllmt,
Just came across to this CIP-0008 what what @Frederic posted above and was wondering the encryption part of it.
I would say, and I think that almost all the cryptographers would agree, that you should never use an Ed25519 verify key for ECDH but only X25519 public keys, for several reason I do not want to point out.
Though, fortunately, an Ed25519 verify key can be easily converted to an X25519 public key for encryption. The other way is not straight forward as you would get two valid Ed25519 verify keys.
Also, the first 32-byte of a Cardano’s extended key is a valid X25519 private key, so there is some easy change could be made for that specification to be securely valid. Though, you should consults /w some IOG’s cryptograpers relating to that encryption part. I am still digesting the other parts.
Also, a good idea could be to standardise the bech32 hrps for the keys too.
for example I just generated this table now.
| Keypairs | Main HRP | Alt HRP(s) | Key length | Purpose | Comment |
|---|---|---|---|---|---|
| ed25519 | ed25519_sk | ed25519_skpk | 64 | Ed25519 signatures | |
| ed25519_pk | 32 | Ed25519 signatures | Can be converted to x25519_pk for ECDH |
||
| Extended Ed25519 | ed25519e_sk | ed25519_esk | 64 | Ed25519 signatures | Can be converted to x25519_sk for ECDH |
| ed25519_pk | 32 | Ed25519 signatures | |||
| Bip32-Ed25519 | ed25519bip32_sk | ed25519bip32_skcc ed25519bip32_eskcc xprv (not recommended) | 96 | Ed25519 signatures | Can be converted to x25519_sk for ECDH |
| ed25519bip32_pk | ed25519bip32_pkcc xpub (not recommended) | 64 | Ed25519 signatures | Can be converted to x25519_pk for ECDH |
|
| X25519 | x25519_sk | 32 | ECDH | The left part of an ed25519e_sk or ed2551bip32_sk is a valid X255119 private key. |
|
| x25519_pk | 32 | ECDH |
I gave it a second thought and this below (As some API like presentation for the publicKey, rawKey, encryptionKey, signignKey and verifyKey) would make much more sense, as there are only two type of keys. The Ed25519 (for EdDSA i.e. Signatures signing/verify keys) and the X25519 (for ECDH encryption keys) and the Extended and the Bip32-Ed25519 keys are theoretically same keys.
But, this could be discussed further, but I doubt it would make any progress imo.
| 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 The encryption key is the first 32-byte long bytes |
| 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 |