DEV Community: Sadjad

Everyone agrees on the risk. They disagree on the price.

Sadjad — Sun, 06 Sep 2026 09:56:50 +0000

Published 2026-09-06

Every regulatory claim here was read from the primary document on that
date, and each is cited in
the policy sources. Guidance moves — the ASD ISM
is revised roughly monthly — so check the sources before acting on any of
it.

Germany's BSI recommends that post-quantum key establishment be deployed
alongside a classical algorithm. So does France's ANSSI. So does the EU's
coordinated roadmap. Australia's ASD recommends against it. The NSA says do not
use one on national security systems at all, outside named exceptions.

The obvious story is that the authorities disagree about whether hybrid
cryptography is safe. That story is wrong, and the real one is more useful.

They are all making the same argument

Here is ANSSI, explaining why it wants a classical algorithm kept alongside the
post-quantum one:

"even if the post-quantum algorithms have gained a lot of attention, they are
still not mature enough to solely ensure the security. For example, several
post-quantum schemes have suffered from classical attacks in the past years"

The citation attached to that sentence is Beullens, Breaking Rainbow takes a
weekend on a laptop. Rainbow and SIKE both fell to classical cryptanalysis
during the NIST competition — no quantum computer involved. The concern is not
that ML-KEM will be broken by a quantum computer. It is that it might be broken
by a mathematician.

BSI reaches the same place, and states the design requirement precisely:
hybridisation "should be implemented in such a way that the hybrid signature
scheme is secure as long as at least one of the schemes is secure."

Now here is ASD, the agency that recommends against hybrids:

"Generally, such schemes have the advantage of the security offered by the
traditional cryptographic algorithm if the post-quantum cryptographic
algorithm is vulnerable to an implementation flaw or new attack."

That is ANSSI's argument, in Australia's own words, in the paragraph where it
declines to follow it. ASD is not disputing the benefit. It is pricing it:

"This advantage comes at the cost of increased complexity, making maintenance,
analysis and secure implementation more difficult, as well as having greater
computational and bandwidth overheads."

And the NSA, in its CNSA 2.0 FAQ, makes the cost side explicit as an empirical
claim:

"Because more security products fail due to implementation or configuration
errors than failures in their underlying cryptographic algorithms, spending
limited resources to add cryptographic complexity can at times weaken security
rather than improve it."

So the disagreement is not about cryptography. It is a bet on which failure mode
is more likely: a new lattice scheme falling to cryptanalysis, or an engineer
misconfiguring a construction with twice the moving parts. Both are real. The
evidence for the first is Rainbow and SIKE. The evidence for the second is every
CVE ever filed against a TLS stack.

Reasonable people land differently on that, and they have.

Which makes it your problem

None of this would matter if you shipped into one jurisdiction. The trouble is
that the requirements are not merely different — they are, in one specific
configuration, mutually unsatisfiable.

ASSET           PURPOSE        bsi-de      anssi-fr    eu-roadmap  asd-au      cnsa-2.0
───────────────────────────────────────────────────────────────────────────────────────────
ECDH            key-agreement  WARN        WARN        WARN        WARN        FAIL          ⚠ c1,c2
                └ bsi-de · disallowed 2031-12-31
                └ anssi-fr · complete 2030-12-31
                └ eu-roadmap · transition_start 2026-12-31 · complete 2035-12-31
                └ asd-au · disallowed 2030-12-31 · complete 2030-12-31
                └ cnsa-2.0 · disallowed 2030-12-31 · exclusive_use 2031-12-31
                └ critical · exposure 19.0y · harvest-now-decrypt-later
                └ src/payments/legacy.go:12
X25519MLKEM768  key-agreement  PASS        PASS        PASS        WARN        FAIL          ⚠ c3,c4
                └ asd-au · deprecated 2030-12-31

X25519MLKEM768 — a hybrid of X25519 and ML-KEM-768, the construction most TLS
libraries are shipping today — passes in Europe, warns in Australia, and fails
for the NSA. And the conflict section explains why, in the terms above:

ASSET           PURPOSE        bsi-de      anssi-fr    eu-roadmap  asd-au      cnsa-2.0
───────────────────────────────────────────────────────────────────────────────────────────
ECDH            key-agreement  WARN        WARN        WARN        WARN        FAIL          ⚠ c1,c2
                └ bsi-de · disallowed 2031-12-31
                └ anssi-fr · complete 2030-12-31
                └ eu-roadmap · transition_start 2026-12-31 · complete 2035-12-31
                └ asd-au · disallowed 2030-12-31 · complete 2030-12-31
                └ cnsa-2.0 · disallowed 2030-12-31 · exclusive_use 2031-12-31
                └ critical · exposure 19.0y · harvest-now-decrypt-later
                └ src/payments/legacy.go:12
