ENISA opens a call to participate in the public review of “Agreed Cryptographic Mechanisms” until end of July

[Markku-Juhani O. Saarinen]

FYI --  News announcement

2 June 2026 European Union Agency for Cybersecurity

ECCG “Agreed Cryptographic Mechanisms”, or ACM, provides recommendations regarding the cryptographic mechanisms that should preferably be used in ICT products submitted to certification.

Version 2.0 was adopted mid-2025 and the ECCG subgroup on cryptography, that is responsible for its maintenance, has developed a new version 3 submitted to public review until the end of July 2026. The changelog is provided together with the updated version on this page and all modifications are highlighted in red in the document.

Survey news item:
https://certification.enisa.europa.eu/news/participate-public-review-new-draft-agreed-cryptographic-mechanisms-2026-06-02_en

ACM 3.0 Draft Document:
https://certification.enisa.europa.eu/publications/eucc-guidelines-cryptography_en

[Kris Kwiatkowski]

I understand why there is no HQC on the list at this point, but I wonder if it will be added to this recommendation at some point?

--
You received this message because you are subscribed to the Google Groups "pqc-forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pqc-forum+...@list.nist.gov.
To view this discussion visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/4c934a50-e6e6-4a84-8cce-81bcd0400ffdn%40list.nist.gov.

[Markku-Juhani O. Saarinen]

Hi Kris,

Technically speaking, the ACM list represents the consensus of the 27+1 European national cybersecurity certification authorities. There is no proper HQC standard yet, so that would have to be reviewed by the group before such decisions can be made.

Importantly, the draft has a new Annex C, "Update process for Agreed Cryptographic Mechanisms," which allows one to request the inclusion of HQC (or any other mechanism) if the appropriate criteria are met.

Quoting:
"- it is standardised;
- it is stable for at least two years;
- it has a generic purpose and several applications/use cases;
- its security level should be at least of 125 bits (the mechanism will enter at Recommended level);
- it has been submitted to peer reviews, security proofs or security analysis by academics, side-channel analysis, tentative of fault attacks, etc. and related documentation is publicly available."

Personally, I'd expect HQC-KEM to end up on the list eventually.

Cheers,

-markku

Dr. Markku-Juhani O. Saarinen <mj...@iki.fi>

To view this discussion visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/a40c6f57-440a-4482-b007-ea55e7f6feb9%40amongbytes.com.

[Bas Westerbaan]

Thanks for the pointer, Markku.

I find it quite jarring that AES-128 and RSA / ECC  are put at the same level "A". We wouldn't want organisations to spend time moving to AES-256 that could've been spent moving away from RSA. What options do you see to make that distinction clearer?

[D. J. Bernstein]

'Bas Westerbaan' via pqc-forum writes:
> We wouldn't want organisations to spend time moving to AES-256
> that could've been spent moving away from RSA.

AES-128 allows attacks _today_. In applications that have trillions of
AES-128 sessions each with a known plaintext block, an attack costing
roughly $100M today will break one of the sessions. Trying to handle
this problem by telling all applications to randomize plaintext blocks
is unrealistic and unwise; telling applications to simply move up to
256-bit cipher keys is much simpler and much less error-prone. See,
e.g., the 128-bit attack in https://cr.yp.to/papers.html#footloose; this
is why there was a security patch to the FrodoKEM design in 2023.

As for RSA, my median estimate is 2029 for NSA and comparable attackers
to secretly have $1B quantum computers starting to break some RSA-2048
keys. The key sizes recommended in the document are above 3000 bits, but
this will buy us only a year or two. Probably costs per key broken will
start at roughly $1M. Even worse, moving away from RSA is another
complicated, error-prone task. See https://cr.yp.to/papers.html#qrcsp
and https://cr.yp.to/papers.html#mldsa for examples of what goes wrong.

Moving up to 256-bit cipher keys easily deals with one of these security
problems and isn't going to take noticeable time away from trying to
handle the other security problem.

---D. J. Bernstein

[Bas Westerbaan]

