Minutes IETF105: cfrg
||Minutes IETF105: cfrg
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 firstname.lastname@example.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.
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 --
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
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)
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.