POST-QUANTUM POSTURE
Half of our cryptography is already quantum-resistant. We publish which half.
Quantum computers do not affect all cryptography equally. They barely touch the maths that proves a document has not been altered, and they eventually break the maths that proves who signed it. Bidda depends on both. This page states plainly which of ours sits where, and gives you the means to check every claim on it yourself.
Version 1.1 · Last updated 4 August 2026 · Issued by Bidda Intelligence PTY LTD (CIPC 2026/363776/07)
Where each layer stands
The short version: the parts that establish what a record says are hash-based and are not broken by quantum computers. The part that establishes who issued it is an elliptic-curve signature, and that is the part being migrated.
Content integrity
UNAFFECTED
SHA-256 fingerprints
Every entry carries a fingerprint computed over its full text. Anyone holding the entry can recompute it and confirm nothing was altered.
Tamper-evident log
UNAFFECTED
SHA-256 Merkle tree (RFC 6962)
Issued records are appended to an append-only log. Inclusion and consistency proofs are pure hash operations, the same construction used by Certificate Transparency.
Transport
PROTECTED
TLS 1.3, X25519MLKEM768 hybrid
Connections negotiate hybrid post-quantum key agreement, combining classical X25519 with ML-KEM-768 (FIPS 203). Traffic captured today cannot be decrypted later.
Record signatures
MIGRATING
Ed25519 (RFC 8032)
This is the layer a quantum computer would break. It is an elliptic-curve signature, and it is the part of our system on a stated migration path. We say so rather than leave it implied.
A vendor telling you every layer is already quantum-resistant is either using different words for the same thing, or has not looked closely. The row that reads Migrating is the reason to trust the three that do not.
Check the transport claim yourself
The realistic near-term quantum risk is not that systems break tomorrow. It is that traffic captured today is stored and decrypted years from now. Hybrid key agreement closes that window: both the classical and the post-quantum component would have to fall for the session to be recovered, so the connection is never weaker than the classical one alone.
DO NOT TAKE OUR WORD FOR IT
openssl s_client -connect bidda.com:443 -groups X25519MLKEM768
COPY
If the handshake completes when that is the only key agreement group offered, the server selected it. Compare the reported handshake byte counts against a run with -groups X25519: the client key share grows by roughly 1,184 bytes, which is the ML-KEM-768 encapsulation key, and the server response by roughly 1,088 bytes, which is the ciphertext. Requires OpenSSL 3.5 or later on the client side.
This protects data in transit. It is a separate question from the signatures on issued records, which is why the table above reads Migrating on that row and not Done.
Last verified against the live endpoint at build time: 2026-08-03T09:19:23.339Z.
How keys are handled
✓
Every signature carries a key identifier, which sits outside the signed content. That is why it could be added without breaking records issued before it existed.
✓
The full key set, current plus every retired key, is published with validity windows. Retired public keys are kept and published permanently, so a record signed under an old key stays verifiable after rotation.
✓
Signing keys rotate on a fixed cycle. Rotation never touches customer keys or subscriptions, which are a separate system.
Direction of travel
Our stated direction for the signature layer is a hybrid signature: a record carries its existing signature plus an additional one under a post-quantum standard. This is the posture the major national technical authorities recommend during a transition, because it fails safe if a weakness is later found in either scheme.
The architecture already allows it without breaking anything: an additional signature is carried outside the signed content, and the additional public key is published in the existing key set. Records issued before the change continue to verify unchanged, because the bytes that were signed do not change.
FIXED, AND NOT UP FOR CHANGE
The signed field list and canonicalisation of every record type, and the SHA-256 entry fingerprint. Any additional digest is published alongside the existing one, never in place of it, so previously published fingerprints stay byte-identical.
We do not publish target dates for this work. A date we might miss is worth less to you than a design you can inspect.
How to check each claim
Entry fingerprints are reproducible
Recompute SHA-256 over the entry with the fingerprint field removed, using the method in the attestation specification.
Signatures verify offline, with no account
Use the browser verifier, or the command line tools published alongside it. Verification never requires a subscription.
Retired keys still verify older records
Fetch the published key set and confirm the key id on any older record still appears there.
Log proofs are hash-only
Rebuild the Merkle root from the published leaves and check it against the signed tree head.
This statement is the one we published
Recompute the SHA-256 of the Markdown copy and compare it against the published digest. The full recipe and a one-line command are at /.well-known/bidda-cryptographic-posture.sha256. The digest deliberately excludes the machine-managed transport-status block, so it does not churn on builds that changed nothing.
Transport uses hybrid post-quantum key agreement
Run the command above. Needs OpenSSL 3.5 or later.
VERIFY AN ENTRY →
TRANSPARENCY LOG
HOW ENTRIES ARE BUILT
What this page does not claim
×
That any Bidda system is unbreakable. Hybrid transport and hash-based integrity raise cost and narrow exposure. They do not create an absolute.
×
That using Bidda makes an organisation compliant with any post-quantum migration obligation. We describe obligations and their sources. Nothing here is legal advice.
×
That our record signatures are already post-quantum. They are not, and the table above says so.
×
A timetable for when quantum attacks become practical. Nobody credible has one.
Common questions
Is Bidda quantum-resistant?
+
Does Bidda use post-quantum encryption for its API?
+
Will a record signed by Bidda today still verify after quantum computers arrive?
+
Do quantum computers break SHA-256?
+
Does using Bidda make my organisation compliant with post-quantum migration rules?
+
When is the post-quantum migration deadline?
+
Standards referenced
Rows marked with an arrow are carried as entries in the registry, each with its own primary source citation, obligation checkpoints and workflow. Follow one and check it. The three IETF construction RFCs at the end are referenced here because our design uses them; they are not registry entries, and we say so rather than let the list imply otherwise.
FIPS 180-4
Secure Hash Standard (SHA-256) →
FIPS 202
SHA-3 and SHAKE extendable-output functions →
FIPS 203
ML-KEM, module-lattice key encapsulation →
FIPS 204
ML-DSA, module-lattice digital signature →
FIPS 205
SLH-DSA, stateless hash-based signature →
NIST IR 8547
Transition to post-quantum cryptography standards →
NIST SP 800-131A Rev. 2
Transitioning the use of cryptographic algorithms →
NIST CSWP 39
Considerations for achieving cryptographic agility →
CNSA 2.0
Commercial National Security Algorithm Suite →
RFC 9794
Terminology for post-quantum traditional hybrid schemes →
RFC 6962
Certificate Transparency Merkle tree construction
RFC 7638
JSON Web Key thumbprint
RFC 8032
EdDSA and Ed25519
Who is being told to migrate
The standards above describe what to migrate to. These describe who has been told to migrate, by when, and by whom. They do not agree with each other, which is the practical problem for anyone operating in more than one jurisdiction. Each is carried with its published dates traced to the instrument itself.
NSM-10 →
UNITED STATES
OMB M-23-02 →
US FEDERAL AGENCIES
Quantum Computing Cybersecurity Preparedness Act →
UNITED STATES
CNSS Policy 15 →
US NATIONAL SECURITY SYSTEMS
Recommendation (EU) 2024/1101 →
EUROPEAN UNION
NCSC migration timelines →
UNITED KINGDOM
CCCS ITSM.40.001 →
CANADA
BSI TR-02102-1 →
GERMANY
Carrying an obligation is not certifying that yours is met. Bidda states what each instrument says and where it says it. Nothing here is legal advice.
Document history
A posture that never changes is a posture nobody is maintaining. Entries here are appended, not rewritten.
Version 1.1
4 AUGUST 2026
Separated the standards we carry as registry entries from the ones we only reference, and added the migration obligations by jurisdiction. Added this history. Added a plain-text mirror so the full statement is readable without JavaScript.
Version 1.0
2 AUGUST 2026
First published. Four layers stated with their primitives, the Ed25519 signature layer named as the one being migrated, and the hybrid transport claim gated on a live build-time probe.
Questions about this document: see security.txt. This statement is also published as Markdown, as a plain-text mirror that needs no JavaScript to read, as structured JSON for agents, and with a content digest you can recompute.