X25519MLKEM768  key-agreement  PASS        PASS        PASS        WARN        FAIL          ⚠ c3,c4
                └ asd-au · deprecated 2030-12-31
                └ src/payments/tls.go:88
ML-DSA-65       signature      WARN        WARN        WARN        WARN        FAIL          ⚠ c5,c6
                └ asd-au · deprecated 2030-12-31
                └ src/payments/sign.go:7
RSA-2048        ambiguous      INDET       INDET       INDET       INDET       INDET
                └ eu-roadmap · transition_start 2026-12-31
                └ unresolved: purpose-ambiguous (primitive:pke)
                └ as key transport → critical · as signature → medium
                └ Declare the purpose in cbomctl.yaml, or regenerate the CBOM with a generator that records
                  cryptoFunctions.
                └ src/payments/keys.go:41

CONFLICTS (6)
  c1  [construction]  ECDH
      anssi-fr, bsi-de, eu-roadmap recommend a hybrid construction for key-agreement; asd-au
      recommend against it; cnsa-2.0 does not permit one outside named interoperability
      exceptions.
      cnsa-2.0 does not permit a hybrid construction outside named interoperability exceptions,
      while anssi-fr, bsi-de, eu-roadmap recommend one. **No single configuration satisfies all
      selected jurisdictions.** You will need different builds, or to drop a jurisdiction from
      scope. asd-au would permit a hybrid but recommends against it, so even dropping cnsa-2.0
      leaves a documented cost. This is a business decision, not a technical one.

Two distinct collisions on one asset. The construction conflict has no
resolution: nothing you can build satisfies a jurisdiction that recommends
hybrids and one that does not permit them. The parameter conflict does have
one — ML-KEM-1024 clears everybody, because CNSA 2.0 requires that level "for
all classification levels" while BSI and ANSSI accept 768 without objecting to

It just costs you performance nobody else asked for.

That distinction matters more than it looks. "Discouraged but not prohibited" —
ASD's actual wording — leaves a compromise available at a documented cost. "Do
not use except for those exceptions NSA specifically recommends" does not. A
tool that reports PASS/FAIL cannot tell you which situation you are in.

The gradient, not the tribe

It is tempting to frame this as Europe versus the anglophone agencies. The
tidier reading is a three-step gradient:

stance	who	what it means for you
recommended	BSI, ANSSI, EU roadmap	ship hybrid
not recommended, not prohibited	ASD	hybrid is allowed, at a documented cost
not permitted outside named exceptions	NSA (NSS only)	no compromise exists

And the second contradiction has nothing to do with hybrids at all. BSI and
ANSSI both exempt hash-based signatures — SLH-DSA, XMSS, LMS — from their
hybrid recommendations, because their security rests only on hash-function
assumptions and there is no young lattice assumption to hedge. The NSA's answer
on the same family: "While SLH-DSA is hash-based, it is not part of CNSA and is
not approved for any use in NSS." Approved-standalone in two jurisdictions, not
approved at all in a third.

What I did about it

cbomctl reads a CycloneDX CBOM — from CBOMkit, from a vendor, from a
procurement process — and evaluates it against several national policies at
once, reporting the matrix and the collisions.

pip install cbomctl
cbomctl verdict your-cbom.json -j bsi-de,anssi-fr,asd-au,cnsa-2.0

Every rule carries the document, the section or page, the date it was read, and
a binding classification. That last field is load-bearing: most PQC guidance
is not a mandate, and a technical guideline that recommends cannot produce a
FAIL. BSI TR-02102-1 recommends. ANSSI's "mandatory hybridation" applies only
inside its security-visa process. The EU roadmap is a Recommendation, non-binding
on operators under TFEU Art. 288. Flattening those into "mandates" is the most
common error in this space, and I made it myself in an early draft — which is
why the field exists.

All seven packs are read from primary sources. Where a source is a draft, the
tool prints "draft". And where reading it required a judgement, the tool shows
the judgement rather than hiding it behind a verdict.

That last one earns its place here. NSA's FAQ answers the hybrid question
twice, and the answers differ in force: one says only "will not require", the
other says "Do not use … except for those exceptions NSA specifically
recommends" — but sits under a question framed "while waiting for a final NIST
post-quantum standard", a premise that arguably ended when FIPS 203/204/205
were finalised in August 2024.

I encoded the stronger reading, because Ver. 2.1 is dated four months after
that finalisation and was demonstrably revised in the interval — it notes that
"NSA clarified the CNSA 2.0 language when the FIPS documents were published"
and discusses a FIPS 204 variant — and NSA kept the imperative through that
revision. But the encoding is a judgement, and it is the judgement that decides
whether the tool tells you a compromise exists. So the conflict says both:

⚖ This conflict depends on a contested encoding. Under the alternative reading
  (cnsa-2.0 silent), a hybrid construction would satisfy all selected
  jurisdictions, at a documented cost.

