QuantovaQstampby Quantova
EN
EnglishEN日本語JAFilipinoFIL한국어KO简体中文ZHFrançaisFREspañolESУкраїнськаUK
GitHub Start building →
Qstamp / National security
National security alignment

National security aligned tooling through the Qstamp family tree.

The Qstamp family is designed to align with the published post quantum and integrity requirements that govern national security systems, defence supply chains and critical public infrastructure. This page sets out those requirements, the controls they map to, the position of each part of the family against them and the work that remains before any formal validation or accreditation.

Requirements

The published requirements the family is designed against.

Each requirement below is published by a government body. The position column states the current position of the Qstamp family against it, without anticipating any validation that has not been granted.

RequirementPublisherWhat it requiresPosition of the Qstamp family
CNSA 2.0Published by the National Security Agency of the United StatesML KEM 1024, ML DSA 87, SHA 384 or SHA 512 and AES 256 for national security systems, LMS or XMSS for firmware signing, and transition of those systems by 2035The released SDKs sign with ML DSA 65. ML DSA 87, ML KEM 1024, SHA 384 and SHA 512 are implemented in the Quantova cryptographic library and pass the NIST test vectors, and a CNSA 2.0 profile of the family is being built
FIPS 204National Institute of Standards and TechnologyThe Module Lattice Digital Signature AlgorithmUsed for every signature in the family and across the Quantova network, tested against the NIST vectors
FIPS 203National Institute of Standards and TechnologyThe Module Lattice Key Encapsulation MechanismImplemented in the Quantova cryptographic library, including the 1024 parameter set
FIPS 202National Institute of Standards and TechnologyThe SHA3 family of hash functionsUsed for every fingerprint, commitment and key identifier
FIPS 180 4National Institute of Standards and TechnologyThe SHA 2 family of hash functionsSHA 384 and SHA 512 implemented for the CNSA 2.0 profile
FIPS 140 3NIST and the Canadian Centre for Cyber Security, through the Cryptographic Module Validation ProgramValidation of cryptographic modules used by federal systemsNot yet validated
NIST IR 8547 (draft)National Institute of Standards and TechnologyTransition away from quantum vulnerable public key algorithms, deprecated from 2030 and disallowed from 2035No classical public key algorithm is used anywhere in the family or the Quantova network
National Security Memorandum 10 and OMB Memorandum M 23 02The White House and the Office of Management and BudgetInventory and migration of quantum vulnerable cryptography in federal systemsRecords sealed with the family need no future migration of their signatures
Control mapping

NIST SP 800 53 Revision 5, control by control.

The controls below are those for which the family produces direct technical evidence. Each system owner remains responsible for the selection, implementation and assessment of its own controls.

ControlTitleHow the family supports it
AU 8Time stampsAnchor times finalised by a post quantum validator committee and bound to each record
AU 9Protection of audit informationQLog hash chained logs sealed by anchored checkpoints, so that removal, reordering or alteration is detected
AU 9(3)Cryptographic protectionML DSA signatures and SHA3 commitments over every log segment
AU 10Non repudiationEach record signed by the key of the person or system that produced it
AU 11Audit record retentionReceipts that remain verifiable for the full retention period without dependence on the producer
CM 14Signed componentsInstallation limited to components whose fingerprints were registered under an authorised key
SC 12Cryptographic key establishment and managementKeys generated and held by the operator and never transmitted to Quantova
SC 13Cryptographic protectionNIST standardised post quantum algorithms throughout
SI 7Software, firmware and information integrityFingerprints of software builds and data sets registered and anchored before use
SR 4ProvenanceQTrace records the origin and history of AI content and data sets
Deployment

Designed for accredited and sensitive environments.

Operator held keys

Signing keys are generated and held inside the accredited boundary of the operator. Quantova never receives, stores or escrows them.

Minimal data egress

Only a salted 32 byte commitment of each record leaves the boundary. No record content, metadata or personal data is transmitted.

Disconnected operation

Records are signed inside the boundary without network access. Anchoring can be batched through a controlled gateway and completed later from a saved pending stamp.

Independent verification

The verification procedure is published in full, so a verifier can check any record without Quantova software or Quantova systems.

Open source

The SDKs are published under the Apache License 2.0 or the MIT licence for code review by the operator and its assessors.

Separation of duties

Government tools enforce distinct keys for distinct roles, and Quanta council contracts require approval by several parties.

Engagement

Working towards engagement with national security agencies.

Quantova Inc is working towards engagement with national security, defence and public sector agencies in the jurisdictions it serves, with the aim of supplying the Qstamp family tooling, its integration structures and deployment support to those agencies and to the companies that serve them. Any such engagement will follow the procurement, security accreditation and legal requirements of each agency. No agency has endorsed, approved, certified or contracted for the Qstamp family, and nothing on this website states or implies otherwise.

Path to validation

The work that remains before formal validation.

  1. 01Independent audit

    An external security audit of the Quantova network code has been carried out and its findings addressed. Each SDK is audited before release, and an independent audit of the Quantova cryptographic library is to follow.

  2. 02CNSA 2.0 profile

    Release of a CNSA 2.0 profile of the family using ML DSA 87 and SHA 384 or SHA 512, as minor versions of each SDK.

  3. 03Module validation

    Preparation of the Quantova cryptographic module for validation under FIPS 140 3.

  4. 04Hardware keys

    Support for hardware security modules, so that signing keys never exist outside certified hardware.

  5. 05Product evaluation

    Evaluation under the schemes each customer requires, such as Common Criteria.

  6. 06Authorisation

    System and service authorisation by the responsible authority of each deployment.

Scope

What alignment means on this website.

Alignment describes the design of the family against published requirements. It is not a certification, a validation or an accreditation, and it is not an endorsement by any agency. Use of the family in a national security system requires the approval of the authority responsible for that system. The current releases anchor on the Quantova test network ahead of production use.