Skip to content

post-quantum-security.md

Latest commit

 

History

History
69 lines (56 loc) · 3.71 KB

post-quantum-security.md

File metadata and controls

69 lines (56 loc) · 3.71 KB

How QNS Is Quantum-Secure

QNS inherits Quantova's post-quantum security at the layer that matters most for a name service: the signatures that authorize who owns a name and who can change it. This document explains why .qtov names are quantum-secure and how that security is preserved through the QVM tech stack.

The risk for classical name services

Owning a name on a classical name service means controlling an elliptic-curve key (ECDSA / Ed25519). A sufficiently capable quantum computer running Shor's algorithm can recover such a private key from its public key. Because public keys and signatures are visible on-chain, a harvest-now, decrypt-later adversary can record them today and forge them later — silently transferring names or repointing records once the hardware exists. The names you trust would become forgeable retroactively.

QNS removes that risk at the signing layer

On Quantova there is no elliptic-curve path. Every action that establishes or changes ownership of a .qtov name — registering it, transferring it, setting its resolver records — is a transaction whose signature is post-quantum:

  • The signature is one of the NIST schemes Quantova supports — CRYSTALS-Dilithium (ML-DSA), Falcon (FN-DSA), or SPHINCS+ (SLH-DSA) — verified by the runtime's QSignature type.
  • The owning account is the post-quantum public key (via the address derivation in address-scheme.md). To take a name you must hold the corresponding post-quantum private key.
  • There is no classical fallback to downgrade to. A name registered today cannot be forged by a future quantum adversary, because no efficient quantum attack is known against these schemes.

How the QVM tech stack preserves that security

QNS resolves and stores data through the QVM, and the QVM is engineered so that EVM-style compatibility does not weaken the post-quantum guarantee:

  • Authorization happens before the VM. A QNS registration or update is a post-quantum-signed extrinsic. The QSignature is verified at the transaction layer before the call reaches the QVM. The VM only ever sees an already- authenticated 20-byte caller — it never handles a classical key.
  • Hashing is quantum-resistant. Names are keyed with keccak-256 (the EIP-137 namehash) and the chain hashes state with SHA3-256. Hash functions are not broken by Shor's algorithm; the generic Grover speed-up is mitigated by the 256-bit digests.
  • No EVM key model leaks in. The QVM uses 20-byte addresses and the standard Solidity ABI for compatibility, but a Quantova address is derived from a post-quantum public key, not an ECDSA key. So contract-level resolution is EVM-friendly while ownership remains post-quantum.
  • Inheritance, not opt-in. Because the runtime fixes the post-quantum signature type and SHA3-256 hashing once, the QNS pallet — like every Quantova pallet — inherits them automatically. QNS does not implement its own signature scheme.

What this means for a name owner

  • Only the holder of your post-quantum private key can transfer your name or change its records.
  • A purchase or update that is tampered with (different owner, price, or records) fails signature verification and is rejected — demonstrated in ../demo/back_test.py.
  • Your name's security does not depend on elliptic-curve cryptography at any point.

Verify it yourself

The demo reproduces the exact namehash and address derivation and shows a purchase being post-quantum signed and verified, including that tampered or wrong-key purchases fail. The namehash is cross-checked against the published EIP-137 vector, so the cryptographic shape shown is provably the real one.