Multiple cryptosystems #6

New issue

Open

opened 2025-08-23 08:03:24 +12:00 by mikedilger · 0 comments

mikedilger commented

2025-08-23 08:03:24 +12:00

(Migrated from github.com)

It would be nice to support secp256k1 as well as ed25519, and it would be nice to be ready for post-quantum cryptography.

NOTE: This is NOT the same as supporting nostr. In this case, secp256k1 keys would generate signatures of mosaic records, not of nostr records.

Stage 1 - Support for future additions of cryptosystems

To support any future cryptosystem, and any length of public key or signature, we do the following:

Presume that the public key fields in records are either (a) the public key itself or, (b) a hash of the public key, the full key you can lookup somewhere else. With this presumption, we don't need to make the public key fields variable size, we can keep them 32 bytes.
Move the signature to the end so that the signature can be variable size in the future.

This is already in place.

Stage 2 - Support secp256k1 as signature keys, but not master keys

For this, we need

A record bit flag indicating that the signing key is secp256k1 and the signature is such (but of the mosaic record, not a nostr signature)
A way to mark secp256k1 keys on your keyschedule

This is already in place, but disabled in the spec.

Stage 3 - Support a new specific cryptosystem for user master keys

For this, we need

A new bootstrap system designed around the cryptosystem (to lookup by the secp256k1 key, for example)
Flags in printed keys (mosec, mocryptsec) specifying the cryptosystem

What we do not need

No additional flag needed in the record (the master key is used to lookup, not to sign/verify)
No flag needed in an address. Addresses can be used for lookup without knowing the cryptosystem
No flag in bootstraps to indicate cryptosystem.

Stage 4 - Support a new specific cryptosystem for server keys

TBD

It would be nice to support secp256k1 as well as ed25519, and it would be nice to be ready for post-quantum cryptography. NOTE: This is NOT the same as supporting nostr. In this case, secp256k1 keys would generate signatures of mosaic records, not of nostr records. # Stage 1 - Support for future additions of cryptosystems To support any future cryptosystem, and any length of public key or signature, we do the following: * Presume that the public key fields in records are either (a) the public key itself or, (b) a hash of the public key, the full key you can lookup somewhere else. With this presumption, we don't need to make the public key fields variable size, we can keep them 32 bytes. * Move the signature to the end so that the signature can be variable size in the future. This is already in place. # Stage 2 - Support secp256k1 as signature keys, but not master keys For this, we need * A record bit flag indicating that the signing key is secp256k1 and the signature is such (but of the mosaic record, not a nostr signature) * A way to mark secp256k1 keys on your keyschedule This is already in place, but disabled in the spec. # Stage 3 - Support a new specific cryptosystem for user master keys For this, we need * A new bootstrap system designed around the cryptosystem (to lookup by the secp256k1 key, for example) * Flags in printed keys (mosec, mocryptsec) specifying the cryptosystem What we do not need * No additional flag needed in the record (the master key is used to lookup, not to sign/verify) * No flag needed in an address. Addresses can be used for lookup without knowing the cryptosystem * No flag in bootstraps to indicate cryptosystem. # Stage 4 - Support a new specific cryptosystem for server keys TBD