Re: [Cfrg] Meeting notes
Yoav Nir <ynir.ietf@gmail.com> Fri, 27 March 2015 12:49 UTC
Return-Path: <ynir.ietf@gmail.com>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 445671ACDB3 for <cfrg@ietfa.amsl.com>; Fri, 27 Mar 2015 05:49:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LMnYflR3ZqxX for <cfrg@ietfa.amsl.com>; Fri, 27 Mar 2015 05:49:49 -0700 (PDT)
Received: from mail-ob0-x233.google.com (mail-ob0-x233.google.com [IPv6:2607:f8b0:4003:c01::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B21B81ACDA8 for <cfrg@irtf.org>; Fri, 27 Mar 2015 05:49:48 -0700 (PDT)
Received: by obbgh1 with SMTP id gh1so7809630obb.1 for <cfrg@irtf.org>; Fri, 27 Mar 2015 05:49:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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 10.182.28.39 with SMTP id y7mr15849793obg.11.1427460588233; Fri, 27 Mar 2015 05:49:48 -0700 (PDT)
Received: from [10.111.111.12] ([173.200.48.34]) by mx.google.com with ESMTPSA id ds7sm978999obc.3.2015.03.27.05.49.45 (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 <ynir.ietf@gmail.com>
In-Reply-To: <CAHOTMVKUyNsA7ux4epk8LwR0w0Eh7dh0G3xTXB3O9m8jQPS3EQ@mail.gmail.com>
Date: Fri, 27 Mar 2015 07:49:44 -0500
Message-Id: <0C65868C-1725-4B32-A562-62C9DF36A956@gmail.com>
References: <CAHOTMVKUyNsA7ux4epk8LwR0w0Eh7dh0G3xTXB3O9m8jQPS3EQ@mail.gmail.com>
To: Tony Arcieri <bascule@gmail.com>
X-Mailer: Apple Mail (2.2070.6)
Archived-At: <http://mailarchive.ietf.org/arch/msg/cfrg/AfQeNEj7bbTmwjtwamfMsbQzq78>
Cc: "cfrg@irtf.org" <cfrg@irtf.org>
Subject: Re: [Cfrg] Meeting notes
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=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. Yoav > On Mar 27, 2015, at 2:02 AM, Tony Arcieri <bascule@gmail.com> 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.
- [Cfrg] Meeting notes Tony Arcieri
- Re: [Cfrg] Meeting notes Yoav Nir
- Re: [Cfrg] Meeting notes Derek Atkins
- Re: [Cfrg] Meeting notes Yoav Nir
- Re: [Cfrg] Meeting notes Derek Atkins
- Re: [Cfrg] Meeting notes Watson Ladd
- Re: [Cfrg] Meeting notes Daniel Kahn Gillmor
- Re: [Cfrg] Meeting notes Johannes Merkle
- Re: [Cfrg] Meeting notes Yoav Nir
- Re: [Cfrg] Meeting notes Ilari Liusvaara
- [Cfrg] (on Algebraic Eraser) Re: Meeting notes Rene Struik
- Re: [Cfrg] (on Algebraic Eraser) Re: Meeting notes Derek Atkins
- Re: [Cfrg] (on Algebraic Eraser) Re: Meeting notes Nico Williams
- Re: [Cfrg] Meeting notes Nico Williams
- Re: [Cfrg] (on Algebraic Eraser) Re: Meeting notes Rene Struik
- Re: [Cfrg] (on Algebraic Eraser) Re: Meeting notes Nico Williams
- Re: [Cfrg] Meeting notes Derek Atkins
- Re: [Cfrg] Meeting notes Alexey Melnikov