Dan, so those reading along don't misunderstand you: you're surely not suggesting that the migration away from AES-128 is as urgent as migrating away from RSA in the context of quantum attack?

On Mon, Jun 8, 2026 at 2:19 PM D. J. Bernstein <d...@cr.yp.to> wrote:

Moving up to 256-bit cipher keys [...] isn't going to take noticeable time away from trying to

handle the other security problem.

When it's easy, sure, let them switch—no argument there. But many teams in many organisations waste real time discussing whether AES-128 and SHA-256 are quantum vulnerable. It's our duty to communicate the risk clearly.

Best,

 Bas

 

[John Mattsson]

D. J. Bernstein wrote:

>In applications that have trillions of AES-128 sessions each with a known plaintext block, an attack costing roughly $100M today will break one of the sessions.

That may be correct, but do you have an example of anyone being willing to spend $100 million to compromise a single session out of trillions? I do not see a plausible cost–benefit justification for such an attack. Moreover, assuming the session follows best practices and periodically rekeys with PCS, a successful attack would compromise only a portion of the session rather than the entire communication.

D. J. Bernstein wrote:

>telling applications to simply move up to 256-bit cipher keys is much simpler and much less error-prone.

>Moving up to 256-bit cipher keys easily deals with one of these security problems and isn't going to take noticeable time

There is a huge difference between new and existing systems. Using 256-bit security in a completely new system is easy, whereas migrating an existing system to 256-bit security can be anything but easy. Even newly deployed systems may depend on existing hardware, key management infrastructure, or provisioning systems that only support 128-bit security, making a transition to 256-bit security more difficult than it might initially appear.

Cheers,

John Preuß Mattsson

[D. J. Bernstein]

Bas Westerbaan writes:
> Dan, so those reading along don't misunderstand you: you're surely not
> suggesting that the migration away from AES-128 is as urgent as migrating
> away from RSA in the context of quantum attack?

As I said: 128-bit cipher keys, as in AES-128, allow attacks in various
applications for roughly $100M/key today. The simple fix is to use
256-bit cipher keys.

Meanwhile RSA at the sizes in this document will allow attacks by $1B
quantum computers, starting in roughly 2030, for roughly $1M/key. Here
fixes are much more complicated and error-prone.

For organizations trying to stop large-scale attackers, _both_ of these
are urgent to fix: the first because attacks are already feasible today,
the second because solutions are much harder and because attacks will be
less expensive and because user data often has a long security lifetime.

There are many other urgent security problems too, such as exploitable
buffer overflows. It's not easy to figure out the best way to spend an
organization's limited security budget. Looking at only part of the
attack surface is an oversimplification, often a dangerous one.

> discussing whether AES-128 and SHA-256 are quantum vulnerable

This is an example of looking at only part of the attack surface. People
looking at how far away quantum attacks are against AES-128 miss today's
security problems with AES-128, such as the multi-target attacks that I
mentioned (easy fix: 256-bit keys) and cache-timing attacks (easy fix:
ChaCha20, of course with 256-bit keys).

---D. J. Bernstein

[Oscar Smith]

>As I said: 128-bit cipher keys, as in AES-128, allow attacks in various
applications for roughly $100M/key today. The simple fix is to use
256-bit cipher keys.

Is Cha-Cha at 128 bit key size an alternative mitigation here?

[D. J. Bernstein]

'John Mattsson' via pqc-forum writes:
> I do not see a plausible cost–benefit justification for such an attack.

"First, even if the attacker's expected cost obviously outweighs the
attacker's expected benefit, sometimes the attacker goes ahead and
carries out the attack anyway. The 'attacker economist' approach assumes
that rational attackers won't carry out uneconomical attacks, so users
don't have to worry about such attacks; but attackers in the real world
do not always act on the basis of rational economic analyses. The damage
done by the attack, beyond its benefits to the attacker, is invisible to
the 'attacker economist' philosophy.

