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.
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.
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_pk||32||Ed25519 signatures||Can be converted to
|Extended Ed25519||ed25519e_sk||ed25519_esk||64||Ed25519 signatures||Can be converted to
|Bip32-Ed25519||ed25519bip32_sk||ed25519bip32_skcc ed25519bip32_eskcc xprv (not recommended)||96||Ed25519 signatures||Can be converted to
|ed25519bip32_pk||ed25519bip32_pkcc xpub (not recommended)||64||Ed25519 signatures||Can be converted to
|X25519||x25519_sk||32||ECDH||The left part of an
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.
|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|