CFRG Interim Meeting

Wednesday, July 15, 2020
16:00 - 17:30 UTC, Virtual

Minutes:

CFRG Update - Stanislav Smyshlyaev (SS)

SPAKE2 - Watson Ladd (WL)
Rene Struik (RS): Why do we allow multiple curve types? It makes maintainence harder.
WL: User demand. The burden of supporting different representations is not very much. Point representations can be easily mapped to each other.
Bjorn Haase (BH): "It might be worth adding the pointer to the recent paper with the UC analysis for SPAKE2 (IIRC to be presented at crypto 2020)." https://eprint.iacr.org/2020/320. Different point representations can be more or less efficient in different settings.
Ben Kaduk (BK): Some people need NIST curves for compliance reasons, in the Kerberos use case we need to use Edwards curves because of licensing issues.
Phillip Hallam-Baker (PHB): "There is no 'easy mapping' if Montgomery curves are involved"
WL: Take the point format discussion to the list.

Usage Limits on AEAD - Chris Wood (CW)
Uri Blumenthal (UB): Why are you excluding SIV, esp. since GCM-SIV comes with pre-computed bounds.
CW: Only because we haven't put them in yet. We would like to cover it here.
SS: No hat. I support this document. It's important work.
Joes? +1
Dmitry Belyavskiy (DB): Would you like to add the MGM (Multilinear Galois Mode) to your draft?
CW: We focused on popular ciphers first.
Scott Fluhrer (SF): The TLS GCM ciiphersuiites include 32 bits from the KDF into the nonce used - this increases the security from multiuser attacks. Does this document address such usage-specific situations?
CW: Yes. The limits are worse if you use AEADs "out-of-the-box"
WL: Can we have a general method for discovering the bounds, where we just plug-in the blocksize, PRF vs PRP, etc. The proofs of ChaCha and AES GCM are essentially the same.
Felix Gunther: Not simple how you would do this. The formulae from the papers use quite varied assumptions, and we are working on unifying them.
PHB: "I also support this work. I did some thinking about how to encrypt really large files (e.g. backups of backups so 1Tb blobs. When you get to that point, the encryption limit turns out to be less a concern than the integrity checksums in TCP/IP, RAM, etc."
Yaron Sheffer: +1, +1 for SIV, do you consider the PQ threat model?
CW: Don’t consider PQ in this document.
Dan Harkins (DH): Do you consider cases where the AEAD is much larger than the plaintext?
CW: We assume that the AEAD is much less than the plaintext being encrypted. We should make that clear.
UB: +1, +1 to PQ
SS: We will have an adoption call in the CFRG mailing list

VOPRF - Alex Davidson (AD)
UB: Would SHA-3 serve better than SHA-512?
AD: We don't do any key derivation with SHA-512, we use it to generate random field elements. We're willing to consider it.
BH: Is is mandatory to require the "RO"-version of the map for Curve25519?
AD: We need a uniform-group element, not sure if simpler versions give us that.
RS: What is the benefit of Ristretto or Decaf?
AD: They provide a unified encoding for mapping these curves to prime-order groups.
Nick Sullivan: There is an expensive check making sure that a potentially malicious point is not on the prime-order subgroup, and ristretto/decaf eliminates the need for it.
BH: SHA-512 is often used with Ed25519 signatures, so SHA-512 is a good choice.
CW: +1 for SHA-512. SHA-3 is not yet wide-spread enough, not all TLS stacks support SHA-3, so we wouldn’t be able to use it the OPAQUE.
UB: One way to make SHA-3 more prevalent is to start using it. Any TLS implementation that is up-to-date enough to use OPAQUE would be new enough to implement SHA-3.
Alexey Melnikov (AM): We can take the SHA-3 debate to the list.

NKDF - Christopher Brzuska (CB):
MLS is proposing using the NKDF construction. We would like some eyes on it from the CFRG.
AM: Can we include the paper in our meeting materials?
Chelsea Komlo (CK): Can you talk about your proofs, and how the proofs of security of NPRF interact with the proofs of MLS as a protocol?
CB: This change should be modular, it only changes the way the local computation is done, but doesn't change the interface.
WL: Why not just run everything through SHA-3? A sponge construction can produce as much output as you like from as much input as you have.
CB: This pattern lets stacks re-use values if a computation changes slightly.
Jonathan Hoyland (JH): Is SHA-3 parallelisable?
Robert Moskowitz (BM): Yes, as are cSHAKE and KMAC. HMAC takes two hash operations. KMAC is one sponge operation.