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

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)

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)

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)

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)

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)

Slides:
https://datatracker.ietf.org/meeting/116/materials/slides-116-cfrg-properties-of-aead-algorithms-00

• No questions.

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)

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)

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)

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

• 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.