**Session Date/Time:** 22 Jul 2026 07:00 # [CFRG](../wg/cfrg.html) ## Summary The Crypto Forum Research Group (CFRG) met during IETF 126 in Vienna. The session was chaired by Alexey Melnikov and Nick Sullivan, with Stanislav Smyshlyaev participating remotely. The meeting covered administrative updates, including the renewal of the Crypto Review Panel, followed by an open discussion on Post-Quantum (PQ) Key Encapsulation Mechanism (KEM) security considerations. Technical presentations spanned zero-knowledge proofs (Longfellow ZK), hybrid post-quantum password-authenticated key exchange (PAKE), non-separable hybrid signatures (Silithium), asynchronous remote key generation (ARKG), and compact PQ mutual authentication (PQuAKE). A formal poll was taken regarding the adoption of hybrid PQ/T signatures. --- ## Key Discussion Points ### Admin and Document Status * **Crypto Review Panel:** The panel has been renewed for a two-year term with a mix of continuing and new members. * **Document Status:** * `draft-irtf-cfrg-rsa-guidance` is in IESG review. * `draft-irtf-cfrg-cpase` is in IRSG review. * Three errata reports were presented with proposed resolutions. ### Open Discussion: PQ KEM Security Considerations * **Context:** The chairs opened the floor to discuss how CFRG should handle the influx of security considerations drafts for various PQ KEMs, particularly regarding their usability by other working groups (e.g., TLS, IPsecME). * **Technical & Policy Debate on FrodoKEM:** * John Preuß Mattsson noted significant interest in FrodoKEM (`draft-longa-cfrg-frodokem`) from other IETF working groups (e.g., IPsecME's `draft-ietf-ipsecme-hybrid-kem-ikev2-frodo`). * A central issue raised in the chat by Yoav Nir, Bas Westerbaan, and Pascal Schäfer is that the official FrodoKEM specification is published by ISO and sits behind a paywall. The IETF community strongly pushes back against normative references to paywalled documents. * Daniel Van Geest confirmed that the authors of the IETF draft are the ISO authors and the specifications are identical modulo minor formatting. * Bas Westerbaan questioned whether there is a true international technical need for FrodoKEM over ML-KEM, warning against standardizing algorithms purely to satisfy national regulatory policies. Tanja Lange countered that FrodoKEM has different underlying mathematical assumptions compared to ML-KEM, making it a valuable conservative alternative. * **Guidance Structure:** * Scott Fluhrer argued that a single document cannot cover all KEMs due to subtle, algorithm-specific differences, particularly in authenticated use cases. * Tanja Lange and Russ Housley supported the creation of a comparison or usability guidance document focusing on trade-offs (e.g., public key size vs. ciphertext size) to assist protocol designers, warning authors to remain neutral. * Eliot Lear cautioned against duplicating `RFC 9958` (Post-Quantum Cryptography for Engineers) but supported neutral documentation addressing the security nuances of hybrid vs. non-hybrid approaches. * Victor Duchovni flagged a growing inconsistency in key formats for hybrids between HPKE (which uses a master seed) and LAMPS (which uses separate seeds for individual components). ### Longfellow ZK * **Presentation:** Abhi Shelat presented [Longfellow ZK](https://datatracker.ietf.org/meeting/126/materials/slides-126-cfrg-longfellow-zk-00). * **Technical Details:** Longfellow is a transparent, hash-based zero-knowledge argument system relying solely on the hardness of SHA-256. Recent work includes rewriting the implementation in Rust, formalizing parts of the circuit generation in Lean (with an equivalence proof for ECDSA verification), and verifying implementation properties using Verus. * **Proposed Draft Restructuring:** The authors plan to split the work: 1. Move the generic Fiat-Shamir construction to the interactive Oracle proof (IOP) section of the draft-michele-kathy-fiat-shamir-style document. 2. Maintain a core CFRG document containing the scheme and parameters. 3. Keep application-specific circuits separate. * **Discussion:** Christopher Wood supported the split and suggested standardizing a library of common, verified cryptographic gadgets (e.g., ML-DSA verification, Merkle trees, hash functions) within the CFRG to prevent application developers from implementing them incorrectly. Abhi Shelat agreed that establishing verified composition primitives is a strong direction. ### Hybrid Post-Quantum Password Authenticated Key Exchange * **Presentation:** Christopher Wood presented [Hybrid Post-Quantum Password Authenticated Key Exchange](https://datatracker.ietf.org/meeting/126/materials/slides-126-cfrg-hybrid-post-quantum-password-authenticated-key-exchange-01). * **Technical Details:** The presentation detailed "APAIC" (OakQuake), a post-quantum PAKE design using a black-box approach. It integrates symmetric/asymmetric variants (OakQuake / OakQuake Plus) and sequential hybrid modes with CPAsE. * **Scope Proposal:** Christopher Wood proposed that CFRG adopt and specify the core cryptographic research building blocks (such as the hybrid combiner and the "splittable KEM" required by the Tempo variant to mitigate timing attacks on the password). The wire formats and protocol-specific engineering details should be handled in a dedicated, short-lived IETF working group. * **Discussion:** * Dan Harkins supported adoption but questioned the necessity of the "splittable binary uniform encoded KEM" (BUA-sKEM) abstraction, arguing that standard ML-KEM key generation combined with the `kemeleon` protocol is sufficient. He also advised removing strict bit-level encoding rules (e.g., LV encode/decode) from the CFRG draft. * Christopher Wood responded that splitting the KEM public key is mathematically required in Tempo to block a severe side-channel timing attack on the password. * Scott Fluhrer expressed skepticism regarding multi-round hybrid PAKEs due to integration challenges in existing protocols. Stefan Santesson strongly supported the work, emphasizing the industry's need for a standardized post-quantum replacement for Opaque. ### Silithium: A Compact, Efficient and Non-Separable Hybrid Signature * **Presentation:** Sofian Brissaud presented [Silithium - A compact, efficient and non-separable hybrid signature](https://datatracker.ietf.org/meeting/126/materials/slides-126-cfrg-sessb-silithium-a-compact-efficient-and-non-separable-hybrid-signature-01). * **Technical Details:** Silithium is a hybrid signature scheme designed to provide "non-separability" (preventing an attacker from stripping one signature type and presenting the other). It uses an ML-DSA "sandwich" construction, embedding a classical Schnorr/ECC commitment directly into the ML-DSA context string. * **Discussion:** * Scott Fluhrer noted that if a repeated nonce under the same key can compromise security, the scheme must use a hedged or deterministic nonce generation mechanism for all elliptic curves (not just Ed25519). He also warned that appending the commitment to the message (rather than the context string) reduces the security bounds to those of composite signatures. * John Preuß Mattsson strongly advocated for hedged over purely deterministic randomness due to side-channel injection vulnerabilities on physical IoT devices. * Steffen Kittel and several chat participants expressed concern over "hybrid signature overload" and the resulting interoperability and testing challenges, noting the abundance of existing proposals (e.g., 18 composite variants in LAMPS). * Britta Hale and Kris Kwiatkowski noted via chat that hybrid signatures possess subtle security failure modes not present in hybrid KEMs, necessitating a deeper analysis of required properties before adoption. ### Asynchronous Remote Key Generation (ARKG) * **Presentation:** Emil Nygren presented [The Asynchronous Remote Key Generation (ARKG) algorithm](https://datatracker.ietf.org/meeting/126/materials/slides-126-cfrg-sessb-the-asynchronous-remote-key-generation-arkg-algorithm-00). * **Technical Details:** ARKG allows a client to generate public keys asynchronously from a hardware-bound seed without requiring online interaction or user gestures for each key generation. It is highly relevant for the EU Digital Identity (EUDI) wallet to achieve unlinkability. The latest draft updates include detailed privacy considerations on seed secrecy and ciphertext integrity. * **Discussion:** * John Bradley (co-author) clarified that while zero-knowledge credentials (like Longfellow or BBS) are the preferred long-term privacy solution, ARKG represents the best currently deployable mechanism for batch-issuance and hardware security modules. * Nick Sullivan asked which parts of the draft represented engineering rather than research. Emil Nygren responded that the core is based on existing peer-reviewed research, though the draft currently includes COSE wire-format bindings that could be moved to an IETF working group if requested. ### PQuAKE: Compact Post-Quantum Mutual Authentication for Key Exchange * **Presentation:** Stanislav Smyshlyaev presented [PQuAKE: Compact post-quantum mutual authentication for key exchange](https://datatracker.ietf.org/meeting/126/materials/slides-126-cfrg-sessb-pquake-compact-post-quantum-mutual-authentication-for-key-exchange-00) on behalf of author Yuri Blumenthal. * **Technical Details:** PQuAKE is a protocol designed to achieve mutual authentication and key exchange using only KEMs, bypassing the need for large post-quantum signature schemes (such as ML-DSA). It significantly reduces handshake sizes and CPU overhead, making it attractive for constrained devices and high-throughput VPN gateways. * **Discussion:** * John Preuß Mattsson pointed out that the Lake working group recently adopted a similar KEM-based mutual authentication mechanism for EDHOC, which may limit the need for a separate design. * Thom Wiggers (author of KEM-TLS) remarked that KEM-based authentication is highly protocol-specific due to varying requirements for identity hiding, transcript binding, and round-trip limits. He questioned whether a generic framework could be meaningfully standardized in CFRG. * Goutam Paul supported the efficiency benefits of KEM-based authentication for battery-powered devices and suggested trying to unify the underlying cryptographic frameworks used by TLS, IKEv2, and EDHOC. --- ## Decisions and Action Items * **Hybrid PAKE Draft Split:** Christopher Wood will restructure the hybrid PAKE draft to separate the core cryptographic primitives (for CFRG) from the protocol-specific wire formats (for a future IETF working group / BoF) before initiating an adoption call. * **Longfellow Draft Split:** The authors of the Longfellow ZK draft will coordinate with the authors of the Fiat-Shamir draft to integrate the IOP sections and refine the core scheme/parameters document. --- ## Next Steps * **PQ KEM Security Considerations:** The chairs will compile the feedback from the session and initiate a structured discussion on the mailing list regarding the potential adoption of a general-purpose KEM guidance document. * **Hybrid PQ/T Signatures Adoption:** Given the split feedback in the session poll, the chairs will take the discussion to the mailing list to determine if and how CFRG should proceed with hybrid signature schemes. * **ARKG Review:** The chairs encouraged the WG to read and review `draft-nygren-cfrg-arkg` on the mailing list to gauge readiness for adoption. --- ## Session Polls ### Poll 1 * **Question:** Is the topic of Hybrid PQ/T Signatures something the CFRG should explore adopting? * **Result:** * **Yes:** 42 * **No:** 17 * **No Opinion:** 8 * **Total Votes:** 121 --- **Session Date/Time:** 24 Jul 2026 09:30 # [CFRG](../wg/cfrg.html) ## Summary The Crypto Forum Research Group (CFRG) met during IETF 126. The session was chaired by Stanislav Smyshlyaev. The meeting consisted of four technical presentations and associated discussions covering: * Chameleon encodings for ML-KEM (`draft-ietf-cfrg-kemeleon-encodings`) * BBS Signatures and extensions (`draft-ietf-cfrg-bbs-signatures` and `draft-ietf-cfrg-blind-signatures`) * Schnorr-type proofs of possession for ECDSA device binding * Pairing-Friendly Curves (`draft-ietf-cfrg-pairing-friendly-curves`) --- ## Key Discussion Points ### 1. Kemeleon Encodings * **Speaker:** Felix Günther * **Slide Deck:** [Kemeleon Encodings](https://datatracker.ietf.org/meeting/126/materials/slides-126-cfrg-kemeleon-encodings-00) * **Discussion:** * **Background:** Chameleon encodings turn ML-KEM public keys and ciphertexts into random-looking byte strings to prevent wire-format distinguishability (useful for censorship resistance, metadata hiding, and PAKEs). * **Updates in Version 02:** * The main encoding (previously "non-rejecting") is in Section 4. It represents an $n$-bit integer in $n + t$ bits, yielding a statistical distance of at most $2^{-t}$ from uniform. * The parameter $t$ is now fixed to $76$ (statistical distance $2^{-76}$) to ensure byte alignment and eliminate tunable parameters. This results in public keys with the same size as regular ML-KEM keys. * The rejection variant (Section 5.1) has been updated for byte alignment and bit-clearing in the top byte. This variant yields smaller outputs at the cost of a reduced success rate. * A deterministic variant (Section 5.2) derives randomness deterministically from the shared secret. * **Feedback Requested:** 1. Should the statistical distance be fixed ($t = 76$) or remains a tunable parameter? 2. Is there a preferred mechanism for specifying randomness generation to aid implementation comparison? * **Q&A and Comments:** * **Chris Wood:** Raised a mailing list exchange regarding parallelized password guessing attacks. He suggested that a tunable parameter with reasonable guidance might be appropriate, particularly because other consuming protocols within CFRG could make reasonable assumptions. * **Felix Günther:** Agreed to follow up on the exact mechanics of parallelized password guessing. * **Scott Fluhrer:** Noted that the required statistical distance depends on the distinguisher. If the only distinguisher requires observing $2^{76}$ squared outputs, then $2^{-76}$ is an overkill. If there is a different distinguisher where one can be certain with probability $2^{-76}$, then $2^{-76}$ is appropriate. --- ### 2. BBS Signatures & Extensions * **Speakers:** Vasilis Kalos, Emil Lundberg, and Anja Lehmann * **Slide Deck:** [BBS](https://datatracker.ietf.org/meeting/126/materials/slides-126-cfrg-bbs-00) * **Discussion:** * **BBS Core Draft (`draft-ietf-cfrg-bbs-signatures`):** * Vasilis Kalos noted the core draft is stable and has resolved the first round of Crypto Panel reviews. * Two active pull requests address implementer feedback regarding the difficulty of writing straight-line implementations of the core without implementing all extensions. These PRs restructure operations and introduce an object notation to separate redundant validity checks. * **Pseudonyms & Blind Signatures (`draft-ietf-cfrg-blind-signatures`):** * Vasilis Kalos described two flavors of pseudonyms: pseudonymous identity (constant within a context, unlinkable across contexts) and rate-limiting pseudonyms. * The editors are considering merging the pseudonyms draft into the blind signatures draft to create a unified "BBS Extensions" document. * **Native Device Binding:** * Emil Lundberg presented a method for "native" device binding on hardware-bound keys using the DBAC (Device Bound Anonymous Credentials) model. * Instead of directly signing a challenge (which is impossible on hardware signers without leaking the private key due to the BBS structure), the prover demonstrates a blinding relationship within the BBS proof and separately proves possession of the blinded public key. * This requires splitting the blind issuance commitment and proof generation into distinct initialization, proof, and finalization/assembly phases. Emil queried whether the group wants to support multiple device binding keys and if they should survey existing Schnorr/BLS implementations for compatibility. * **Committed Disclosures:** * Anja Lehmann explained the "committed disclosures" extension to BlindBBS. To avoid monolithic zero-knowledge proof specifications for every combination of use cases (e.g., pseudonyms, range proofs, device binding), they propose a modular framework. * In this framework, the core BBS module outputs attributes and a Pedersen commitment along with an equality proof. Other extension modules (e.g., pseudonyms or ECDSA device binding) plug in and run their proofs directly on these committed inputs. This model is already aligned with the European Digital Identity (EUDI) Wallet TS 14. --- ### 3. Schnorr-Type Proofs of Possession for ECDSA Device Binding * **Speakers:** Anja Lehmann and Shay Gueron * **Slide Deck:** [Schnorr-Type Proofs of Possession](https://datatracker.ietf.org/meeting/126/materials/slides-126-cfrg-schnorr-type-proofs-of-possession-00) * **Discussion:** * **Motivation:** For high-security digital wallets (like the EUDI Wallet), credentials must be bound to hardware-secured keys (non-transferability). Most current smartphones only support ECDSA inside their secure elements. * **Challenge:** To maintain user anonymity, the device's public key must not be revealed. Instead, the user must present a zero-knowledge proof of possession of the private key corresponding to a committed ECDSA public key. * **Technical Details (Shay Gueron):** * The standard ECDSA verification equation is rearranged so that the hash evaluation does not need to be proven in zero-knowledge. The ephemeral value $k$ can be revealed because it is unique per signature. * To link the BLS-friendly curves used in BBS with the P-256 curve of the secure element, a "Tom Curve" (T256) is used to commit to the coordinates of the P-256 point. * A commitment transfer proof is executed to show that the BLS commitment and the T256 commitment open to the same public key. * The proof utilizes optimized point addition and scalar multiplication proofs (based on the CaDLs and CLZ papers), which achieve a 25-30% reduction in proof size and verification time. * **Next Steps:** The authors called for assistance on serialization, data formats, integration with existing BBS standards, and specifying the complete non-interactive protocol via Fiat-Shamir. --- ### 4. Pairing-Friendly Curves * **Speaker:** Yumi Sakemi * **Slide Deck:** [Pairing-Friendly Curves](https://datatracker.ietf.org/meeting/126/materials/slides-126-cfrg-pairing-friendly-curves-00) * **Discussion:** * **Updates in Version 13 of `draft-ietf-cfrg-pairing-friendly-curves`:** * Nine issues and ten PRs were closed. * **Curve Set:** Suggestions to replace proposed curves with BN446, BLS24509, or BLS48575 were evaluated against the draft’s selection policy (detailed in Issue 87). With evaluation assistance from Diego F. Aranha, the curve set remains unchanged. * **192-bit Security:** No 192-bit security curve was added as none met the selection criteria and there was no interest expressed on the mailing list. * **Point Serialization:** Added point serialization procedures to the normative part of the draft to resolve discrepancies between BBS, COSE, and BLS signature serialization formats. * **Q&A and Comments:** * **Emil Lundberg:** Thanked the authors for incorporating the pairing implementation guidance. He noted some minor editorial issues in the serialization/deserialization procedures but stated they are straightforward to fix without needing deep discussion. * **Stanislav Smyshlyaev (Chair):** Stated that the chairs will proceed with sending the draft for a second Crypto Panel review, focusing on the updated normative serialization parts (Section 5 and Appendices B and D). --- ## Decisions and Action Items * **`draft-ietf-cfrg-pairing-friendly-curves`:** The chairs will initiate a second Crypto Panel review of the draft, specifically targeting the updated point serialization sections. --- ## Next Steps * **Kemeleon Encodings:** Editors and contributors will continue list discussions to determine if statistical distance should be fixed or tunable, and to select a concrete randomness generation mechanism. * **BBS Core:** Merge current PRs simplifying straight-line core implementations and determine if a follow-up Crypto Panel review is required. * **BBS Extensions & Pseudonyms:** The editors will discuss merging the pseudonyms draft with the blind signatures draft into a single "BBS Extensions" document. * **ECDSA Proof of Possession:** The authors will collaborate with the working group on serialization, Fiat-Shamir non-interactive conversion, and alignment with BBS drafts. * **Pairing-Friendly Curves:** Authors aim to address the minor serialization comments raised by Emil Lundberg, close issues #74 and #84 on GitHub, and prepare the document for Research Group Last Call (RGLC) following the Crypto Panel review.