Re: [Cfrg] Meeting notes

[Yoav Nir <[e-mail]>]

The chairs will post the edited notes when they get the chance to go over them. But I’ve posted the raw notes below.

Yoav

> On Mar 27, 2015, at 2:02 AM, Tony Arcieri <[e-mail]> wrote:
> 
> Did anyone take any notes from Wednesday's CFRG meeting? I'd be interested in reading them.

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.
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
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.
PHB: 
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 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 part. 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.

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? Standards track won't be able to use it
Chorus: not anymore


=== Fourth item: the Algebraic Eraser (Paul E Gunnels)
Protocol for IoT things.

Renee: what about sigs
Atkins: a little different. fleshing 
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.
AGL: on a large scale you would need... (OK, I didn't understand the trusted 3rd party issue...) 


=== Fifth item: Hash-based signatures (Huelsing)
AGL: why not generate bit masks using stream ciphers?
Huelsing: you don't get the 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 s step towards standardizing the stateless schemes. This 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)

=== 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)
PHB: I've solved the problem that was impossible to solved - the key generation one.