Second, evaluating the attacker's benefit requires understanding all the
consequences of, e.g., successfully forging a signature. How exactly is
the signature being used? What exactly does the attacker gain from the
forgery? What is the monetary value of this benefit? The answers are
complicated and constantly changing; they have a dramatic dependence on
the details of how cryptography is integrated into real applications. A
single forgery might not sound so bad, but it might also allow the
attacker to take complete control over a critical computer. Sure, we can
tell cryptographic users that they should evaluate the consequences of
the cryptography failing, and that they should limit the attacker's gain
from a successful attack, but the reality is that nobody gets this
right: people are constantly surprised by how much damage an attack can
do. For comparison, there's at least some hope of accurately assessing
the resources available to attackers and of building cryptographic
systems that are _infeasible_ to break.

Third, even in situations where it's clear how much damage is caused by
each forgery, 'attacker economist' proponents are constantly
overestimating the attacker's _cost per forgery_. The typical process
here might sound reasonable at first: take what everybody says is the
state-of-the-art forgery algorithm, and look at what everybody says is
the cost of that algorithm. The problem is that the algorithm designers
are practically always optimizing and reporting costs in a metric that's
different from, and much larger than, the cost per forgery.
Specifically, the usual metric is the cost of forging _one_ message
under _one_ key, while the attacker is trying to forge _many_ messages
under _many_ keys."

These quotes are from https://blog.cr.yp.to/20151120-batchattacks.html,
which continues with various concrete examples of how the "attacker
economist" philosophy has botched one security decision after another.

---D. J. Bernstein

[D. J. Bernstein]

> > As I said: 128-bit cipher keys, as in AES-128, allow attacks in various
> > applications for roughly $100M/key today. The simple fix is to use
> > 256-bit cipher keys.
> Is Cha-Cha at 128 bit key size an alternative mitigation here?

No. Don't use cryptosystems where the keys are that small. For example:
AES-128 inputs a 128-bit key, so don't use it. FrodoKEM-640 outputs a
128-bit session key, so don't use it.

There are various security advantages of ChaCha20 over AES (e.g., larger
block size, something that NIST seems to be gradually acknowledging as
an advantage; larger security margin in case attacks break more rounds;
not having to worry about things like CVE-2025-52496) but those are
orthogonal to the broader point that 128-bit keys are a security hazard.

---D. J. Bernstein

[Markku-Juhani O. Saarinen]

On Mon, Jun 8, 2026 at 1:26 PM Bas Westerbaan <b...@cloudflare.com> wrote:

Thanks for the pointer, Markku.

I find it quite jarring that AES-128 and RSA / ECC  are put at the same level "A". We wouldn't want organisations to spend time moving to AES-256 that could've been spent moving away from RSA. What options do you see to make that distinction clearer?

Hi Bas,

Perhaps explanatory text would be best -- you/we can propose language for that. From what I have seen, there have been proposals to have additional categories, but the group seemed reluctant to make such a change.

One thing to note -- all "Admissible" (A) schemes are expected to be eventually depreciated, but the year is not explicitly written if it is beyond the default, which is A = A[2033+] for this document version (Section 1.1). Once we get a little bit closer to the final depreciation deadlines for RSA and ECC (2035 is stated in the "Coordinated Implementation Roadmap for the Transition to Post-Quantum Cryptography"), RSA and ECC probably will have the A[2035] explicitly for all key sizes, while AES-128 will hopefully stay simply as "A" for a while longer.

Cheers,

-markku

[Antony Vennard]

Hi Bas, Markku,

