BetterSign™

Cryptographic Model

BetterSign separates stable identity from active cryptographic material. The VLAD anchors the identity; the provenance log records the current keys, algorithms, lock scripts, unlock scripts, and proofs.

Keys and signatures are stored as typed multikey and multisig values. A verifier does not trust a label alone: it parses the encoded object, checks the codec, verifies the signature or proof, and accepts a state transition only if the previous log policy authorized it.

This model lets a BetterSign identity use Ed25519 today, rotate to a post-quantum signature later, or keep multiple subsystem keys under different plog paths without changing the stable VLAD.

Signatures

BetterSign supports classical signatures for operational compatibility and post-quantum signatures for future-facing identity policy.

Ed25519 is the default day-to-day signing key in many workflows because it is compact, fast, and widely supported by SSH. Ed448 offers a higher-security Edwards curve, secp256k1 is available for ecosystems that already use it, and BLS12-381 supports aggregate and threshold-style workflows.

The codebase also includes ML-DSA, FN-DSA, SLH-DSA, MAYO, hybrid Ed25519/BLS post-quantum codecs, and two hash-based families: XMSS (stateful) and Lamport (one-time, with threshold shares). BetterSign can carry all of these in identity state, while individual protocol integrations may accept only the algorithms their surrounding ecosystem can encode.

Encryption and KEMs

The /keys/encrypt path carries the current public encryption material for an identity. Other peers resolve and verify the recipient plog before sealing messages or command envelopes to that key.

X25519 is the compact classical KEM used by default identity creation. BetterSign also supports post-quantum KEM families including ML-KEM, FrodoKEM, SNTRUP, and Classic McEliece, plus hybrid X25519/post-quantum KEM codecs for migration paths.

WireGuard PSK rotation and BetterSign message exchange can use this plog-resolved encryption material so peers rotate secrets through verified identity state rather than manually copying shared files.

Post-Quantum KEMs

BetterSign can carry post-quantum KEM public keys in verified identity state and use them for encrypted envelopes, key-agreement workflows, and subsystem-specific control-plane exchanges.

The supported PQ KEM list includes FrodoKEM, SNTRUP, and Classic McEliece in addition to ML-KEM. These are encoded as typed multikey values, so followers know which algorithm family and parameter set they are verifying before using the key material.

Hybrid KEMs are also supported for deployments that want classical X25519 security and post-quantum KEM security in the same key agreement.

Stateful and One-Time Signatures

Two hash-based families need careful key-state handling. XMSS is stateful: every signature consumes a leaf index, and reusing an index can expose the key, so the advanced private key must be persisted before another signature is issued. Lamport is one-time: a key may sign at most one message before its secret is exposed.

BetterSign enforces these properties where it matters most — at verification. Provenance-log verification rejects an XMSS signature that reuses or rolls back a leaf index, and rejects a second signature by the same Lamport public key, both within a single verification pass.

Threshold Signing and Distributed Key Generation

BetterSign supports two distinct threshold behaviors, and the difference matters. Threshold signing has participants each hold a share and jointly produce one ordinary signature without any party ever reconstructing the private key. Static key splitting for recovery divides a whole private key into shares that are later reassembled; that is backup, not threshold signing, and it does briefly reconstruct the key.

Threshold signing is available through FROST across Ed25519, P-256, P-384, secp256k1, and Ed448, plus a separate BLS12-381 path for BLS signature shares. Distributed key generation, which creates the shared key so the full secret never exists in one place, is implemented for those curves, including BLS12-381. Lamport one-time keys can also be split into t-of-n shares whose partial signatures combine into a full signature, though each combined signature still consumes the key single use.

Static splitting and recovery is broader: implemented private-key material, including RSA, classical elliptic curves, post-quantum signatures and KEMs, and hybrid keys, can be split into t-of-n shares and later reconstructed. Curve scalar keys use verifiable Feldman sharing where applicable; opaque post-quantum, RSA, and hybrid secret bytes use GF(256) sharing.

Signature Size at a Glance

One tradeoff is easy to feel once you see it: classical signatures are tiny, while post-quantum and hash-based signatures buy their quantum resistance with size. That size shows up in every signed commit, certificate, and log entry, so it matters for storage and bandwidth.

Public Key Size at a Glance

Signature size is only half the story — public key size matters too, and the ranking is different. Notably, hash-based SLH-DSA has tiny public keys even though its signatures are large, while the lattice schemes carry bigger keys.

Choosing an Algorithm: Tradeoffs

No single algorithm is best for every path. Classical curves are small and fast but not post-quantum. Lattice PQ schemes are well-rounded but larger. Code-based schemes have large keys but conservative assumptions. Hash-based schemes rest only on a hash function but trade away size or reusability; for deeper background on the stateful and one-time hash-based options, see SKIPSH.

Because BetterSign stores typed keys per plog path, one identity can use different algorithms for different jobs — a compact Ed25519 for SSH, a lattice or hash-based key for long-horizon signing, and a separate KEM for encryption — and rotate any of them without changing the VLAD.

Hashes, CIDs, and Proofs

Provenance log entries are content-addressed. If an entry changes, its CID changes, which breaks the chain unless the altered bytes are reintroduced as a newly authorized entry.

Hashes are multihash-labeled, so a verifier knows which function produced a digest. The supported generation set includes SHA-2 (256/384/512), SHA-3 (224/256/384/512/512-256), Keccak, BLAKE2b, BLAKE2s, BLAKE3, RIPEMD-160, and MD5. SHA-1-labeled legacy multihashes remain decodable for interoperability, but BetterSign no longer generates SHA-1 digests.

Plog proof data is a map of named byte strings. A standard identity entry may carry primary and recovery signatures, while another workflow can carry hash preimages, threshold signature shares, or application-specific proofs.

Lock and unlock scripts decide which proof names matter. That keeps the log format stable while allowing new authorization policies to be introduced by the identity itself.

Protocol Boundaries

A BetterSign plog can hold more cryptography than every downstream protocol can consume. SSH authorized_keys needs OpenSSH-encodable public keys. X.509 and rustls-backed TLS have their own algorithm limits. WireGuard identities have fixed key formats and use BetterSign mainly for verified metadata and PSK coordination.

BetterSign handles that by separating identity policy from integration policy. The plog can retain rich state, while each integration reads only the paths and algorithms it knows how to apply safely.