Re: [Cfrg] Meeting notes

Yoav Nir <> Fri, 27 March 2015 12:49 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 445671ACDB3 for <>; Fri, 27 Mar 2015 05:49:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id LMnYflR3ZqxX for <>; Fri, 27 Mar 2015 05:49:49 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4003:c01::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B21B81ACDA8 for <>; Fri, 27 Mar 2015 05:49:48 -0700 (PDT)
Received: by obbgh1 with SMTP id gh1so7809630obb.1 for <>; Fri, 27 Mar 2015 05:49:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=9ea4grQkLmPJ5YdXj7L5UP0dCPik7u8z84xOWdV4llU=; b=NP7NbRIbYNVfJYbSXYKXqHNlNKlHHoiSnI6cpce35tLo9XUL9oIqOJLKCySkd6pFRD PqMDnYB2ZdJijoEdufQ/V44LPtkrWyTVcX7gap6l2/eap2ubzTjfY7cf0C4Yg5zSSWv9 di+qr6lFNoIDJW8SGXt7Np9xSnmQ4guB1CsIry1Ef3jS8eDN/bimuBq1r5JwMcxIc/7a vmdqZ8/fUn4sckycFz3+685VowZZ/zuYwxdf+X1zmexXmbfkcN9+8XzphufyMFTMlJe8 HqJk88EaKDIvepg9NUzTFhDdy2kh07kMpyhhmvQp/SmejQ53YMr0MkBpIQwjvlKg5Hks 312A==
X-Received: by with SMTP id y7mr15849793obg.11.1427460588233; Fri, 27 Mar 2015 05:49:48 -0700 (PDT)
Received: from [] ([]) by with ESMTPSA id ds7sm978999obc.3.2015. (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 27 Mar 2015 05:49:46 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_D8D64596-75F6-4941-87BE-CAB766C7D2AC"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
From: Yoav Nir <>
In-Reply-To: <>
Date: Fri, 27 Mar 2015 07:49:44 -0500
Message-Id: <>
References: <>
To: Tony Arcieri <>
X-Mailer: Apple Mail (2.2070.6)
Archived-At: <>
Cc: "" <>
Subject: Re: [Cfrg] Meeting notes
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 27 Mar 2015 12:49:56 -0000

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


> On Mar 27, 2015, at 2:02 AM, Tony Arcieri <> 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
	- 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.
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.