Cryptography

Tenzro Network 1 is post-quantum from genesis. Every signature that authorises a transaction, a vote or a custody change has a post-quantum leg, and every channel between validators is keyed with a post-quantum key encapsulation. The classical algorithms stay alongside the post-quantum ones, so an attacker has to break both.

Primitives

Composite hybrid signatures

A Tenzro signature is one composite object with two legs: a classical signature (P-256 from a passkey, TPM or Secure Enclave, or Ed25519) and an ML-DSA-65 signature. It follows the IETF composite ML-DSA construction:

• Both legs are required. A verifier accepts the signature only if both legs verify. There is no classical-only path and no post-quantum-only path.
• Non-separable. Both legs sign a message that is bound to the composite: to the pairing of the two public keys and to a domain label for the construction. A leg lifted out of a composite signature does not verify as a stand-alone signature, and cannot be recombined with a different partner.
• Bound to the account. The ML-DSA-65 public key used for transactions is part of the account's identity. A transaction's hash commits to the sender's post-quantum key, and the network checks that this key belongs to the sending account. A valid ML-DSA-65 signature from any other key is rejected.

The same construction covers passkey operations (P-256 + ML-DSA-65), validator handshakes (P-256 + ML-DSA-65, signed by the validator's hardware key) and guardian approvals.

Where keys come from

Classical keys live in hardware: a passkey authenticator, a TPM 2.0 or a Secure Enclave. The ML-DSA-65 key that pairs with each one is derived from the same hardware root when it is needed, used in memory and wiped. Nothing that can sign is kept in a file. See Hardware-rooted keys.

Consensus

Tenzro DAG Consensus (TDC), our post-quantum consensus protocol, uses these primitives throughout:

• Channels. Validator-to-validator channels are keyed with a hybrid of X25519 and ML-KEM-768. The handshake is signed by each validator's hardware key with a composite ML-DSA-65 + P-256 signature.
• Votes. Validators sign votes with an in-memory session key that their TPM certifies once per epoch.
• Finality certificates are signed with ML-DSA-65. They are portable: a light client, a bridge or a new node can check them, and they are the evidence used to slash double-signing.
• STARK compression. Finality certificates are compressed with STARK proofs.

See Consensus and Finality certificates.

Encryption

Key agreement is hybrid wherever a long-lived secret is at stake: an X25519 exchange and an ML-KEM-768 encapsulation are combined through HKDF-SHA256, and the result keys AES-256-GCM. Raw X25519 output never keys a cipher directly, and envelope encryption binds the derivation to both the sender's ephemeral key and the recipient's key, so an exchange cannot be replayed against a different recipient. See Secure messaging.

STARKs

Tenzro uses Plonky3 STARKs for proofs that must be cheap to verify: compressed finality certificates, settlement proofs and identity proofs. STARKs rely only on hash functions, so they need no trusted setup and stay sound against quantum attackers. See Zero-knowledge proofs.

Inference is verified with TEE attestation, not with STARKs. See TEE.

Verifiable randomness

Where the network needs unbiased randomness it uses an RFC 9381 VRF, whose output anyone can check against the prover's public key. See VRF.

Tools

The CLI hashes and verifies without touching a key:

tenzro crypto hash --data 0x68656c6c6f --algorithm sha256
tenzro crypto hash --data 0x68656c6c6f --algorithm keccak256
tenzro crypto verify --key 0x<public-key> --message 0x<message> --signature 0x<signature>

Signing is done by your hardware-rooted signer, never by passing a private key on the command line. See Hardware signer SDK.

The open method tenzro_verifySignature checks a signature against a public key over JSON-RPC.