# CFRG - Crypto Forum Research Group {#cfrg---crypto-forum-research-group} IETF 116 in Yokohama Friday, March 31, 2023, 09:30-11:30 (UTC + 9) Meetecho: https://meetings.conf.meetecho.com/ietf116/?group=cfrg&short=&item=1 Jabber: cfrg@jabber.ietf.org Notes: https://notes.ietf.org/notes-ietf-116-cfrg Chairs: Stanislav Smyshlyaev, Nick Sullivan and Alexey Melnikov Note-taker: Jonathan Hammell ## Chairs' update {#chairs-update} Slides: https://datatracker.ietf.org/meeting/116/materials/slides-116-cfrg-chairs-update-03 * No agenda bashing * Document status * Colin Perkins: VOPRF draft almost done, FROST will be processed soon. ## Guidelines for writing cryptography specifications (Nick Sullivan) {#guidelines-for-writing-cryptography-specifications-nick-sullivan} Slides: https://datatracker.ietf.org/meeting/116/materials/slides-116-cfrg-guidelines-for-writing-cryptography-specifications-01 * Not a draft yet, but a draft that authors are considering writing * Goal is to incorporate trustworthy specifications * Rich Salz: Glad to help and there are others that can support in Akamai * Kirsty P: May not need a draft, but could be documented on a wiki page * Nick: Originally we were doing it that way, but got complicated and we wanted more eyes on it * Scott: Willing to help out. One problem I see is that crypto researchers often assume mathematics that the average protocol dev isn't familiar with. * Joe Salowey: I think it is a good idea and willing to contribute text. * Daniel Gillmor (DKG): "Yes". Test vectors: standardizing on explicit wire formats is a really important thing or downstream protocol devs haggle over wire formats forever. * Colin Perkins: I also think this is a fantastic idea. Two things (not a cryptographer): It would be useful if it could highlight things to consider for reviewers. There is no obvious way of going from pseudocode to test vectors. That provenance is not usually described in the text. * Chris Wood: A lot of academic papers make simiplifying assumptions about the underlying mathematics. CFRG should attempt to specify those things to help implementors. Ex.: mathematicians assume prime order groups exist, then implementors stumble over actually generating them. Multiparty computation and new techniques will be even more complicated * Yoav Nir: Test vectors should be comprehensive and cover corner cases. You also need to be very simple and clear, since implementers are not in this room. * Shivan Sahib: List examples that do this well, since these are useful references for writers. * Flo D: Strongly in favour of this draft. Hard to write one draft for three audiences. * Nick: Seems to be strong support. We will submit a draft. ## Key blinding for signature schemes (Ted Eaton) {#key-blinding-for-signature-schemes-ted-eaton} Slides: https://datatracker.ietf.org/meeting/116/materials/slides-116-cfrg-key-blinding-for-signature-schemes-00 * No questions ## Verifiable Distributed Aggregation Functions (VDAF) (Phillipp Schoppmann) {#verifiable-distributed-aggregation-functions-vdaf-phillipp-schoppmann} Slides: https://datatracker.ietf.org/meeting/116/materials/slides-116-cfrg-vdaf-01 * Stanislav: It would help if the definitions are game-based to assist with game-based proofs. Ask for early verification of the security models. ## The BBS Signature Scheme (Tobias Looker) {#the-bbs-signature-scheme-tobias-looker} Slides: https://datatracker.ietf.org/meeting/116/materials/slides-116-cfrg-the-bbs-signature-scheme-00 * DKG: If you have already done the work of creating the negative test cases, keep them. Publish them somewhere, even if not in the draft * Armando Faz Hernandez: Regarding the dependence on hash-to-curve, how are you creating the random scalars? * Vasilis Kalos: We don't use the hash-to-curve mechanism for generating random scalars. * Mike Ounsworth: Does Nick's draft have an opinion on including negative test cases? * Nick: They do make the draft larger, and there may be other places to put them. But no opinion yet. * Orie Steele: Also in favour of keeping the negative test cases. Implementers should be aware of them. * Tobias: The negative test cases may also include a description of why. * Chris Wood: Don't punt to the application for the mapping of messages to scalars. * No feedback on use of the ZCash compact encoding of the curve points. ## Properties of AEAD algorithms (Andrey Bozhko) {#properties-of-aead-algorithms-andrey-bozhko} Slides: https://datatracker.ietf.org/meeting/116/materials/slides-116-cfrg-properties-of-aead-algorithms-00 * No questions. ## Rocca-S (Yuto Nakano) {#rocca-s-yuto-nakano} Slides: https://datatracker.ietf.org/meeting/116/materials/slides-116-cfrg-rocca-s-00 * https://datatracker.ietf.org/doc/draft-nakano-rocca-s/ * Stanislav: If Yuto has any comments for the AEAD Properties draft based on the Rocca-S analysis, please submit them. ## RSA Blind Signatures with Public Metadata (Ghous Amjad) {#rsa-blind-signatures-with-public-metadata-ghous-amjad} Slides: https://datatracker.ietf.org/meeting/116/materials/slides-116-cfrg-rsa-blind-signatures-with-public-metadata-01 * David Schinazi: Google is interested in using this in Chrome. Supportive of RG adoption. * Scott Hendrickson: Posted a draft that uses this mechanism. Interest in having this adopted. * Stanislav: Adoption call will be made on the mailing list. ## PLASMA (VDAF-related protocol) (Dimitris Mouris) {#plasma-vdaf-related-protocol-dimitris-mouris} Slides: https://datatracker.ietf.org/meeting/116/materials/slides-116-cfrg-plasma-00 * Philipp Schoppmann: Yours is a better version of the Dopplar. Fits very well with the VDAF draft. With the hashing at the end of the VDPF, if we have only zeros, what happens? * Pratik Sarkar: We only consider leaf-level comparison. With Heavy-Hitters, we have to consider the root and each parent and child have same value. * Dimitris: VDPF is from another paper. We introduce verifiable incremental VDPF. * Tim Geoghegan: One of the editors of the VDAF draft. I am interested in the dimension where there's an extra aggregator server. This is a trade-off because it is much more expensive to run. We have committed to restrict VDAF to only use two aggregator servers. We are choosing to optimize for operational efficency and simplicity. If others in the room concerned about these types of attacks, please let us know in PPM. * Dimitris: We have a trick that makes it more optimal for performance * Chris Wood: Tim said what I wanted to say. We don't need to answer this right now in the DAP world. We could consider whether we want to merge this in VDAF. * Stanislav: Please continue discussion on the mailing list. ## KEM-combiners (Mike Ounsworth) {#kem-combiners-mike-ounsworth} Slides: https://datatracker.ietf.org/meeting/116/materials/slides-116-cfrg-kem-combiners-01 * Deb Cooley: Why SHA-3 as opposed to SHA-2? * Mike: There was discussion on the list. Aron and Stavros had opinions. In an earlier version we had an HKDF-SHA-2 construction. * Aron Wussler: SHA-3 gives a simpler proof. Use of SHA-2 requires a more complicated construction to achieve a security proof. * Douglas Stebila: We will look to try to provide additional security proofs in comparison with other combiners * Stavros: We rely upon the random oracle properties of SHA-3. * Quyhn Dang: Is the ct\_i the KEM ciphertext? * Mike: Yes. * Quyhn: Some KEMs in the future may generate a shared secret without a ciphertext. And the ciphertext may be large. This may create a performance problem. * Mike: Stavros added this change for the proof. Described in the Security Considerations. * Quyhn: For CCA2, we look to the specific KEM. The KEM already has a KDF to generate the shared secret. * Mike: Not true for RSA KEM. * Quyhn: What is H? * Mike: H is a hash function. The KDF is SHA-3. * Stavros: We rely upon the ciphertext being present. This mitigates decapsulation oracles (based on an academic paper). * Quyhn: Whether the KEM has CCA2 security depends on the KEM. * Stavros: This KEM combiner may take KEM outputs that are not CCA2 secure. Will preserve CCA2 security. * Russ Housley: I am in favour of this work. Please get it done as quickly as possible. We have an opportunity for cryptographic libraries to implement it the best way, even if we discover our assumptions were incorrect. * DKG: I would love to have the CFRG eyes on it. Please adopt it. The OpenPGP WG will be rechartering soon and could use this in new work. * Scott Fluhrer: There may be places to use SHAKE instead of SHA-3. * Aron: We use KMAC as well. The combiner has a counter to produce as much output as necessary. ## AOB {#aob} * Dan Harkins: I have a draft in CFRG on doing extensions to HPKE. Watson Ladd introduced a draft that has another feature. It might be better to merge if there is desire to support AES-CBC. Please speak up on the list. * Scott Fluhrer: Looking at the partially blind signatures, there might be a cryptographic weakness. Maybe 1% of all possible metadatas could be forged. Will post it on the mailing list. * Florence D: PQUIP is next session. There is a PQC terminology draft there. If you are interested in debating terminology, please come.