CFRG - Crypto Forum Research Group

IETF 126 in Vienna

Notes: Morgane Guerreau

Wednesday July 22, 2026, 09:00-11:00 (UTC+2)

Chairs: Alexey Melnikov, Stanislav Smyshlyaev and Nick Sullivan

Alexey Melnikov, "Chairs' update" (10 mins)

Agenda bashing, moved "Longfellow ZK" and "Hybrid Post-Quantum PAKE"
earlier

Open Discussion: PQ KEMs (30 mins)

John Preuss Mattsson: it seems to be quite a lot of people want to use
FrodoKEM, there is an expectation in other WG that CFRG publish the
specification fo FrodoKEM. If you don't publish it, we need to refer to
the paywall spec.

Chair: this is a research group, not a republishing venue. We published
ChaCha because it was a requirement of the TLS WG. CFRG is not
re-running a contest for algorithms. If people want to adopt FrodoKEM
they're fine to do so, and if they have issues analyzing security
considerations they can come to CFRG. Our goal is to enable other groups
to be more confident in their crypto choices.

Rohan Mahy: We've got a lot of RG items on our plate. Are there
volunteers to do this work?

Chair: Good question. We're getting many documents from people who have
not been involved in CFRG before.

Scott Fluhrer: Almost every protocol uses a KEM, I don't see how we
could cover every possible KEMs including future KEMs. But I believe
that there are subtle questions to be adressed.

Chair: some documents explore some of the mathematics behind the KEM so
they could apply more generally to KEM that don't exist yet

Tanja Lange: I think it's useful work, I think it's good that more
cryptographers are getting involved in the RG. People should pay more
attention to McEliece because it has small ciphertexts.

Chair: that's a valid feedback, that's something that should be
mentioned

Rich Salz: As a veteran of the hybrid war, I think it would be useful. A
lot of people are not familiar with the tradeoffs.

Chair: So it's about having on central documentent about the very high
level aspects.

Tanja Lange: I wnat to make a plea for an additional document that does
this comparison between KEMs.

Chair: we don't have volunteers yet for a shared document, we'd love to
hear from them.

John Gray: It would be nice to have guidance for engineers

Scott Fluhrer: We need to remember who the audience is, we need to keep
the work relevant for the other WG.

Viktor Dukhovni: We have a bit of a mess about key format for hybrids
between HPKE which has a master seed and LAMPS which has one seed per
component.

Eliot Lear: There is already RFC 9958 about PQC for engineers so we have
to avoid reproducing it. It would be great to have a neutral document
about hybrid vs non-hybrid.

Chair: will take the summary to the list and see how we can move on

abhi shelat, "Longfellow ZK" (5+5 mins)

https://datatracker.ietf.org/doc/draft-google-cfrg-libzk/

Christopher Wood: I support the work. I would collapse the scheme and
parameters in a single CFRG document. The application doc should go to
another WG. The CFRG doc should be written in way that makes
implementation easy to do when you're not a cryptographer. The work on
formal verification is fantastic.

abhi shelat: I'm fine with the merging of the two documents. We have
done formal verif for ECDSA. We have proven that our circuit is
equivalent to the spec. ML-DSA is more difficult to do.

Christopher Wood: if you had everything you describe, how much work do
you think people need to do to produce a similar circuit?

abhi shelat: there are at leats 3 other groups that are developping
circuits, so it's possible for other people to do that. I think the
workload is quite reasonable.

Christopher Wood: if doc C is reframed as being about gadgets it can
stay separate.

Chair: my recommendation is sync up with the authors to work on a split

Christopher Wood, "Hybrid Post-Quantum PAKE" (10+5 mins)

https://datatracker.ietf.org/doc/draft-vos-cfrg-pqpake/

Dan Harkins: I'm very in favor of this being adopted by the RG. I think
splitting the binary key is not a necessary construction. You can just
use Kemeleon. Another WG should specify the length values and so on.

Christopher Wood: I agree that the CFRG doc is not the best place to do
that. If you don't split the key there is an attack.

Scott Fluhrer: Hybrid requires several rounds and hence it's difficult
to integrate into existing protocols.

Stefan Santesson: Very strong support for this work. It would be great
if it became a standard and not only a informational document.

Rohan Mahy: Strongly support the doc.

Chair: I encourage you to seek out if there are use cases, but there is
general positive feedback so we can probably move on to adoption.

Julien Devevey, "Silithium" (10+5 mins)

https://datatracker.ietf.org/doc/draft-devevey-cfrg-silithium/

Scott Fluhrer: The whole reason EdDSA use a non-deterministic is to
avoid issues with RNG, if you don't have issues with that in your
construction you don't want to parse the message twice while signing. If
you append the context to the message it's very similar to composite.
For the context size, you can use a hash function and not be limited in
size.

