CIP outlining standard for key serialisation formats

[intricate]

This CIP aims to standardize cryptographic key serialisation formats to be used by projects throughout the Cardano eco-system.

[dcoutts]

@intricate thanks very much. We had a first look at this at the CIP editors meeting this week. I don't expect you to push this one along, and I've asked @SebastienGllmt to help, though if you want to that's great of course.

Main initial thought from Sebastien and I was that we should also mention the extended-but-not-bip32 format, just to clarify the relationship between them all, and say which formats are actually used. and which are legacy.

[ilap]

Yes, some standard should be required.

And the following can be the base of the conversation.

There are two type of keys associated /w the Curve25519 (this also applies to the Curve448 as ED448 or X448, which gives 224-bit security instead of the current ~128)

• Ed25119 - EdDSA, for signing and verifying and
• X25519 - ECDH, for encryption/decryption

Therefore, the common prefix could be

• Ed25519
• Ed25519Extended
• Ed25519e
• Ed25519Bip32
• x25519 etc.

The common suffix could be

• sk as secret key
• sk as signing key
• pk as private key
• pk as public key (should not be interpreted as public key)
• vk as verify key
• esk as extended signing key
• epk as extended public key
• skpk as concatenation of signing and verifying key
• xsk as extended signing key
• xvk as extendend veriying key
• esk as extended secret key
• eskcc as extended secret key /w cc
• xsk as extended secret key
• xskxx as extended secret key /w chaincode
• pkcc s extended public key /w chain code
• vkcc as extended public key /w chain code
• and some others I am not aware of.

My thoughts

• There are only 2 types of keys (despite the Bip32 and Extended additions, they are only Ed25519)
• Ed25519
  • Every BIP32-Ed25519 is valid Extended key (bits are set and cleared, an additional bits is cleared)
  • Every extended keys are compatible /w Ed25519 signature algorithm
  • Therefore every Bip32-Ed25519 keys are compatible /w Ed25519 Signature alg.
  • But, not every Ed25519 key (and therefore Extended key) is a valid Bip32 key, therefore the other way to be a valid Ed5519 key needs brute forcing or cracking the hashing alg.
• X25519
  • Every first 32-byte of the Extended and Bip32 secret keys are valid X25519 secret (encryption) keys
  • Every Ed25519 public keys can be converted to X25519 public (encryption) keys (the other way is not trivial as there will be 2 valid Ed25519 keys from an X25519 public key)

So, we do not need to distinguish between verify/signing and encryption/decryption keys as the prefix would already do that anyway.

One caveat I see, is the confusion between the definition of the extended keys:

1. BIP32 - it defines it as the concatenation of the secret key and the chain code
2. BIP32-Ed25519 - it defines it as the stretched (by PBKDF2, SHA512 etc as the spec allows use different stretching algs) secret key (64 or 96 byte long).
3. In Cardano ecosystem - it is a mix of these above, with not clear definition (see different stretch, key gen algs).

I am seeking for opinion from all of you guys @intricate @dcoutts @SebastienGllmt and from others.
As I can imagine the esk and pk could be related to only the normal (stretched) extended keys, while xsk and xvk to a Bip32-Ed25519 key pairs.

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
or	ed25519_xsk	ed25519_xpk	x25519_sk	verifyKey	ed25519_esk	rawKey a valid extended key
	ed25519_xpk	ed25519_xpk	x25519_pk	verifyKey	ed25519_pk	rawKeys is a valid Ed25519 signing key
not recommended	ed25519_xsk	ed25519_xvk	x25519_sk	verifyKey	ed25519_esk	rawKey a valid extended key
	ed25519_xvk	ed25519_xvk	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

UPDATED

[ilap]

As I can imagine the esk and pk could be related to only the normal (stretched) extended keys, while xsk and xvk to a Bip32-Ed25519 key pairs.

Meaning:

• sk: represents the normal 32-byte log Ed25519 secret key called (seed), not stretched and bits are not set/cleared.
  • pk represent its public key
• esk: represent the streched sk, bits are set and cleared
  • pk represent its public key, as this is just a nomral Ed25519 public key.
• xsk: represent an esk with the additional bit is cleared and concatenated /w the chaincode.
  • xpk or xvk (not recommented imo) represents the normal pk | cc as it's just a concatenation of a normal Ed25519 public key /w the chain code.

Though, the xskcc with the pkcc can be the option, but the xsk, xpk (or xvk) sounds to me better.

[ilap]

The reason I am against the vk like suffixes as we should change the ed25519_pk to ed25519_vk then or similar for being consistent.

[dcoutts]

@ilap thanks for all the input. Needs a bit of thinking to digest.

I should note that if we're talking about bech32 prefixes, the prior art that we should be consistent with is https://github.com/cardano-foundation/CIPs/blob/master/CIP-0005/CIP-0005.md. We use prefixes there to indicate the role of the key and not merely the format. So there are several ed25519 keys there with different roles, and thus different prefixes.

This explicit use of roles helps to avoid some cases of user error since it allows tools (e.g. cli tools) to see that someone has asked to use an inappropriate key type in some place (even if it happens to be the same underlying key type).

[crptmppt]

Tentatively flagging as CIP-0016 & adding to tomorrow's review agenda (~24 hours from now at https://www.crowdcast.io/e/cip-editors-meeting-18)

[KtorZ]

On second thoughts, this looks both more specific than "Cryptographic Key Serialisation Formats" (doesn't really refers to any key, but specifically to ed25519 keys).

On the other hand, it also feels very much connected to CIP-0005 since this specifies the so-called data-part coming with the prefixes specified in CIP-0005. I'd suggest to transform this PR into an extension of CIP-0005 specifying the datapart for all binary objects specified in CIP-0005; starting however with just the various *_vk, *_sk, *_xvk, *_xsk stated in the CIP.

To summarize: I am fully okay with the content of the CIP, yet I think it could / should be framed differently to have more impact and more usability with CIP-0005.

---

In today's meeting, we also agreed to have a cryptographer from IOG look at it and comment on the soundness of the serialization format.

[iquerejeta]

Serialisation format looks good to me

[crptmppt]

Considering this PR/CIP as reviewed as per CIP Editors meeting #19 - moving to Last Check / pending merge (tentative CIP-0016)