On Mon, 2026-06-08 at 23:11 +0300, Markku-Juhani O. Saarinen wrote:
> On Mon, Jun 8, 2026 at 1:26 PM Bas Westerbaan <b...@cloudflare.com>
> wrote:
> > Thanks for the pointer, Markku.
> >
> > I find it quite jarring that AES-128 and RSA / ECC  are put at the
> > same level "A". We wouldn't want organisations to spend time moving
> > to AES-256 that could've been spent moving away from RSA. What
> > options do you see to make that distinction clearer?
> >
>
>
> Hi Bas,
>
> Perhaps explanatory text would be best -- you/we can propose language
> for that. From what I have seen, there have been proposals to have
> additional categories, but the group seemed reluctant to make such a
> change.
>
> One thing to note -- all "Admissible" (A) schemes are expected to be
> eventually depreciated, but the year is not explicitly written if it
> is beyond the default, which is A = A[2033+] for this document
> version (Section 1.1). Once we get a little bit closer to the final
> depreciation deadlines for RSA and ECC (2035 is stated in
> the "Coordinated Implementation Roadmap for the Transition to Post-
> Quantum Cryptography"), RSA and ECC probably will have the A[2035]
> explicitly for all key sizes, while AES-128 will hopefully stay
> simply as "A" for a while longer.
>
> Cheers,
> -markku
>

I gave feedback via the survey on this specific point (and others) and
I'll paraphrase what I wrote here. I think the "quantum threat" part is
not particularly clear for this and I proposed a clearer layout. This
is an improved version of my feedback - structure the note in the
following paragraphs:

- If you read no further: do it everywhere it is easy, but prioritise
asymmetric/2k RSA if hard.
- The headline threat is that AES drops below the 128-bit level but
that has caveats.
- Caveats: that Shor speedup is exponential but Grover is quadratic;
cost of Grover for AES-128 exceeds cost vs Shor with 4k RSA.
- Now circuit depth - theoretical 64-bit pq security, practical effect
hard to estimate real security drop, but costlier than asymmetric hence
prioritisation advice.

I don't really have a strong opinion on what the levels should be, but
I do think the advice could be clearer on what the risks to prioritise.

Kind regards,

Antony
>

[Bas Westerbaan]

Antony, thanks for submitting feedback on this!

 - If you read no further: do it everywhere it is easy, but prioritise
asymmetric/2k RSA if hard.

For sure.

 

 - Caveats: that Shor speedup is exponential but Grover is quadratic;
cost of Grover for AES-128 exceeds cost vs Shor with 4k RSA.

This is quite the understatement.

We have many companies around the world with roadmaps for building quantum computers that will run Shor on cryptographic key sizes. We're discussing whether these dates are correct, and how expensive breaking each key would be ($100, $10,000 or $1M), and how these costs will evolve over time.

Contrast that with Grover. I have seen not a single roadmap that's even close to running Grover on cryptographic scale. Typical analyses of Grover assume breakthroughs (quantum AES exeucution in <1µs) and/or resources (quantum computer the size of the surface of the moon) far beyond any roadmap or reasonable expectation, and still conclude Grover is impractical.

[Antony Vennard]

Hi Bas,

I didn't want to cite the wrong numbers when I wrote that email so I
hedged a bit, but this paper (2023):
https://www.frontiersin.org/journals/physics/articles/10.3389/fphy.2023.1171753/full
suggests 16k Toffoli gates for AES-128. Grover requires an invertible
quantum circuit for AES and 2^64 invocations if I understand correctly,
so 2^64*16k, around 2^77 gates. The estimate I've seen for Shor for 4k
RSA is around 10^13 Toffoli gates / 2^44 in base 2. So the cost for
error correction is "orders of magnitude" even if the precise estimates
have shifted a bit, and indeed they're not at all equivalent.

-- Kind regards, Antony

[Bas Westerbaan]

Recent results optimising for qubit count are still below 10^11 (2^36) logical Toffoli's, see https://arxiv.org/pdf/2505.15917

 

So the cost for
error correction is "orders of magnitude" even if the precise estimates
have shifted a bit, and indeed they're not at all equivalent.

Numbers you quoted don't contain error correction. But that won't change the conclusion that Grover on AES-128 and Shor on RSA-4096 are very different indeed

Best,

 Bas

 

-- Kind regards, Antony

--
You received this message because you are subscribed to the Google Groups "pqc-forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pqc-forum+...@list.nist.gov.

To view this discussion visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/57addfe44ff905c0c476b752c5c913ad845066dd.camel%40vennard.ch.