Skip to main content

Minutes interim-2020-cfrg-02: Wed 16:00
minutes-interim-2020-cfrg-02-202007151600-00

The information below is for an old version of the document.
Meeting Minutes Crypto Forum (cfrg) RG Snapshot
Date and time 2020-07-15 16:00
Title Minutes interim-2020-cfrg-02: Wed 16:00
State Active
Other versions plain text
Last updated 2020-07-16

minutes-interim-2020-cfrg-02-202007151600-00
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 focussed 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.