CFRG notes ========== All three chairs present. ~80 people in the room. Session began at 12:59. Document status Dragonfly in IRSG review Spake2 accepted as RG Document Work item: new curves for TLS. === First item: AGL on status of CFRG curves draft. Goldilocks has been included. Algorithms tweaked to work with different length. Not re-checked yet. WG decided to send u-value for DH Check for zero output - happens if input point has wrong order, checking is cheap, now a MUST. Parameter generation used to generate (twisted) Edwards curves and then hop isomorphisms and isogenies. Base point - in sage. generates the standard base point for curve25519 and u=5 for curve448. SAGE is a standard maths library based on Python. === no questions. Second item: Kenny Paterson on next steps for curves RG selected Curve25519 and Goldilocks (~224 bits) Produced by a deterministic procedure Submitted short proposal for NIST workshop as IETF/IRTF input. next: define a signature scheme for use with the new curves. Some options: - ECDSA on (twisted) Edwards form versions of the new curves - De-randomised ECDSA: - avoids common failure mode of ECDSA - generate r for ECDSA by hashing message and private key - generate r via prf. - EdDSA [BDLST'11] - variant of schnorr signature scheme Questions: - what other signature - does NIST compliance matter? for TLS? Others? - How should we structure the discussion to make it reaches a useful conclusion in a timely fashion. Rene Struik: we should also do non-special primes Kenny: We can do that when the main recommendations for TLS are done, but not now. Yoav Nir + Joe Sallowey: we should not consider NIST compliance, because nothing that is not ECDSA on P-256/P-384 is going to be. Paul Hoffman: You never know what NIST is going to say, so don't include it in our considerations. Kenny: we should engage with NIST Mike St. Johns: We should consider if it will be acceptable to banks and other high-value organizations. Andrei Jivsov: Do the decisions of DH for compressed vs uncompressed apply? Shouldn't we kick it to high-level protos? Stephen Farrell: no. DKG: Doesn't make sense to re-use formats because we want to not re-use keys Bob Moskowitz: keep it small AGL: strong feeling we should not worry about NIST. Should check on the list. randomized vs no? How Schnorrish should it be? Andrei: There is benefit in unified point format. You can still not share keys. AGL: not giving up on unified point format yet. Renee Struik: Confusion point about whether the Montgomery can be done with all formats. Rich Salz: should move to the next argument. This one is done. Stephen Farrell: Perhaps need to not use an incremental approach. KP: I think it has worked. AGL: EdDSA hashes twice, so you need to get it all the message in one block. Different from current APIs. === Third item: Scrypt KDF password-based KDF widely used current draft has pseudo-code in python, test vectors Seeking CFRG input. To be published as informational (currently outside of CFRG). Ben Kaduk: AGL: it is historical? The password hashing competition should be done by then. KP: should look at the password hashing competition. They're in their final stages - 6-8 months Nico: why informational? IETF Standards Track won't be able to use it. Chorus: Nico, you are wrong. === Fourth item: the Algebraic Eraser (Paul E Gunnels) Protocol for IoT things. Renee: what about sigs Atkins: a little different. fleshing out details, not yet public. Yoav: if it's good for IoT, why not for everything else? Derek Atkins: that's just our focus. Nico: Because this needs a trusted 3rd party that can break everything. KP: need some more cryptanalysis to know that key search is the best attack. PEG: there are other attacks. One to recover the conjugator. Another to recover the matrix part or the private key. Those have been refuted - reduced to exhaustive search. AGL: have you tried an optimized implementation? Would it be 70x faster on a quality CPU? Derek: I have seen 50x. AE could benefit from larger tables on commodity CPU. Stephen Farrell: trusted third party - what does it need to do? Derek: the trusted 3rd party is needed for the curve parameters. Derek: AE has a set of public parameters that you use to generate keypairs that can communicate (the equivalent of an ECC Curve or DH Prime). The issue is that you need random data to generate those public parameters, and that random data needs to be kept secret. Once the parameters are generated you don't need access to the random data ever again, but the issue, as I understand it, is "how do you know that that random data wasn't compromised during the parameter generation process?" === Fifth item: Hash-based signatures (Huelsing) AGL: why not generate bit masks using stream ciphers? Huelsing: you don't get the size reductions going AGL: if this is a stateful scheme. It really needs to work for a long time. Isn't this contradictory to having a stateful scheme? Huelsing: We have to always increase the index. Easily possible on certain applications like smartcards. AGL: if you want to be conservative, you need to be stateless. Huelsing: some people want the stateful scheme. Smaller signatures are an advantage. This is a step towards standardizing the stateless schemes. The current proposal is more efficient. AGL: Are you planning on going forward? Huelsing: yes Hannes: you talked about efficiency. Do you have numbers somewhere? Huelsing: yes, we have a C implementation on my website. We have numbers for a smartcard implementation. Hannes: will check your webpage. === Sixth item: PAKE requirements (Harkins) Dan: the requirement draft is in writing. Some initial requirements on the slide, but not ready to discuss them yet. === Seventh: AugPage (Shin) AGL: you had lots of requirements on the EC groups. What is the advantage of this over Spake2 that works with less requirements. Shin: it's not augmented. Yaron: The person in the Jabber room (bitwiseshiftleft = Mike Hamburg) thinks the proof is incorrect Renee: Can you tweak the scheme so you can get rid of this inversion that computes the z in slide #10? Shin: Not big computation cost === Eighth: SIP authentication with EC-SRP (Liu)