If you disagree with me, you can see exactly which sentence you would argue
with. That seems more useful than a confident answer.

It refuses to guess, too. In CBOMkit's published Keycloak CBOM, 8 of 22
algorithm components carry no usable indication of what the key is for, and for
an ambiguous RSA key the answer spans the entire severity range. Those come back
unresolved, with the range they would have spanned.

The policy packs
are a separately versioned artifact with their own schema and changelog. If you
want to build something else on them, take them — that is what the citations
are for.

Prior art, because you will find it anyway:
open-quantum-secure is a
scanner with seven compliance frameworks that documents cross-framework
divergence in its own README — running multiple jurisdictions is not a gap in
the market. What it emits is one report per framework; cbomctl computes the
collision, and reads a CBOM you did not generate.
sbom-tools does CBOM diffing and
validation better than I will.

Originally published at https://lvlrsajjad.github.io/cbomctl/writing/everyone-agrees-on-the-risk/, which is the copy that gets corrected — this article describes a draft standard whose dates may move.

RSA-2048 and RSA-3072 have different futures

Sadjad — Sun, 06 Sep 2026 09:44:51 +0000

Published 2026-09-06

This describes NIST IR 8547 ipd — the initial public draft of November
2024 — as it stood on the date above. Its dates are proposed. If a final
IR 8547 has published since you are reading this, check it: the numbers
below may have moved, and the article's central caveat may no longer apply.

If you have read anything about post-quantum migration in the last year, you
have read that RSA is deprecated in 2030. It is one of those facts that has
been repeated into the shape of a rule.

It is half true, and the half that is false is the half people plan around.

Here is the actual table, from NIST IR 8547, Transition to Post-Quantum
Cryptography Standards:

algorithm	parameters	transition
RSA, ECDSA	112 bits of security strength	Deprecated after 2030 Disallowed after 2035
RSA, ECDSA, EdDSA	≥ 128 bits of security strength	Disallowed after 2035

Read the second row again. At 128 bits and above there is no 2030 row at
all. RSA-3072 is not deprecated in 2030. Neither is P-256. The 2030 date
applies to 112-bit strength — RSA-2048, P-224, 2048-bit finite-field
Diffie-Hellman — and to nothing else.

The key-establishment table (Table 4, covering finite-field DH/MQV, elliptic
curve DH/MQV and RSA) has exactly the same shape. Same split, same dates.

So an inventory that reports "47 uses of RSA, all deprecated in 2030" is
reporting something the document does not say. Some of those uses are on a
2030 clock and some are on a 2035 clock, and which is which depends on a field
most tooling does not look at.

Deprecated is not disallowed

The second thing worth getting right is what the two words mean, because they
are not synonyms and NIST defines both:

deprecated — "The algorithm and key length may be used, but the user must
accept some security risk."

disallowed — "The algorithm or key length is no longer allowed for
applying cryptographic protection."

Deprecated is a risk acceptance. You may continue, with your eyes open and
presumably a note in a register somewhere. Disallowed is a stop.

Collapsing them into "banned by 2030" produces two failures at once. It makes
2030 look like a wall when for most algorithms it is a signpost, and it makes
2035 — the date that actually stops things — disappear from the conversation.
I have seen migration plans built entirely around 2030 that had no 2035
milestone in them at all.

If you are budgeting, the practical shape is: 2030 is when your 112-bit
material becomes a documented risk acceptance, and 2035 is when everything
quantum-vulnerable stops being usable for new protection, at any strength.

The part almost nobody mentions

NIST IR 8547 is an initial public draft. Not a final publication. The cover
says so, the running header on every page says so, and the comment period closed
in January 2025.

Every date in it is proposed. The 2030s and 2035s that have propagated across
vendor roadmaps, conference slides and procurement documents are draft dates
from a draft document that, at the time of writing, has not been finalised.

That is not a reason to ignore them — they are the best available signal about
where NIST is going, and planning against them is entirely sensible. It is a
reason to say "draft" out loud when you cite them, and to not build a
contractual commitment on top of a number that can still move.

Why tooling gets this wrong

The distinction between the rows is security strength, which is not a field
in a CBOM. It has to be derived: RSA-2048 gives roughly 112 bits, RSA-3072
roughly 128, P-224 112, P-256 128.

Most compliance tooling models a regulation as a list of banned algorithm names
with a date attached. That model cannot express this table — it has one slot for
"RSA" and one date, so it picks one, usually the earlier, because erring strict
feels safe.

Erring strict is not safe. A team that believes RSA-3072 dies in 2030 builds a
migration schedule five years tighter than it needs, competing for budget
against work that actually is on a 2030 clock. Crying wolf has a cost, and it is
paid by the findings that were real.

