CFRG meeting 20 Nov 2019 Wednesday, November 20, 2019 13:30-15:00, room: Canning Chairs: Alexey Melnikov, Nick Sullivan, Kenny Paterson (not present) Administrivia... RG document status: - RFC published on re-keying - Argon2 document is nearly done - various active drafts -- h2c, vrf, kangaroo12, voprf, hpke. Q (Colin Perkins) on changes to Argon2 draft, thought there would be an update, talk later. Crypto review panel update - lots of good work done, thanks! - many nominations received for new membership. - New members for 2020-2021 to be announced next week. PAKE selection process update - narrowed it down to 2 balanced and 2 augmented PAKEs - Round 2 of selection to follow ----------------------------------------- Status of PAKE Selection Process - Stanislav Smyshlyaev - Process recap - 8 PAKEs, 4 balanced and 4 augmented, were submitted - great team of reviewers - reviews collected on github-- https://github.com/cfrg/pake-selection - all reviews were gathered and reviewed again by 4 reviewers (Bjoern Tackmann, Russ Housley, Yaron Sheffer, Stanislav Smyshlaev), selected 4 PAKEs for next round: * SPAKE2 (balanced) * CPace (balanced) * OPAQUE (augmented) * AuCPace (augmented) - we can now select 1 (or 0) of each - additional questions for 4 candidate PAKEs to be collected * use same constant for SPAKE2, can constant use h2c * others - expect Round 2 to start, new reviews for 4 candidates by 14-2-2020 - expect chairs to present reviews and specify what happens when selection is over * detailed description of protocol published as RFC * test vectors * guidelines No questions. ----------------------------------------- Hash to curve update -- Chris Wood - removed Icart - promoted simplified SWU for weierstrass curves - shallue-van de Woestijne parameterizations now applies to any curve - bunch of minor updates-- guidance for mapping functions and alternate base-to-hash functions, clarify output to sign to align with vrf draft, new Z selection code - next steps: add test vectors, finish ongoing implementations, RGLC? Chairs don't object Q: Stanislav-- needed for PAKEs, review needed, happy to review document A: yes, the review panel Chairs concur ----------------------------------------- HPKE -- Richard Barnes - minor technical changes, "single-shot" API, clarification and cleanup, test vectors - analysis by Benjamin Lipp based on reasonable assumptions to get IND-CCA2 public key encryption, all 4 modes analyzed. Q: Chris-- want to make analysis general for any KEM but now focusing on DH A: yes, if you want to help please help - next steps, implementation interop, finish analysis, start RGLC? Chairs think we can do CFRG LC Q: Chris-- encrypted SNI may depend on this so timelines are sensitive, other stuff has started using HPKE so we may want to get this out sooner rather than later A: RFC or stable? Q: well, stable...dunno Chairs: when it gets stable enough we'll do RGLC Deoxys- Thomas Peyrin - Proposing 2 modes for an AE primitive - get efficiency gain and avoid pitfalls of misordering, feature of authenticated-only - CAESAR competition picked this as a winner in "Defense in depth" category. - problem is a limit on the number of queries based on birthday paradox, solution is to get a beyond-birthday mode beyond 2^(n/2) potentially up to full 2^n - security will remain quite high even as queries grow - want nonce-misuse resistance. Nonce misuse is a big problem with AE, need robust defense even if the nonce is reused (some) security is retained - design review (see slides)-- it's tweakable, allowing for a selection from a family of permutationsof the block cipher mode, different modes allow for different amounts of tweakery - it's very efficient and unpatented - SCT AEAD Mode uses this AE * 2 pass, since it has nonce-misuse resistance * very efficient, almost no overhead for small messages * provably secure, strong MRAE security notion * inverse-free (for decrypt) * no patent - new proposed mode ZMAC/ZAE * little more efficient but more complex - comparison between AES-GCM-SIV and Deoxys * Deoxys was CAESAR winner, best tradeoffs for efficiency and flexibility * GCM is sensitive to timing attacks, this not so much * SCT is inverse free, more efficient in hardware * higher security for number of queries * Deoxys is more efficient on smaller packets, AES-GCM-SIV more efficient on larger ones Q: Dmitri Belyavsky -- did you study applying ways to deal with side channel attack protection? A: we are studying this, we're working on modes to provide this, ongoing work Q: Vasili Shishkin -- how much cryptanalysis has been done? A: it's on the website Q: Stanislav -- we have more modes for AEAD, we might want to select 1 or more of the best AEAD modes and make a CFRG recommendation, a la our PAKE process, for AEAD A: the crypto community already went through this work, different portfolios for selection, this one the "defense in depth" portfolio Q: yes but if there are other properties needed, important for different schemes, is fully parellelizable better than nonce misuse resistance, etc, things to look at Chairs: yes, we will keep an eye on this space ----------------------------------------- Committing AE-- Nick - how is this different than regular AE? AE where it's hard to find a ciphertext with multiple correct decryptions, binding committments - intuitively, imagine a safe and a key. this breaks down if keys are adversarial, if there are multiple possible decryptions this binds to a single one. - e.g. CTR is not committing, it can be decrypted with any key, GCM is not committing - where is cAE needed? Message franking, OPAQUE which is fragile without cAE, MLS may need this because it ensures transcript consistency - why do we need an RFC? Fewer mistakes and better designs. Lots of knobs to tweak, need guidance on threat models, requirements, use cases. Q: Stanislav -- thanks for good overview of problem, committing schemes are addressing one of main pitfals, good to have this advance Q: PHB -- very helpful, want to see it go forward. Good way of seeing if keys derived are "solid" ----------------------------------------- Mult-for-7748 -- Richard Barnes - multiplication is hard. Sometimes nice to multiply both the public and private keypairs of an elliptic curve to get a new point - commutivity is not true for x448 - high order bit is set, "clamped". We can create a mult operation that can take whichever is clamped, x or n-x - for some x, neither x nor n-x is clamped and then the operation fails, it's rare but it happens. Private key holder can detect this failure but public key holder can't. - Questions: is there interest? Good for CFRG? Q: Yaron Sheffer -- can this be done with out-of-the-box libraries or will people have to write this all themselves? A: it's possible to use X25519 libraries as they stand now, yes if you pull out the private key. One benefit of doing and RFC is it will get into the libraries without having to reach inside. ----------------------------------------- End of meeting!