CFRG Summary - IETF 105 Meeting started at 15:52 New co-chair appointed since the last IETF (Nick Sullivan). Also a new secretary (Stanislav Smyshlyaev). Looking for volunteers for CFRG Crypto Review Panel. Need both academic and industry experience. Please email chairs cfrg-chairs@ietf.org. PAKE selection process has started (summary by Stanislav later) HPKE (Richard Barnes) Dan Harkins: Same key-pair - same key? Richard: No, we got fresh enthropy Tanja Lange: it depends on how they define ephemeral Adam Langley: Consider NOISE. Shows we can do something worthwhile. Go there. Richard: What does "go there" mean? Adam: Don't need to do an all too general framework Richard: This is orhtogonal to the NOISE approach Riad: What would you remove if it was up to you? Richard: The modes in which the sender is authenticated with a symmetric key. Riad: Remove the unauthenticated case? Richard: Not sure it would streamline things much. It's already a special case. Joe Sallowey: In a WG I'd say we need to take things out. In an RG - less so. But still - less is more. Richard: I think we have a consolidated set. Think we should leave things as they are. Richard: naming? CASHEW: Combined Asymmetric/Symmetric Hybrid Encryption Wrapping Chris Wood: Likes cashews. MGM (Stanislav): Multilinear Galois Mode Scott Fluhrer: GCM also has the property that you can begin encrypting before you have the AAD Stanislav: Right Yoav: why not call for adoption? Stanislav: I am not the designer. Maybe in the future. Watson Ladd: The cited attacks don't really break GCM. Stanislav: MGM has better security bounds than GCM for some attacks. Watson: The slides conflict. One says MGM performs better; the other says GCM does. Stanislav: Depends on context. Authentication vs. Confidentiality Pairing Friendly Curves (Shoko Yonezawa) Riad: BLS12-381 is designed for use with pairing-based arguments (zkSNARKs). Is it worthwhile to define curves at the 192- and 256-bit levels for this purpose, too? (One reason not to is that generating proofs at the 128-bit level is already unbelievably slow, and higher security levels will be even worse, so maybe no one would ever use curves for that purpose even if they were available.) Shoko: We have to consider many curves. Not all for implementers to implement because they are confused as to which curve to implement. Riad: Yes, but is specifying BLS48-581 (vs. some other BLS48 curve) necessary? Don't know that people are using 581---maybe we could replace it now before its use becomes widespread. Tanja Lange: Optimal TNFS-secure pairings on elliptic curves with composite embedding degree Georgios Fotiadis and Chloe Martindale -- https://ia.cr/2019/555 Anyone has applications? 3 hands are raised. Streebog and Kuznyechik (Lėo Perrin) PHB: Some jiggering going on. Yoav: Why does ISO standardization matter? Russ Housley: We only know that something smells funny. Stanislav: Thanks for doing the analysis. There was public info before standardization. Maybe not as public as it should have been. Agree that any analysis should be done. Concerns should be investigated. Papers say there are structures, not showing how it could be exploited. If you find attack or hazard, I'll be happy to discuss with you. For now we only have structures. Léo: Right. No attack. Analyzers should have had all the information. Vasily Dolmatov: Presence of a structure does not imply presence of a vulnerability. Logic chain is broken here. Nevertheless, we appreciate your finding of effective computational representation of S-boxes and programmers who implement this algorithm are willing to thank you for this. Hash to curve update (Riad Wahby) (no comment) Alexey: 1 more revision? More? Riad: Close to done; need to cover a few more curves. No huge changes. PAKE Contest Update (Stanislav) Vasily Dolmatov: Hopefully people from TLS or IKEv2 are here. Otherwise we need to contact them. Alexey: TLS people are here. Yoav: Also IKE people Bjoern Haase: Could you post the place where to find the replies regarding VTBPEKE? I did not find it on the mailing list. Stanislav: Yes. They're either on the CFRG mailing list or the chairs posted to the mailing list. We'll try to publish again in a convenient way. Nick: Still looking for volunteers for the panel. Would like people to review more than one for better comparison.