Concept
Cryptography
The cryptographic building blocks of Tenrai. ML-DSA-65 signatures, SHA-384 identifiers, SHAKE256 locks, post-quantum TLS, and how they are kept apart.
Tenrai uses post-quantum signatures everywhere a signature decides something: spending, staking, votes, node identity, API answers and releases. There is no classical signature scheme to fall back or downgrade to.
Primitives
| Purpose | Primitive |
|---|---|
| Signatures | ML-DSA-65, FIPS 204, NIST security category 3 |
| Identifiers and commitments | SHA-384 with a domain and length framing |
| Spend locks | SHAKE256 over the public key |
| Proof of work | TenQ, built on SHAKE256 |
| Transport key exchange | X25519MLKEM768, a hybrid of X25519 and ML-KEM-768, in TLS 1.3 |
| Wallet encryption | Argon2id and XChaCha20-Poly1305 |
| Messenger | ML-KEM-512 key encapsulation, XChaCha20-Poly1305, see TCC-0009 |
| Release signatures | ML-DSA-65 and SLH-DSA-SHA2-192s, both required |
| ML-DSA-65 | Size |
|---|---|
| Public key | 1,952 bytes |
| Signature | 3,309 bytes |
One context per purpose
FIPS 204 binds a context string into every signature. Tenrai gives each purpose its own, so a signature made in one role is never valid in another, whatever the signed bytes are.
| Context | Signs |
|---|---|
TRAI/UTXO/SPEND/1 | The authorization of one input |
TRAI/POS/OPERATION/1 | A staking operation, by its owner |
TRAI/POS/POSSESSION/1 | Proof that a validator holds its consensus key |
TRAI/POS/HEARTBEAT/1 | A validator heartbeat, by its consensus key |
TRAI/CUT/VOTE/1 | A committee vote, and so a cut certificate |
TRAI/P2P/NODE-AUTH/1 | Node authentication between peers |
TRAI/API/RESPONSE/1 | A signed API answer |
TRAI/RELEASE/MLDSA65/1 | A release manifest |
TRAI/ADDRESS/PROOF/1 | An address ownership proof |
An ownership proof can therefore never authorize a spend, and a spend signature never proves ownership to a third party.
Hashing
Every identifier, whether transaction, work block, cut or state root, is a SHA-384 digest of 48 bytes, written as 96 hexadecimal characters. Each commitment names an ASCII domain and frames every field with its length:
SHA-384( len(domain) ‖ domain ‖ field count ‖ len(field 0) ‖ field 0 ‖ … )The lengths make it impossible for two different sets of fields to produce the same input. 384 bits keep a comfortable margin against generic quantum search.
Deterministic verification
Whether a signature is valid is a consensus question: two nodes that disagreed about one signature would disagree about a block. Every node therefore verifies with the same portable ML-DSA-65 implementation instead of choosing one by CPU features. Signing may use the fastest code available, because a faulty signature simply fails for everyone.
Transport
Node to node, wallet to service and miner to pool connections use TLS 1.3 and offer X25519MLKEM768 as the only key exchange. That protects traffic recorded today against decryption by a later quantum computer.
Peers additionally authenticate each other with ML-DSA-65 over a transcript that includes key material exported from that TLS session. A machine in the middle that terminates two sessions cannot forward the exchange from one to the other.
Browsers choose the key exchange themselves. A wallet in a browser checks the signed answers of the service it talks to.