Julien Devevey: You can generate the nonce in a hedged way like MLDSA.

John Preuss Mattsson: On nonces, I think you should go hedged. IoT
persons will never deploy a deterministic version because of SCA. There
are at least 3 different drafts in CFRG about hybrid signatures, we need
to coordinate.

Chair: look at hedged EdDSA

Sophie Schmieg: if we do hybrid this is a nice hybrid, but my problem is
that we have too many hybrids. The one in LAMPS is winning, I'm not sure
I want an additional hybrid.

Julien Devevey: I agree that there are too many hybrids. SUFHybSig is
similar to Silithium, we should keep only one of them. For composite and
Mothma it's more difficult to compare.

Chair: composite signatures have already progressed, let's do a show of
hands

"Is the topic of Hybrid PQ/T Signatures something the CFRG should
explore adopting?"

Yes: 48
No: 18
No opinion: 6

Chair: it's worth having this discussion on the mailing list

Emil Lundberg, "The ARKG algorithm" (10+5 mins)

https://datatracker.ietf.org/doc/draft-bradleylundberg-cfrg-arkg/

John Bradley: (one of the co-authors) ARKG is not the best long-term
solution, it's the best solution we have now. ZkP are the better way
forward not deployable yet.

Chair: how would you describe this draft in terms of what is pure
engineering and what is research that need to be validated?

Emil Lundberg: most of the draft is connected to research, there is one
section in the draft that is more engineering, if that's more
appropriate we can move it to another document.

Chair: IANA registries are not updated by CFRG documents. What problem
does this solve?

Emil Lundberg: It allows you to have hardware bound keys but without
having to use the hardware everytime.

Chair: follow-up should be a list discussion. Call for volunteers to
review. Very few people have read the document yet.

Uri Blumenthal, Valery Smyslov, "PQuAKE" (15+5 mins)

https://datatracker.ietf.org/doc/draft-uri-cfrg-pquake/

John Preuss Mattsson: I agree that KEM-based auth can be really useful.
These slides use EDHOC a lot. The LAKE WG has adopted KEM-based auth.

Thom Wiggers: As an author of KEM-TLS I'm of course enthusiastic. There
are some propoerties that some protocols may or may not be concerned
about. I'm not sure that CFRG is the right spot because it's higly
protocol specific.

Guilin Wang: We believe KEM-based auth is a good option for some
scenarios, for example when one party can pre-download the public key.
Also it saves some computation which is useful for battery-powered
devices. We can see if they unify the proposal in the TLS WG.

John Gray: I support this work. It opens up another interesting case for
KEM certificates. If we don't do this people will do bad things.

Chair: We need more discussion about what we want to do with KEM-based
auth and it's worth having on the list. It's not only from TLS but also
from IKEv2 so it could benefit from a shared framework.

AOB

None.

Friday July 24, 2026, 11:30-12:30 (UTC+2)

Chairs: Alexey Melnikov, Stanislav Smyshlyaev and Nick Sullivan

Felix Günther, "Kemeleon Encodings" (10+5 mins)

https://datatracker.ietf.org/doc/draft-irtf-cfrg-kemeleon/

Christopher Wood: The question is how much you can parallelize password
guessing. Another option would be larger parameters. (reference to
discussion on the mailing list)

Scott Fluhrer: what is the actual variation bewteen the completely
random and statistical distance you have. Current distinguisher at 2^-76
looks massively overkill.

Felix Günther: I'm happy to discuss to see if the bound can be set more
reasonably.

Greg Bernstein, Anja Lehman, "BBS, Blind BBS, BBS pseudonyms" (15+5 mins)

https://datatracker.ietf.org/doc/draft-irtf-cfrg-bbs-blind-signatures/
https://datatracker.ietf.org/doc/draft-irtf-cfrg-bbs-per-verifier-linkability/

No questions, chairs will follow up with editors

Shai Levin, Anja Lehman, "Schnorr-Type Proofs for ECDSA Device Binding" (10+5 mins)

https://datatracker.ietf.org/doc/draft-cllz-cfrg-ecdsa-pop/

No questions

Yumi Sakemi, "Pairing-Friendly Curves" (5+5 mins)

https://datatracker.ietf.org/doc/draft-irtf-cfrg-pairing-friendly-curves/

Emil Lundberg: Thank you very much for you work on that. I appreciate
the additions on the latest draft about implementation guidance. I agree
with the serialization functions. There are some minor issues but don't
require any discussion to fix.

Chair: we encourage the audience to comment on the issues so we can
close them and move on to RGLC. Thank you for all your work.