The same flattening recurs across this whole space, always in the same
direction — toward something simpler, stricter and wrong. "BSI mandates hybrid":
BSI recommends it, in a technical guideline. "The US mandates PQC by 2030":
Executive Order 14412 covers federal High Value Assets and high impact systems,
explicitly excluding National Security Systems, with key establishment at 2030
and signatures at 2031.

Try it

cbomctl is a CLI that reads a CycloneDX CBOM and evaluates it against
national post-quantum policies. The IR 8547 pack models the two states
separately, scoped by security strength, and prints "draft" wherever it cites
them.

pip install cbomctl
cbomctl verdict your-cbom.json --jurisdictions nist-ir8547

Assets that differ only in strength come out differently. This block is
generated from a fixture in the repository by a script and diff-checked in CI,
so it cannot drift from what the tool actually does:

⚠ DRAFT SOURCE — these rules cite a document that is still a draft; their dates are proposed and may move:
    nist-ir8547/nist-112bit-key-establishment-deprecated-2030
    nist-ir8547/nist-112bit-signatures-deprecated-2030
    nist-ir8547/nist-key-establishment-disallowed-2035
    nist-ir8547/nist-signatures-disallowed-2035

ASSET       PURPOSE        nist-ir8547
────────────────────────────────────────
ECDSA-P224  signature      WARN
            └ nist-ir8547 · deprecated 2030-12-31 · disallowed 2035-12-31
RSA-2048    key-agreement  WARN
            └ nist-ir8547 · deprecated 2030-12-31 · disallowed 2035-12-31
ECDSA-P256  signature      WARN
            └ nist-ir8547 · disallowed 2035-12-31
RSA-3072    key-agreement  WARN
            └ nist-ir8547 · disallowed 2035-12-31

Note ECDSA-P224 and ECDSA-P256. Because IR 8547 scopes by strength rather
than by algorithm name, P-256 escapes the 2030 deprecation exactly as RSA-3072
does. The rule is not "RSA is fine and ECDSA is not", or the reverse — it is
112 bits versus 128, whatever the algorithm.

If the strength cannot be derived — no key size, no curve, no
classicalSecurityLevel in the CBOM — the finding is reported as indeterminate
rather than falling back to the stricter rule. Erring strict would put RSA-3072
on a 2030 clock it is not on.

How the demo caught the tool lying

Worth admitting, since this article is about people repeating claims they have
not checked.

I wrote the paragraphs above first, then wrote the demo block by hand to
illustrate them, then — almost as an afterthought — actually ran the command.
Both RSA keys came out identical.

The bug was that the rule selector for security strength was inert. It always
reported "not declared", because nothing computed strength from a CBOM in the
first place. Every strength-scoped rule silently never fired. The prose was
describing behaviour the tool did not have, and I would have shipped it.

The fix derives strength from modulus size, elliptic curve, or the CBOM's own
classicalSecurityLevel field — which is the one in bits;
nistQuantumSecurityLevel is a category from 1 to 5 and reading it by mistake
would score ML-KEM-768 as three-bit security. There is now a test for that
specific confusion, tests pinning that RSA-2048 and P-224 get the 2030
deprecation while RSA-3072 and P-256 do not, and a fixture holding all four.

Two smaller things fell out. The report was displaying both RSA sizes as RSA
and both ECDSA curves as ECDSA-SHA256, because canonicalising an algorithm for
policy matching throws the parameter away — so the distinction existed in the
verdict and was invisible in the output. And every code block in this article is
now generated by a script and diff-checked in CI, the same way the tool's policy
documentation is, because a block typed by hand is a claim nobody verified.

That failure — confident prose about behaviour that does not exist — is
precisely the one this tool is built to catch in compliance reporting. It is
worth saying out loud that it happened here first.

Try it yourself

You can read the rule and its citation without installing anything:

cbomctl policies show nist-ir8547

Every rule carries the section it was read from, the edition, a verification
date, and whether the source is a draft. The packs are a
separate versioned artifact
with their own schema, so you can consume them without the tool if you would
rather build your own.

All seven packs are read from primary sources — every rule names the section or
page it came from. Where a source is a draft, as IR 8547 is, the tool says
draft. Where a source is ambiguous, the ambiguity is recorded rather than
resolved quietly. The banner and --require-verified-policy remain in place for
the next rule that has not been checked yet, because rules assembled from blog
posts are roughly how "RSA is deprecated in 2030" got started.

NIST IR 8547 ipd is a US federal work in the public domain.
Read it directly —
Tables 2 and 4 are on pages 13 and 14, and the glossary definitions are in
Appendix A. Check whether a final version has published since; if it has, this
article's caveat is out of date and the dates may have moved.

Originally published at https://lvlrsajjad.github.io/cbomctl/writing/rsa-2048-and-rsa-3072/, which is the copy that gets corrected — this article describes a draft standard whose dates may move.