From nobody Thu Oct 2 05:14:46 2014 Return-Path: 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 5FDAB1A6EF1 for ; Thu, 2 Oct 2014 05:14:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.785 X-Spam-Level: X-Spam-Status: No, score=-2.785 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.786] 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 aaTSEKiNaVVd for ; Thu, 2 Oct 2014 05:14:40 -0700 (PDT) Received: from waldorf.isode.com (ext-bt.isode.com [217.34.220.158]) by ietfa.amsl.com (Postfix) with ESMTP id 7250E1A1BF5 for ; Thu, 2 Oct 2014 05:14:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1412252079; d=isode.com; s=selector; i=@isode.com; bh=F0ICCEdKvkx6cLxSE0Kejh1jE+yvlkId+cvWqqfq15g=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=k+beYYwRLcKVQ40HCXlBHoFOPNYfxLOUButHY76gb5DmVEXLPkwTvoq5DEkrDp+3mOA0IM G1tj7MKBUfv8BMKTx2PNG/lFkR/78PBm8lK0ew7sH2lDezT+MM6iKQukSO7NZwx9DLxyDK qzGuRUl6JpmarKx1xizY5//4ZgY0IpI=; Received: from [172.20.1.49] (dhcp-49.isode.net [172.20.1.49]) by waldorf.isode.com (submission channel) via TCP with ESMTPA id ; Thu, 2 Oct 2014 13:14:39 +0100 Message-ID: <542D41B4.6030003@isode.com> Date: Thu, 02 Oct 2014 13:14:44 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 To: "cfrg@irtf.org" References: <5416032F.5040904@isode.com> In-Reply-To: <5416032F.5040904@isode.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------000007030600080307070401" Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/7TlWkhNCcqJlU3uuWSQglY2BLvo Subject: Re: [Cfrg] Acceptance call for draft-mcgrew-hash-sigs-02.txt X-BeenThere: cfrg@irtf.org 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: Thu, 02 Oct 2014 12:14:42 -0000 This is a multi-part message in MIME format. --------------000007030600080307070401 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 14/09/2014 22:05, Alexey Melnikov wrote: > Dear RG participants, > CFRG chairs received a request to accept draft-mcgrew-hash-sigs-02.txt > ("Hash-Based Signatures") as a RG document: > http://datatracker.ietf.org/doc/draft-mcgrew-hash-sigs/ > > The document was presented in Toronto and chairs would like to know if > there is enough interest to complete this document in CFRG. > > The acceptance call starts today and will last for slightly over 2 > weeks: please send your comments and statement of support (or not) for > this work till the end of September 28th. > > Thank you, > Alexey, on behalf of CFRG Chairs. The call has ended. Anybody else wants to voice their opinion on working on this document in the RG? (Note, it doesn't mean that the document is perfect or ready for publication, just that there is interest to work on it). In the absence of objections I would declare this document as accepted by the RG. Alexey, as a co-chair. --------------000007030600080307070401 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 14/09/2014 22:05, Alexey Melnikov wrote:
Dear RG participants,
CFRG chairs received a request to accept draft-mcgrew-hash-sigs-02.txt ("Hash-Based Signatures") as a RG document:
 http://datatracker.ietf.org/doc/draft-mcgrew-hash-sigs/

The document was presented in Toronto and chairs would like to know if there is enough interest to complete this document in CFRG.

The acceptance call starts today and will last for slightly over 2 weeks: please send your comments and statement of support (or not) for this work till the end of September 28th.

Thank you,
Alexey, on behalf of CFRG Chairs.
The call has ended. Anybody else wants to voice their opinion on working on this document in the RG? (Note, it doesn't mean that the document is perfect or ready for publication, just that there is interest to work on it).

In the absence of objections I would declare this document as accepted by the RG.

Alexey,
as a co-chair.
 

--------------000007030600080307070401-- From nobody Thu Oct 2 05:44:57 2014 Return-Path: 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 D0DA21A6FDF for ; Thu, 2 Oct 2014 05:44:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.786 X-Spam-Level: X-Spam-Status: No, score=-2.786 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.786] 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 VAntERtnU9PV for ; Thu, 2 Oct 2014 05:44:55 -0700 (PDT) Received: from waldorf.isode.com (ext-bt.isode.com [217.34.220.158]) by ietfa.amsl.com (Postfix) with ESMTP id 88BD71A031F for ; Thu, 2 Oct 2014 05:44:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1412253894; d=isode.com; s=selector; i=@isode.com; bh=bm8V/JcP3fW1ZSw9onEA8he++v0aZ5XbHYMms+8AjuY=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=gCd14j646qUfQRcpaDRmCSbTV+bOL2CNOEwcHlNIlyccpV24OvELFvEcFFXGsQk8grvqUo kyUXCWw6PFISWXtNdpTceC7RMJ9IehWYClOi56dmJbNiXIXHbsTpaFBe/yX9PfZQhAtoQd 9900S3tyvjcdw2CH4K118xLD15M+9q0=; Received: from [172.20.1.49] (dhcp-49.isode.net [172.20.1.49]) by waldorf.isode.com (submission channel) via TCP with ESMTPA id ; Thu, 2 Oct 2014 13:44:54 +0100 Message-ID: <542D48CD.9060404@isode.com> Date: Thu, 02 Oct 2014 13:45:01 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 To: "cfrg@irtf.org" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/AWdWjUjQMdHQxWWSP0OQdSRHc1I Subject: [Cfrg] RGLC on draft-irtf-cfrg-chacha20-poly1305-01.txt X-BeenThere: cfrg@irtf.org 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: Thu, 02 Oct 2014 12:44:57 -0000 The authors of "ChaCha20 and Poly1305 for IETF protocols", draft-irtf-cfrg-chacha20-poly1305-01.txt believe the draft is ready for a RGLC. This starts a two week research group last call, to end on 17 Oct 2014. The draft is available at http://datatracker.ietf.org/doc/draft-irtf-cfrg-chacha20-poly1305/ Please do comment on the list, indicating whether you believe this draft is ready for publication. Please send your comments, indication of support for the publication or objections to the publication to the mailing list or directly to the RG chairs (cfrg-chairs@tools.ietf.org). Alexey, As a co-chair. From nobody Fri Oct 3 04:10:36 2014 Return-Path: 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 193151A028B for ; Fri, 3 Oct 2014 04:10:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.101 X-Spam-Level: X-Spam-Status: No, score=0.101 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, UNPARSEABLE_RELAY=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 5uxFK4-sZ7V0 for ; Fri, 3 Oct 2014 04:10:33 -0700 (PDT) Received: from mace.cs.uic.edu (mace.cs.uic.edu [131.193.32.224]) by ietfa.amsl.com (Postfix) with SMTP id 0709D1AD038 for ; Fri, 3 Oct 2014 04:10:32 -0700 (PDT) Received: (qmail 5449 invoked by uid 1011); 3 Oct 2014 11:10:30 -0000 Received: from unknown (unknown) by unknown with QMTP; 3 Oct 2014 11:10:30 -0000 Received: (qmail 20326 invoked by uid 1001); 3 Oct 2014 11:10:24 -0000 Date: 3 Oct 2014 11:10:24 -0000 Message-ID: <20141003111024.20324.qmail@cr.yp.to> From: "D. J. Bernstein" To: cfrg@irtf.org Mail-Followup-To: cfrg@irtf.org In-Reply-To: <54116278.3080901@gmx.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/hXwTjUHi_xconBo_6FCApC_PVCQ Subject: [Cfrg] Trusting government certifications of cryptography X-BeenThere: cfrg@irtf.org 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, 03 Oct 2014 11:10:35 -0000 Torsten Schuetze writes: > Smart cards, i.e., its coprocessors and its ECC software > implementations, are always certified by Common Criteria, usually with > rather high assurance level. Don't you trust this certification in > principle? http://smartfacts.cr.yp.to explains how we factored 184 RSA-1024 keys from Taiwan's national "Citizen Digital Certificate" database. As you can see from http://smartfacts.cr.yp.to/cert.html, these keys were generated by government-issued smart cards that advertised all of the usual Common Criteria and FIPS certifications from BSI, NIST, and CSE. http://smartfacts.cr.yp.to/analysis.html analyzes five contributing factors to this security disaster---low-quality hardware RNG, inadequate sanity checks, no run-time sanity checks, no postprocessing, and inadequate initial response---and the complete failure of certification to prevent the disaster from occurring. Another interesting example to consider is the FIPS certification for branches of OpenSSL starting with openssl-fips-1.1.2.tar.gz (2007). The pursuit of FIPS certification was the reason that OpenSSL added support for Dual EC with NSA's P and Q. The certification procedure failed to catch the fact that OpenSSL's Dual EC implementation didn't work at all: https://www.mail-archive.com/openssl-announce@openssl.org/msg00127.html As Steve Marquess put it: "Frankly the FIPS 140-2 validation testing isn't very useful for catching 'real world' problems." After the public learned that Dual EC with this P and Q was an NSA back door (see, e.g., https://projectbullrun.org/dual-ec), the slowness of recertification stopped openssl-fips from dropping Dual EC support for _nine months_: https://www.mail-archive.com/openssl-users@openssl.org/msg75061.html It's clear that OpenSSL's certification had various other effects, such as diverting quite a bit of OpenSSL funding into InfoGard Laboratories Inc. How much positive security impact did this have to outweigh its obvious negative impacts? For example, how many of OpenSSL's security holes, whether in the FIPS version or generally, were discovered through the FIPS validation process? Security review is of course important, and I've heard several stories of security problems being caught by Common Criteria testing labs. But the security problems that _aren't_ caught show that certification is not true "assurance" of security---even in relatively simple settings such as the Taiwanese Citizen Digital Certificates, never mind the much more complex environment of Internet cryptography. I understand that words such as "certification" and "validation" and "assurance" have an important impact on users in some markets. But for experts it should be clear that more skepticism is warranted. You can't reasonably ask CFRG to "trust this certification in principle". ---Dan From nobody Fri Oct 3 09:19:43 2014 Return-Path: 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 AF3BC1A19E9 for ; Fri, 3 Oct 2014 09:19:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] 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 B59ambHTb0oJ for ; Fri, 3 Oct 2014 09:19:26 -0700 (PDT) Received: from nm1-vm6.access.bullet.mail.gq1.yahoo.com (nm1-vm6.access.bullet.mail.gq1.yahoo.com [216.39.63.149]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 254271A03F9 for ; Fri, 3 Oct 2014 09:19:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sbcglobal.net; s=s1024; t=1412353165; bh=BAHn+hMEaaZAfbIn3XquXaYY9Q6oLK6Gp3BWzD99/AI=; h=Received:Received:Received:DKIM-Signature:X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:From:Subject; b=LzBELvd/C2TYGZw72yxBlDSyGBLK9gQqk74CombWYzgEmRwyeuvikCID0cBqHjA/KKUjQ0Wq7+33fDWRPt7Vskm21/ZTVv6VKi58ZRewjmcyVO2/es4o+LRNrHGF7fnz8Vp5uey1Xca0Oam9K/WjA4NhlHVv17fh4xWkj5+SIHw= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=sbcglobal.net; b=4mAVGEsj02733cs6ysF/OblNmnPmyXuSkCatnIKhJziYtWYInLYdny8pz0gfbuhWq2pYqSiVR0tvQGonMHXoH9bOf6QthgLRyCZzTto2vq3AjJ+/ekuwJggZXo6JtPtVwCK1YEFC8KVwImQPDWUdd5+BOg2yMAL5gOyBu8ncusg=; Received: from [216.39.60.173] by nm1.access.bullet.mail.gq1.yahoo.com with NNFMP; 03 Oct 2014 16:19:25 -0000 Received: from [67.195.22.116] by tm9.access.bullet.mail.gq1.yahoo.com with NNFMP; 03 Oct 2014 16:19:25 -0000 Received: from [127.0.0.1] by smtp111.sbc.mail.gq1.yahoo.com with NNFMP; 03 Oct 2014 16:19:25 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sbcglobal.net; s=s1024; t=1412353165; bh=BAHn+hMEaaZAfbIn3XquXaYY9Q6oLK6Gp3BWzD99/AI=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=nSjgP/vpGh3Rm087yhMqV7sOZq6mxy7b/8DRk2n04tZNc0OanjxpJD7N0vckm6TzQ8PPT4JyiZHaW0fY+ZLzYCbKHtUH5WD6JAaHT3vOf0VdYnV9YYbgBgBNCtTFH28FJd5rCw3XLiktyFGnbEdTjv2yYibBGjKEJwUPYR96dUU= X-Yahoo-Newman-Id: 629287.3075.bm@smtp111.sbc.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: U3j24d0VM1lD5a0jMUaJYB54Kkrg_kMxbeSIAQP8Hgc8yKR BemRpNC4_Zs6AVH9a3RFmAe3bzJrHuG4.RhmpAaPwzz1VUFgpvRkJyAvbUKy uL2Pm52C8dbPjqcAc2f9ZcLEFTxJwpw.zwZbJS11KDlAIJ8ztXz3VZpAGiCi KpG5l1a1gfZ9qJ_ktUm6iOHImBdopEVU4OKJS_vaeObo8Md9IlZS1RbQhL7N 7bavZ8t3KhotReiJLMnJQ32sOMIeKegrLasruFR_tWaqcJH2uSPAFWfup81q .WU.McwnpMsyX_t66bMFWziNKWSZxMAF7SkH3VLYLdLcmy4oBwUEdxZtKJ2J PeXgnNtWB.SS32IvFfbA4mSzwsXGTqecvcJBV79NPjacF0nffmiThBPihLLw N2O8cEkFKZFOy5pyc5s8uXBE_fVuCJRNeyflZEQlvIxt7ePBsrSoRjs1Untw Dmy_InqS3Y5ylzmaTx0PhuVvpcDYP4JXIiUbjtH.D2_09Cep1HW1o79Bzx1. YG40MryUYx2dJXHg5Amug5ihmPCTkbXHQ9DAgyvRpdgMHS3BMY3Uq8PVxWgN xAzvJCbTCKMH2VYIhWdswddeggAxMSbvyUg2moyjY54LaAqJFrkwrGAsZ7fo mLxjVtrDHg0ZUxAO7Z4thEG.DQuHc0vkogstNXWhVItisZu4s9__MfnPASws a0m3gWyYsz.XEIsehqkkuVDHyJzBV1H0ATUSKeZj9rPZMd2zIeJPLmKxLghU zCNijSzfWobw5M68QvgjSbLC6C85fG8a0.YCo8FtXoRJWcu0wQlK0.J62ekX hRIok X-Yahoo-SMTP: nOrmCa6swBAE50FabWnlVFUpgFVJ9Gbi__8U5mpvhtQq7tTV1g-- Message-ID: <542ECC8C.7000002@sbcglobal.net> Date: Fri, 03 Oct 2014 09:19:24 -0700 From: David Jacobson User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: cfrg@irtf.org References: <20141003111024.20324.qmail@cr.yp.to> In-Reply-To: <20141003111024.20324.qmail@cr.yp.to> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/9_rUeCRdQ0ZkTv3uH1fPevIaes4 Subject: Re: [Cfrg] Trusting government certifications of cryptography X-BeenThere: cfrg@irtf.org 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, 03 Oct 2014 16:19:31 -0000 On 10/3/14, 4:10 AM, D. J. Bernstein wrote: > Torsten Schuetze writes: >> Smart cards, i.e., its coprocessors and its ECC software >> implementations, are always certified by Common Criteria, usually with >> rather high assurance level. Don't you trust this certification in >> principle? > http://smartfacts.cr.yp.to explains how we factored 184 RSA-1024 keys > from Taiwan's national "Citizen Digital Certificate" database. As you > can see from http://smartfacts.cr.yp.to/cert.html, these keys were > generated by government-issued smart cards that advertised all of the > usual Common Criteria and FIPS certifications from BSI, NIST, and CSE. > > http://smartfacts.cr.yp.to/analysis.html analyzes five contributing > factors to this security disaster---low-quality hardware RNG, inadequate > sanity checks, no run-time sanity checks, no postprocessing, and > inadequate initial response---and the complete failure of certification > to prevent the disaster from occurring. > > Another interesting example to consider is the FIPS certification for > branches of OpenSSL starting with openssl-fips-1.1.2.tar.gz (2007). The > pursuit of FIPS certification was the reason that OpenSSL added support > for Dual EC with NSA's P and Q. The certification procedure failed to > catch the fact that OpenSSL's Dual EC implementation didn't work at all: > > https://www.mail-archive.com/openssl-announce@openssl.org/msg00127.html > > As Steve Marquess put it: "Frankly the FIPS 140-2 validation testing > isn't very useful for catching 'real world' problems." > > After the public learned that Dual EC with this P and Q was an NSA back > door (see, e.g., https://projectbullrun.org/dual-ec), the slowness of > recertification stopped openssl-fips from dropping Dual EC support for > _nine months_: > > https://www.mail-archive.com/openssl-users@openssl.org/msg75061.html > > It's clear that OpenSSL's certification had various other effects, such > as diverting quite a bit of OpenSSL funding into InfoGard Laboratories > Inc. How much positive security impact did this have to outweigh its > obvious negative impacts? For example, how many of OpenSSL's security > holes, whether in the FIPS version or generally, were discovered through > the FIPS validation process? > > Security review is of course important, and I've heard several stories > of security problems being caught by Common Criteria testing labs. But > the security problems that _aren't_ caught show that certification is > not true "assurance" of security---even in relatively simple settings > such as the Taiwanese Citizen Digital Certificates, never mind the much > more complex environment of Internet cryptography. > > I understand that words such as "certification" and "validation" and > "assurance" have an important impact on users in some markets. But for > experts it should be clear that more skepticism is warranted. You can't > reasonably ask CFRG to "trust this certification in principle". > > ---Dan > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg > I totally agree with Dan. I've been involved in getting several products validated at FIPS 140-2 some at level 3 and some at level 1. Here are some examples of unnecessary difficulty and/or weaknesses. Some of what I say is based on what our consultant told us, and I presume he knew standard better than we. 1. In one product we were accelerating IPSEC. In IPSEC the security associations in the kernel contain the keys in plaintext. But FIPS 140-2 level 3 requires that all key material be encrypted as it crosses the security boundary. Our consultant advised us to just use a fixed, hard coded, AES key on both sides. Apparently this is allowed. 2. Random number generators are required to implement a "continuous test", which means that they have to check that no two consecutive generated random numbers are the same, and if this does occur they must enter an error state. Apparently this requirement was written back in the days when RNGs were generated using SHA1 and always had the same size. But this is not the case with, say, CTR_DRBG from SP 800-90A. Even if we neglect that, it (sort of) requires saving each output value until the next generate operation. This spoils backtracking resistance. For good backtracking resistance, we want to delete the delivered value as soon as possible. The "sort of" is because we could compute the hash of each delivered value, and save that and compare with the hash of the next one. But that adds a lot of extra cycles. And this is a waste, since the NIST-recommeded DRBGs can only get stuck with cryptographically small probability. And even if the DRBG did get stuck, a better response would be to force an immediate reseed, rather than entering an error state. 3. There is a requirement at level 3 that the "operator" log in using "identity-based" credentials. Well, when the host operating system is providing crypto services, sometimes for the OS itself, who is the "operator"? Solution: The driver for the crypto card is. We gave the driver some credentials. The validation requirements only apply to the interface, and it sees an approved login protocol, so all is well. 4. One of the onerous things is the self test requirements. If you build the HASH-DRBG in hardware, you would think the running the known answer tests at each power-on would be an acceptable way showing the the logic hasn't rotted. This would only require a way for the driver to push in a known entropy blob instead of getting entropy from the hardware entropy generator. No. The HASH-DRBG hardware contains a dedicated implementation of SHA-256. You have to not only do the known answer test on the whole HASH-DRBG, but you also have to apply known answer tests to the internal dedicated SHA-256. This adds a lot of complexity with no benefit. Summary, FIPS-140 is not a system level security assurance. It is showing that a lot of rules are satisfied at and inside the "security boundary". --David Jacobson From nobody Mon Oct 6 01:13:20 2014 Return-Path: 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 0C3A11A1B56 for ; Mon, 6 Oct 2014 01:13:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.485 X-Spam-Level: X-Spam-Status: No, score=-0.485 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, URIBL_RHS_DOB=1.514] autolearn=no 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 2LF2rvr4FoRi for ; Mon, 6 Oct 2014 01:13:16 -0700 (PDT) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8342F1A1A4A for ; Mon, 6 Oct 2014 01:13:16 -0700 (PDT) Received: by mail-wi0-f175.google.com with SMTP id d1so3720764wiv.14 for ; Mon, 06 Oct 2014 01:13:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=bxt6PKVdSRoX4lrAH86jpYLivd5KfMl7Fk2ONoKoUtY=; b=wCKMFyZnJNhk7EXKIaJEoL8XJai0G1QqQV7INw17Djp6zRZMwBlVW9RinawFdhSpzv pda/BYxnTrtHmBG5phbwgQNRPty6HPnJv38Z3TEm0L0Aw652ppSqRGqsPqmHDWUEt0HO v1KP3fx7QrkqaZB5tOONHgc+eeX07cxHR+TXeeKzzhOlilA0mTy6R5/MghGALhPTVTQN WJT4FjGJVEgSaxdLNaXj6dii4ZqQW/CFFcUtaI17cmwwMMm8JcDjG7onwKPGsDtrdEgM XJEw/V7RuRZ8c+D060/H4VPNuHpuLJ1Igb7jdm4gu+cXogOWSKrcNYNrDffX2tXKVGQM itcQ== MIME-Version: 1.0 X-Received: by 10.180.92.33 with SMTP id cj1mr17223279wib.49.1412583195064; Mon, 06 Oct 2014 01:13:15 -0700 (PDT) Received: by 10.194.220.104 with HTTP; Mon, 6 Oct 2014 01:13:15 -0700 (PDT) In-Reply-To: <542D48CD.9060404@isode.com> References: <542D48CD.9060404@isode.com> Date: Mon, 6 Oct 2014 11:13:15 +0300 Message-ID: From: Yoav Nir To: Alexey Melnikov Content-Type: multipart/alternative; boundary=f46d043c81308ebf200504bca78a Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/0OrR8MHf4akEkDpgAMUNsQtFT3o Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] RGLC on draft-irtf-cfrg-chacha20-poly1305-01.txt X-BeenThere: cfrg@irtf.org 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: Mon, 06 Oct 2014 08:13:18 -0000 --f46d043c81308ebf200504bca78a Content-Type: text/plain; charset=UTF-8 Hi. As co-author of the draft, it's no surprise that I think it's ready. So I'll just point out that: - The algorithms described have been implemented multiple times, both by the authors and by others - At least two implementations were done by following the draft (and the test vectors checked out) - At least one browser (Google Chrome) has these algorithms running in production and used with the Google servers. So I guess we've got the "running code" part down. Yoav On Thu, Oct 2, 2014 at 3:45 PM, Alexey Melnikov wrote: > The authors of "ChaCha20 and Poly1305 for IETF protocols", > draft-irtf-cfrg-chacha20-poly1305-01.txt believe the draft is ready for a > RGLC. > > This starts a two week research group last call, to end on 17 Oct 2014. > > The draft is available at http://datatracker.ietf.org/ > doc/draft-irtf-cfrg-chacha20-poly1305/ > > Please do comment on the list, indicating whether you believe this draft > is ready for publication. Please send your comments, indication of support > for the publication or objections to the publication to the mailing list or > directly to the RG chairs (cfrg-chairs@tools.ietf.org). > > Alexey, > As a co-chair. > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg > --f46d043c81308ebf200504bca78a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi.

As co-author of the draft, it's= no surprise that I think it's ready. So I'll just point out that:<= /div>
=C2=A0- The algorithms described have been implemented multiple t= imes, both by the authors and by others
=C2=A0- At least two impl= ementations were done by following the draft (and the test vectors checked = out)
=C2=A0- At least one browser (Google Chrome) has these algor= ithms running in production and used with the Google servers.
So I guess we've got the "running code" part down= .

Yoav

<= div class=3D"gmail_quote">On Thu, Oct 2, 2014 at 3:45 PM, Alexey Melnikov <= span dir=3D"ltr"><alexey.melnikov@isode.com> wrote:
The authors of "ChaCha20 and Poly1305 for IETF protoco= ls", draft-irtf-cfrg-chacha20-poly1305-01.txt believe the draft= is ready for a RGLC.

This starts a two week research group last call, to end on 17 Oct 2014.

The draft is available at http://datatracker.ietf.org= /doc/draft-irtf-cfrg-chacha20-poly1305/

Please do comment on the list, indicating whether you believe this draft is= ready for publication. Please send your comments, indication of support fo= r the publication or objections to the publication to the mailing list or d= irectly to the RG chairs (cfrg-chairs@tools.ietf.org).

Alexey,
As a co-chair.

_______________________________________________
Cfrg mailing list
Cfrg@irtf.org
htt= p://www.irtf.org/mailman/listinfo/cfrg

--f46d043c81308ebf200504bca78a-- From nobody Mon Oct 6 08:27:03 2014 Return-Path: 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 820951A6FE2 for ; Mon, 6 Oct 2014 08:26:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.6 X-Spam-Level: X-Spam-Status: No, score=-0.6 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 dEY9LIKcHoD8 for ; Mon, 6 Oct 2014 08:26:53 -0700 (PDT) Received: from mail-qg0-x22c.google.com (mail-qg0-x22c.google.com [IPv6:2607:f8b0:400d:c04::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D3C91A6FD3 for ; Mon, 6 Oct 2014 08:26:52 -0700 (PDT) Received: by mail-qg0-f44.google.com with SMTP id j5so3910440qga.3 for ; Mon, 06 Oct 2014 08:26:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=o8Yenz01z+duvfqKDSdCkE28pZQUFk8dKEIJScZXSmk=; b=bsgaSrRgCLEwMvE5ac0bGfKNvBj+AZaja91GvSpj/A8isGZOHJ5BJyttBWAlRyBmq8 2KgjM3i3iROo1z9LeYA1TRJbkOVTmtbKuyJGNXmg67vUbHhnCbRo9WbI/PaEt4P3vcOX fWMNwtbpLYiy7njI4Ck+c1SvDYd8qrCkSr4c/CtP81ycK4cFG6Z1I/IkqIlETSMNYC+P ygteJRLdJtmgyXHBPCLhFhkuWrCJon0ytPOvGUnO8mjRyMx5y/p3IXxfwjVQstVUWHbV ume+vryJMSi9SC5FBoAbtKW+KIELsZ+0e0JajF+nt7u5yEiKVEjF+Lnhn79Itn8tqWpX q3gQ== MIME-Version: 1.0 X-Received: by 10.224.151.143 with SMTP id c15mr6837108qaw.10.1412609211456; Mon, 06 Oct 2014 08:26:51 -0700 (PDT) Received: by 10.140.20.199 with HTTP; Mon, 6 Oct 2014 08:26:51 -0700 (PDT) Date: Mon, 6 Oct 2014 08:26:51 -0700 Message-ID: From: Watson Ladd To: "cfrg@irtf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/1vxr4-dn3v1LzeW7T7ky5EUNYSs Subject: [Cfrg] When's the decision? X-BeenThere: cfrg@irtf.org 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: Mon, 06 Oct 2014 15:26:54 -0000 Dear all, We were promised on July 27 a process running for 6 weeks. Doubling I get 12 weeks, which is three months, of which two (August, September) have already gone. Am I correct in supposing that we're on track for a decision by Halloween? If we aren't, what remaining issues need to be addressed/when can we expect a decision? Sincerely, Watson Ladd From nobody Mon Oct 6 08:53:38 2014 Return-Path: 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 E64C01A02DF for ; Mon, 6 Oct 2014 08:53:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 Jky-uYh7FcVI for ; Mon, 6 Oct 2014 08:53:33 -0700 (PDT) Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3B3A1A007F for ; Mon, 6 Oct 2014 08:53:32 -0700 (PDT) Received: by mail-wg0-f46.google.com with SMTP id l18so6918838wgh.17 for ; Mon, 06 Oct 2014 08:53:31 -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 :content-transfer-encoding:message-id:references:to; bh=V+Wlgc7TIkEfHDU7jVcDhADBCL68ZD8NB0/igS19BHI=; b=ORPupAMJ2NXzfoswlNfYTNh7872XyoYr3aKY8hFQlb+C4QXJOGXp20ZpPERHp7jiaN ULXIhMqKABjAa3RLDtNOKvFc9Nt7EEKH4IHphh95FBzJZW3thrYgBQIDjPddOegJ5Vn9 weWZKsPyniLYuZHsyJQl3CUdQNlKXLUOnHMLWBIHiv9zCxcn3RGPP5sVVskoja2gUYGc /VPjX2hAUx+dY2EiC5WY4qRCLBrP2tz47nARnxUY/PuMxZ5xMc0BR8dLAmFsMjxXOlxr q4PUQg8ZOxoIu3UNQvGHaZBMnegMTuqXGOzwkFzHKB5YPYfgbhfNS+MkQYl5VW/PB2O/ 3whg== X-Received: by 10.194.189.82 with SMTP id gg18mr31313934wjc.2.1412610811560; Mon, 06 Oct 2014 08:53:31 -0700 (PDT) Received: from yoavs-mbp.mshome.net ([95.35.51.128]) by mx.google.com with ESMTPSA id ma8sm17679820wjb.46.2014.10.06.08.53.29 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 06 Oct 2014 08:53:31 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Yoav Nir In-Reply-To: Date: Mon, 6 Oct 2014 18:53:25 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <3EE5AEA5-3ADE-4D67-AC51-478074349D1B@gmail.com> References: To: Watson Ladd X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/mvanDZ9hsUS3v_F0pf-501Kid0o Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] When's the decision? X-BeenThere: cfrg@irtf.org 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: Mon, 06 Oct 2014 15:53:35 -0000 Hi Watson. Just to be clear, you=92re referring to the curve decision, right? = Because the WG is also discussing ChaCha, hash signatures and = (supposedly) Dragonfly. I think the conversation about the new curves has dried up, so it=92s up = to the chairs to call consensus if they can. If it were up to me, I = would say that there=92s very little separating the different proposals, = especially for the ~128-bit strength, meaning that whichever one gets = chosen is likely to be accepted (no =93Oh, my, you got this so wrong! = How could you! Don=92t you care about the kittens?=94) The differences = in performance are small enough to not matter, and I don=92t think = anyone thinks that any of the proposals has some hidden weakness in the = carefully chosen parameters. So with implementer hat on, I=92ll quietly wait CFRG to make the = decision, and for AGL or DJB or one of the others who know how to write = this kind of code securely to contribute code to OpenSSL, and then I=92ll = happily copy the code from there. If the wrong choice either (a) made my = session rate 20% smaller or (b) made me stay up all night delivering = security hotfixes, I=92d feel strongly about this choice. As it is, I = (and I=92m sure some others on this list) don=92t think it matters that = much. They=92re all good enough. Yoav On Oct 6, 2014, at 6:26 PM, Watson Ladd wrote: > Dear all, > We were promised on July 27 a process running for 6 weeks. Doubling I > get 12 weeks, which is three months, of which two (August, September) > have already gone. Am I correct in supposing that we're on track for a > decision by Halloween? >=20 > If we aren't, what remaining issues need to be addressed/when can we > expect a decision? >=20 > Sincerely, > Watson Ladd >=20 > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg From nobody Mon Oct 6 08:57:42 2014 Return-Path: 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 E37F11A0351 for ; Mon, 6 Oct 2014 08:57:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] 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 QWC7iFTk7lp5 for ; Mon, 6 Oct 2014 08:57:39 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 543D51A0353 for ; Mon, 6 Oct 2014 08:57:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 0B878BE02; Mon, 6 Oct 2014 16:57:37 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V4xPDv45n9P4; Mon, 6 Oct 2014 16:57:36 +0100 (IST) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id DE964BDF9; Mon, 6 Oct 2014 16:57:36 +0100 (IST) Message-ID: <5432BBF1.5060003@cs.tcd.ie> Date: Mon, 06 Oct 2014 16:57:37 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: Yoav Nir , Watson Ladd References: <3EE5AEA5-3ADE-4D67-AC51-478074349D1B@gmail.com> In-Reply-To: <3EE5AEA5-3ADE-4D67-AC51-478074349D1B@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/PnfuI3hXJ6JkZ2_AnWy6OKD1Ymc Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] When's the decision? X-BeenThere: cfrg@irtf.org 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: Mon, 06 Oct 2014 15:57:41 -0000 Hiya, On 06/10/14 16:53, Yoav Nir wrote: > They’re all good enough Tend to agree. But CFRG, pretty-please don't pick them all! If you do we'll just have to pick elsewhere (e.g. saag or specific IETF wgs) with less clue immediately involved. S. From nobody Mon Oct 6 14:06:49 2014 Return-Path: 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 C0BEB1A1A47 for ; Mon, 6 Oct 2014 14:06:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.353 X-Spam-Level: X-Spam-Status: No, score=-2.353 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, URIBL_RHS_DOB=1.514] 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 B0PSROOJCKMh for ; Mon, 6 Oct 2014 14:06:44 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 0912A1A6FD6 for ; Mon, 6 Oct 2014 14:06:44 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id C4C2A10224008; Mon, 6 Oct 2014 14:06:42 -0700 (PDT) Received: from 104.36.248.10 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Mon, 6 Oct 2014 14:06:43 -0700 (PDT) Message-ID: <9a348a00f974bffba1c3785464cd2032.squirrel@www.trepanning.net> In-Reply-To: References: <542D48CD.9060404@isode.com> Date: Mon, 6 Oct 2014 14:06:43 -0700 (PDT) From: "Dan Harkins" To: "Yoav Nir" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/vKyjL1yd66fjdMWLRlRX6Zz5kwU Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] RGLC on draft-irtf-cfrg-chacha20-poly1305-01.txt X-BeenThere: cfrg@irtf.org 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: Mon, 06 Oct 2014 21:06:47 -0000 On Mon, October 6, 2014 1:13 am, Yoav Nir wrote: > Hi. > > As co-author of the draft, it's no surprise that I think it's ready. So > I'll just point out that: > - The algorithms described have been implemented multiple times, both by > the authors and by others > - At least two implementations were done by following the draft (and the > test vectors checked out) > - At least one browser (Google Chrome) has these algorithms running in > production and used with the Google servers. > > So I guess we've got the "running code" part down. Very nice! It's good to see people with running code that implements the proposals for which they are attempting to achieve rough consensus. I guess we could call it "old school" :-) One suggestion is that since this takes a cipher and a separate MAC function to create a composite, you should define this combined AEAD mode to fit into the RFC 5116 AEAD abstraction. This will require a subtle modification to section 2.8-- around formation of the AEAD, and specification of maximal limits-- and the requisite IANA Considerations in section 5. I understand that this is the CFRG and not any particular IETF WG that produces standards for some protocol but given that you say your running code includes some secure browser-to-server communication it might be nice to include such a conversation (using, for example, ssldump) as a separate test vector. regards, Dan. > Yoav > > On Thu, Oct 2, 2014 at 3:45 PM, Alexey Melnikov > > wrote: > >> The authors of "ChaCha20 and Poly1305 for IETF protocols", >> draft-irtf-cfrg-chacha20-poly1305-01.txt believe the draft is ready for >> a >> RGLC. >> >> This starts a two week research group last call, to end on 17 Oct 2014. >> >> The draft is available at http://datatracker.ietf.org/ >> doc/draft-irtf-cfrg-chacha20-poly1305/ >> >> Please do comment on the list, indicating whether you believe this draft >> is ready for publication. Please send your comments, indication of >> support >> for the publication or objections to the publication to the mailing list >> or >> directly to the RG chairs (cfrg-chairs@tools.ietf.org). >> >> Alexey, >> As a co-chair. >> >> _______________________________________________ >> Cfrg mailing list >> Cfrg@irtf.org >> http://www.irtf.org/mailman/listinfo/cfrg >> > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg > From nobody Mon Oct 6 14:27:15 2014 Return-Path: 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 091761A6FD6 for ; Mon, 6 Oct 2014 14:27:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.787 X-Spam-Level: X-Spam-Status: No, score=-2.787 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.786, 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 XJhL6x9i5UNn for ; Mon, 6 Oct 2014 14:27:12 -0700 (PDT) Received: from ore.jhcloos.com (ore.jhcloos.com [198.147.23.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31FAB1A8A44 for ; Mon, 6 Oct 2014 14:27:12 -0700 (PDT) Received: by ore.jhcloos.com (Postfix, from userid 10) id 6412B1E273; Mon, 6 Oct 2014 21:27:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=ore14; t=1412630830; bh=a6KLKvG29W/4t23eXulrGqeuXCMq4QxxtP2IAHVemVU=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=nVwOqbhx/7vRZKC/8Op1GKJzVLXj+P9abX8cOyI3+lBwA1Gfx2s9alClZvWtwI9+v bxzqxd2fG6/BMxk6iFWr4jJ0NjWVzhVaAuTm93hcMW7Gr3A7UmdtnBXhXFdLeoVRRP 8MLIqQHoiALqclU4Ym0iK0cgRVGAYaZ1LyzSPNBc= Received: by carbon.jhcloos.org (Postfix, from userid 500) id ECF3F60023; Mon, 6 Oct 2014 21:25:38 +0000 (UTC) From: James Cloos To: In-Reply-To: <542D48CD.9060404@isode.com> (Alexey Melnikov's message of "Thu, 02 Oct 2014 13:45:01 +0100") References: <542D48CD.9060404@isode.com> User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/24.4.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2014 James Cloos OpenPGP: 0x997A9F17ED7DAEA6; url=https://jhcloos.com/public_key/0x997A9F17ED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Mon, 06 Oct 2014 17:25:38 -0400 Message-ID: Lines: 30 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:28:141006:cfrg@irtf.org::YTBEE2ds7sRAqv1W:000LF5Kg X-Hashcash: 1:28:141006:alexey.melnikov@isode.com::MlQqZ40ncXjPg1ED:00000000000000000000000000000000000B3270 Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/IeYOWcoGwr5R0f3QosaZOtUaxEU Subject: Re: [Cfrg] RGLC on draft-irtf-cfrg-chacha20-poly1305-01.txt X-BeenThere: cfrg@irtf.org 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: Mon, 06 Oct 2014 21:27:14 -0000 [I thought I sent on this subect weeks ago, but I cannot find it in the archives, ... -JimC] I have to object to defaulting to a 96/32 split. The rfc should specify Dan's 64/64 split as default, and only offer 96/32 as an option. Chacha isn't only useful for in-flight encryption. One should not have to bother with multiple keys or IVs to encrypt large files. And 128 Gigs is not all that large for things like backups (tar, cpio, et cetera), disk images, some AV files and the like. It is very reasonable to presume that larger and larger files will become more and more common as the storage devices sizes and demand for higher resolution media files each continue to escalate. The RFC should be a valid reference for all potential uses of chacha. Even in the IETF, OpenPGP encrypts files at rest. Secsh should continue to use 64/64; OpenPGP and SMIME should add chacha with 64/64; I would prefer 64/64 for TLS. But if IPSEC insists on 96/32, that should be an option, not the primary scenario. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6 From nobody Mon Oct 6 14:50:10 2014 Return-Path: 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 254F21A1B7F for ; Mon, 6 Oct 2014 14:50:08 -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 0pAahcR-ZtnR for ; Mon, 6 Oct 2014 14:50:06 -0700 (PDT) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C4021A0108 for ; Mon, 6 Oct 2014 14:50:06 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id cc10so6042881wib.11 for ; Mon, 06 Oct 2014 14:50:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to; bh=7TnNzsEEOIqs9LZ562qogWksTLeTYxh7BM+D2h0XlzI=; b=Hxwqknp6btr36y1P4nWTX8X2sW3Iav63fS0njgHO02oJo8cwo1Q3/6nR02iQO4WuIy fwVTOGjiljGcEghbnPvsHargJP2aiufS/BHpY7BkfB4HIK27M3DVk94PRyYlCayNZyU8 XTRMNqG0UoxCoSrBkmQWZmEcsdIZRl3T3m3578SBxmlbzmn559Jld9f0mSGYNKdwk657 T+IMZV03C/RJ/8H2fpLmBLuDdqWuqjpMo6RfIhVjBmnx5/AsRDurFA5kgcWPvK/3oER2 z1sD9ULdIInMK3FfD8/pKO/esAsOAqvqoxyV8otDpbSE0KwwcGsDl98Mt5GB0YwjYf4q e62g== X-Received: by 10.180.93.193 with SMTP id cw1mr22315850wib.68.1412632204861; Mon, 06 Oct 2014 14:50:04 -0700 (PDT) Received: from [192.168.1.104] (IGLD-84-228-54-144.inter.net.il. [84.228.54.144]) by mx.google.com with ESMTPSA id ei1sm12557732wib.20.2014.10.06.14.50.03 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 06 Oct 2014 14:50:04 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_125187A5-8F3D-4740-8555-36F2125F0221" From: Yoav Nir X-Priority: 3 (Normal) In-Reply-To: <9a348a00f974bffba1c3785464cd2032.squirrel@www.trepanning.net> Date: Tue, 7 Oct 2014 00:50:02 +0300 Message-Id: <1CFF7FC2-DDC9-46AF-B574-4126379232DB@gmail.com> References: <542D48CD.9060404@isode.com> <9a348a00f974bffba1c3785464cd2032.squirrel@www.trepanning.net> To: Dan Harkins X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/32EZoad9uX-iFlK0DFKUqdjhDcc Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] RGLC on draft-irtf-cfrg-chacha20-poly1305-01.txt X-BeenThere: cfrg@irtf.org 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: Mon, 06 Oct 2014 21:50:08 -0000 --Apple-Mail=_125187A5-8F3D-4740-8555-36F2125F0221 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi, Dan Thanks for the kind words. On Oct 7, 2014, at 12:06 AM, Dan Harkins wrote: >=20 > One suggestion is that since this takes a cipher and a separate MAC > function to create a composite, you should define this combined AEAD > mode to fit into the RFC 5116 AEAD abstraction. This will require a = subtle > modification to section 2.8-- around formation of the AEAD, and > specification of maximal limits-- and the requisite IANA = Considerations > in section 5. I=92m not quite sure I follow. The construction uses a 96-bit nonce = precisely so that we comply with RFC 5116. What requirement of 5116 are = we not fitting into? Yoav --Apple-Mail=_125187A5-8F3D-4740-8555-36F2125F0221 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi, = Dan

Thanks for the kind = words.

On Oct 7, 2014, at 12:06 AM, Dan Harkins = <dharkins@lounge.org> = wrote:


 One suggestion is that = since this takes a cipher and a separate MAC
function to create a = composite, you should define this combined AEAD
mode to fit into the = RFC 5116 AEAD abstraction. This will require a subtle
modification to = section 2.8-- around formation of the AEAD, and
specification of = maximal limits-- and the requisite IANA Considerations
in section = 5.

I=92m not quite sure I = follow. The construction uses a 96-bit nonce precisely so that we comply = with RFC 5116. What requirement of 5116 are we not fitting = into?

Yoav

= --Apple-Mail=_125187A5-8F3D-4740-8555-36F2125F0221-- From nobody Mon Oct 6 14:53:12 2014 Return-Path: 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 09A921A8A8D for ; Mon, 6 Oct 2014 14:53:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no 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 jTDiMxHCgegl for ; Mon, 6 Oct 2014 14:53:07 -0700 (PDT) Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4FEC1A1B7F for ; Mon, 6 Oct 2014 14:53:06 -0700 (PDT) Received: by mail-lb0-f174.google.com with SMTP id p9so5108931lbv.33 for ; Mon, 06 Oct 2014 14:53:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=3Dxx8cOYGvtwD1rOTjk5fFp6dSn2Ymy1tOyD/AbKH5E=; b=OOYgKkuwLKhRq31txhe6gTLRQxjmdr798M5npPeHevxLXBRgf9jxP7M+L9Zl7KsPe8 ytE+fw4+8vWu5lXU0iTY+CddA8kCN+ydHKmkSbrMhshvvHFoF7HwpZtLYAh5tz2jI7f8 Wl3XaW8Zt2zMYLYklVk/SO/Yiuh999eUz1o4kkuMJE0KrCw3H5HeydYNN1vgMEaPbxN5 6+FlnScOw0iklENZ2RNBrBR/YCmxCps4RAUaaNmJRjBG/rZSOv4l62uqeesm9PK9s5Fo K+EPFLYfSskMG9jJd5fNsxY1EhOUgpeuZ12o70bXyu7Ijl38lAgzOXSPwFz/mzEcTrkH fgXw== MIME-Version: 1.0 X-Received: by 10.152.21.101 with SMTP id u5mr11348146lae.76.1412632384934; Mon, 06 Oct 2014 14:53:04 -0700 (PDT) Sender: alangley@gmail.com Received: by 10.112.241.103 with HTTP; Mon, 6 Oct 2014 14:53:04 -0700 (PDT) In-Reply-To: <1CFF7FC2-DDC9-46AF-B574-4126379232DB@gmail.com> References: <542D48CD.9060404@isode.com> <9a348a00f974bffba1c3785464cd2032.squirrel@www.trepanning.net> <1CFF7FC2-DDC9-46AF-B574-4126379232DB@gmail.com> Date: Mon, 6 Oct 2014 14:53:04 -0700 X-Google-Sender-Auth: ivwDctPloLv0U73byxUdLa88ZrA Message-ID: From: Adam Langley To: Yoav Nir Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/DT2F2Bo7fk14peUDykbQUyiCFsM Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] RGLC on draft-irtf-cfrg-chacha20-poly1305-01.txt X-BeenThere: cfrg@irtf.org 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: Mon, 06 Oct 2014 21:53:09 -0000 On Mon, Oct 6, 2014 at 2:50 PM, Yoav Nir wrote: > I=E2=80=99m not quite sure I follow. The construction uses a 96-bit nonce= precisely > so that we comply with RFC 5116. What requirement of 5116 are we not fitt= ing > into? I think Dan is just saying that the limits need to be specified. For example see page 8 in https://tools.ietf.org/html/draft-agl-tls-chacha20poly1305-04#section-5 (although these values are wrong now). Cheers AGL --=20 Adam Langley agl@imperialviolet.org https://www.imperialviolet.org From nobody Mon Oct 6 14:56:10 2014 Return-Path: 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 248A61A8AC4 for ; Mon, 6 Oct 2014 14:56:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 00HlBglMyyEx for ; Mon, 6 Oct 2014 14:56:03 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC39E1A6F2D for ; Mon, 6 Oct 2014 14:55:59 -0700 (PDT) Received: by mail-wi0-f179.google.com with SMTP id d1so6073820wiv.6 for ; Mon, 06 Oct 2014 14:55:58 -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 :content-transfer-encoding:message-id:references:to; bh=AUow2G4CkITlEh0aOtrmv5nCd96QTFNFTOlLrPctYms=; b=HBXQdjX3z3JNev3lYfuIWfwuXZ44sNDCmn15+5GeXAeUCgEYBDO/rPQYMDyHN9sVdi apIz+5A7hgTl3SdB0LQIem9KINiwTryx5xHTyzQoVuQoVxi/01TvpkQBtxM1ZkKzYQzX VOrABQ1ou4nhZ/CscmHbDLLZe1TlJlxYwuuX9SRqbazHR5jHo266HgeLYqZcGRxokgjw CDGQhtjcL3ygitvGpEBlqbbAkrGgaD8wm+aU8U8YxBurR9eI2MJg6rrycB35tD8J9Eh2 3D84RqerYYhUA4GK9O0oIP6uTeTns1JPOtAny/lZz+6UomdTpBf4FIP6PRV5cUsFg2a0 Qt6A== X-Received: by 10.194.78.238 with SMTP id e14mr32266450wjx.48.1412632558567; Mon, 06 Oct 2014 14:55:58 -0700 (PDT) Received: from [192.168.1.104] (IGLD-84-228-54-144.inter.net.il. [84.228.54.144]) by mx.google.com with ESMTPSA id he2sm655951wib.4.2014.10.06.14.55.57 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 06 Oct 2014 14:55:58 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Yoav Nir In-Reply-To: Date: Tue, 7 Oct 2014 00:55:56 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <36143287-DBB5-4872-BD43-672B7737B89C@gmail.com> References: <542D48CD.9060404@isode.com> <9a348a00f974bffba1c3785464cd2032.squirrel@www.trepanning.net> <1CFF7FC2-DDC9-46AF-B574-4126379232DB@gmail.com> To: Adam Langley X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/CfWEJ6lO1yGsns2BDoN9Iy3j8A4 Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] RGLC on draft-irtf-cfrg-chacha20-poly1305-01.txt X-BeenThere: cfrg@irtf.org 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: Mon, 06 Oct 2014 21:56:06 -0000 On Oct 7, 2014, at 12:53 AM, Adam Langley = wrote: > On Mon, Oct 6, 2014 at 2:50 PM, Yoav Nir wrote: >> I=92m not quite sure I follow. The construction uses a 96-bit nonce = precisely >> so that we comply with RFC 5116. What requirement of 5116 are we not = fitting >> into? >=20 > I think Dan is just saying that the limits need to be specified. For > example see page 8 in > = https://tools.ietf.org/html/draft-agl-tls-chacha20poly1305-04#section-5 > (although these values are wrong now). Ah, I see. Thanks. I=92ll get on it tomorrow. Yoav From nobody Mon Oct 6 15:35:03 2014 Return-Path: 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 7909F1A9030 for ; Mon, 6 Oct 2014 15:35:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.867 X-Spam-Level: X-Spam-Status: No, score=-3.867 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_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 RRfkgyqfMCpm for ; Mon, 6 Oct 2014 15:35:01 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 303C11A902E for ; Mon, 6 Oct 2014 15:35:01 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 59FFD10224008; Mon, 6 Oct 2014 15:35:00 -0700 (PDT) Received: from 104.36.248.10 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Mon, 6 Oct 2014 15:35:00 -0700 (PDT) Message-ID: In-Reply-To: References: <542D48CD.9060404@isode.com> <9a348a00f974bffba1c3785464cd2032.squirrel@www.trepanning.net> <1CFF7FC2-DDC9-46AF-B574-4126379232DB@gmail.com> Date: Mon, 6 Oct 2014 15:35:00 -0700 (PDT) From: "Dan Harkins" To: "Adam Langley" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/Xo1xXku04iUcUuJJLq2X83bdL1E Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] RGLC on draft-irtf-cfrg-chacha20-poly1305-01.txt X-BeenThere: cfrg@irtf.org 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: Mon, 06 Oct 2014 22:35:02 -0000 On Mon, October 6, 2014 2:53 pm, Adam Langley wrote: > On Mon, Oct 6, 2014 at 2:50 PM, Yoav Nir wrote: >> I’m not quite sure I follow. The construction uses a 96-bit nonce >> precisely >> so that we comply with RFC 5116. What requirement of 5116 are we not >> fitting >> into? > > I think Dan is just saying that the limits need to be specified. For > example see page 8 in > https://tools.ietf.org/html/draft-agl-tls-chacha20poly1305-04#section-5 > (although these values are wrong now). I'm sorry, I meant the formation of the AAD. Is it a single blob that gets passed to the algorithm? Does the mode allow for multiple distinct AAD inputs ala RFC 5297? What if the protocol I want to use with this mode has several distinct blobs I want to use as AAD (like how IEEE Std 802.11 uses AAD with AEAD cipher modes-- take these bits and then concatenate these addresses, etc)? I suspect it's all just a single concatenated blob but it would help to say so explicitly and to define the RFC 5116 interface. It obviously takes AAD since section 2.8 mentions it as something to include as input to AEAD_CHACHA20-POLY1305. So I'm suggesting you define what AAD looks like when it is delivered to the mode: "Distinct AAD shall be concatenated into a single input to AEAD_CHACHA20-POLY1305", for example. regards, Dan. > Cheers > > AGL > > -- > Adam Langley agl@imperialviolet.org https://www.imperialviolet.org > From nobody Mon Oct 6 16:28:06 2014 Return-Path: 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 19B4E1A904F for ; Mon, 6 Oct 2014 16:28:05 -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 Zzr66Dngnst2 for ; Mon, 6 Oct 2014 16:28:03 -0700 (PDT) Received: from mail-yk0-x22f.google.com (mail-yk0-x22f.google.com [IPv6:2607:f8b0:4002:c07::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50B9A1A904E for ; Mon, 6 Oct 2014 16:28:03 -0700 (PDT) Received: by mail-yk0-f175.google.com with SMTP id 19so2402925ykq.34 for ; Mon, 06 Oct 2014 16:28:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=vINgDq6xRSfHEg4neGmE2KMjXvSlWzql+Lzpi1yDKI0=; b=l5V1Ld5YFrHtrSJ+wmzLGgyFVPk8NxKmcZi0dqT2Qdp8LR/Q8ztFQgM7M9tCrb8TZW y5jqruFJWMDtt94Hl5dW8OgGMU42AQOzgizKCVb4ddHsoyLCnK4K3ZUaC75T0xXCncu+ z5yr8HjpenLzY/1+cztkr9J1Lb9eQ1YUISVZ02d80+gj8TvouYCGKwkWAmGJ1jb1mvJj v8pU3UDtderrn3gKXUNwcCuZBZGRIPrwulSKgkhUjB/yCUicX61g+Y3DOQ8YkcIY4lPe 9yer/7hFeuhksdJZcmeQLj2UsLDyKYkTcFC9grJD/HzJP7pULuL1epLhxnRtAm2nx9+I Ay6g== MIME-Version: 1.0 X-Received: by 10.236.94.130 with SMTP id n2mr7920822yhf.163.1412638082435; Mon, 06 Oct 2014 16:28:02 -0700 (PDT) Received: by 10.170.195.149 with HTTP; Mon, 6 Oct 2014 16:28:02 -0700 (PDT) Received: by 10.170.195.149 with HTTP; Mon, 6 Oct 2014 16:28:02 -0700 (PDT) In-Reply-To: <5432BBF1.5060003@cs.tcd.ie> References: <3EE5AEA5-3ADE-4D67-AC51-478074349D1B@gmail.com> <5432BBF1.5060003@cs.tcd.ie> Date: Mon, 6 Oct 2014 16:28:02 -0700 Message-ID: From: Watson Ladd To: Stephen Farrell Content-Type: multipart/alternative; boundary=20cf3011e19519907e0504c96f75 Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/_orTrpwk1A-CNYuNBSUixGGpgWg Cc: cfrg@irtf.org Subject: Re: [Cfrg] When's the decision? X-BeenThere: cfrg@irtf.org 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: Mon, 06 Oct 2014 23:28:05 -0000 --20cf3011e19519907e0504c96f75 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Oct 6, 2014 8:57 AM, "Stephen Farrell" wrote= : > > > Hiya, > > On 06/10/14 16:53, Yoav Nir wrote: > > They=E2=80=99re all good enough > > Tend to agree. But CFRG, pretty-please don't pick them all! This ignores the significance of choices such as which coordinates to use on the wire, whether to use compression, and which signature scheme to use. These are not make or break items, and any curve could be used several ways, but these issues do not go away with the choice of curve. > > If you do we'll just have to pick elsewhere (e.g. saag or > specific IETF wgs) with less clue immediately involved. Agreed: the buck stops here. > > S. > --20cf3011e19519907e0504c96f75 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Oct 6, 2014 8:57 AM, "Stephen Farrell" <stephen.farrell@cs.tcd.ie> wrote:
>
>
> Hiya,
>
> On 06/10/14 16:53, Yoav Nir wrote:
> > They=E2=80=99re all good enough
>
> Tend to agree. But CFRG, pretty-please don't pick them all!

This ignores the significance of choices such as which coord= inates to use on the wire, whether to use compression, and which signature = scheme to use.

These are not make or break items, and any curve could be us= ed several ways, but these issues do not go away with the choice of curve. =
>
> If you do we'll just have to pick elsewhere (e.g. saag or
> specific IETF wgs) with less clue immediately involved.

Agreed: the buck stops here.
>
> S.
>

--20cf3011e19519907e0504c96f75-- From nobody Mon Oct 6 21:08:03 2014 Return-Path: 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 CA9FB1A911E for ; Mon, 6 Oct 2014 21:08:01 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] 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 QjN-r3B8Tufn for ; Mon, 6 Oct 2014 21:07:59 -0700 (PDT) Received: from nm15-vm4.access.bullet.mail.gq1.yahoo.com (nm15-vm4.access.bullet.mail.gq1.yahoo.com [216.39.63.103]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88CA71A1A16 for ; Mon, 6 Oct 2014 21:07:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sbcglobal.net; s=s1024; t=1412654879; bh=rxkJLUuVBvHnGqUluZJxQtUEhDZ4fFmH50dUYB5Hxx4=; h=Received:Received:Received:DKIM-Signature:X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:From:Subject; b=PUZxrPEEyfZR9O939cjzb+e/RTbRLw8Cl2h1DilWTpRFUkgBpjJgrHPZAIxx3cnCBT/+oQvUl57Mk6c30ZwmTL9AWyqSIjh8Movp3DSBy36O2/8HOM59d7RNVIqDEjYSCdabQtQr0XQiquUGY+mFgpkqxYLwteT7AnKEllPZfD8= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=sbcglobal.net; b=rN+8FTgzQPB8ERgjg2cKGD/zSol3KrrckMlxuEa973NWh0/diRo+jUCDDrCL28o5zoTDPW7L5uWUlV9j+lkfMikTJahFiU0S1h24+ZfFM1dMo9GhiWvbiOkZNJfuZyHPgMnUNeHaZ1siTIaOivZ0q8uyiJiFpLuxyMnT+g9xngE=; Received: from [216.39.60.175] by nm15.access.bullet.mail.gq1.yahoo.com with NNFMP; 07 Oct 2014 04:07:59 -0000 Received: from [67.195.22.113] by tm11.access.bullet.mail.gq1.yahoo.com with NNFMP; 07 Oct 2014 04:07:59 -0000 Received: from [127.0.0.1] by smtp115.sbc.mail.gq1.yahoo.com with NNFMP; 07 Oct 2014 04:07:59 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sbcglobal.net; s=s1024; t=1412654879; bh=rxkJLUuVBvHnGqUluZJxQtUEhDZ4fFmH50dUYB5Hxx4=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type; b=J7Rk8tZH/DqSmQjHUuUhcJQ+oSEMG8rWv5W+jXD0BVdm9kX0uF1y78esb6ZigCMyNrnYZOwAZRE+MiwLUT7z3lYJhriDkMp3s9GarMx3RUGdtOvOVnt1nlLU9/SwfzoqwDlEQlmJv/AzXaYYAgSsuGyuEnyRQ0Myrvu59orK3GU= X-Yahoo-Newman-Id: 116154.50389.bm@smtp115.sbc.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: GaWNrScVM1k88QgDdCMMEyhKX_QA4QjRl5VSn.hE2Nv2j9O T0s5jAl_NAVaFtmogniRWmy9oga.D.3jPeBqxHA._QeJB3HWRElO.S6xZCHs 5ls9ECbA50Fo1jzwGIymo9i_EGbNqrsdT5UYCAUSV0.CovtOLZ5O0It6AJ35 OZgiXu7oySzjA2ceSUIQpeJXxahERGciOZm0iIkC9tF4Ap.mT808A.1Frtuk MzIy5o9r6UKcJxKDRVR.dlTYnUf0JbcLgtVX5985XY3ItiY.8hnmflbIocu. VXl..2NFPW2oxSUwvcB7kTzkSoowYVnB3vvvttZq76nevbJjFrSMF2dsF0v_ TuqT2Qebz0NfzX3a6AhWrpg8pibIr2_CX7L7Kv0qMh8rJaYWjGz8p74sOkq. i2QPhoPZl2x.u8RfYyVOSv7r_jx.fVj6sFhRPGEtTWO2d1s2MnBtB5vFx2YL GsT2_UJBhOid9Fq_uDY4yafXH5wtwz7R79KYKtZVhR.fiW7bBzZZhoRiliju qK4C1ZGL7noVzvtg0zoqaKHhV83NNywyP8Z2gqBMOWfRIPpGo9hpZFjxQ X-Yahoo-SMTP: nOrmCa6swBAE50FabWnlVFUpgFVJ9Gbi__8U5mpvhtQq7tTV1g-- Message-ID: <5433671E.9080308@sbcglobal.net> Date: Mon, 06 Oct 2014 21:07:58 -0700 From: David Jacobson User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Watson Ladd , Stephen Farrell References: <3EE5AEA5-3ADE-4D67-AC51-478074349D1B@gmail.com> <5432BBF1.5060003@cs.tcd.ie> In-Reply-To: Content-Type: multipart/alternative; boundary="------------080401040304070206020702" Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/BfzzHr29-wQof4f70M17wjlNvY8 Cc: cfrg@irtf.org Subject: Re: [Cfrg] When's the decision? X-BeenThere: cfrg@irtf.org 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: Tue, 07 Oct 2014 04:08:02 -0000 This is a multi-part message in MIME format. --------------080401040304070206020702 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 10/6/14, 4:28 PM, Watson Ladd wrote: > > > On Oct 6, 2014 8:57 AM, "Stephen Farrell" > wrote: > > > > > > Hiya, > > > > On 06/10/14 16:53, Yoav Nir wrote: > > > They're all good enough > > > > Tend to agree. But CFRG, pretty-please don't pick them all! > > This ignores the significance of choices such as which coordinates to > use on the wire, whether to use compression, and which signature > scheme to use. > > These are not make or break items, and any curve could be used several > ways, but these issues do not go away with the choice of curve. > > > > If you do we'll just have to pick elsewhere (e.g. saag or > > specific IETF wgs) with less clue immediately involved. > > Agreed: the buck stops here. > > > > S. > > > > I've implemented elliptic curve systems quite a few times. But never with compression. (The patent just expired.) Could someone with experience implementing compression and with the short list of candidates, comment, for each curve, on how much of a hassle compression is to write, how much it expands the code, and how much it slows down the computation? If the hassle, code bloat, and slowdown are minor, I suggest we just do compressed. (Rationale: Compression is always a win so do compressed. Keep it simple---no options) If the hassle, code bloat, or slowdown are considerable, I suggest we require uncompressed and make compressed optional. (Rationale: Compression is sometimes a win, e.g. for applications were bits on the wire are precious, and sometimes a lose. For guaranteed interoperability there should be one variant that is always there, and that one should be the simpler, smaller.) This probably interacts with the on-the-wire representation. That will make the deciding a bit harder, but such is life. --David Jacobson --------------080401040304070206020702 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 10/6/14, 4:28 PM, Watson Ladd wrote:


On Oct 6, 2014 8:57 AM, "Stephen Farrell" <stephen.farrell@cs.tcd.ie> wrote:
>
>
> Hiya,
>
> On 06/10/14 16:53, Yoav Nir wrote:
> > They’re all good enough
>
> Tend to agree. But CFRG, pretty-please don't pick them all!

This ignores the significance of choices such as which coordinates to use on the wire, whether to use compression, and which signature scheme to use.

These are not make or break items, and any curve could be used several ways, but these issues do not go away with the choice of curve.
>
> If you do we'll just have to pick elsewhere (e.g. saag or
> specific IETF wgs) with less clue immediately involved.

Agreed: the buck stops here.
>
> S.
>


I've implemented elliptic curve systems quite a few times.  But never with compression.  (The patent just expired.)  Could someone with experience implementing compression and with the short list of candidates, comment, for each curve, on how much of a hassle compression is to write, how much it expands the code, and how much it slows down the computation?

If the hassle, code bloat, and slowdown are minor, I suggest we just do compressed.  (Rationale:  Compression is always a win so do compressed.  Keep it simple---no options)

If the hassle, code bloat, or slowdown are considerable, I suggest we require uncompressed and make compressed optional.  (Rationale:  Compression is sometimes a win, e.g. for applications were bits on the wire are precious, and sometimes a lose.  For guaranteed interoperability there should be one variant that is always there, and that one should be the simpler, smaller.)

This probably interacts with the on-the-wire representation.  That will make the deciding a bit harder, but such is life.

   --David Jacobson

--------------080401040304070206020702-- From nobody Mon Oct 6 21:57:00 2014 Return-Path: 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 0FCA31A911E for ; Mon, 6 Oct 2014 21:56:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 q2_4o00l_2Bq for ; Mon, 6 Oct 2014 21:56:57 -0700 (PDT) Received: from mail-yh0-x22a.google.com (mail-yh0-x22a.google.com [IPv6:2607:f8b0:4002:c01::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C5211A911B for ; Mon, 6 Oct 2014 21:56:57 -0700 (PDT) Received: by mail-yh0-f42.google.com with SMTP id t59so2648692yho.15 for ; Mon, 06 Oct 2014 21:56:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=ZOmymMqLHIFkPREPhyiAavzLjBKUYPPyJ3Xm2N04HoA=; b=sYngJq3wmqVZklVSz6sMEVfsW1+gjVoATfae4UlonfRPlAhDxKeRvx41VQuFju+2U5 XvNktY0wyMn9E7788ir0v4KhgPiOk/xMUwhNTtn+RJnZTaVWL/FclC5zg/2wwuCXXyLE 3tN9OyuwzJo7G/jA+Mz26Jd8VjyKWIznncfns+0Rt8YlHxeL1t18rQguQsB456JV5kxW obhvDhuvQ77SkEiJA/ixmknb0yNM3Lpqwa304+sykYtkx1IJSPgrnoTIZ7lOnynMWo/q G/vwRLeC3R1tKGfTJN9KfvEd2kKIUHIDEV0TcJ/qPhkRwLdhQOHwf5GeDDzN9emG2k5y AOAA== MIME-Version: 1.0 X-Received: by 10.236.35.116 with SMTP id t80mr2093468yha.49.1412657816618; Mon, 06 Oct 2014 21:56:56 -0700 (PDT) Received: by 10.170.195.149 with HTTP; Mon, 6 Oct 2014 21:56:56 -0700 (PDT) In-Reply-To: <5433671E.9080308@sbcglobal.net> References: <3EE5AEA5-3ADE-4D67-AC51-478074349D1B@gmail.com> <5432BBF1.5060003@cs.tcd.ie> <5433671E.9080308@sbcglobal.net> Date: Mon, 6 Oct 2014 21:56:56 -0700 Message-ID: From: Watson Ladd To: David Jacobson Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/SxZ2rc9XGeVojD5VvMAbEK0dqJ8 Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] When's the decision? X-BeenThere: cfrg@irtf.org 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: Tue, 07 Oct 2014 04:56:59 -0000 On Mon, Oct 6, 2014 at 9:07 PM, David Jacobson w= rote: > On 10/6/14, 4:28 PM, Watson Ladd wrote: > > > On Oct 6, 2014 8:57 AM, "Stephen Farrell" wro= te: >> >> >> Hiya, >> >> On 06/10/14 16:53, Yoav Nir wrote: >> > They=E2=80=99re all good enough >> >> Tend to agree. But CFRG, pretty-please don't pick them all! > > This ignores the significance of choices such as which coordinates to use= on > the wire, whether to use compression, and which signature scheme to use. > > These are not make or break items, and any curve could be used several wa= ys, > but these issues do not go away with the choice of curve. >> >> If you do we'll just have to pick elsewhere (e.g. saag or >> specific IETF wgs) with less clue immediately involved. > > Agreed: the buck stops here. >> >> S. >> > > > I've implemented elliptic curve systems quite a few times. But never wit= h > compression. (The patent just expired.) Could someone with experience > implementing compression and with the short list of candidates, comment, = for > each curve, on how much of a hassle compression is to write, how much it > expands the code, and how much it slows down the computation? Huh? The choice of formula doesn't have much of an impact. For any prime not 1 mod 8, a single square root is pretty quick: equivalent to a single modular exponentiation. Compression doesn't add much time. Montgomery form never needs compression: the question is whether Edwards points should be compressed. This reduces the size of signatures, but isn't as critical for security as compression/validation of points for use in ECDH. The code bloat is another addition chain, but you can probably take advantage of the relation between (p+1)/4 and p-1 when code size is a concern. Sincerely, Watson Ladd > > If the hassle, code bloat, and slowdown are minor, I suggest we just do > compressed. (Rationale: Compression is always a win so do compressed. > Keep it simple---no options) > > If the hassle, code bloat, or slowdown are considerable, I suggest we > require uncompressed and make compressed optional. (Rationale: Compress= ion > is sometimes a win, e.g. for applications were bits on the wire are > precious, and sometimes a lose. For guaranteed interoperability there > should be one variant that is always there, and that one should be the > simpler, smaller.) > > This probably interacts with the on-the-wire representation. That will m= ake > the deciding a bit harder, but such is life. > > --David Jacobson > --=20 "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Mon Oct 6 22:21:00 2014 Return-Path: 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 4F50F1A9126 for ; Mon, 6 Oct 2014 22:20:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.556 X-Spam-Level: * X-Spam-Status: No, score=1.556 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, RDNS_DYNAMIC=0.982, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no 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 lwqIbJigmUEf for ; Mon, 6 Oct 2014 22:20:56 -0700 (PDT) Received: from aspartame.shiftleft.org (199-116-74-168-v301.PUBLIC.monkeybrains.net [199.116.74.168]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D849D1A9123 for ; Mon, 6 Oct 2014 22:20:55 -0700 (PDT) Received: from [192.168.1.129] (unknown [192.168.1.1]) by aspartame.shiftleft.org (Postfix) with ESMTPSA id 5573A3AA49; Mon, 6 Oct 2014 22:19:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=shiftleft.org; s=sldo; t=1412659175; bh=S4b+T8NJ5u3RgIrojn7tos1eqqqnrTZSPDF6V6L1gJE=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=Gfut0anar2jOXP8GCq/yZy4gZAtGGVCScruqr3hPlH90QS1bRzHpLeinRTMA0o4pS mr8+uSG81IZ9gc8r07IMYd/7Z/hQXKpyNTgrMWNpiTRDeDQ5OPppYEYFRpOty5nDUo TzO0OvMRtWN308jfuyZH63/pfmPVkhuXTaGWEkxA= Content-Type: multipart/alternative; boundary="Apple-Mail=_22A1AD4A-8FF9-4E4E-B7A8-5D160CCA4A01" Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1988\)) From: Michael Hamburg In-Reply-To: Date: Mon, 6 Oct 2014 22:20:53 -0700 Message-Id: References: <3EE5AEA5-3ADE-4D67-AC51-478074349D1B@gmail.com> <5432BBF1.5060003@cs.tcd.ie> <5433671E.9080308@sbcglobal.net> To: Watson Ladd X-Mailer: Apple Mail (2.1988) Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/7boI3PqOs411pyG-b88VT2xlg3Q Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] When's the decision? X-BeenThere: cfrg@irtf.org 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: Tue, 07 Oct 2014 05:20:58 -0000 --Apple-Mail=_22A1AD4A-8FF9-4E4E-B7A8-5D160CCA4A01 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Oct 6, 2014, at 9:56 PM, Watson Ladd wrote: >=20 > On Mon, Oct 6, 2014 at 9:07 PM, David Jacobson = > wrote: >> On 10/6/14, 4:28 PM, Watson Ladd wrote: >>=20 >>=20 >> On Oct 6, 2014 8:57 AM, "Stephen Farrell" = wrote: >>>=20 >>>=20 >>> Hiya, >>>=20 >>> On 06/10/14 16:53, Yoav Nir wrote: >>>> They=E2=80=99re all good enough >>>=20 >>> Tend to agree. But CFRG, pretty-please don't pick them all! >>=20 >> This ignores the significance of choices such as which coordinates to = use on >> the wire, whether to use compression, and which signature scheme to = use. >>=20 >> These are not make or break items, and any curve could be used = several ways, >> but these issues do not go away with the choice of curve. >>>=20 >>> If you do we'll just have to pick elsewhere (e.g. saag or >>> specific IETF wgs) with less clue immediately involved. >>=20 >> Agreed: the buck stops here. >>>=20 >>> S. >>>=20 >>=20 >>=20 >> I've implemented elliptic curve systems quite a few times. But never = with >> compression. (The patent just expired.) Could someone with = experience >> implementing compression and with the short list of candidates, = comment, for >> each curve, on how much of a hassle compression is to write, how much = it >> expands the code, and how much it slows down the computation? >=20 > Huh? The choice of formula doesn't have much of an impact. For any > prime not 1 mod 8, a single square root is pretty quick: equivalent to > a single modular exponentiation. Compression doesn't add much time. In particular, compression adds almost no time vs sending the point in = affine, because you=E2=80=99re mostly just throwing away information. = Decompression costs about 10% of a variable-base scalarmul. This = doesn=E2=80=99t really depend on which curve is chosen. Edwards point compression has a trick required to implement it = efficiently, as described in the EdDSA paper. But it isn=E2=80=99t = terribly complicated. > Montgomery form never needs compression: the question is whether > Edwards points should be compressed. This reduces the size of > signatures, but isn't as critical for security as > compression/validation of points for use in ECDH. Depends on the form of your signature, of course. Traditional Schnorr = sigs don=E2=80=99t send the point anyway, and neither does ECDSA, but = DJB=E2=80=99s "EdDSA" Schnorr variant does. > The code bloat is another addition chain, but you can probably take > advantage of the relation between (p+1)/4 and p-1 when code size is a > concern. Yeah, it=E2=80=99s easiest to just base everything on a 1/sqrt(x) = subroutine, or if 4th roots are needed for something in the same = library, an x^(-3/4) subroutine. That way the addition chain won=E2=80=99= t add bloat. For compression code bloat, I have some data. The Ed448-Goldilocks = reference code uses an unusually complicated compression mode for kicks: = it=E2=80=99s compatible with the Montgomery ladder, conveys sign without = a sign bit, and reduces the cofactor by encoding only even points. = According to nm, the code uses 528 bytes for compression and 592 for = decompression on Mac clang -O3 with field additions inlined, but not = multiplications. The size doesn=E2=80=99t include the exception = handling tables, which probably get stripped anyway because this is C = and there are no exceptions. This is comparable to 560 bytes for a = point addition on the same settings. A more traditional compression method would be somewhat smaller than = this. > Sincerely, > Watson Ladd >=20 >>=20 >> If the hassle, code bloat, and slowdown are minor, I suggest we just = do >> compressed. (Rationale: Compression is always a win so do = compressed. >> Keep it simple---no options) I concur. I think the code bloat and slowdown will only be a problem = for embedded machines, and those are the ones which will feel the size = advantage most. The only exception is that some protocols may have = required point formats, but that will be annoying anyway. Cheers, =E2=80=94 Mike >> If the hassle, code bloat, or slowdown are considerable, I suggest we >> require uncompressed and make compressed optional. (Rationale: = Compression >> is sometimes a win, e.g. for applications were bits on the wire are >> precious, and sometimes a lose. For guaranteed interoperability = there >> should be one variant that is always there, and that one should be = the >> simpler, smaller.) >>=20 >> This probably interacts with the on-the-wire representation. That = will make >> the deciding a bit harder, but such is life. >>=20 >> --David Jacobson >>=20 >=20 >=20 >=20 > --=20 > "Those who would give up Essential Liberty to purchase a little > Temporary Safety deserve neither Liberty nor Safety." > -- Benjamin Franklin >=20 > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg = --Apple-Mail=_22A1AD4A-8FF9-4E4E-B7A8-5D160CCA4A01 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Oct 6, 2014, at 9:56 PM, = Watson Ladd <watsonbladd@gmail.com> wrote:

On Mon, Oct 6, 2014 at 9:07 PM, David Jacobson = <dmjacobson@sbcglobal.net> wrote:
On 10/6/14, 4:28 PM, = Watson Ladd wrote:


On Oct 6, = 2014 8:57 AM, "Stephen Farrell" <stephen.farrell@cs.tcd.ie> wrote:


Hiya,

On 06/10/14 16:53, Yoav = Nir wrote:
They=E2=80=99= re all good enough

Tend to = agree. But CFRG, pretty-please don't pick them all!

This ignores the significance of = choices such as which coordinates to use on
the wire, = whether to use compression, and which signature scheme to use.

These are not make or break items, and any = curve could be used several ways,
but these issues do not = go away with the choice of curve.

If you do we'll just have to pick elsewhere = (e.g. saag or
specific IETF wgs) with less clue = immediately involved.

Agreed: = the buck stops here.

S.


I've implemented elliptic curve systems quite = a few times.  But never with
compression.  (The = patent just expired.)  Could someone with experience
implementing compression and with the short list of = candidates, comment, for
each curve, on how much of a = hassle compression is to write, how much it
expands the = code, and how much it slows down the computation?

Huh? The choice of formula = doesn't have much of an impact. For any
prime not 1 mod 8, a single square root is = pretty quick: equivalent to
a single modular = exponentiation. Compression doesn't add much time.

In = particular, compression adds almost no time vs sending the point in = affine, because you=E2=80=99re mostly just throwing away information. =  Decompression costs about 10% of a variable-base scalarmul. =  This doesn=E2=80=99t really depend on which curve is = chosen.

Edwards point compression = has a trick required to implement it efficiently, as described in the = EdDSA paper.  But it isn=E2=80=99t terribly complicated.

Montgomery form never needs compression: the = question is whether
Edwards points should be = compressed. This reduces the size of
signatures, but isn't as critical for security = as
compression/validation of = points for use in ECDH.

Depends= on the form of your signature, of course.  Traditional Schnorr = sigs don=E2=80=99t send the point anyway, and neither does ECDSA, but = DJB=E2=80=99s "EdDSA" Schnorr variant does.

The code bloat is another addition chain, but = you can probably take
advantage of the relation = between (p+1)/4 and p-1 when code size is a
concern.

Yeah, it=E2=80=99s easiest to just base everything = on a 1/sqrt(x) subroutine, or if 4th roots are needed for something in = the same library, an x^(-3/4) subroutine.  That way the addition = chain won=E2=80=99t add bloat.

For = compression code bloat, I have some data.  The Ed448-Goldilocks = reference code uses an unusually complicated compression mode for kicks: = it=E2=80=99s compatible with the Montgomery ladder, conveys sign without = a sign bit, and reduces the cofactor by encoding only even points. =  According to nm, the code uses 528 bytes for compression and 592 = for decompression on Mac clang -O3 with field additions inlined, but not = multiplications.  The size doesn=E2=80=99t include the exception = handling tables, which probably get stripped anyway because this is C = and there are no exceptions.  This is comparable to 560 bytes for a = point addition on the same settings.

A= more traditional compression method would be somewhat smaller than = this.

Sincerely,
Watson Ladd


If the = hassle, code bloat, and slowdown are minor, I suggest we just do
compressed.  (Rationale:  Compression is always a = win so do compressed.
Keep it simple---no options)

I concur.  I think the code bloat and = slowdown will only be a problem for embedded machines, and those are the = ones which will feel the size advantage most.  The only exception = is that some protocols may have required point formats, but that will be = annoying anyway.

Cheers,
=E2= =80=94 Mike

If the hassle, code bloat, or slowdown are = considerable, I suggest we
require uncompressed and make = compressed optional.  (Rationale:  Compression
is = sometimes a win, e.g. for applications were bits on the wire are
precious, and sometimes a lose.  For guaranteed = interoperability there
should be one variant that is = always there, and that one should be the
simpler, = smaller.)

This probably interacts with the = on-the-wire representation.  That will make
the = deciding a bit harder, but such is life.

  --David Jacobson




-- 
"Those who would give up Essential Liberty to = purchase a little
Temporary Safety deserve = neither  Liberty nor Safety."
-- Benjamin Franklin

_______________________________________________
Cfrg mailing list
Cfrg@irtf.org
http://www.irtf.org/mailman/listinfo/cfrg

= --Apple-Mail=_22A1AD4A-8FF9-4E4E-B7A8-5D160CCA4A01-- From nobody Mon Oct 6 22:35:49 2014 Return-Path: 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 C58031A9125 for ; Mon, 6 Oct 2014 22:35:46 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] 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 F0A0izKm-J7m for ; Mon, 6 Oct 2014 22:35:44 -0700 (PDT) Received: from nm22-vm1.access.bullet.mail.gq1.yahoo.com (nm22-vm1.access.bullet.mail.gq1.yahoo.com [216.39.63.20]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A8B71A9123 for ; Mon, 6 Oct 2014 22:35:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sbcglobal.net; s=s1024; t=1412660144; bh=qAO27/aLB+AOZRddGGB23LC0FROziQH9dSlNvAGPYcU=; h=Received:Received:Received:DKIM-Signature:X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:From:Subject; b=zf6+yP6aCZLJk+pAdXuJSCXBMbjqEhGpcAlPVYJzUmxHxZDfefKqEZnKUURJ0d5+S+GZorj0TQZNjKmPHgHwdhhE2l+z6t5Hd1N6CkYjdZfdD66x07V6MER3vBnkVtr8FPzLEEbmWHRY5aK+Vhla5etaveYOUtr/iaY+Z3AvtVI= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=sbcglobal.net; b=Fw5Zga/ynkk1OLQ1pdvp3A2ltYKaqdRnv+SM1W90nIpIsCqD/+QBUirvS2mJQYI1Nzg+RQ4tCYqS2v0dUThq23y2Z8uGersiY3rtXOvcj2zGiLHSIDg5Hm9TQEzu9hVPPsP2B+ESaOsgT29gI4WzAQcqWpH1j2QvdxsHNqdekrg=; Received: from [216.39.60.176] by nm22.access.bullet.mail.gq1.yahoo.com with NNFMP; 07 Oct 2014 05:35:44 -0000 Received: from [67.195.22.118] by tm12.access.bullet.mail.gq1.yahoo.com with NNFMP; 07 Oct 2014 05:35:44 -0000 Received: from [127.0.0.1] by smtp113.sbc.mail.gq1.yahoo.com with NNFMP; 07 Oct 2014 05:35:44 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sbcglobal.net; s=s1024; t=1412660144; bh=qAO27/aLB+AOZRddGGB23LC0FROziQH9dSlNvAGPYcU=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type; b=H5IfJP/wu/wlkOr3l+YVnjFm4DBnD8ooXbgnW849GXNOWGWraxmm+yl3vvYxgx1Q31R7NAKyRXlvY4SjK88wNOpWTeTC/Q54NWowd/Ui0SvUgmrq2yWr5yRhT05BA/50vlk4zUIsW/dvEJo6FAEQggGnN/gWBeishBtPtphXqmg= X-Yahoo-Newman-Id: 263251.6854.bm@smtp113.sbc.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: NzBBycYVM1lwxEKTkvjy.GsHz03QjXEIIaJSLTE15IEhE8M iWMf6ezDIJeYlruK1_M4AcyJuVwVJ05NKvM5esmeFOJF.PBQgrvLBlsrFYKC gs6zQnbMvyCemgmuwglUQaLjEENsHGkaJGj18tX95gPcSF6jXq7NFveUeDKy NGJtDcsWPKglza4jPrXlEB5FuuaxHoHElRlIN19rjyPCvRVc5_dEezRtKBcQ GoMnQKvL_OEIFw5sSBqptMDwveV8VtwDkki6yqCyuPEdK.l8gnxD6rvzKhQi ad3FOzpslzsxT.mEDjFXaTWfaM6tW3TumcD0H5kmJYdoFw2WiGVlsStSMDQY qMfX0k8Aka.tbx0_IX_Oq6oxoJGNOgFYWMZ.IW0jQYTgBWuCHL.25nCR3K0w IxyANHK5MV9doliJl7YhRW_LP105CgXlJqPZc8nOuiU4DA_AgwLmX9jXC7gU Od3VajqM3uDpKDiubgajZj50cLIPzrMa6jBb2ls8j1ucdl8Dpgw93LinjwvO pRseSpJ443nsv.FA9L9D_R1UwMNUr4_.jvo6.dQ9OtShg3Dw8 X-Yahoo-SMTP: nOrmCa6swBAE50FabWnlVFUpgFVJ9Gbi__8U5mpvhtQq7tTV1g-- Message-ID: <54337BAF.30104@sbcglobal.net> Date: Mon, 06 Oct 2014 22:35:43 -0700 From: David Jacobson User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Michael Hamburg , Watson Ladd References: <3EE5AEA5-3ADE-4D67-AC51-478074349D1B@gmail.com> <5432BBF1.5060003@cs.tcd.ie> <5433671E.9080308@sbcglobal.net> In-Reply-To: Content-Type: multipart/alternative; boundary="------------020500000706090104010209" Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/VdwGNP7_mMhwyqB5shayams0zic Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] When's the decision? X-BeenThere: cfrg@irtf.org 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: Tue, 07 Oct 2014 05:35:47 -0000 This is a multi-part message in MIME format. --------------020500000706090104010209 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 10/6/14, 10:20 PM, Michael Hamburg wrote: > >> On Oct 6, 2014, at 9:56 PM, Watson Ladd > > wrote: >> >> On Mon, Oct 6, 2014 at 9:07 PM, David Jacobson >> > wrote: >>> On 10/6/14, 4:28 PM, Watson Ladd wrote: >>> >>> >>> On Oct 6, 2014 8:57 AM, "Stephen Farrell" >> > wrote: >>>> >>>> >>>> Hiya, >>>> >>>> On 06/10/14 16:53, Yoav Nir wrote: >>>>> They’re all good enough >>>> >>>> Tend to agree. But CFRG, pretty-please don't pick them all! >>> >>> This ignores the significance of choices such as which coordinates >>> to use on >>> the wire, whether to use compression, and which signature scheme to use. >>> >>> These are not make or break items, and any curve could be used >>> several ways, >>> but these issues do not go away with the choice of curve. >>>> >>>> If you do we'll just have to pick elsewhere (e.g. saag or >>>> specific IETF wgs) with less clue immediately involved. >>> >>> Agreed: the buck stops here. >>>> >>>> S. >>>> >>> >>> >>> I've implemented elliptic curve systems quite a few times. But >>> never with >>> compression. (The patent just expired.) Could someone with experience >>> implementing compression and with the short list of candidates, >>> comment, for >>> each curve, on how much of a hassle compression is to write, how much it >>> expands the code, and how much it slows down the computation? >> >> Huh? The choice of formula doesn't have much of an impact. For any >> prime not 1 mod 8, a single square root is pretty quick: equivalent to >> a single modular exponentiation. Compression doesn't add much time. > > In particular, compression adds almost no time vs sending the point in > affine, because you’re mostly just throwing away information. > Decompression costs about 10% of a variable-base scalarmul. This > doesn’t really depend on which curve is chosen. > > Edwards point compression has a trick required to implement it > efficiently, as described in the EdDSA paper. But it isn’t terribly > complicated. > >> Montgomery form never needs compression: the question is whether >> Edwards points should be compressed. This reduces the size of >> signatures, but isn't as critical for security as >> compression/validation of points for use in ECDH. > > Depends on the form of your signature, of course. Traditional Schnorr > sigs don’t send the point anyway, and neither does ECDSA, but DJB’s > "EdDSA" Schnorr variant does. > >> The code bloat is another addition chain, but you can probably take >> advantage of the relation between (p+1)/4 and p-1 when code size is a >> concern. > > Yeah, it’s easiest to just base everything on a 1/sqrt(x) subroutine, > or if 4th roots are needed for something in the same library, an > x^(-3/4) subroutine. That way the addition chain won’t add bloat. > > For compression code bloat, I have some data. The Ed448-Goldilocks > reference code uses an unusually complicated compression mode for > kicks: it’s compatible with the Montgomery ladder, conveys sign > without a sign bit, and reduces the cofactor by encoding only even > points. According to nm, the code uses 528 bytes for compression and > 592 for decompression on Mac clang -O3 with field additions inlined, > but not multiplications. The size doesn’t include the exception > handling tables, which probably get stripped anyway because this is C > and there are no exceptions. This is comparable to 560 bytes for a > point addition on the same settings. > > A more traditional compression method would be somewhat smaller than this. > >> Sincerely, >> Watson Ladd >> >>> >>> If the hassle, code bloat, and slowdown are minor, I suggest we just do >>> compressed. (Rationale: Compression is always a win so do compressed. >>> Keep it simple---no options) > > I concur. I think the code bloat and slowdown will only be a problem > for embedded machines, and those are the ones which will feel the size > advantage most. The only exception is that some protocols may have > required point formats, but that will be annoying anyway. > > Cheers, > — Mike > >>> If the hassle, code bloat, or slowdown are considerable, I suggest we >>> require uncompressed and make compressed optional. (Rationale: >>> Compression >>> is sometimes a win, e.g. for applications were bits on the wire are >>> precious, and sometimes a lose. For guaranteed interoperability there >>> should be one variant that is always there, and that one should be the >>> simpler, smaller.) >>> >>> This probably interacts with the on-the-wire representation. That >>> will make >>> the deciding a bit harder, but such is life. >>> >>> --David Jacobson >>> >> >> >> >> -- >> "Those who would give up Essential Liberty to purchase a little >> Temporary Safety deserve neither Liberty nor Safety." >> -- Benjamin Franklin >> >> _______________________________________________ >> Cfrg mailing list >> Cfrg@irtf.org >> http://www.irtf.org/mailman/listinfo/cfrg > We should probably wait a day or two to see if there are any opposing opinions. But given the response from people who have implemented compression, I'd lean towards compressed as the only option. --David --------------020500000706090104010209 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
On 10/6/14, 10:20 PM, Michael Hamburg wrote:

On Oct 6, 2014, at 9:56 PM, Watson Ladd <watsonbladd@gmail.com> wrote:

On Mon, Oct 6, 2014 at 9:07 PM, David Jacobson <dmjacobson@sbcglobal.net> wrote:
On 10/6/14, 4:28 PM, Watson Ladd wrote:


On Oct 6, 2014 8:57 AM, "Stephen Farrell" <stephen.farrell@cs.tcd.ie> wrote:


Hiya,

On 06/10/14 16:53, Yoav Nir wrote:
They’re all good enough

Tend to agree. But CFRG, pretty-please don't pick them all!

This ignores the significance of choices such as which coordinates to use on
the wire, whether to use compression, and which signature scheme to use.

These are not make or break items, and any curve could be used several ways,
but these issues do not go away with the choice of curve.

If you do we'll just have to pick elsewhere (e.g. saag or
specific IETF wgs) with less clue immediately involved.

Agreed: the buck stops here.

S.



I've implemented elliptic curve systems quite a few times.  But never with
compression.  (The patent just expired.)  Could someone with experience
implementing compression and with the short list of candidates, comment, for
each curve, on how much of a hassle compression is to write, how much it
expands the code, and how much it slows down the computation?

Huh? The choice of formula doesn't have much of an impact. For any
prime not 1 mod 8, a single square root is pretty quick: equivalent to
a single modular exponentiation. Compression doesn't add much time.

In particular, compression adds almost no time vs sending the point in affine, because you’re mostly just throwing away information.  Decompression costs about 10% of a variable-base scalarmul.  This doesn’t really depend on which curve is chosen.

Edwards point compression has a trick required to implement it efficiently, as described in the EdDSA paper.  But it isn’t terribly complicated.

Montgomery form never needs compression: the question is whether
Edwards points should be compressed. This reduces the size of
signatures, but isn't as critical for security as
compression/validation of points for use in ECDH.

Depends on the form of your signature, of course.  Traditional Schnorr sigs don’t send the point anyway, and neither does ECDSA, but DJB’s "EdDSA" Schnorr variant does.

The code bloat is another addition chain, but you can probably take
advantage of the relation between (p+1)/4 and p-1 when code size is a
concern.

Yeah, it’s easiest to just base everything on a 1/sqrt(x) subroutine, or if 4th roots are needed for something in the same library, an x^(-3/4) subroutine.  That way the addition chain won’t add bloat.

For compression code bloat, I have some data.  The Ed448-Goldilocks reference code uses an unusually complicated compression mode for kicks: it’s compatible with the Montgomery ladder, conveys sign without a sign bit, and reduces the cofactor by encoding only even points.  According to nm, the code uses 528 bytes for compression and 592 for decompression on Mac clang -O3 with field additions inlined, but not multiplications.  The size doesn’t include the exception handling tables, which probably get stripped anyway because this is C and there are no exceptions.  This is comparable to 560 bytes for a point addition on the same settings.

A more traditional compression method would be somewhat smaller than this.

Sincerely,
Watson Ladd


If the hassle, code bloat, and slowdown are minor, I suggest we just do
compressed.  (Rationale:  Compression is always a win so do compressed.
Keep it simple---no options)

I concur.  I think the code bloat and slowdown will only be a problem for embedded machines, and those are the ones which will feel the size advantage most.  The only exception is that some protocols may have required point formats, but that will be annoying anyway.

Cheers,
— Mike

If the hassle, code bloat, or slowdown are considerable, I suggest we
require uncompressed and make compressed optional.  (Rationale:  Compression
is sometimes a win, e.g. for applications were bits on the wire are
precious, and sometimes a lose.  For guaranteed interoperability there
should be one variant that is always there, and that one should be the
simpler, smaller.)

This probably interacts with the on-the-wire representation.  That will make
the deciding a bit harder, but such is life.

  --David Jacobson




-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin

_______________________________________________
Cfrg mailing list
Cfrg@irtf.org
http://www.irtf.org/mailman/listinfo/cfrg

We should probably wait a day or two to see if there are any opposing opinions.  But given the response from people who have implemented compression, I'd lean towards compressed as the only option.

   --David

--------------020500000706090104010209-- From nobody Tue Oct 7 01:15:13 2014 Return-Path: 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 C2A9E1A9142 for ; Tue, 7 Oct 2014 01:15:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.314 X-Spam-Level: X-Spam-Status: No, score=0.314 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.786, 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 bjW48gkIV13B for ; Tue, 7 Oct 2014 01:15:08 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CAC81A1B4E for ; Tue, 7 Oct 2014 01:15:08 -0700 (PDT) Received: from [80.246.32.33] by 3capp-gmx-bs29.server.lan (via HTTP); Tue, 7 Oct 2014 10:15:03 +0200 MIME-Version: 1.0 Message-ID: From: =?UTF-8?Q?=22Torsten_Sch=C3=BCtze=22?= To: "D. J. Bernstein" Content-Type: text/plain; charset=UTF-8 Date: Tue, 7 Oct 2014 10:15:03 +0200 Importance: normal Sensitivity: Normal In-Reply-To: <20141003111024.20324.qmail@cr.yp.to> References: <20141003111024.20324.qmail@cr.yp.to> Content-Transfer-Encoding: quoted-printable X-UI-Message-Type: mail X-Priority: 3 X-Provags-ID: V03:K0:i2065a7oWgLKf8qYfMpzwVt+0Lf8w3q4e8r0K39AWM3 9cz3Lb59SLLN4geeCtHHjRncprfeAGEcwp3t3M7/l51UQwEajA apYDotKCGOcUQume3IeQh5qq3lkEABv0Ce4tT2HVwSDo+oRYyK yIAvCVuNTDUwDAm0w0QiwKvH2tyh0onCeEgjRED7/vKXn1k1Z/ dY2WP3RPaMcd7sKdvqzdcJXci/+mUvOKJ6MFCRRLGF6yFReFcx yyyIFVZPa8k7NlOKfqIIMF4hUrvDD4B/4GQIO80UdlE+TyXKNx 28HF/U= X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/jLtu-M4xNoFMf2OkM7p3A7kWI9g Cc: cfrg@irtf.org Subject: Re: [Cfrg] Trusting government certifications of cryptography X-BeenThere: cfrg@irtf.org 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: Tue, 07 Oct 2014 08:15:12 -0000 On 10/3/14, 4:10 AM, D. J. Bernstein wrote: >Torsten Schuetze writes: >> Smart cards, i.e., its coprocessors and its ECC software >> implementations, are always certified by Common Criteria, usually with >> rather high assurance level. Don't you trust this certification in >> principle?=20 > > http://smartfacts.cr.yp.to explains how we factored 184 RSA-1024 keys > from Taiwan's national "Citizen Digital Certificate" database. As you > can see from http://smartfacts.cr.yp.to/cert.html, these keys were > generated by government-issued smart cards that advertised all of the > usual Common Criteria and FIPS certifications from BSI, NIST, and CSE. Dan, you may remember that we discussed this RNG topic at the eve of last years CRYPTO at Santa Barbara. Following the discussion in this and the other threads on CFRG, I should have better re-phrased my original question into: Do you distrust Common Criteria (or government certification, as you call it) in principle? Background of the question was to find out where does the individual trust boundary of Alyssa run. Of course, I cannot (and I will not) speak on behalf of BSI or another ``government agency=C2=B4=C2=B4 or on behalf of an independent evaluation = lab as T-Systems GEI or on behalf of any other official lab/agency. But believe me, these presentations/these revelations have been discussed thoroughly inside the German RNG community. What do we have? - We have a rather old CC EAL4+ certificate from January 2004 and a Assurance Continuity Maintenance Report from September 2004. (BTW, the first link to the Maintenance Report on your web site is wrong. The mirror link works.) This certificate claims that the smart card hardware RNG TOGETHER WITH ACCOMPANYING SOFTWARE provides a class P2 high physical true RNG according to AIS 31, Version 1, 25.09.2001. The relevant technical guide is Killmann/Schindler: A proposal for: Functionality classes and evaluation methodology for true (physical) random number generators, Version 3.1, 25.09.2001. - Then we have your nice research paper and talks from the mid/end of 2013. Of course, there was a major problem with this product. But this doesn't mean necessarily that there is a major problem with the certification / evaluation process. P2 high requires that there are a) a startup test, b) a total failure test, and c) a continuous on-line test. This is not surprising, but the big difference, e.g., to NIST FIPS 140-2 is, that there must be a so-called stochastic model, i.e., a ``Comprehensible and plausible description of a mathematical model of the physical noise source and the statistical properties of the digitised noise signal sequence derived from it.=C2=B4=C2=B4 The on-line test has to be adapted specifical= ly to the stochastic model. Commonly this amounts in understanding your entropy source (and not just passing statistical tests) and providing, at best, lower bounds on the entropy. Or as Victor Fischer puts it:=20 ``It is quite easy to design a TRNG that will let the statistical tests pass ... but it is much more difficult to know where the randomness comes from and how much true randomness is there.=C2=B4=C2=B4 P2 high DOES NOT require that there is a cryptographic post-processing of the internal random sequence (non-cryptographic post-processing as von Neumann or Peres procedure does not count here). So, obviously the mentioned product failed to implement an effective total failure test and/or an effective continuous on-line test.=20 The situation with RNGs is completely different with NIST FIPS. Usually NIST is focused much more on deterministic RNGs, see the infamous SP800-90A. Up to the publication of FIPS drafts SP800-90B and SP800-90C you could not find much on entropy sources and their evaluation. (And with the last two FIPS drafts I see some problems, too. For example, an entropy defect of order 2^{-64} can NEVER be estimated experimentally. In AIS 31, we have now the requirement of an entropy defect of less than 3E-03, practically E-4..E-5, i.e., average Shannon entropy per bit exceeds 0.997. And for this estimate 2^30 random bits are recommended to test. The full entropy sources from SP800-90B/C would require such HUGE random data for estimating the defect 2^{-64}=3D5E-20 that this is practically impossible.) At your website you wrote regarding FIPS mode or non-FIPS mode: ``However, this did not result in HICOS failing certification; it merely resulted in extra words on the certificate saying that the certificate was valid only when the card was "operated in FIPS mode".=C2=B4=C2=B4 I presume that the card has been CC certified in FIPS mode. For CC we only have=20 ``The confirmed assurance package is only valid on the condition that - all stipulations regarding generation, configuration and operation, as given in the following report, are observed, - the product is operated in the environment described, where specified in the following report.=C2=B4=C2=B4 This means, that the card has not been used properly, i.e., the external preconditions have not been fulfilled. So, no problem with CC certificate or CC process, but with individual usage. By the way, the above mentioned certificate does only apply to the smart card hardware. Usually, you either have a manufacturer library for RSA with certificate or another CC certificate for operating system and RSA application. I could not find anything like this at your website. So the manufacturer/producer of the RSA application and their evalution lab/certification THESE WERE THE PEOPLE TO BLAIM, NOT THE CC EVAL LABS OF THE HARDWARE. However, even I have some criticism on Common Criteria. It is much too easy to define a Target of Evaluation that is too narrow, sometimes almost meaningless. For example, when I see an IPsec product evaluated where the public-key and the symmetric key coprocessors are not in the TOE. Or, when the organizational security policies and assumptions are too wide, even unrealistic. But this just means: The statement ``CC certification exists=C2=B4=C2=B4 is not very meaningful alone, one has to = read the complete security problem definition. Another problem I sometimes have with CC is their reliance on keeping design documents confidential and getting AVA points. I do not advocate to publish everything, but one should not get any points for confidential user manuals, etc. > http://smartfacts.cr.yp.to/analysis.html analyzes five contributing > factors to this security disaster---low-quality hardware RNG, inadequate > sanity checks, no run-time sanity checks, no post-processing, and > inadequate initial response---and the complete failure of certification > to prevent the disaster from occurring. I admit the low-quality RNG and the missing/ineffective tests. However, I do not see ``the complete failure of certification=C2=B4=C2=B4,= only then when you can prove that a smart card used in the CC specified mode has been compromised. Further, the analyzed product was rather old. This is no excuse and shall not impair your results. But current AIS 20/31 standards, effective since 2011, see Killmann/Schindler: A proposal for: Functionality classes for random number generators, version 2.0, September 18, 2011, recommend a class PTG.3 generator, e.g., a hybrid physical true random number generator, basically a P2 high (now PTG.2) with cryptographic post-processing (DRG.3). This type of RNG is/will be REQUIRED for all German so-called qualified digital signatures, see BSI Algorithmenkatalog 2014 (=C3=9Cbersicht =C3=BCber geeignete Algorithme= n, Bekanntmachung zur elektronischen Signatur, Bundesnetzagentur). A PTG.3 RNG would have made the attack impossible. Nevertheless, your result from last year provided one good reasoning for me explaining the need of PTG.3 RNGs to our non-technical management (besides certification requirement facts) :-) As you may have noticed I have only written about Common Criteria certification. This is the process I have the most experience with. FIPS certification in general, for example, FIPS 140-2 and RNG certification specifically, for example, SP800-90A, are completely different. FIPS 140-2 is, in my opinion, rather old nowadays. FIPS 140-3 drafts, even they more than 5 years old now, had some good ideas. Specifically with respect to side-channel evaluation. This leads us back to the original problem: Elliptic Curve Cryptography and Certification. Dan, I am sure you know the BSI Guidelines AIS 46 Minimum Requirements for Evaluating Side-Channel Attack Resistance of Elliptic Curve Implementations as Tanja was one of the co-authors. All that I'm saying is that one should consider, at least for applications in hostile environments, the complete set of attacks and countermeasures. And not only timing attacks. Common criteria may not be sufficient in some areas. But at least, it is better than nothing (or everything else we have). Our aim as security researchers/practitioners should be to improve that process and not to discredit it. Of course, in a perfect university world it would be fine to disclose anything http://smartfacts.cr.yp.to/faq.html: > We strongly recommend that the chip manufacturer publicly disclose > full details of the RNG hardware in use and provide copies of the RNG > hardware to researchers, allowing a thorough characterization of the > physical failures of the RNG hardware on the 1024-bit cards and an > analysis of the differences in the RNG hardware on the 2048-bit cards. = =20 and it would even interest me, personally. But what would happen if you find something in millions of enrolled cards and cannot fix it immediately? So, there are some differences between university and industry. > You can't reasonably ask CFRG to "trust this certification in > principle". What I do ask CFRG, is to consider established security evaluation as Common Criteria as ONE BLOCK OF BUILDING TRUST.=20 And what I would like to ask CFRG further, is to consider the different, more general ``performance=C2=B4=C2=B4 requirements as formulat= ed in=20 http://www.ietf.org/mail-archive/web/cfrg/current/msg05105.html Regards, Torsten From nobody Tue Oct 7 02:57:18 2014 Return-Path: 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 1BB2A1ACD6A for ; Tue, 7 Oct 2014 02:57:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 y3eUUTiMvPF0 for ; Tue, 7 Oct 2014 02:57:14 -0700 (PDT) Received: from mail-qg0-x230.google.com (mail-qg0-x230.google.com [IPv6:2607:f8b0:400d:c04::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1C961ACD69 for ; Tue, 7 Oct 2014 02:57:14 -0700 (PDT) Received: by mail-qg0-f48.google.com with SMTP id i50so4900423qgf.7 for ; Tue, 07 Oct 2014 02:57:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/yfSmoGEv2YwJD/K6l9+877GbozLGL1LmgKfvG6iXU0=; b=oPUYSEps1kzhQmTFwkkimuBiUI58qwd1q4P2PpoGTxaB9nUyAfQig+Lvg/6tWF/cGG x8joZj6HaVK6GxGXRUysvwsvj3FR1Ow7Qgzmq7jYKn0QXYkyhPenkm6NxXnFr+SZ++PA fcWDQaUN+4hxBjQRuM8mJQQZLlcfT+M3nLtPkpm1vehW0b0kn9cPBIg5IIQ7NyUxN5uu r3mxrSqDcswUinNqpOewN2v99MXQ0nHEispR6scMuGnSNQWjS02VNERhE23oDHRP26dy psijORt67l7Al1dlZ9ampwVSsL3CZ2RrXM+r9OZ6O7DLRnGwDDIcBxXOZEy2T/Wmj45c G98Q== MIME-Version: 1.0 X-Received: by 10.224.65.9 with SMTP id g9mr2671631qai.59.1412675833939; Tue, 07 Oct 2014 02:57:13 -0700 (PDT) Received: by 10.229.226.65 with HTTP; Tue, 7 Oct 2014 02:57:13 -0700 (PDT) In-Reply-To: References: <542D48CD.9060404@isode.com> Date: Tue, 7 Oct 2014 11:57:13 +0200 Message-ID: From: Nikos Mavrogiannopoulos To: James Cloos Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/8QVZahoydg5jpoCYGQPYcTyBKa8 Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] RGLC on draft-irtf-cfrg-chacha20-poly1305-01.txt X-BeenThere: cfrg@irtf.org 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: Tue, 07 Oct 2014 09:57:16 -0000 On Mon, Oct 6, 2014 at 11:25 PM, James Cloos wrote: > [I thought I sent on this subect weeks ago, but I cannot find it in > the archives, ... -JimC] > > I have to object to defaulting to a 96/32 split. > The rfc should specify Dan's 64/64 split as default, and only offer > 96/32 as an option. > Chacha isn't only useful for in-flight encryption. One should not > have to bother with multiple keys or IVs to encrypt large files. > And 128 Gigs is not all that large for things like backups (tar, > cpio, et cetera), disk images, some AV files and the like. Would you really want to use an AEAD cipher for backup encryption in a single pass? I mean a single bit corruption in 128 Gigs and you lost everything as authentication would fail. Most probably backup encryption software would split the large backup data into smaller chunks that are authenticated and in that case the 96/32 split would fit. regards, Nikos From nobody Tue Oct 7 03:28:01 2014 Return-Path: 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 4BA6E1A1BA9 for ; Tue, 7 Oct 2014 03:28:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.986 X-Spam-Level: X-Spam-Status: No, score=-4.986 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786] 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 Rxiih2KIRQl5 for ; Tue, 7 Oct 2014 03:27:56 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4756A1ACD21 for ; Tue, 7 Oct 2014 03:27:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1412677670; x=1444213670; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=0UwloywA2dpW8I4okKwVBRbjZEoeWkPqYvoqrXXp7JQ=; b=UUBrHSgCLNjTQQM4/o6hUnPmaTgwuRVZuIEo0NDk1A8mwO1XxXD0Pmdd wBp6vwxoWVrgCzfKiU1QuC+5OkOcfosWKJ5hOgBU8Mk3b+/ryq3Yx7ys9 +0exwG+Ovns5ZgNuuTMc7xjq2XxtwvvKR2+TPXkR3WegH0gOgOt3u4Vgw 0=; X-IronPort-AV: E=Sophos;i="5.04,630,1406548800"; d="scan'208";a="281103985" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.125 - Outgoing - Outgoing Received: from uxchange10-fe3.uoa.auckland.ac.nz ([130.216.4.125]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 07 Oct 2014 23:27:46 +1300 Received: from UXCN10-TDC05.UoA.auckland.ac.nz ([169.254.9.70]) by uxchange10-fe3.UoA.auckland.ac.nz ([130.216.4.125]) with mapi id 14.03.0174.001; Tue, 7 Oct 2014 23:27:45 +1300 From: Peter Gutmann To: "'cfrg@irtf.org'" Thread-Topic: [Cfrg] RGLC on draft-irtf-cfrg-chacha20-poly1305-01.txt Thread-Index: Ac/iGVUsGWhSSZ6iTumgxDHPopfDTA== Date: Tue, 7 Oct 2014 10:27:44 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C739B9C314B@uxcn10-tdc05.UoA.auckland.ac.nz> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/OjEBUts8T8YhplcD3CUQGBwkjyI Subject: Re: [Cfrg] RGLC on draft-irtf-cfrg-chacha20-poly1305-01.txt X-BeenThere: cfrg@irtf.org 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: Tue, 07 Oct 2014 10:28:00 -0000 Nikos Mavrogiannopoulos writes:=0A= =0A= >Would you really want to use an AEAD cipher for backup encryption in a sin= gle=0A= >pass? I mean a single bit corruption in 128 Gigs and you lost everything a= s=0A= >authentication would fail. =0A= =0A= You wouldn't lose anything, you'd just get a notification that some of the= =0A= data was corrupted. In fact if you use one of the CTR-mode-based AEAD=0A= constructions, which are just KSG ciphers, then you could flip all sorts of= =0A= bits with minimal data loss.=0A= =0A= Peter.= From nobody Tue Oct 7 06:22:16 2014 Return-Path: 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 E284E1A212D for ; Tue, 7 Oct 2014 06:22:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.787 X-Spam-Level: X-Spam-Status: No, score=-2.787 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.786, 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 wfkFc7V1pcb5 for ; Tue, 7 Oct 2014 06:22:13 -0700 (PDT) Received: from ore.jhcloos.com (ore.jhcloos.com [198.147.23.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E21431A6EE0 for ; Tue, 7 Oct 2014 06:22:13 -0700 (PDT) Received: by ore.jhcloos.com (Postfix, from userid 10) id 920251E2C1; Tue, 7 Oct 2014 13:22:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=ore14; t=1412688132; bh=rlNBKockHnmRKjcKiYniYryhARhOGqnysVZlshP+WuA=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=G0/7hzZVbPiKzioCfSogppdZmU9l0izIJJw/1yDY1qrJKbNujFGPXywTnhhf3iJ3e zXffmp7qHoEHi02d8SeiqftrXMo/EXXOpFNpa1H07noovNRIJU6B77esND/pt/P9Gs plYsIlU37s1lXa7rjKphD6OF3FcgfqK+dZbBq0O8= Received: by carbon.jhcloos.org (Postfix, from userid 500) id 67BF160024; Tue, 7 Oct 2014 13:20:23 +0000 (UTC) From: James Cloos To: Nikos Mavrogiannopoulos In-Reply-To: (Nikos Mavrogiannopoulos's message of "Tue, 7 Oct 2014 11:57:13 +0200") References: <542D48CD.9060404@isode.com> User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/24.4.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2014 James Cloos OpenPGP: 0x997A9F17ED7DAEA6; url=https://jhcloos.com/public_key/0x997A9F17ED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Tue, 07 Oct 2014 09:20:23 -0400 Message-ID: Lines: 13 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:28:141007:n.mavrogiannopoulos@gmail.com::rLY4RDdfydfnVq28:00000000000000000000000000000008GX8q X-Hashcash: 1:28:141007:"cfrg\@irtf.org"::ObzAGi/eFX1LaxNd:808i7 X-Hashcash: 1:28:141007:cfrg@irtf.org::zN+li+ob3ZDWSbcW:000L0DRJ Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/BlGyxw-xkbaaD2VBoTDuppmWiq0 Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] RGLC on draft-irtf-cfrg-chacha20-poly1305-01.txt X-BeenThere: cfrg@irtf.org 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: Tue, 07 Oct 2014 13:22:15 -0000 >>>>> "NM" == Nikos Mavrogiannopoulos writes: NM> Would you really want to use an AEAD cipher for backup encryption in a NM> single pass? I mean a single bit corruption in 128 Gigs and you lost NM> everything as authentication would fail. One should only loose the block which failed auth. Ie, each block should be treated separately. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6 From nobody Tue Oct 7 07:02:58 2014 Return-Path: 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 728D91ACD96 for ; Tue, 7 Oct 2014 07:02:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.036 X-Spam-Level: X-Spam-Status: No, score=-2.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.786] 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 LA4j_HbttV_f for ; Tue, 7 Oct 2014 07:02:55 -0700 (PDT) Received: from mordell.elzevir.fr (mordell.elzevir.fr [92.243.3.74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BA331ACDA1 for ; Tue, 7 Oct 2014 07:02:55 -0700 (PDT) Received: from thue.elzevir.fr (thue.elzevir.fr [88.165.216.11]) by mordell.elzevir.fr (Postfix) with ESMTPS id 56303160D1; Tue, 7 Oct 2014 16:02:53 +0200 (CEST) Received: from [192.168.0.124] (unknown [192.168.0.254]) by thue.elzevir.fr (Postfix) with ESMTPSA id 9ED2A290A4; Tue, 7 Oct 2014 16:02:52 +0200 (CEST) Message-ID: <5433F28C.9060501@elzevir.fr> Date: Tue, 07 Oct 2014 16:02:52 +0200 From: =?windows-1252?Q?Manuel_P=E9gouri=E9-Gonnard?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: James Cloos , Nikos Mavrogiannopoulos References: <542D48CD.9060404@isode.com> In-Reply-To: OpenPGP: id=98EED379; url=https://elzevir.fr/gpg/mpg.asc Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/CWY8FZIibAMfAOOgh7rPTZFcROE Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] RGLC on draft-irtf-cfrg-chacha20-poly1305-01.txt X-BeenThere: cfrg@irtf.org 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: Tue, 07 Oct 2014 14:02:57 -0000 On 07/10/2014 15:20, James Cloos wrote: >>>>>> "NM" == Nikos Mavrogiannopoulos writes: > > NM> Would you really want to use an AEAD cipher for backup encryption in a > NM> single pass? I mean a single bit corruption in 128 Gigs and you lost > NM> everything as authentication would fail. > > One should only loose the block which failed auth. > > Ie, each block should be treated separately. > I'm sorry if I'm missing something painfully obvious, but if each block is treated separately, then why do you need a counter larger than 32 bits? Manuel. From nobody Tue Oct 7 07:23:54 2014 Return-Path: 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 F17E51ACDB6 for ; Tue, 7 Oct 2014 07:23:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.487 X-Spam-Level: X-Spam-Status: No, score=-2.487 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.786, 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 VOroKYuphNrM for ; Tue, 7 Oct 2014 07:23:41 -0700 (PDT) Received: from ore.jhcloos.com (ore.jhcloos.com [IPv6:2604:2880::b24d:a297]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 483B11ACDB1 for ; Tue, 7 Oct 2014 07:23:41 -0700 (PDT) Received: by ore.jhcloos.com (Postfix, from userid 10) id AFA131E273; Tue, 7 Oct 2014 14:23:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=ore14; t=1412691820; bh=vD98s6bU1pV8GD7EOIGppDGU1bpqMc74YHXzYoW5kJE=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=dN+yPhSc0S1Ktlr6pEJpNiwo8swpON0IKB5WL9kT+wbFJGNx6gWOSAnWTZJvrq+Z4 OS2v+7L1aRL6awU1WTseBGNE/S+fXcm9lJ8TiMpJYz76vI/KlUF4JBFYGryWApO4iD kjhHSiYGpVRb4zODBSxsZ8b/3xvG9RrN7mtMvNfI= Received: by carbon.jhcloos.org (Postfix, from userid 500) id D79C960024; Tue, 7 Oct 2014 14:22:23 +0000 (UTC) From: James Cloos To: Manuel =?iso-8859-1?Q?P=E9gouri=E9-Gonnard?= In-Reply-To: <5433F28C.9060501@elzevir.fr> ("Manuel =?iso-8859-1?Q?P=E9gou?= =?iso-8859-1?Q?ri=E9-Gonnard=22's?= message of "Tue, 07 Oct 2014 16:02:52 +0200") References: <542D48CD.9060404@isode.com> <5433F28C.9060501@elzevir.fr> User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/24.4.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2014 James Cloos OpenPGP: 0x997A9F17ED7DAEA6; url=https://jhcloos.com/public_key/0x997A9F17ED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Tue, 07 Oct 2014 10:22:23 -0400 Message-ID: Lines: 35 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Hashcash: 1:28:141007:mpg@elzevir.fr::Sy//49ul4jAFTntK:00NwW3P X-Hashcash: 1:28:141007:n.mavrogiannopoulos@gmail.com::OMKud7hUxmVGOq0e:00000000000000000000000000000000dWmB X-Hashcash: 1:28:141007:"cfrg\@irtf.org"::ZAPqV8jiSTgEip3H:0vxwd X-Hashcash: 1:28:141007:cfrg@irtf.org::YCtAGzwTkR3yimq5:0000nwnh Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/82bpv_FNdHgA3J2GSxS3jDXTgVc Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] RGLC on draft-irtf-cfrg-chacha20-poly1305-01.txt X-BeenThere: cfrg@irtf.org 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: Tue, 07 Oct 2014 14:23:43 -0000 >>>>> "MP" == Manuel Pgouri-Gonnard writes: MP> ... if each block is treated separately, then why do you need a MP> counter larger than 32 bits? The counter increments for each 256bit block. I'd expect two block sizes; the 256-bit chacha block and some arbitrary, potentially larger poly1305 block, perhaps covering somewhere between 4 and 256 chacha blocks. Each 256bit block gets its own counter value. Each poly1305 block is vulnerable to loss due to corruption. Although even then it can be analyzed to attempt to recover as many bits as possible --- since it is not on-the-fly, time is available to let people make judgement calls. Which reminds me of something I forgot to mention in this thread. I'd also prefer to see three RFCs. One covering chacha itself (including each of two, three or five quad-rounds[sic]), one for poly1305 (including with chacha and aes (it's original spec)), and the combination, referecing the first two. Chacha on its own has value, too. Dan's paper on aes/poly1305 makes it look like a better choice than gcm, at least. Maybe also better than ccm, et alia. And then the third can be specific to on-the-fly. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6 From nobody Tue Oct 7 07:27:30 2014 Return-Path: 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 BBF3D1A6F86 for ; Tue, 7 Oct 2014 07:27:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 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, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no 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 qereSjqSpeo3 for ; Tue, 7 Oct 2014 07:27:21 -0700 (PDT) Received: from mail-yh0-x234.google.com (mail-yh0-x234.google.com [IPv6:2607:f8b0:4002:c01::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BB161ACDB6 for ; Tue, 7 Oct 2014 07:27:10 -0700 (PDT) Received: by mail-yh0-f52.google.com with SMTP id 29so3047880yhl.11 for ; Tue, 07 Oct 2014 07:27:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Fif9+Z81dUH7pfH4My8JHR2eC+qMCsJ87aor5yPjkGg=; b=DL/LDor2DFIPL71jDKYO0xmls8JHvg/nskWFs7r2nbA2ZCOGOCy3qTPxiuLRYjQbvw pzQShrGrhqzpZpUt77apRatm+MV6btbjRAWkedli9sLqv8vZ7Xk4QHQS794fcQ3wk/8f a6oy7i+1oKpJVwg9pfehLP9jXwu0hNZ/cknj5uZq5wS670tTSQuZ+iZEXPhyh54B7xt5 aAFX/k3dqSM+6VtLCZk3qnNH2tJKlpRx4zrnc960NSQPwtWR2YhIKTD/Hj1wguGrOjSu 6aDjmUV4PpzroRY97AYGwRP7d9ZZYXpAZFlzFdyP2cRfNt+r4T2dpIl6CQX+rOeUNvZB cvTw== MIME-Version: 1.0 X-Received: by 10.236.172.161 with SMTP id t21mr5897124yhl.65.1412692030038; Tue, 07 Oct 2014 07:27:10 -0700 (PDT) Received: by 10.170.195.149 with HTTP; Tue, 7 Oct 2014 07:27:09 -0700 (PDT) In-Reply-To: References: <20141003111024.20324.qmail@cr.yp.to> Date: Tue, 7 Oct 2014 07:27:09 -0700 Message-ID: From: Watson Ladd To: =?UTF-8?Q?Torsten_Sch=C3=BCtze?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/ABKJMlsac6MSmC5O8eA2nsvE3o0 Cc: "cfrg@irtf.org" , "D. J. Bernstein" Subject: Re: [Cfrg] Trusting government certifications of cryptography X-BeenThere: cfrg@irtf.org 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: Tue, 07 Oct 2014 14:27:28 -0000 On Tue, Oct 7, 2014 at 1:15 AM, "Torsten Sch=C3=BCtze" wrote: > On 10/3/14, 4:10 AM, D. J. Bernstein wrote: >>Torsten Schuetze writes: >>> Smart cards, i.e., its coprocessors and its ECC software >>> implementations, are always certified by Common Criteria, usually with >>> rather high assurance level. Don't you trust this certification in >>> principle? >> >> http://smartfacts.cr.yp.to explains how we factored 184 RSA-1024 keys >> from Taiwan's national "Citizen Digital Certificate" database. As you >> can see from http://smartfacts.cr.yp.to/cert.html, these keys were >> generated by government-issued smart cards that advertised all of the >> usual Common Criteria and FIPS certifications from BSI, NIST, and CSE. > > Dan, > > you may remember that we discussed this RNG topic at the eve of last > years CRYPTO at Santa Barbara. > > Following the discussion in this and the other threads on CFRG, I > should have better re-phrased my original question into: Do you > distrust Common Criteria (or government certification, as you call it) > in principle? Background of the question was to find out where does > the individual trust boundary of Alyssa run. > > Of course, I cannot (and I will not) speak on behalf of BSI or another > ``government agency=C2=B4=C2=B4 or on behalf of an independent evaluation= lab as > T-Systems GEI or on behalf of any other official lab/agency. But > believe me, these presentations/these revelations have been discussed > thoroughly inside the German RNG community. This is not an isolated incident. Apple claims various things about their certification (FIPS 140 lowest level), yet the core ECC implementation does not validate points and has a timing+control flow side channel. I'm sure we could find other problems with certified products if we tried. > > What do we have? > - We have a rather old CC EAL4+ certificate from January 2004 and a > Assurance Continuity Maintenance Report from September 2004. > (BTW, the first link to the Maintenance Report on your web site is > wrong. The mirror link works.) > > This certificate claims that the smart card hardware RNG TOGETHER > WITH ACCOMPANYING SOFTWARE provides a class P2 high physical true RNG > according to AIS 31, Version 1, 25.09.2001. The relevant technical > guide is Killmann/Schindler: A proposal for: Functionality classes and > evaluation methodology for true (physical) random number generators, > Version 3.1, 25.09.2001. > > - Then we have your nice research paper and talks from the mid/end of > 2013. > > Of course, there was a major problem with this product. But this > doesn't mean necessarily that there is a major problem with the > certification / evaluation process. > > P2 high requires that there are a) a startup test, b) a total failure > test, and c) a continuous on-line test. This is not surprising, but the > big difference, e.g., to NIST FIPS 140-2 is, that there must be a > so-called stochastic model, i.e., a ``Comprehensible and plausible > description of a mathematical model of the physical noise source and > the statistical properties of the digitised noise signal sequence > derived from it.=C2=B4=C2=B4 The on-line test has to be adapted specifica= lly to > the stochastic model. Commonly this amounts in understanding your > entropy source (and not just passing statistical tests) and providing, > at best, lower bounds on the entropy. Or as Victor Fischer puts it: > ``It is quite easy to design a TRNG that will let the statistical > tests pass ... but it is much more difficult to know where the > randomness comes from and how much true randomness is there.=C2=B4=C2=B4 > > P2 high DOES NOT require that there is a cryptographic > post-processing of the internal random sequence (non-cryptographic > post-processing as von Neumann or Peres procedure does not count here). > > So, obviously the mentioned product failed to implement an effective > total failure test and/or an effective continuous on-line test. > > The situation with RNGs is completely different with NIST FIPS. > Usually NIST is focused much more on deterministic RNGs, see the > infamous SP800-90A. Up to the publication of FIPS drafts SP800-90B and > SP800-90C you could not find much on entropy sources and their > evaluation. > > (And with the last two FIPS drafts I see some problems, too. For > example, an entropy defect of order 2^{-64} can NEVER be estimated > experimentally. In AIS 31, we have now the requirement of an entropy > defect of less than 3E-03, practically E-4..E-5, i.e., average Shannon > entropy per bit exceeds 0.997. And for this estimate 2^30 random bits > are recommended to test. The full entropy sources from SP800-90B/C > would require such HUGE random data for estimating the defect > 2^{-64}=3D5E-20 that this is practically impossible.) > > At your website you wrote regarding FIPS mode or non-FIPS mode: > ``However, this did not result in HICOS failing certification; it > merely resulted in extra words on the certificate saying that the > certificate was valid only when the card was "operated in FIPS > mode".=C2=B4=C2=B4 > > I presume that the card has been CC certified in FIPS mode. For CC we > only have > > ``The confirmed assurance package is only valid on the condition that > - all stipulations regarding generation, configuration and > operation, as given in the following report, are observed, > - the product is operated in the environment described, where > specified in the following report.=C2=B4=C2=B4 > > This means, that the card has not been used properly, i.e., the > external preconditions have not been fulfilled. So, no problem with CC > certificate or CC process, but with individual usage. > > By the way, the above mentioned certificate does only apply to the > smart card hardware. Usually, you either have a manufacturer library > for RSA with certificate or another CC certificate for operating > system and RSA application. I could not find anything like this at > your website. So the manufacturer/producer of the RSA application and > their evalution lab/certification THESE WERE THE PEOPLE TO BLAIM, NOT > THE CC EVAL LABS OF THE HARDWARE. Why? The software can't make random numbers without the hardware. The configuration issue is part of the problem: it's clear that people don't understand the limits of the certification, or how to ensure they are configuring things correctly. Taiwan had every incentive to get this right and couldn't. > > However, even I have some criticism on Common Criteria. It is much too > easy to define a Target of Evaluation that is too narrow, sometimes > almost meaningless. For example, when I see an IPsec product evaluated > where the public-key and the symmetric key coprocessors are not in the > TOE. Or, when the organizational security policies and assumptions are > too wide, even unrealistic. But this just means: The statement ``CC > certification exists=C2=B4=C2=B4 is not very meaningful alone, one has to= read > the complete security problem definition. > > Another problem I sometimes have with CC is their reliance on keeping > design documents confidential and getting AVA points. I do not > advocate to publish everything, but one should not get any points for > confidential user manuals, etc. > >> http://smartfacts.cr.yp.to/analysis.html analyzes five contributing >> factors to this security disaster---low-quality hardware RNG, inadequate >> sanity checks, no run-time sanity checks, no post-processing, and >> inadequate initial response---and the complete failure of certification >> to prevent the disaster from occurring. > > I admit the low-quality RNG and the missing/ineffective tests. > However, I do not see ``the complete failure of certification=C2=B4=C2=B4= , only > then when you can prove that a smart card used in the CC specified > mode has been compromised. > > Further, the analyzed product was rather old. This is no excuse and > shall not impair your results. But current AIS 20/31 standards, > effective since 2011, see Killmann/Schindler: A proposal for: > Functionality classes for random number generators, version 2.0, > September 18, 2011, recommend a class PTG.3 generator, e.g., a hybrid > physical true random number generator, basically a P2 high (now PTG.2) > with cryptographic post-processing (DRG.3). This type of RNG is/will > be REQUIRED for all German so-called qualified digital signatures, see > BSI Algorithmenkatalog 2014 (=C3=9Cbersicht =C3=BCber geeignete Algorithm= en, > Bekanntmachung zur elektronischen Signatur, Bundesnetzagentur). > > A PTG.3 RNG would have made the attack impossible. Nevertheless, > your result from last year provided one good reasoning for me > explaining the need of PTG.3 RNGs to our non-technical management > (besides certification requirement facts) :-) > > As you may have noticed I have only written about Common Criteria > certification. This is the process I have the most experience with. > FIPS certification in general, for example, FIPS 140-2 and RNG > certification specifically, for example, SP800-90A, are completely > different. FIPS 140-2 is, in my opinion, rather old nowadays. FIPS > 140-3 drafts, even they more than 5 years old now, had some good > ideas. Specifically with respect to side-channel evaluation. > > This leads us back to the original problem: Elliptic Curve > Cryptography and Certification. Dan, I am sure you know the BSI > Guidelines AIS 46 Minimum Requirements for Evaluating Side-Channel > Attack Resistance of Elliptic Curve Implementations as Tanja was one > of the co-authors. All that I'm saying is that one should consider, at > least for applications in hostile environments, the complete set of > attacks and countermeasures. And not only timing attacks. Most applications are not smart-cards. I don't see why we need to take a 50% performance hit on every TLS connection, for devices that are generally deployed in specialized systems anyway. The argument that some devices will need to do this doesn't convince me either: why would they need to connect to arbitrary websites? Even if those are true, what's wrong with the Brainpool curves for this purpose? The quality of certification has nothing to do with this question: it's entirely a question about the relevance of power-side channel attacks to most ECC deployments. > > Common criteria may not be sufficient in some areas. But at least, it > is better than nothing (or everything else we have). Our aim as > security researchers/practitioners should be to improve that process > and not to discredit it. > > Of course, in a perfect university world it would be fine to disclose > anything > > http://smartfacts.cr.yp.to/faq.html: >> We strongly recommend that the chip manufacturer publicly disclose >> full details of the RNG hardware in use and provide copies of the RNG >> hardware to researchers, allowing a thorough characterization of the >> physical failures of the RNG hardware on the 1024-bit cards and an >> analysis of the differences in the RNG hardware on the 2048-bit cards. > > and it would even interest me, personally. But what would happen if > you find something in millions of enrolled cards and cannot fix it > immediately? So, there are some differences between university and > industry. > >> You can't reasonably ask CFRG to "trust this certification in >> principle". > > What I do ask CFRG, is to consider established security evaluation as > Common Criteria as ONE BLOCK OF BUILDING TRUST. > > And what I would like to ask CFRG further, is to consider the > different, more general ``performance=C2=B4=C2=B4 requirements as formula= ted in > http://www.ietf.org/mail-archive/web/cfrg/current/msg05105.html > > Regards, > > Torsten > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg --=20 "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Tue Oct 7 08:09:53 2014 Return-Path: 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 E30F91ACE06 for ; Tue, 7 Oct 2014 08:09:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 i3jAPGVKEare for ; Tue, 7 Oct 2014 08:09:32 -0700 (PDT) Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 431071ACDFC for ; Tue, 7 Oct 2014 08:09:31 -0700 (PDT) Received: by mail-la0-f49.google.com with SMTP id q1so6608569lam.36 for ; Tue, 07 Oct 2014 08:09:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=p8/WlJPR/mksc0TTa3LIyzozVaE87DzQ1QSoa7fcvL8=; b=bBmt7Ea/QZ2jS9gqcwOI2g6cZVgo11ISdlSHlwnDQKh2u/5r9fe2eWqhVboh7NFQcs +3Z2uRRsg87my8pXCAUzCguGNrbmUw03AXPqbKK3wTRiRMn4BhjLPmSemeX32O2NefV0 awz57J6VJZLitnAvsr7mIadPodkvTHD3NXUbWb2YawhpiMFQkqnxhGYWmY7TSvIs5PhF 5Q56/lqizZITXBtyEX9QZNfzx+XrE7EiBc7zTjsh8LQEjNQfZ8aBy/ZBxn+ZUhCfKQ7S SXNgGeYoZgOmeo1LJTUzyWI0ddLQYTEAdzuSQsPb4wqAIxgmfyQvs/h8ejoxHiduNzBa XOYQ== X-Received: by 10.112.151.99 with SMTP id up3mr4642881lbb.45.1412694569367; Tue, 07 Oct 2014 08:09:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.218.145 with HTTP; Tue, 7 Oct 2014 08:09:09 -0700 (PDT) In-Reply-To: References: <542D48CD.9060404@isode.com> From: David Leon Gil Date: Tue, 7 Oct 2014 11:09:09 -0400 Message-ID: To: Yoav Nir Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/FudzA3nK3-UJmIu3HH0FoAVCCXc Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] RGLC on draft-irtf-cfrg-chacha20-poly1305-01.txt X-BeenThere: cfrg@irtf.org 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: Tue, 07 Oct 2014 15:09:44 -0000 (This I-D is really excellent; my comments are minor nits. I support moving this along to RFC status ASAP.) On Mon, Oct 6, 2014 at 4:13 AM, Yoav Nir wrote: > - At least two implementations were done by following the draft (and the > test vectors checked out) Re A.2: There are still no ChaCha20 test-vectors to ensure that implementations use the correct counter rule. I.e., what happens when the 32-bit block counter is 2^32 - 1? It is rather critical that implementations never reuse the keystream for block 0 in this construction. I'd suggest, in light of the note in 2.8.1, that simply letting the counter mode be non-separated is simplest. (This has the advantage that it retains compatibility with the original definition.[*]) (I have test-vectors for either option; but the authors would need to pick one...) -- Perhaps add a reference to the more recent paper by Namprempre et al., "Reconsidering generic composition" https://eprint.iacr.org/2014/206 (I believe this would be a N2-type scheme in their terminology.) [*] I too think 2^32 blocks is not a large amount of data. From nobody Tue Oct 7 08:47:10 2014 Return-Path: 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 1F8691ACE1C for ; Tue, 7 Oct 2014 08:47:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.821 X-Spam-Level: X-Spam-Status: No, score=-1.821 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779] 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 gWuTkcCS0NOR for ; Tue, 7 Oct 2014 08:47:06 -0700 (PDT) Received: from mail-pd0-f182.google.com (mail-pd0-f182.google.com [209.85.192.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F6BE1A6FC0 for ; Tue, 7 Oct 2014 08:47:06 -0700 (PDT) Received: by mail-pd0-f182.google.com with SMTP id y10so5195636pdj.41 for ; Tue, 07 Oct 2014 08:47:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=vjGesYgPKAyRUA/CR5Jy2bLXOem5cuti06vihDIYFyE=; b=dJ1Q8XoBNltfDP9uWvrNetkJ0m09XRTuPy34/iC3kUKv0O6hfWZaGE5L+X8XSTY0j/ mhHLTLByu2RoLDxnnhUOPWc6Py0ZxuL79/3BTYtFcKh8xn9CbSU9jlPSwFihVBYXsOGO 09LFXXREF1E+ZmaqMZRwvMl0MwRRt98l3ZEW4uniifh0aYtJZHAcbNdbdvnmZY6DHeuE T8cXKCaN4+qw4sYJ5xpneG4KIi78CIRFm9m7g0GUWR5Ztt4vknrq0/fkx4nUJA6T7+0n gMFO2JlK18RbH7ughkQPXg8uVD5DZmC84CTmcbsXgrFlpeDPsnqHYuBRkIOgyZ+5+tIn 4g5g== X-Gm-Message-State: ALoCoQnyVMFJ9XE7fH2vMK3DhoVg2sf/8CtFVRqiRviizgHhH9cACeYfZ5z1BcaQEB5UnyARBVFq X-Received: by 10.68.129.9 with SMTP id ns9mr4478436pbb.25.1412696825761; Tue, 07 Oct 2014 08:47:05 -0700 (PDT) Received: from [192.168.1.100] (c-76-20-47-101.hsd1.ca.comcast.net. [76.20.47.101]) by mx.google.com with ESMTPSA id p1sm14240446pdr.15.2014.10.07.08.47.02 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 07 Oct 2014 08:47:04 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ted Krovetz In-Reply-To: Date: Tue, 7 Oct 2014 08:47:01 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <5571619C-3D05-4E2F-A3A0-22C0A6FC1DD4@krovetz.net> References: <542D48CD.9060404@isode.com> To: "cfrg@irtf.org" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/WHkfCbH6cTn-ziaXrmSxGQH1eG8 Subject: Re: [Cfrg] RGLC on draft-irtf-cfrg-chacha20-poly1305-01.txt X-BeenThere: cfrg@irtf.org 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: Tue, 07 Oct 2014 15:47:08 -0000 > [*] I too think 2^32 blocks is not a large amount of data. If one views the chacha core as a PRF from 384 bits to 512 bits, then = there are all sorts of ways to increase the lengths of the internal = counter and/or external nonce. Here are a couple different data layouts = for chacha core input that would allow longer counters. You could shorten the key: 224 bits of key || 96 bits of nonce || 64 bits of counter Or, you could mix the key and nonce (allowing 16 byte nonces): first 192 bits of key || ((last 64 bits of key) xor (first 64 bits of nonce)) || last 64 bits of nonce || 64 bits of counter If one uses only the "last 64 bits of nonce", this second suggestion = becomes chacha as originally specified. -Ted= From nobody Tue Oct 7 09:09:00 2014 Return-Path: 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 9F7501A01A8 for ; Tue, 7 Oct 2014 09:08:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.95 X-Spam-Level: X-Spam-Status: No, score=-1.95 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] 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 x88Jv43j7tdB for ; Tue, 7 Oct 2014 09:08:55 -0700 (PDT) Received: from apfel.src-bonn.de (apfel.src-bonn.de [78.35.41.6]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBFE41A01A5 for ; Tue, 7 Oct 2014 09:08:54 -0700 (PDT) Received: from imail (imail.src-gmbh.lan [192.168.8.3]) by apfel.src-bonn.de (Postfix) with SMTP id 74F11959A; Tue, 7 Oct 2014 18:08:51 +0200 (CEST) Message-ID: <54341010.8050207@src-gmbh.de> Date: Tue, 07 Oct 2014 18:08:48 +0200 From: Dirk Feldhusen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Watson Ladd , =?UTF-8?B?VG9yc3RlbiBTY2jDvHR6ZQ==?= References: <20141003111024.20324.qmail@cr.yp.to> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/OMEyOaaY7RcUcSHnbBsBZ1KOyvU Cc: "cfrg@irtf.org" , "D. J. Bernstein" Subject: Re: [Cfrg] Trusting government certifications of cryptography X-BeenThere: cfrg@irtf.org 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: Tue, 07 Oct 2014 16:08:58 -0000 Am 07.10.2014 16:27, schrieb Watson Ladd: > On Tue, Oct 7, 2014 at 1:15 AM, "Torsten Sch=C3=BCtze" > wrote: >> On 10/3/14, 4:10 AM, D. J. Bernstein wrote: >>> Torsten Schuetze writes: >>>> Smart cards, i.e., its coprocessors and its ECC software >>>> implementations, are always certified by Common Criteria, usually wi= th >>>> rather high assurance level. Don't you trust this certification in >>>> principle? >>> http://smartfacts.cr.yp.to explains how we factored 184 RSA-1024 keys= >>> from Taiwan's national "Citizen Digital Certificate" database. As you= >>> can see from http://smartfacts.cr.yp.to/cert.html, these keys were >>> generated by government-issued smart cards that advertised all of the= >>> usual Common Criteria and FIPS certifications from BSI, NIST, and CSE= =2E >> Dan, >> >> you may remember that we discussed this RNG topic at the eve of last >> years CRYPTO at Santa Barbara. >> >> Following the discussion in this and the other threads on CFRG, I >> should have better re-phrased my original question into: Do you >> distrust Common Criteria (or government certification, as you call it)= >> in principle? Background of the question was to find out where does >> the individual trust boundary of Alyssa run. >> >> Of course, I cannot (and I will not) speak on behalf of BSI or another= >> ``government agency=C2=B4=C2=B4 or on behalf of an independent evaluat= ion lab as >> T-Systems GEI or on behalf of any other official lab/agency. But >> believe me, these presentations/these revelations have been discussed >> thoroughly inside the German RNG community. > This is not an isolated incident. Apple claims various things about > their certification (FIPS 140 lowest level), yet the core ECC > implementation does not validate points and has a timing+control flow > side channel. I'm sure we could find other problems with certified > products if we tried. OK, by a certifcation it cannot be guaranteed that the product is unbreakable. The statement provides an estimate for the minimal effort which is required to break it. I am no FIPS expert, but to my opinion this example shows that a low level evaluation is not an adequate measure to detect vulnerabilities on implementation level. Contrariwise a CC EAL4 evaluation (or higher) requires the evaluator to get access to the source code by ADV_IMP. > >> What do we have? >> - We have a rather old CC EAL4+ certificate from January 2004 and a >> Assurance Continuity Maintenance Report from September 2004. >> (BTW, the first link to the Maintenance Report on your web site is >> wrong. The mirror link works.) >> >> This certificate claims that the smart card hardware RNG TOGETHER >> WITH ACCOMPANYING SOFTWARE provides a class P2 high physical true RNG >> according to AIS 31, Version 1, 25.09.2001. The relevant technical >> guide is Killmann/Schindler: A proposal for: Functionality classes and= >> evaluation methodology for true (physical) random number generators, >> Version 3.1, 25.09.2001. >> >> - Then we have your nice research paper and talks from the mid/end of >> 2013. >> >> Of course, there was a major problem with this product. But this >> doesn't mean necessarily that there is a major problem with the >> certification / evaluation process. >> >> P2 high requires that there are a) a startup test, b) a total failure >> test, and c) a continuous on-line test. This is not surprising, but th= e >> big difference, e.g., to NIST FIPS 140-2 is, that there must be a >> so-called stochastic model, i.e., a ``Comprehensible and plausible >> description of a mathematical model of the physical noise source and >> the statistical properties of the digitised noise signal sequence >> derived from it.=C2=B4=C2=B4 The on-line test has to be adapted specif= ically to >> the stochastic model. Commonly this amounts in understanding your >> entropy source (and not just passing statistical tests) and providing,= >> at best, lower bounds on the entropy. Or as Victor Fischer puts it: >> ``It is quite easy to design a TRNG that will let the statistical >> tests pass ... but it is much more difficult to know where the >> randomness comes from and how much true randomness is there.=C2=B4=C2=B4= >> >> P2 high DOES NOT require that there is a cryptographic >> post-processing of the internal random sequence (non-cryptographic >> post-processing as von Neumann or Peres procedure does not count here)= =2E >> >> So, obviously the mentioned product failed to implement an effective >> total failure test and/or an effective continuous on-line test. >> >> The situation with RNGs is completely different with NIST FIPS. >> Usually NIST is focused much more on deterministic RNGs, see the >> infamous SP800-90A. Up to the publication of FIPS drafts SP800-90B and= >> SP800-90C you could not find much on entropy sources and their >> evaluation. >> >> (And with the last two FIPS drafts I see some problems, too. For >> example, an entropy defect of order 2^{-64} can NEVER be estimated >> experimentally. In AIS 31, we have now the requirement of an entropy >> defect of less than 3E-03, practically E-4..E-5, i.e., average Shannon= >> entropy per bit exceeds 0.997. And for this estimate 2^30 random bits >> are recommended to test. The full entropy sources from SP800-90B/C >> would require such HUGE random data for estimating the defect >> 2^{-64}=3D5E-20 that this is practically impossible.) >> >> At your website you wrote regarding FIPS mode or non-FIPS mode: >> ``However, this did not result in HICOS failing certification; it >> merely resulted in extra words on the certificate saying that the >> certificate was valid only when the card was "operated in FIPS >> mode".=C2=B4=C2=B4 >> >> I presume that the card has been CC certified in FIPS mode. For CC we >> only have >> >> ``The confirmed assurance package is only valid on the condition that >> - all stipulations regarding generation, configuration and >> operation, as given in the following report, are observed, >> - the product is operated in the environment described, where >> specified in the following report.=C2=B4=C2=B4 >> >> This means, that the card has not been used properly, i.e., the >> external preconditions have not been fulfilled. So, no problem with CC= >> certificate or CC process, but with individual usage. >> >> By the way, the above mentioned certificate does only apply to the >> smart card hardware. Usually, you either have a manufacturer library >> for RSA with certificate or another CC certificate for operating >> system and RSA application. I could not find anything like this at >> your website. So the manufacturer/producer of the RSA application and >> their evalution lab/certification THESE WERE THE PEOPLE TO BLAIM, NOT >> THE CC EVAL LABS OF THE HARDWARE. > Why? The software can't make random numbers without the hardware. The > configuration issue is part of the problem: it's clear that people > don't understand the limits of the certification, or how to ensure > they are configuring things correctly. Taiwan had every incentive to > get this right and couldn't. The information how to use the product in a secure way is given in the guidance which has to be delivered together with the product. The smart card hardware is not able to make every possible software on it secure, so you need also a certificate for the RSA implementation, which implies that the software uses the hardware properly. > >> However, even I have some criticism on Common Criteria. It is much too= >> easy to define a Target of Evaluation that is too narrow, sometimes >> almost meaningless. For example, when I see an IPsec product evaluated= >> where the public-key and the symmetric key coprocessors are not in the= >> TOE. Or, when the organizational security policies and assumptions are= >> too wide, even unrealistic. But this just means: The statement ``CC >> certification exists=C2=B4=C2=B4 is not very meaningful alone, one has= to read >> the complete security problem definition. >> >> Another problem I sometimes have with CC is their reliance on keeping >> design documents confidential and getting AVA points. I do not >> advocate to publish everything, but one should not get any points for >> confidential user manuals, etc. >> >>> http://smartfacts.cr.yp.to/analysis.html analyzes five contributing >>> factors to this security disaster---low-quality hardware RNG, inadequ= ate >>> sanity checks, no run-time sanity checks, no post-processing, and >>> inadequate initial response---and the complete failure of certificati= on >>> to prevent the disaster from occurring. >> I admit the low-quality RNG and the missing/ineffective tests. >> However, I do not see ``the complete failure of certification=C2=B4=C2= =B4, only >> then when you can prove that a smart card used in the CC specified >> mode has been compromised. >> >> Further, the analyzed product was rather old. This is no excuse and >> shall not impair your results. But current AIS 20/31 standards, >> effective since 2011, see Killmann/Schindler: A proposal for: >> Functionality classes for random number generators, version 2.0, >> September 18, 2011, recommend a class PTG.3 generator, e.g., a hybrid >> physical true random number generator, basically a P2 high (now PTG.2)= >> with cryptographic post-processing (DRG.3). This type of RNG is/will >> be REQUIRED for all German so-called qualified digital signatures, see= >> BSI Algorithmenkatalog 2014 (=C3=9Cbersicht =C3=BCber geeignete Algori= thmen, >> Bekanntmachung zur elektronischen Signatur, Bundesnetzagentur). >> >> A PTG.3 RNG would have made the attack impossible. Nevertheless, >> your result from last year provided one good reasoning for me >> explaining the need of PTG.3 RNGs to our non-technical management >> (besides certification requirement facts) :-) >> >> As you may have noticed I have only written about Common Criteria >> certification. This is the process I have the most experience with. >> FIPS certification in general, for example, FIPS 140-2 and RNG >> certification specifically, for example, SP800-90A, are completely >> different. FIPS 140-2 is, in my opinion, rather old nowadays. FIPS >> 140-3 drafts, even they more than 5 years old now, had some good >> ideas. Specifically with respect to side-channel evaluation. >> >> This leads us back to the original problem: Elliptic Curve >> Cryptography and Certification. Dan, I am sure you know the BSI >> Guidelines AIS 46 Minimum Requirements for Evaluating Side-Channel >> Attack Resistance of Elliptic Curve Implementations as Tanja was one >> of the co-authors. All that I'm saying is that one should consider, at= >> least for applications in hostile environments, the complete set of >> attacks and countermeasures. And not only timing attacks. > Most applications are not smart-cards. I don't see why we need to take > a 50% performance hit on every TLS connection, for devices that are > generally deployed in specialized systems anyway. The argument that > some devices will need to do this doesn't convince me either: why > would they need to connect to arbitrary websites? Even if those are > true, what's wrong with the Brainpool curves for this purpose? > > The quality of certification has nothing to do with this question: > it's entirely a question about the relevance of power-side channel > attacks to most ECC deployments. To exclude the possibilty of power or EM side channel you need the assumption that the attacker has no physical access to the device. As I understand Torsten the main problem here are special primes which are harder to secure against such side channel leakage. > >> Common criteria may not be sufficient in some areas. But at least, it >> is better than nothing (or everything else we have). Our aim as >> security researchers/practitioners should be to improve that process >> and not to discredit it. >> >> Of course, in a perfect university world it would be fine to disclose >> anything >> >> http://smartfacts.cr.yp.to/faq.html: >>> We strongly recommend that the chip manufacturer publicly disclose >>> full details of the RNG hardware in use and provide copies of the RNG= >>> hardware to researchers, allowing a thorough characterization of the >>> physical failures of the RNG hardware on the 1024-bit cards and an >>> analysis of the differences in the RNG hardware on the 2048-bit cards= =2E >> and it would even interest me, personally. But what would happen if >> you find something in millions of enrolled cards and cannot fix it >> immediately? So, there are some differences between university and >> industry. >> >>> You can't reasonably ask CFRG to "trust this certification in >>> principle". >> What I do ask CFRG, is to consider established security evaluation as >> Common Criteria as ONE BLOCK OF BUILDING TRUST. >> >> And what I would like to ask CFRG further, is to consider the >> different, more general ``performance=C2=B4=C2=B4 requirements as form= ulated in >> http://www.ietf.org/mail-archive/web/cfrg/current/msg05105.html >> >> Regards, >> >> Torsten >> >> _______________________________________________ >> Cfrg mailing list >> Cfrg@irtf.org >> http://www.irtf.org/mailman/listinfo/cfrg > > From nobody Tue Oct 7 09:49:15 2014 Return-Path: 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 E3E0C1ACE24 for ; Tue, 7 Oct 2014 09:49:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 Ge2jF4hRgeje for ; Tue, 7 Oct 2014 09:49:12 -0700 (PDT) Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 526291ACDA0 for ; Tue, 7 Oct 2014 09:49:12 -0700 (PDT) Received: by mail-wg0-f45.google.com with SMTP id m15so9738302wgh.4 for ; Tue, 07 Oct 2014 09:49:11 -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 :content-transfer-encoding:message-id:references:to; bh=NIElr6Cvae9mbZsUsQX17hi6C/a4/MejPUmcLWuAP1E=; b=nXUlnUwinvV7XjzLj7cftITvJjREqQIm5S+xTt/8c3IoDwuJRJTKannzSmBzLojmf1 9pc33jQjW2NlMPxRlcbiK5pST7dl3niKj38D6nqPtAqHEZfOm+W9MDOMS6lhOkYTDqPz 5Z0wsGfTItb8PkBTEAj6I4ZyZhsiNEkL/+xv+KHU3bfO320Co1hR7GgRxTi1IFFZ+wWj /QYupa3+30d+iKU7OCKq0YeR9u1j84hvV+bshC5tPgk6ci/K7tLEPk7qIu7EzAZo6b3i WcPcnYFePmEJUqZzvv/NRuVuTioLn2T8yrj/70/ieoIJRhvv1regwjDRZqUk4l+xLcAo EANQ== X-Received: by 10.194.206.103 with SMTP id ln7mr6261479wjc.30.1412700550967; Tue, 07 Oct 2014 09:49:10 -0700 (PDT) Received: from [192.168.1.104] (IGLD-84-228-54-144.inter.net.il. [84.228.54.144]) by mx.google.com with ESMTPSA id gt7sm15377846wib.18.2014.10.07.09.49.10 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 07 Oct 2014 09:49:10 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Yoav Nir In-Reply-To: Date: Tue, 7 Oct 2014 19:49:08 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <7C2D2B7D-CB2A-4541-88B8-49B5CCC64CA8@gmail.com> References: <542D48CD.9060404@isode.com> To: James Cloos X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/wF1UcCVR0cy8z2De3qrTUac1aug Cc: cfrg@irtf.org Subject: Re: [Cfrg] RGLC on draft-irtf-cfrg-chacha20-poly1305-01.txt X-BeenThere: cfrg@irtf.org 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: Tue, 07 Oct 2014 16:49:14 -0000 Hi, James The 96/32 split is dictated by the recommendation in RFC 5116. While any = sane use of symmetric keys will never use the same keys for either 2^96 = messages or 2^64 messages, being able to safely split the range of = acceptable nonces is an advantage. Neither regular IPsec nor regular TLS = need this, but multi-sender IPsec (GDOI) and multi-sender DTLS can = benefit. As it is, the current TLS 1.3 draft defines AEAD ciphersuites as those = described by RFC 5116. So yes, it=92s possible to decide on a 64-bit = nonce and state clearly in both this draft and the draft for = ChaCha20-Poly1305 for TLS that we=92ve decided to ignore the = recommendation in 5116, but I don=92t think that=92s a good idea. Yoav On Oct 7, 2014, at 12:25 AM, James Cloos wrote: > [I thought I sent on this subect weeks ago, but I cannot find it in > the archives, ... -JimC] >=20 > I have to object to defaulting to a 96/32 split. >=20 > The rfc should specify Dan's 64/64 split as default, and only offer > 96/32 as an option. >=20 > Chacha isn't only useful for in-flight encryption. One should not > have to bother with multiple keys or IVs to encrypt large files. > And 128 Gigs is not all that large for things like backups (tar, > cpio, et cetera), disk images, some AV files and the like. >=20 > It is very reasonable to presume that larger and larger files will > become more and more common as the storage devices sizes and demand > for higher resolution media files each continue to escalate. >=20 > The RFC should be a valid reference for all potential uses of chacha. >=20 > Even in the IETF, OpenPGP encrypts files at rest. >=20 > Secsh should continue to use 64/64; OpenPGP and SMIME should add = chacha > with 64/64; I would prefer 64/64 for TLS. >=20 > But if IPSEC insists on 96/32, that should be an option, not the = primary > scenario. >=20 > -JimC > --=20 > James Cloos OpenPGP: 0x997A9F17ED7DAEA6 >=20 From nobody Tue Oct 7 09:54:56 2014 Return-Path: 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 D16AD1ACE7D for ; Tue, 7 Oct 2014 09:54:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 CXNjGUFCRZjh for ; Tue, 7 Oct 2014 09:54:44 -0700 (PDT) Received: from emh07.mail.saunalahti.fi (emh07.mail.saunalahti.fi [62.142.5.117]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD2D31ACE7E for ; Tue, 7 Oct 2014 09:54:43 -0700 (PDT) Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh07.mail.saunalahti.fi (Postfix) with ESMTP id DCC183FC2; Tue, 7 Oct 2014 19:54:40 +0300 (EEST) Date: Tue, 7 Oct 2014 19:54:39 +0300 From: Ilari Liusvaara To: James Cloos Message-ID: <20141007165439.GA28933@LK-Perkele-VII> References: <542D48CD.9060404@isode.com> <5433F28C.9060501@elzevir.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/Wg23v12W3gM2rkGaEZoNorzhnOU Cc: Manuel =?utf-8?B?UMOpZ291cmnDqS1Hb25uYXJk?= , "cfrg@irtf.org" Subject: Re: [Cfrg] RGLC on draft-irtf-cfrg-chacha20-poly1305-01.txt X-BeenThere: cfrg@irtf.org 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: Tue, 07 Oct 2014 16:54:48 -0000 On Tue, Oct 07, 2014 at 10:22:23AM -0400, James Cloos wrote: > > Dan's paper on aes/poly1305 makes it look like a better choice than gcm, > at least. Maybe also better than ccm, et alia. Depends. Poly1305 should be faster than CCM and unaccelerated GCM (plus that one is really nasty to implement without side channels out the wazoo). HW- accelerated GCM is faster and simpler than poly1305. There are some platforms that do have HW AES but no HW GCM. But those are fairly rare. AES/Poly1305 would be useful on such. Some other things: - GCM and original Poly1305(-AES) reuse R (this AEAD construct doesn't). - Poly1305 is independent of encryption blocksize, whereas GCM is for 128-bit ciphers only (it could be generalized to other sizes, but IIRC, it slows down as blocksize increases). -Ilari From nobody Tue Oct 7 09:54:57 2014 Return-Path: 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 ED1091ACE7E for ; Tue, 7 Oct 2014 09:54:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 Nu72tuycd6cL for ; Tue, 7 Oct 2014 09:54:47 -0700 (PDT) Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71B131ACE80 for ; Tue, 7 Oct 2014 09:54:47 -0700 (PDT) Received: by mail-lb0-f174.google.com with SMTP id p9so6514346lbv.19 for ; Tue, 07 Oct 2014 09:54:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=keOXf3kYaxfskgv6bOGslj+QbViUy0oiRJKrjiJaHck=; b=JmVOtBnVxlBFzG2s59ZRchhzKArqG0eJgm5EtgpbScvEc6k1ShUY2EObQba/uamOeI QmNEI7j7+7zqBZZaovruE8ULXLJfcd2mh1DSFMLd5w2GQc1TbGGzUCYi4azexwi8LbM2 YQUAb6+2tuUIomwHkI274aXbwdTy5785gTyQj8NJw9YdOWjX/drIMeTY5ZD8+ZblLHw6 ZcH2p39P8h0yyfc39/EGVfRsU5kPjzPKNGPV4qTsSyyo01YJQePTAyEOF5mkhKblTPJf df4MXsiog3GO3W8Da+m9TTPzhDhAD4hdp8trVuJzeHHUQByHjY8SsHdfeCdwOkyBfYAu Q46A== X-Received: by 10.152.28.167 with SMTP id c7mr5446996lah.27.1412700885681; Tue, 07 Oct 2014 09:54:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.218.145 with HTTP; Tue, 7 Oct 2014 09:54:25 -0700 (PDT) In-Reply-To: <5571619C-3D05-4E2F-A3A0-22C0A6FC1DD4@krovetz.net> References: <542D48CD.9060404@isode.com> <5571619C-3D05-4E2F-A3A0-22C0A6FC1DD4@krovetz.net> From: David Leon Gil Date: Tue, 7 Oct 2014 12:54:25 -0400 Message-ID: To: Ted Krovetz Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/4Z_PaQPWD_35TSZ0qwP1zgrvSvE Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] RGLC on draft-irtf-cfrg-chacha20-poly1305-01.txt X-BeenThere: cfrg@irtf.org 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: Tue, 07 Oct 2014 16:54:52 -0000 On Tue, Oct 7, 2014 at 11:47 AM, Ted Krovetz wrote: > If one views the chacha core as a PRF from 384 bits to 512 bits, then there are all sorts of ways to increase the lengths of the internal counter and/or external nonce. Is there a reason not to define an "XChaCha" by analogy with XSalsa? See http://cr.yp.to/snuffle/xsalsa-20110204.pdf (The situation seems trickier for narrow PRPs, but ChaCha and Salsa are both PRFs of the form you describe.) From nobody Tue Oct 7 09:55:47 2014 Return-Path: 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 9B3AE1ACE95 for ; Tue, 7 Oct 2014 09:55:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.455 X-Spam-Level: *** X-Spam-Status: No, score=3.455 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, RDNS_DYNAMIC=0.982, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no 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 DayFBNKxAuhd for ; Tue, 7 Oct 2014 09:55:35 -0700 (PDT) Received: from aspartame.shiftleft.org (199-116-74-168-v301.PUBLIC.monkeybrains.net [199.116.74.168]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74B771ACE7D for ; Tue, 7 Oct 2014 09:55:35 -0700 (PDT) Received: from [192.168.1.129] (unknown [192.168.1.1]) by aspartame.shiftleft.org (Postfix) with ESMTPSA id D8AEBF2208; Tue, 7 Oct 2014 09:54:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=shiftleft.org; s=sldo; t=1412700853; bh=tPtdusKbBHPXD1xGVhTczcVSUVnW3fJBVuP2OrPK78U=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=E25tv1toT7CP8otBzviaTFiLGPm6mzeCzDwuj+cpDtWvD2bxaigu+2xCTNQjMJLAQ 8pGNCjyDdT14aaZxoeM/Dn2e5X6X1kTJ/2sfEPTxA/qAxtQAblf/oSMEJXA6KdnP3F clWR5qLUIahcAq3PCPPCXGZ/VbDhIGWddj7ROeIA= Content-Type: multipart/alternative; boundary="Apple-Mail=_A8D39003-FF47-46FB-AED3-C180FC9294EF" Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1988\)) From: Michael Hamburg In-Reply-To: <54341010.8050207@src-gmbh.de> Date: Tue, 7 Oct 2014 09:55:33 -0700 Message-Id: References: <20141003111024.20324.qmail@cr.yp.to> <54341010.8050207@src-gmbh.de> To: Dirk Feldhusen X-Mailer: Apple Mail (2.1988) Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/rgYUPUSiDZ1itTNFxKwkR6HT7As Cc: "cfrg@irtf.org" , "D. J. Bernstein" Subject: Re: [Cfrg] Trusting government certifications of cryptography X-BeenThere: cfrg@irtf.org 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: Tue, 07 Oct 2014 16:55:37 -0000 --Apple-Mail=_A8D39003-FF47-46FB-AED3-C180FC9294EF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Oct 7, 2014, at 9:08 AM, Dirk Feldhusen = wrote: > To exclude the possibilty of power or EM side channel you need the > assumption that the attacker has no physical access to the device. > As I understand Torsten the main problem here are special primes which > are harder to secure against such side channel leakage. Are they actually harder to secure (eg, requiring new countermeasures), = or just slower on hardware which doesn=E2=80=99t accelerate the special = prime (eg, by requiring longer blinding factors)? =E2=80=94 Mike= --Apple-Mail=_A8D39003-FF47-46FB-AED3-C180FC9294EF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Oct 7, 2014, at 9:08 AM, Dirk Feldhusen <dirk.feldhusen@src-gmbh.de> = wrote:

To exclude the = possibilty of power or EM side channel you need the
assumption that the attacker has no physical = access to the device.
As I understand Torsten = the main problem here are special primes which
are harder to secure against such side channel = leakage.

Are = they actually harder to secure (eg, requiring new countermeasures), or = just slower on hardware which doesn=E2=80=99t accelerate the special = prime (eg, by requiring longer blinding factors)?
=E2=80=94 Mike
= --Apple-Mail=_A8D39003-FF47-46FB-AED3-C180FC9294EF-- From nobody Tue Oct 7 10:28:56 2014 Return-Path: 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 343311A7028 for ; Tue, 7 Oct 2014 10:28:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.787 X-Spam-Level: X-Spam-Status: No, score=-2.787 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.786, 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 5bN0FMQfJdyn for ; Tue, 7 Oct 2014 10:28:52 -0700 (PDT) Received: from ore.jhcloos.com (ore.jhcloos.com [IPv6:2604:2880::b24d:a297]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF6321A7021 for ; Tue, 7 Oct 2014 10:28:52 -0700 (PDT) Received: by ore.jhcloos.com (Postfix, from userid 10) id DF3E81E2C1; Tue, 7 Oct 2014 17:28:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=ore14; t=1412702931; bh=CQU8S+0Nm/A3GKOxpyurq3H1dzSotR4oaayvDoZi55w=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=iAlsPNOXGyYqvMp/BO8Xb8IMo8CcvXlrBzssVa69yyhXhecPUOonHBBE126Ps3azm vCf+GJRxhPeIL4SWVIdFzmRQO14MRdTmAoUFzkW1WIFl890N9S0k8TzQ8zMX4mCYRv /vUYl8qCgLV1zNa/nwZVJq5JbK/SlvF8CBqGzwAM= Received: by carbon.jhcloos.org (Postfix, from userid 500) id 4AC2860023; Tue, 7 Oct 2014 17:26:17 +0000 (UTC) From: James Cloos To: Yoav Nir In-Reply-To: <7C2D2B7D-CB2A-4541-88B8-49B5CCC64CA8@gmail.com> (Yoav Nir's message of "Tue, 7 Oct 2014 19:49:08 +0300") References: <542D48CD.9060404@isode.com> <7C2D2B7D-CB2A-4541-88B8-49B5CCC64CA8@gmail.com> User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/24.4.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2014 James Cloos OpenPGP: 0x997A9F17ED7DAEA6; url=https://jhcloos.com/public_key/0x997A9F17ED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Tue, 07 Oct 2014 13:26:17 -0400 Message-ID: Lines: 26 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:28:141007:ynir.ietf@gmail.com::3oXmSK42ZCWhaPiU:000000000000000000000000000000000000000004vgXf X-Hashcash: 1:28:141007:cfrg@irtf.org::sI693B0KLk+uFseF:000sUp/F Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/PDSdbBbcEb2tUZgkhe1042thsTY Cc: cfrg@irtf.org Subject: Re: [Cfrg] RGLC on draft-irtf-cfrg-chacha20-poly1305-01.txt X-BeenThere: cfrg@irtf.org 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: Tue, 07 Oct 2014 17:28:54 -0000 >>>>> "YN" == Yoav Nir writes: YN> The 96/32 split is dictated by the recommendation in RFC 5116. YN> Neither regular IPsec nor regular TLS need this, but multi-sender YN> IPsec (GDOI) and multi-sender DTLS can benefit. Yes, I read all of the prior discussions. My argument is that 96/32 should be limited to those multi-sender environments. The RFC can spec 64/64, and then note that the upper 32 bits of the counter can be initialized to something other than 0 whenever more than 64 IV bits are required. Just like it should mention that when not using reliable transports like tcp and when the extra data includes any kind of a packet/frame number which has a consistent function to the chacha counter, the receiver can recognize missing packets and decode what it does get by basing its chacha counter on said (authenticated) extra data. Which would allow dtls to avoid retransmission for things like rtp. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6 From nobody Wed Oct 8 01:05:09 2014 Return-Path: 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 B9F871A00D0 for ; Wed, 8 Oct 2014 01:05:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 oztpVLWaJyEL for ; Wed, 8 Oct 2014 01:05:00 -0700 (PDT) Received: from apfel.src-bonn.de (apfel.src-bonn.de [78.35.41.6]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E204C1A00BA for ; Wed, 8 Oct 2014 01:04:59 -0700 (PDT) Received: from imail (imail.src-gmbh.lan [192.168.8.3]) by apfel.src-bonn.de (Postfix) with SMTP id C5EAF959B; Wed, 8 Oct 2014 10:04:57 +0200 (CEST) Message-ID: <5434F025.5020301@src-gmbh.de> Date: Wed, 08 Oct 2014 10:04:53 +0200 From: Dirk Feldhusen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Michael Hamburg References: <20141003111024.20324.qmail@cr.yp.to> <54341010.8050207@src-gmbh.de> In-Reply-To: Content-Type: multipart/alternative; boundary="------------020504060808060406090606" Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/T-dNEx9dGg5cbCY7Lin_neTZcOg Cc: "cfrg@irtf.org" , "D. J. Bernstein" Subject: Re: [Cfrg] Trusting government certifications of cryptography X-BeenThere: cfrg@irtf.org 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: Wed, 08 Oct 2014 08:05:05 -0000 This is a multi-part message in MIME format. --------------020504060808060406090606 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Am 07.10.2014 18:55, schrieb Michael Hamburg: > >> On Oct 7, 2014, at 9:08 AM, Dirk Feldhusen >> > wrote= : > >> To exclude the possibilty of power or EM side channel you need the >> assumption that the attacker has no physical access to the device. >> As I understand Torsten the main problem here are special primes which= >> are harder to secure against such side channel leakage. > > Are they actually harder to secure (eg, requiring new > countermeasures), or just slower on hardware which doesn=E2=80=99t acce= lerate > the special prime (eg, by requiring longer blinding factors)? > > =E2=80=94 Mike I agree to both. First, additive point (and scalar) blinding doesn't work properly for a special prime ie adding a small multiple of the prime leaves most parts of the binary representation of the point coordinate unchanged (depends on the kind of the leakage, here it is assumed that the Hamming weight of single words leaks through the multiplication). Of course other blinding methods could work. Second, hardware designed for general primes doesn't accelerate special primes as far as I know and inserting large blinding factors would slow it further down. But this depends on the blinding method. =E2=80=94 Dirk --------------020504060808060406090606 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Am 07.10.2014 18:55, schrieb Michael Hamburg:

On Oct 7, 2014, at 9:08 AM, Dirk Feldhusen <= dirk.= feldhusen@src-gmbh.de> wrote:

To exclude the possibilty of power or EM side channel you need the
assumption that the attacker has no physical access to the device.
As I understand Torsten the main problem here are special primes which
are harder to secure against such side channel leakage.

Are they actually harder to secure (eg, requiring new countermeasures), or just slower on hardware which doesn=E2=80= =99t accelerate the special prime (eg, by requiring longer blinding factors)?

=E2=80=94 Mike

I agree to both. First, additive point (and scalar) blinding doesn't work properly for a special prime ie adding a small multiple of the prime leaves most parts of the binary representation of the point coordinate unchanged (depends on the kind of the leakage, here it is assumed that the Hamming weight of single words leaks through the multiplication). Of course other blinding methods could work. Second, hardware designed for general primes doesn't accelerate special primes as far as I know and inserting large blinding factors would slow it further down. But this depends on the blinding method.<= br>
=E2=80=94 Dirk
--------------020504060808060406090606-- From nobody Wed Oct 8 04:57:36 2014 Return-Path: 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 255E81A02F9 for ; Wed, 8 Oct 2014 04:57:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.341 X-Spam-Level: X-Spam-Status: No, score=-1.341 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FB_WORD2_END_DOLLAR=3.294, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, UNPARSEABLE_RELAY=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 boFaGscX_dSM for ; Wed, 8 Oct 2014 04:57:32 -0700 (PDT) Received: from m3-bn.bund.de (m3-bn.bund.de [77.87.228.75]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 948E11A02F8 for ; Wed, 8 Oct 2014 04:57:32 -0700 (PDT) Received: from m3.mfw.bn.ivbb.bund.de (localhost.mfw.bn.ivbb.bund.de [127.0.0.1]) by m3-bn.bund.de (8.14.3/8.14.3) with ESMTP id s98BvTbR020190 for ; Wed, 8 Oct 2014 13:57:29 +0200 (CEST) Received: (from localhost) by m3.mfw.bn.ivbb.bund.de (MSCAN) id 5/m3.mfw.bn.ivbb.bund.de/smtp-gw/mscan; Wed Oct 8 13:57:29 2014 X-P350-Id: 21a9350220643a1c X-Virus-Scanned: by amavisd-new at bsi.bund.de From: "Lochter, Manfred" Organization: BSI Bonn To: cfrg@irtf.org Date: Wed, 8 Oct 2014 13:57:02 +0200 User-Agent: KMail/1.9.10 (enterprise35 20140205.23bb19c) References: <20141003111024.20324.qmail@cr.yp.to> <54341010.8050207@src-gmbh.de> In-Reply-To: X-KMail-QuotePrefix: > MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-ID: <201410081357.03062.manfred.lochter@bsi.bund.de> X-AntiVirus: checked by Avira MailGate (version: 3.2.1.26; AVE: 8.3.24.34; VDF: 7.11.177.52; host: sgasmtp2.bsi.de); id=21034-JvOnzC Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/gun3jacFQtJ5ddwhqwhMyb0I65Q Subject: Re: [Cfrg] Trusting government certifications of cryptography X-BeenThere: cfrg@irtf.org 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: Wed, 08 Oct 2014 11:57:35 -0000 Mike, in a nutshell: Yes, they are harder to secure. Long version: There are theoretical arguments that show that blinding becom= es=20 harder for special primes: One of the proposed countermeasures against side-channel attacks on the poi= nt=20 multiplication is Coron's first countermeasure \cite{Coron99}.=20 Instead of computing $\lambda P$ one chooses a random number $r$ (usually $= r$=20 has 32 bits, \cite{Coron99} suggests using 20 bits)=20 and computes $(\lambda +r q)P.$ It has been observed (\cite{Ciet}(The main ideas from \cite{Ciet} are also reproduced i= n=20 \cite{Ebeid}, which is easily available} and later=20 independently in=20 \cite{RandReps}) that the validity of this countermeasure relies on the structure of the bin= ary=20 representation of $p$. For cofactor one curves the upper half of=20 the binary representation of $p$ coincides with the upper half of the=20 representation of $q$ by the Hasse-Weil theorem. If this part of $p$ contains long runs of zeroes or=20 ones (as e.g. for curves over fields with Pseudo-Mersenne characteristic, as the= =20 NIST curves, or over fields with special prime characteristic as=20 $2^{255} -19$ over which curve25519 is defined)=20 some bits of $r$ and $\lambda$ can directly be accessed through measurement= s.=20 In \cite{SchiWi} it is even shown that for some curves even 64 bits blindin= g=20 are not sufficient, depending on the=20 error rate of the measurements. In addition an {\glqq alternate attack\grqq= }\=20 is introduced \glqq that cannot be prevented by=20 increasing the parameter $R$\grqq \ within=20 a reasonable range\footnote{In the notation of \cite{SchiWi} $R$ is the=20 bitlength of the random number $r$}. @inproceedings{Coron99, author =3D {Jean-Sebastien Coron}, booktitle =3D {Cryptographic Hardware and Embedded Systems}, title =3D {{Resistance against Differential Power Analysis for Elliptic= =20 Curve Cryptosystems}}, year =3D {1999} } @ARTICLE{Ebeid, author =3D {Nevine Maurrice Ebeid}, title =3D {{Key Randomization Countermeasures to Power Analysis Attacks= on=20 Elliptic Curve Cryptosystems}}, journal =3D {Thesis}, year =3D {2007}, %volume =3D {12}, %pages =3D {1--28} } @misc{Ciet, author =3D {Mathieu Ciet}, title =3D {Aspects of fast and secure arithmetics for elliptic curve=20 cryptography}, howpublished =3D {Thesis}, year =3D {2003}, } @article{RandReps, title =3D "Randomised representations", author =3D "Elisabeth Oswald and Daniel Page and Nigel Smart", year =3D "2008", volume =3D "2", number =3D "2", pages =3D "19--27", journal =3D "IET Proceedings on Information Security", } @ARTICLE{SchiWi, author =3D {Werner Schindler and Andreas Wiemers}, title =3D {{Power Attacks in the Presence of Exponent Blinding} }, journal =3D {Journal of Cryptographic Engeneering}, year =3D {to appear}, %volume =3D {12}, %pages =3D {1--28} } __________ urspr=C3=BCngliche Nachricht __________ Von: Michael Hamburg Datum: Dienstag, 7. Oktober 2014, 18:55:33 An: Dirk Feldhusen Kopie: "cfrg@irtf.org" , "D. J. Bernstein" Betr.: Re: [Cfrg] Trusting government certifications of cryptography > > On Oct 7, 2014, at 9:08 AM, Dirk Feldhusen > > wrote: > > > > To exclude the possibilty of power or EM side channel you need the > > assumption that the attacker has no physical access to the device. > > As I understand Torsten the main problem here are special primes which > > are harder to secure against such side channel leakage. > > Are they actually harder to secure (eg, requiring new countermeasures), or > just slower on hardware which doesn=E2=80=99t accelerate the special prim= e (eg, by > requiring longer blinding factors)? > > =E2=80=94 Mike =2D-=20 Lochter, Manfred =2D------------------------------------------- Bundesamt f=C3=BCr Sicherheit in der Informationstechnik (BSI) Referat K21 Godesberger Allee 185 -189 53175 Bonn Postfach 20 03 63 53133 Bonn Telefon: +49 (0)228 99 9582 5643 Telefax: +49 (0)228 99 10 9582 5643 E-Mail: manfred.lochter@bsi.bund.de Internet: www.bsi.bund.de www.bsi-fuer-buerger.de From nobody Wed Oct 8 07:28:21 2014 Return-Path: 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 6E3291A1B58 for ; Wed, 8 Oct 2014 07:28:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.6 X-Spam-Level: X-Spam-Status: No, score=-0.6 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 ZhqR8yjDecHk for ; Wed, 8 Oct 2014 07:28:18 -0700 (PDT) Received: from mail-yh0-x236.google.com (mail-yh0-x236.google.com [IPv6:2607:f8b0:4002:c01::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 866C61A1A93 for ; Wed, 8 Oct 2014 07:28:18 -0700 (PDT) Received: by mail-yh0-f54.google.com with SMTP id z6so3774083yhz.41 for ; Wed, 08 Oct 2014 07:28:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=8nmcsWw5rKeMU9E+Pc1trF/SrBC+/aabyEzES317edY=; b=ndBvA4zoteiW8dJLQFcHHU7oyc58Nq1hWNWAT5Z0y9c44Duul93XB46P9AqRcIKCWJ RDlgrb+SjSvVtilUdGi8qZS9hsObozkaYtex4QCW7dlQb4IHR9osKsH7bIzENmSXx30d 7yYcI2OvQzjuoYM+9ul+cU/v+g3Y0z20b+BcO6iNqu0ao1IF2wxmzyPVWgu4RyM47jZc W2vn/S+jvGESyoYHFdsHrS4vQcpxNUjpuwyn62fITIGUg0KESnBMtyQwynrRSDXamHEb enSSfov5vYdbmHDhBukbuww16C7VgTG+awcWvqx8P5mAM7Lym9r5Uo8H0fXPSnmXZZYO HXDw== MIME-Version: 1.0 X-Received: by 10.236.172.161 with SMTP id t21mr15891953yhl.65.1412778497716; Wed, 08 Oct 2014 07:28:17 -0700 (PDT) Received: by 10.170.195.149 with HTTP; Wed, 8 Oct 2014 07:28:17 -0700 (PDT) Date: Wed, 8 Oct 2014 07:28:17 -0700 Message-ID: From: Watson Ladd To: "cfrg@irtf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/98NvsRcfsCUKE1KLcErLiFeELd4 Subject: [Cfrg] Alternatives to McGrew's hash based signatures X-BeenThere: cfrg@irtf.org 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: Wed, 08 Oct 2014 14:28:20 -0000 Dear all, Recently a rather large team from industry and academia has produced SPHINCS, a hash based signature scheme claiming stateless security, and faster signing and verification with smaller signatures at the 128 bit level than has been hitherto achieved. The paper is https://huelsing.files.wordpress.com/2013/04/eprint_sphincs.pdf. Before we consider standardizing the McGrew draft, I'd like to know how these compare and differ. I haven't had the time to do that thoroughly yet. Sincerely, Watson Ladd From nobody Wed Oct 8 07:55:24 2014 Return-Path: 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 E16AE1A1B8F for ; Wed, 8 Oct 2014 07:55:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.786] 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 YU0j02s5lQvV for ; Wed, 8 Oct 2014 07:55:22 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id 7B6EF1A1B8A for ; Wed, 8 Oct 2014 07:55:22 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 8E47647575; Wed, 8 Oct 2014 14:55:21 +0000 (GMT) Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 8227A47571; Wed, 8 Oct 2014 14:55:21 +0000 (GMT) Received: from ustx2ex-cashub.dfw01.corp.akamai.com (ustx2ex-cashub2.dfw01.corp.akamai.com [172.27.25.76]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id 674002030; Wed, 8 Oct 2014 14:55:21 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([169.254.2.28]) by ustx2ex-cashub2.dfw01.corp.akamai.com ([172.27.25.76]) with mapi; Wed, 8 Oct 2014 09:55:20 -0500 From: "Salz, Rich" To: Watson Ladd , "cfrg@irtf.org" Date: Wed, 8 Oct 2014 09:55:20 -0500 Thread-Topic: [Cfrg] Alternatives to McGrew's hash based signatures Thread-Index: Ac/jBB+wYr3fS2CVQLOFArrXreXE3AAA7abg Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C71D2FD0953A@USMBX1.msg.corp.akamai.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/wJhgn0GygqZ1voHS0c5_iibwTeM Subject: Re: [Cfrg] Alternatives to McGrew's hash based signatures X-BeenThere: cfrg@irtf.org 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: Wed, 08 Oct 2014 14:55:24 -0000 Some might find "signatures are 41Kb" a bit of a stopping point. -- =20 Principal Security Engineer, Akamai Technologies IM: rsalz@jabber.me Twitter: RichSalz From nobody Wed Oct 8 08:07:26 2014 Return-Path: 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 3F0FF1A1BE5 for ; Wed, 8 Oct 2014 08:07:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 03VYpYTozyQL for ; Wed, 8 Oct 2014 08:07:20 -0700 (PDT) Received: from mail-yh0-x232.google.com (mail-yh0-x232.google.com [IPv6:2607:f8b0:4002:c01::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AAC51A1B98 for ; Wed, 8 Oct 2014 08:07:20 -0700 (PDT) Received: by mail-yh0-f50.google.com with SMTP id a41so4065552yho.9 for ; Wed, 08 Oct 2014 08:07:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=watIjce4wx9cSFZX8RbYnmk1c//RX56q0P7YfEdhpk0=; b=a12XCOaGZh4S0Kef5ZfawFKfCJ3bwxJQf8YToGkVUezVbr0GvJv8IElTB/4QpU/aoV JWUhCg+S4gaPDac6MCOc53jvMn57guPsTFU0HIDeEdh5XARnIl3+XQnBKeU9mWjDft4b JarDMwA6rfcCZghFgQYZgnXbE9aWDrJh1XfKUv8yv2mSyK8DYIrEHVUYq8dH+wtaIDSF XTdXuev7JwzvLlo0g0F7CQ1wsYykYC+t6iSY1XtUCeUqWAoggAERarStXRIvT0v+rVqV zN/Chj5M5qV4bnEP8Ns8U/aNgGNEGYbWeGILeK9BtjDLhr8678SWItopuzZbhF0zoplA tteg== MIME-Version: 1.0 X-Received: by 10.236.172.161 with SMTP id t21mr16213802yhl.65.1412780839509; Wed, 08 Oct 2014 08:07:19 -0700 (PDT) Received: by 10.170.195.149 with HTTP; Wed, 8 Oct 2014 08:07:19 -0700 (PDT) In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C71D2FD0953A@USMBX1.msg.corp.akamai.com> References: <2A0EFB9C05D0164E98F19BB0AF3708C71D2FD0953A@USMBX1.msg.corp.akamai.com> Date: Wed, 8 Oct 2014 08:07:19 -0700 Message-ID: From: Watson Ladd To: "Salz, Rich" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/Nzdbt4EMcDrEhKdde_ibo5sui44 Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] Alternatives to McGrew's hash based signatures X-BeenThere: cfrg@irtf.org 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: Wed, 08 Oct 2014 15:07:22 -0000 On Wed, Oct 8, 2014 at 7:55 AM, Salz, Rich wrote: > Some might find "signatures are 41Kb" a bit of a stopping point. Some might find that being unable to use a key if restored from a backup is a stopping point. But that's what the McGrew draft does. Maybe we need both. > > -- > Principal Security Engineer, Akamai Technologies > IM: rsalz@jabber.me Twitter: RichSalz -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Wed Oct 8 10:22:44 2014 Return-Path: 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 DDA161ACD1E for ; Wed, 8 Oct 2014 10:22:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.849 X-Spam-Level: **** X-Spam-Status: No, score=4.849 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FB_WORD2_END_DOLLAR=3.294, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.982, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no 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 DoT9ixfZ14eM for ; Wed, 8 Oct 2014 10:22:40 -0700 (PDT) Received: from aspartame.shiftleft.org (199-116-74-168-v301.PUBLIC.monkeybrains.net [199.116.74.168]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7839C1ACD1A for ; Wed, 8 Oct 2014 10:22:40 -0700 (PDT) Received: from [192.168.1.124] (unknown [192.168.1.1]) by aspartame.shiftleft.org (Postfix) with ESMTPSA id 57E2F3AA49; Wed, 8 Oct 2014 10:21:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=shiftleft.org; s=sldo; t=1412788874; bh=5FaxpV/ioI9Ei9gU/XxSsX9hF0EeIK8uzSjaIJ8v1i0=; h=Date:From:To:Subject:References:In-Reply-To:From; b=i0axF7ndbinWJOxZJCKF9JfyjmUpG0pM1v1F3eDsyY3lICAFNXXgAJJXhCRY3dA7V s/MPwBVENxWPX6yoqOTdPpkdUaOF3itshzEVB8CryFzI9/6PkAb11aN595i3zY/Hgh BoJcvBLFS0nou+oWq4v85sLEafo2lwBoddxPN9Jc= Message-ID: <543572CE.5080409@shiftleft.org> Date: Wed, 08 Oct 2014 10:22:22 -0700 From: Mike Hamburg User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Lochter, Manfred" , cfrg@irtf.org References: <20141003111024.20324.qmail@cr.yp.to> <54341010.8050207@src-gmbh.de> <201410081357.03062.manfred.lochter@bsi.bund.de> In-Reply-To: <201410081357.03062.manfred.lochter@bsi.bund.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/BQaX8pVkaGbOzQ-ss4U-rZzLh9o Subject: Re: [Cfrg] Trusting government certifications of cryptography X-BeenThere: cfrg@irtf.org 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: Wed, 08 Oct 2014 17:22:42 -0000 OK, thanks Manfred. On 10/8/2014 4:57 AM, Lochter, Manfred wrote: > Mike, > > in a nutshell: Yes, they are harder to secure. > > Long version: There are theoretical arguments that show that blinding becomes > harder for special primes: > > One of the proposed countermeasures against side-channel attacks on the point > multiplication is Coron's first countermeasure \cite{Coron99}. > Instead of computing $\lambda P$ one chooses a random number $r$ (usually $r$ > has 32 bits, \cite{Coron99} suggests using 20 bits) > and computes $(\lambda +r q)P.$ > It has been > observed (\cite{Ciet}(The main ideas from \cite{Ciet} are also reproduced in > \cite{Ebeid}, which is easily available} and later > independently in > \cite{RandReps}) > that the validity of this countermeasure relies on the structure of the binary > representation of $p$. For cofactor one curves the upper half of > the binary representation of $p$ coincides with the upper half of the > representation of $q$ by the Hasse-Weil theorem. > If this part of $p$ contains long runs of zeroes or > ones > (as e.g. for curves over fields with Pseudo-Mersenne characteristic, as the > NIST curves, or over fields with special prime characteristic as > $2^{255} -19$ over which curve25519 is defined) > some bits of $r$ and $\lambda$ can directly be accessed through measurements. Right. I was trying to understand whether the problem can be solved by using a longer blinding factor -- even blinding to $r ~ \sqrt q$ would be faster on systems that accelerate special primes -- or whether it becomes truly infeasible or impractical. > In \cite{SchiWi} it is even shown that for some curves even 64 bits blinding > are not sufficient, depending on the > error rate of the measurements. In addition an {\glqq alternate attack\grqq}\ > is introduced \glqq that cannot be prevented by > increasing the parameter $R$\grqq \ within > a reasonable range\footnote{In the notation of \cite{SchiWi} $R$ is the > bitlength of the random number $r$}. This paper is paywalled, so I haven't read this paper beyond the first two pages, which describe the attack as working on RSA or ECC in general (with/without CRT). But if they detail a way to attack realistic implementations of blinding on special primes and not general, even for long $r$, then I concede the point. Thanks, -- Mike > @inproceedings{Coron99, > author = {Jean-Sebastien Coron}, > booktitle = {Cryptographic Hardware and Embedded Systems}, > title = {{Resistance against Differential Power Analysis for Elliptic > Curve Cryptosystems}}, > year = {1999} > } > @ARTICLE{Ebeid, > author = {Nevine Maurrice Ebeid}, > title = {{Key Randomization Countermeasures to Power Analysis Attacks on > Elliptic Curve Cryptosystems}}, > journal = {Thesis}, > year = {2007}, > %volume = {12}, > %pages = {1--28} > } > @misc{Ciet, > author = {Mathieu Ciet}, > title = {Aspects of fast and secure arithmetics for elliptic curve > cryptography}, > howpublished = {Thesis}, > year = {2003}, > } > @article{RandReps, > title = "Randomised representations", > author = "Elisabeth Oswald and Daniel Page and Nigel Smart", > year = "2008", > volume = "2", > number = "2", > pages = "19--27", > journal = "IET Proceedings on Information Security", > > } > @ARTICLE{SchiWi, > author = {Werner Schindler and Andreas Wiemers}, > title = {{Power Attacks in the Presence of Exponent Blinding} }, > journal = {Journal of Cryptographic Engeneering}, > year = {to appear}, > %volume = {12}, > %pages = {1--28} > } > > > > > __________ ursprüngliche Nachricht __________ > > Von: Michael Hamburg > Datum: Dienstag, 7. Oktober 2014, 18:55:33 > An: Dirk Feldhusen > Kopie: "cfrg@irtf.org" , "D. J. Bernstein" > Betr.: Re: [Cfrg] Trusting government certifications of cryptography > >>> On Oct 7, 2014, at 9:08 AM, Dirk Feldhusen >>> wrote: >>> >>> To exclude the possibilty of power or EM side channel you need the >>> assumption that the attacker has no physical access to the device. >>> As I understand Torsten the main problem here are special primes which >>> are harder to secure against such side channel leakage. >> Are they actually harder to secure (eg, requiring new countermeasures), or >> just slower on hardware which doesn’t accelerate the special prime (eg, by >> requiring longer blinding factors)? >> >> — Mike From nobody Wed Oct 8 10:32:28 2014 Return-Path: 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 9431A1ACD38 for ; Wed, 8 Oct 2014 10:32:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_LOW=-0.7, UNPARSEABLE_RELAY=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 GS3U-GCHOkKg for ; Wed, 8 Oct 2014 10:32:25 -0700 (PDT) Received: from mace.cs.uic.edu (mace.cs.uic.edu [131.193.32.224]) by ietfa.amsl.com (Postfix) with SMTP id 2FA2F1ACD26 for ; Wed, 8 Oct 2014 10:32:24 -0700 (PDT) Received: (qmail 19366 invoked by uid 1011); 8 Oct 2014 17:32:21 -0000 Received: from unknown (unknown) by unknown with QMTP; 8 Oct 2014 17:32:21 -0000 Received: (qmail 15170 invoked by uid 1001); 8 Oct 2014 17:31:54 -0000 Date: 8 Oct 2014 17:31:54 -0000 Message-ID: <20141008173154.15169.qmail@cr.yp.to> From: "D. J. Bernstein" To: cfrg@irtf.org Mail-Followup-To: cfrg@irtf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/_2KVunviyJP4TYLdtMp2W2KPSbk Subject: Re: [Cfrg] When's the decision? X-BeenThere: cfrg@irtf.org 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: Wed, 08 Oct 2014 17:32:26 -0000 According to an announcement at ECC today, the Brainpool team is completing a paper regarding curve requirements. Obviously Brainpool has been a bit slow to join this discussion, and is already grandfathered into TLS etc., but it sounds like they're serious about providing input that might be useful in selecting new curves. It's also not clear to me whether other teams (such as Barreto et al.) will have curve submissions once the CFRG requirements are finalized. Even if there are no other submissions and no changes to the draft requirements, remember that there's a requirement for wiggle room to be "quantified". For curves that take the as-fast-as-possible approach, such as Curve25519, this is mostly answered by Mike Hamburg's "Rigidity and performance" analysis of wiggle room in as-fast-as-possible primes, but the chairs might want more information. For the Microsoft curves, I presume that Microsoft is working on coming into compliance with this requirement, and we're also doing our own analysis. ---Dan From nobody Wed Oct 8 10:53:50 2014 Return-Path: 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 AF54F1ACD75 for ; Wed, 8 Oct 2014 10:53:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.786 X-Spam-Level: X-Spam-Status: No, score=-2.786 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.786] 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 TWiXzlNjki-S for ; Wed, 8 Oct 2014 10:53:44 -0700 (PDT) Received: from statler.isode.com (ext-bt.isode.com [217.34.220.158]) by ietfa.amsl.com (Postfix) with ESMTP id 1684B1ACD72 for ; Wed, 8 Oct 2014 10:53:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1412790823; d=isode.com; s=selector; i=@isode.com; bh=UCUZXBbdLj+yymONTIbZWMN2CILsxMcx1Zjw1nrSkQ0=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=Nj+DJscwwyaUZMO3O9Y4FooD31xDCyIEnk2HE/y0Q5XBxjZ6PM62kfwHWwBPEdd4TbyqM1 i+llsHU8/s3XHPAN0BZ/d/RsVuovXkkUPJUo/jCsSlKjqC2i4pU1PlkipaB5zIGAdBvEcJ /t6/OjEQwCDWIu9lNfsqDJluEwyuiKc=; Received: from [172.20.1.47] (dhcp-47.isode.net [172.20.1.47]) by statler.isode.com (submission channel) via TCP with ESMTPA id ; Wed, 8 Oct 2014 18:53:42 +0100 Message-ID: <54357A2A.2010800@isode.com> Date: Wed, 08 Oct 2014 18:53:46 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 To: "cfrg@irtf.org" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/v644wIRoRk5KFPKG4EhSysHzZ9U Subject: [Cfrg] draft-irtf-cfrg-dragonfly document status X-BeenThere: cfrg@irtf.org 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: Wed, 08 Oct 2014 17:53:48 -0000 Hi, My apologies for taking so long on this. But I felt I needed to review mailing list discussions to make up my own mind on this topic. After reviewing mailing list discussions about this draft, I would like to do another RGLC on it. I've seen negative comments on the mailing list, but I've also seen some interest in this work and I am also aware that some variants of the algorithm are already implemented/deployed. Also, there were a couple of new revisions of the draft and it is not clear whether people who reported original problems are happy with how they got resolved. So I would like to see a bit more positive feedback on the latest version, in particular I would like to know if specific issues raised by earlier reviews are addressed in the latest version. Considering how difficult previous Last Call on the document was, I would like to ask people to: 1) keep in mind that CFRG chairs believe that the RG should work on PAKE requirements and after that on other PAKE proposals. This was suggested by our previous co-chair David McGrew: http://www.ietf.org/mail-archive/web/cfrg/current/msg03723.html 2) be professional, in particular no ad hominem attacks 3) be constructive. In particular if you would like a disclaimer being added to the document, please suggest specific text. 4) simple statements of support for publishing the document or objection to publishing it are fine and encouraged. Sending them directly to RG chairs is fine. But please avoid saying "but what about PAKEXXX?", due to 1). 5) unlike IETF, IRTF RGs are not required to reach rough consensus. However I would like to see us try. Best Regards, Alexey, on behalf of chairs. From nobody Wed Oct 8 11:09:50 2014 Return-Path: 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 132211A6FF7 for ; Wed, 8 Oct 2014 11:09:47 -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 M9ihCsSFFXqf for ; Wed, 8 Oct 2014 11:09:44 -0700 (PDT) Received: from mail-yk0-x236.google.com (mail-yk0-x236.google.com [IPv6:2607:f8b0:4002:c07::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77E351A01A8 for ; Wed, 8 Oct 2014 11:09:44 -0700 (PDT) Received: by mail-yk0-f182.google.com with SMTP id 79so1631307ykr.13 for ; Wed, 08 Oct 2014 11:09:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=xTJjILk/zyd8WoPMKnGxrwzh59v1Bvd91xAfc5Ui5RM=; b=DygAmu6N5adFCF5EkUvA4fh37w9FczfBJfnDd/Q1XDFXLsyouUO00XoDbleI717g+J PwYQc0EHzICqyIbRxoML5MOWUE3ifwSp35gqclbMDiIOuIk9f7k+Sc8QIHTOi9mMpN6q /FqFmnWqlLPdE2IrWa1HO+qiCmF4T+etT2nuCROCAjsBIgUt5ve5W8gnjSwz5rkGEB/+ skErCAupx2Rfmcvg/j1wJ4PXUAgiTxgwh2khXe0qa0wQ4jL/D22UVkF7unYvrI9RTtSD xkD90SflF8EfCgQgO0ltFBpYUjxPVxmp52ezmmh1TiPDZlA1pJMl0chbHvqFoVmSaiTI 2Zpg== MIME-Version: 1.0 X-Received: by 10.236.172.161 with SMTP id t21mr17713288yhl.65.1412791783698; Wed, 08 Oct 2014 11:09:43 -0700 (PDT) Received: by 10.170.195.149 with HTTP; Wed, 8 Oct 2014 11:09:43 -0700 (PDT) Received: by 10.170.195.149 with HTTP; Wed, 8 Oct 2014 11:09:43 -0700 (PDT) In-Reply-To: <54357A2A.2010800@isode.com> References: <54357A2A.2010800@isode.com> Date: Wed, 8 Oct 2014 11:09:43 -0700 Message-ID: From: Watson Ladd To: Alexey Melnikov Content-Type: multipart/alternative; boundary=20cf304273e068b80d0504ed382b Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/1Swh6GKHwFOSjYfPLJB3P2rmWFA Cc: cfrg@irtf.org Subject: Re: [Cfrg] draft-irtf-cfrg-dragonfly document status X-BeenThere: cfrg@irtf.org 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: Wed, 08 Oct 2014 18:09:47 -0000 --20cf304273e068b80d0504ed382b Content-Type: text/plain; charset=UTF-8 On Oct 8, 2014 10:53 AM, "Alexey Melnikov" wrote: > > Hi, > My apologies for taking so long on this. But I felt I needed to review mailing list discussions to make up my own mind on this topic. > > After reviewing mailing list discussions about this draft, I would like to do another RGLC on it. I've seen negative comments on the mailing list, but I've also seen some interest in this work and I am also aware that some variants of the algorithm are already implemented/deployed. Also, there were a couple of new revisions of the draft and it is not clear whether people who reported original problems are happy with how they got resolved. So I would like to see a bit more positive feedback on the latest version, in particular I would like to know if specific issues raised by earlier reviews are addressed in the latest version. My comment (there is no security proof, and alternatives with better provable security) has been acknowledged to be unresolveable. The draft authors knew this from the very beginning. I don't think we should approve a protocol that doesn't have a security proof, particularly given that we are going to work on alternatives. There is plenty of terrible crypto in IEEE standards we don't issue drafts for because it is so terrible. To the extent our publication leads to use of dragonfly as opposed to known - good protocols, it's a problem. > > Considering how difficult previous Last Call on the document was, I would like to ask people to: > 1) keep in mind that CFRG chairs believe that the RG should work on PAKE requirements and after that on other PAKE proposals. This was suggested by our previous co-chair David McGrew: > http://www.ietf.org/mail-archive/web/cfrg/current/msg03723.html Why doesn't this apply to dragonfly, but only other proposals? > 2) be professional, in particular no ad hominem attacks > 3) be constructive. In particular if you would like a disclaimer being added to the document, please suggest specific text. > 4) simple statements of support for publishing the document or objection to publishing it are fine and encouraged. Sending them directly to RG chairs is fine. But please avoid saying "but what about PAKEXXX?", due to 1). > 5) unlike IETF, IRTF RGs are not required to reach rough consensus. However I would like to see us try. > > Best Regards, > Alexey, > on behalf of chairs. > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg --20cf304273e068b80d0504ed382b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Oct 8, 2014 10:53 AM, "Alexey Melnikov" <alexey.melnikov@isode.com> wrote:
>
> Hi,
> My apologies for taking so long on this. But I felt I needed to review= mailing list discussions to make up my own mind on this topic.
>
> After reviewing mailing list discussions about this draft, I would lik= e to do another RGLC on it. I've seen negative comments on the mailing = list, but I've also seen some interest in this work and I am also aware= that some variants of the algorithm are already implemented/deployed. Also= , there were a couple of new revisions of the draft and it is not clear whe= ther people who reported original problems are happy with how they got reso= lved. So I would like to see a bit more positive feedback on the latest ver= sion, in particular I would like to know if specific issues raised by earli= er reviews are addressed in the latest version.

My comment (there is no security proof, and alternatives wit= h better provable security) has been acknowledged to be unresolveable. The = draft authors knew this from the very beginning.

I don't think we should approve a protocol that doesn= 9;t have a security proof, particularly given that we are going to work on = alternatives.

There is plenty of terrible crypto in IEEE standards we don&= #39;t issue drafts for because it is so terrible. To the extent our publica= tion leads to use of dragonfly as opposed to known - good protocols, it'= ;s a problem.

>
> Considering how difficult previous Last Call on the document was, I wo= uld like to ask people to:
> 1) keep in mind that CFRG chairs believe that the RG should work on PA= KE requirements and after that on other PAKE proposals. This was suggested = by our previous co-chair David McGrew:
> =C2=A0 http://www.ietf.org/mail-archive/web/cfrg/current/msg03723.htm= l

Why doesn't this apply to dragonfly, but only other prop= osals?

> 2) be professional, in particular no ad hominem attacks=
> 3) be constructive. In particular if you would like a disclaimer being= added to the document, please suggest specific text.
> 4) simple statements of support for publishing the document or objecti= on to publishing it are fine and encouraged. Sending them directly to RG ch= airs is fine. But please avoid saying "but what about PAKEXXX?", = due to 1).
> 5) unlike IETF, IRTF RGs are not required to reach rough consensus. Ho= wever I would like to see us try.
>
> Best Regards,
> Alexey,
> on behalf of chairs.
>
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> http://www.irtf.= org/mailman/listinfo/cfrg

--20cf304273e068b80d0504ed382b-- From nobody Wed Oct 8 15:26:32 2014 Return-Path: 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 6B91D1A1B3E for ; Wed, 8 Oct 2014 15:26:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.266 X-Spam-Level: X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, 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 L_KYVU9udn8y for ; Wed, 8 Oct 2014 15:26:24 -0700 (PDT) Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com [67.231.156.173]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79DCF1A0AFE for ; Wed, 8 Oct 2014 15:26:24 -0700 (PDT) Received: from pps.filterd (m0045851.ppops.net [127.0.0.1]) by mx0b-0016f401.pphosted.com (8.14.5/8.14.5) with SMTP id s98MPpst005216; Wed, 8 Oct 2014 15:26:22 -0700 Received: from sc-owa04.marvell.com ([199.233.58.150]) by mx0b-0016f401.pphosted.com with ESMTP id 1pw0uwhn6m-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 08 Oct 2014 15:26:22 -0700 Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by SC-OWA04.marvell.com ([fe80::e56e:83a7:9eef:b5a1%16]) with mapi; Wed, 8 Oct 2014 15:26:21 -0700 From: Paul Lambert To: Watson Ladd , Alexey Melnikov Date: Wed, 8 Oct 2014 15:26:18 -0700 Thread-Topic: [Cfrg] draft-irtf-cfrg-dragonfly document status Thread-Index: Ac/jRuLDRqwqIDrNSKSK0V2+cFQLKw== Message-ID: References: <54357A2A.2010800@isode.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_D05AE16250264paulmarvellcom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.28, 0.0.0000 definitions=2014-10-08_09:2014-10-08,2014-10-08,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1410080200 Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/dXu3ZEdC_fNxp3n3WQox3BqaTJI Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] draft-irtf-cfrg-dragonfly document status X-BeenThere: cfrg@irtf.org 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: Wed, 08 Oct 2014 22:26:29 -0000 --_000_D05AE16250264paulmarvellcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On Oct 8, 2014 10:53 AM, "Alexey Melnikov" > wrote: > > Hi, > My apologies for taking so long on this. But I felt I needed to review ma= iling list discussions to make up my own mind on this topic. > > After reviewing mailing list discussions about this draft, I would like t= o do another RGLC on it. I've seen negative comments on the mailing list, b= ut I've also seen some interest in this work and I am also aware that some = variants of the algorithm are already implemented/deployed. Also, there wer= e a couple of new revisions of the draft and it is not clear whether people= who reported original problems are happy with how they got resolved. So I = would like to see a bit more positive feedback on the latest version, in pa= rticular I would like to know if specific issues raised by earlier reviews = are addressed in the latest version. This draft should be published as an RFC. There is considerable value in h= aving a published stable reference document. The market should be allowed= to do the estimations of risk and value to field this protocol. Versions of the protocol have been adopted and fied. This protocol was firs= t introduced into IEEE 802.11s in 2008. The base protocol exchange has als= o been adopted in the Wi-Fi Alliance. The protocol has been improved by t= he review in the cfrg and if published, the specification would positively = impact the application of the protocol in other forums. My comment (there is no security proof, and alternatives with better provab= le security) has been acknowledged to be unresolveable. Yes, this may be considered a negative point by some but not all. While n= ot a proof, the protocol has been analyzed: Cryptanalysis of the Dragonfly Key Exchange Protocol It was interested that the only issue mentioned was a small subgroup attack= if the public key is not validated =85. which it always should. The draft authors knew this from the very beginning. I don't think we should approve a protocol that doesn't have a security pro= of, particularly given that we are going to work on alternatives. =93=85 Going to work on =85=94 is the issue. The draft under discussion ha= s been on IETF servers for 2 years. It has been used in other industry for= ums for four or five years. Yes, the cfrg should work as quickly as possible to make alternatives. Sto= pping the progression of this draft does not accelerate new work, but does = prevent existing applications from utilizing a reviewed and improved specif= ication. There is plenty of terrible crypto in IEEE standards =85 and IETF standards. Bringing in other good or bad protocols into the d= iscussion is irrelevant to the decision at hand. we don't issue drafts for because it is so terrible. Since when did the IETF mandate a security proof =85 There are terrible p= rotocols with proofs, so why does the lack of a proof made something =91ter= rible=92. Paul To the extent our publication leads to use of dragonfly as opposed to known= - good protocols, it's a problem. > > Considering how difficult previous Last Call on the document was, I would= like to ask people to: > 1) keep in mind that CFRG chairs believe that the RG should work on PAKE = requirements and after that on other PAKE proposals. This was suggested by = our previous co-chair David McGrew: > http://www.ietf.org/mail-archive/web/cfrg/current/msg03723.html Why doesn't this apply to dragonfly, but only other proposals? > 2) be professional, in particular no ad hominem attacks > 3) be constructive. In particular if you would like a disclaimer being ad= ded to the document, please suggest specific text. > 4) simple statements of support for publishing the document or objection = to publishing it are fine and encouraged. Sending them directly to RG chair= s is fine. But please avoid saying "but what about PAKEXXX?", due to 1). > 5) unlike IETF, IRTF RGs are not required to reach rough consensus. Howev= er I would like to see us try. > > Best Regards, > Alexey, > on behalf of chairs. > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg --_000_D05AE16250264paulmarvellcom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable


On Oct 8, 2014 10:53 AM, "Alexey Melni= kov" <alexey.melnikov@= isode.com> wrote:
>
> Hi,
> My apologies for takin= g so long on this. But I felt I needed to review mailing list discussions t= o make up my own mind on this topic.
>
> After reviewing mailin= g list discussions about this draft, I would like to do another RGLC on it.= I've seen negative comments on the mailing list, but I've also seen some i= nterest in this work and I am also aware that some variants of the algorith= m are already implemented/deployed. Also, there were a couple of new revisi= ons of the draft and it is not clear whether people who reported original p= roblems are happy with how they got resolved. So I would like to see a bit = more positive feedback on the latest version, in particular I would like to= know if specific issues raised by earlier reviews are addressed in the lat= est version.

This draft should be publis= hed as an RFC.  There is considerable value in having a published stab= le reference document.   The market should be allowed to do the estima= tions of risk and value to field this protocol.  
Versions of the protocol have been adopted and fied. Thi= s protocol was first  introduced into IEEE 802.11s in 2008. The base p= rotocol exchange has also been adopted in the Wi-Fi  Alliance.  T= he protocol has been improved by the review in the cfrg and if published, t= he specification would positively impact the application of the protocol in= other forums.

My comment (there is no security proof, and alternatives with better prov= able security) has been acknowledged to be unresolveable.

<= /span>
Yes, this may be considered a negative point by some but = not all.   While not a proof, the protocol has been analyzed: 

= Cryptanalysis of the Dragonfly Key Exchange Protocol<= /h3>

It was interested that the only issue ment= ioned was a small subgroup attack if the public key is not validated&n= bsp;=85. which it always should.<= /h3>

The draft authors knew this from the very beginning.<= /p>

I don't think we should approv= e a protocol that doesn't have a security proof, particularly given that we= are going to work on alternatives.

=93= =85 Going to work on =85=94 is the issue.  The draft under discussion = has been on IETF servers for 2 years.  It has been used in other indus= try forums for four or five years.

Y= es, the cfrg should work as quickly as possible to make alternatives.  = ;Stopping the progression of this draft does not accelerate new work, but d= oes prevent existing applications from utilizing a reviewed and improved sp= ecification.

There is plenty of t= errible crypto in IEEE standards

=85 and= IETF standards.  Bringing in other good or bad protocols into the dis= cussion is irrelevant to the decision at hand.    

we don't issue drafts for because it is so terri= ble.

Since when did the IETF mandate a security= proof =85   There are terrible protocols with proofs, so why does the= lack of a proof made something =91terrible=92.  

=
Paul



To the extent our publication leads to use of dragonfly= as opposed to known - good protocols, it's a problem.




>
> Considering how difficult previou= s Last Call on the document was, I would like to ask people to:
> 1) = keep in mind that CFRG chairs believe that the RG should work on PAKE requi= rements and after that on other PAKE proposals. This was suggested by our p= revious co-chair David McGrew:
>   http://www.ietf.org/mai= l-archive/web/cfrg/current/msg03723.html

Why doesn't = this apply to dragonfly, but only other proposals?

> 2= ) be professional, in particular no ad hominem attacks
> 3) be constr= uctive. In particular if you would like a disclaimer being added to the doc= ument, please suggest specific text.
> 4) simple statements of suppor= t for publishing the document or objection to publishing it are fine and en= couraged. Sending them directly to RG chairs is fine. But please avoid sayi= ng "but what about PAKEXXX?", due to 1).
> 5) unlike IETF, = IRTF RGs are not required to reach rough consensus. However I would like to= see us try.
>
> Best Regards,
> Alexey,
> on behal= f of chairs.
>
> ______________________________________________= _
> Cfrg mailing list
> C= frg@irtf.org
> http://www.irtf.org/mailman/listinfo/cfrg

=

--_000_D05AE16250264paulmarvellcom_-- From nobody Wed Oct 8 15:46:30 2014 Return-Path: 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 5C1321A02DE for ; Wed, 8 Oct 2014 15:46:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 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, J_CHICKENPOX_39=0.6, SPF_PASS=-0.001] autolearn=no 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 4rRbfaWZF5Ur for ; Wed, 8 Oct 2014 15:46:24 -0700 (PDT) Received: from mail-yh0-x234.google.com (mail-yh0-x234.google.com [IPv6:2607:f8b0:4002:c01::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 964E91A014B for ; Wed, 8 Oct 2014 15:46:24 -0700 (PDT) Received: by mail-yh0-f52.google.com with SMTP id f10so39960yha.25 for ; Wed, 08 Oct 2014 15:46:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=zbsSn2vMIvQBYfGyl+vUKg5NI4IZkwIOGjf0cwphFqk=; b=wUciATXwbnB/8MtD6xqW8ceEZjJ3U0IN7VwkL9wI8Xh+UgXCXcoFIUBCE0mN8PwU05 fPBHSrJ+yLbzrJL9ylrNrqGQxZaTuPwAkFu7DdUHSozTvdL3Q5Ue8diVvSU5Swpy7c5/ AzwwxdmGs9jjllb0R4tVfieEFCc+16fN2Nfiel5VBn5OWohH0L+IUc21p/uWpga5Meuk HZXo2O5NqU307Cnjh7RHTX4+7+75+b+2uFr4GaMl67kOBdqiW5wLzT8RP3URNOOdYHSP xZTc9Y5czIFyEe2f7P0Bqbfq7QnuwNR28f5VLBnBhjCoKox+0COnL/NAFtXMAuYA96zU cWkg== MIME-Version: 1.0 X-Received: by 10.236.228.100 with SMTP id e94mr19460953yhq.8.1412808383911; Wed, 08 Oct 2014 15:46:23 -0700 (PDT) Received: by 10.170.195.149 with HTTP; Wed, 8 Oct 2014 15:46:23 -0700 (PDT) Received: by 10.170.195.149 with HTTP; Wed, 8 Oct 2014 15:46:23 -0700 (PDT) In-Reply-To: References: <54357A2A.2010800@isode.com> Date: Wed, 8 Oct 2014 15:46:23 -0700 Message-ID: From: Watson Ladd To: Paul Lambert Content-Type: multipart/alternative; boundary=001a11c2cad4dbda130504f11599 Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/qIs-2m_TfwoTfa4JYCqn2jmQMmE Cc: cfrg@irtf.org Subject: Re: [Cfrg] draft-irtf-cfrg-dragonfly document status X-BeenThere: cfrg@irtf.org 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: Wed, 08 Oct 2014 22:46:26 -0000 --001a11c2cad4dbda130504f11599 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Oct 8, 2014 3:26 PM, "Paul Lambert" wrote: > > >> >> On Oct 8, 2014 10:53 AM, "Alexey Melnikov" wrote: >> > >> > Hi, >> > My apologies for taking so long on this. But I felt I needed to review mailing list discussions to make up my own mind on this topic. >> > >> > After reviewing mailing list discussions about this draft, I would like to do another RGLC on it. I've seen negative comments on the mailing list, but I've also seen some interest in this work and I am also aware that some variants of the algorithm are already implemented/deployed. Also, there were a couple of new revisions of the draft and it is not clear whether people who reported original problems are happy with how they got resolved. So I would like to see a bit more positive feedback on the latest version, in particular I would like to know if specific issues raised by earlier reviews are addressed in the latest version. > > This draft should be published as an RFC. There is considerable value in having a published stable reference document. The market should be allowed to do the estimations of risk and value to field this protocol. Just as they did with RC4 and renegotiation? > > Versions of the protocol have been adopted and fied. This protocol was first introduced into IEEE 802.11s in 2008. The base protocol exchange has also been adopted in the Wi-Fi Alliance. The protocol has been improved by the review in the cfrg and if published, the specification would positively impact the application of the protocol in other forums. > >> My comment (there is no security proof, and alternatives with better provable security) has been acknowledged to be unresolveable. > > Yes, this may be considered a negative point by some but not all. While not a proof, the protocol has been analyzed: > Cryptanalysis of the Dragonfly Key Exchange Protocol > It was interested that the only issue mentioned was a small subgroup attack if the public key is not validated =E2=80=A6. which it always should= . This analysis ignores Rene Struik's timing attack, my reflection attack, and other comments incorporated into the draft. >> >> The draft authors knew this from the very beginning. >> >> I don't think we should approve a protocol that doesn't have a security proof, particularly given that we are going to work on alternatives. > > =E2=80=9C=E2=80=A6 Going to work on =E2=80=A6=E2=80=9D is the issue. The= draft under discussion has been on IETF servers for 2 years. It has been used in other industry forums for four or five years. Plenty of alternatives have been put forward in those two years, including EKE+Elligator, SPAKE2, JPAKE, and SMP based solutions. The failure to advance these is inexplicable. > > Yes, the cfrg should work as quickly as possible to make alternatives. Stopping the progression of this draft does not accelerate new work, but does prevent existing applications from utilizing a reviewed and improved specification. The nonexistence of this draft did not stop adoption in Wifi. By contrast advancing a number of PAKEs will kick the issue to WGs without the capacity to evaluate the issues. >> >> There is plenty of terrible crypto in IEEE standards > > =E2=80=A6 and IETF standards. Bringing in other good or bad protocols in= to the discussion is irrelevant to the decision at hand. >> >> we don't issue drafts for because it is so terrible. > > Since when did the IETF mandate a security proof =E2=80=A6 There are te= rrible protocols with proofs, so why does the lack of a proof made something =E2=80=98terrible=E2=80=99. > > Paul > > > >> To the extent our publication leads to use of dragonfly as opposed to known - good protocols, it's a problem. > > > > >> > >> > Considering how difficult previous Last Call on the document was, I would like to ask people to: >> > 1) keep in mind that CFRG chairs believe that the RG should work on PAKE requirements and after that on other PAKE proposals. This was suggested by our previous co-chair David McGrew: >> > http://www.ietf.org/mail-archive/web/cfrg/current/msg03723.html >> >> Why doesn't this apply to dragonfly, but only other proposals? >> >> > 2) be professional, in particular no ad hominem attacks >> > 3) be constructive. In particular if you would like a disclaimer being added to the document, please suggest specific text. >> > 4) simple statements of support for publishing the document or objection to publishing it are fine and encouraged. Sending them directly to RG chairs is fine. But please avoid saying "but what about PAKEXXX?", due to 1). >> > 5) unlike IETF, IRTF RGs are not required to reach rough consensus. However I would like to see us try. >> > >> > Best Regards, >> > Alexey, >> > on behalf of chairs. >> > >> > _______________________________________________ >> > Cfrg mailing list >> > Cfrg@irtf.org >> > http://www.irtf.org/mailman/listinfo/cfrg > > --001a11c2cad4dbda130504f11599 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Oct 8, 2014 3:26 PM, "Paul Lambert" <paul@marvell.com> wrote:
>
>
>>
>> On Oct 8, 2014 10:53 AM, "Alexey Melnikov" <alexey.melnikov@isode.com> wro= te:
>> >
>> > Hi,
>> > My apologies for taking so long on this. But I felt I needed = to review mailing list discussions to make up my own mind on this topic. >> >
>> > After reviewing mailing list discussions about this draft, I = would like to do another RGLC on it. I've seen negative comments on the= mailing list, but I've also seen some interest in this work and I am a= lso aware that some variants of the algorithm are already implemented/deplo= yed. Also, there were a couple of new revisions of the draft and it is not = clear whether people who reported original problems are happy with how they= got resolved. So I would like to see a bit more positive feedback on the l= atest version, in particular I would like to know if specific issues raised= by earlier reviews are addressed in the latest version.
>
> This draft should be published as an RFC.=C2=A0 There is considerable = value in having a published stable reference document. =C2=A0 The market sh= ould be allowed to do the estimations of risk and value to field this proto= col. =C2=A0

Just as they did with RC4 and renegotiation?

>
> Versions of the protocol have been adopted and fied. This protocol was= first =C2=A0introduced into IEEE 802.11s in 2008. The base protocol exchan= ge has also been adopted in the Wi-Fi =C2=A0Alliance.=C2=A0 The protocol ha= s been improved by the review in the cfrg and if published, the specificati= on would positively impact the application of the protocol in other forums.=
>
>> My comment (there is no security proof, and alternatives with bett= er provable security) has been acknowledged to be unresolveable.
>
> Yes, this may be considered a negative point by some but not all. =C2= =A0 While not a proof, the protocol has been analyzed:=C2=A0
> Cryptanalysis of the Dragonfly Key Exchange Protocol
> It was interested that the only issue mentioned was a small subgroup a= ttack if the public key is not=C2=A0validated=C2=A0=E2=80=A6. which it alwa= ys should.

This analysis ignores Rene Struik's timing attack, my re= flection attack, and other comments incorporated into the draft.

>>
>> The draft authors knew this from the very beginning.
>>
>> I don't think we should approve a protocol that doesn't ha= ve a security proof, particularly given that we are going to work on altern= atives.
>
> =E2=80=9C=E2=80=A6 Going to work on =E2=80=A6=E2=80=9D is the issue.= =C2=A0 The draft under discussion has been on IETF servers for 2 years.=C2= =A0 It has been used in other industry forums for four or five years.

Plenty of alternatives have been put forward in those two ye= ars, including EKE+Elligator,=C2=A0 SPAKE2,=C2=A0 JPAKE,=C2=A0 and SMP base= d solutions. The failure to advance these is inexplicable.

>
> Yes, the cfrg should work as quickly as possible to make alternatives.= =C2=A0 Stopping the progression of this draft does not accelerate new work,= but does prevent existing applications from utilizing a reviewed and impro= ved specification.

The nonexistence of this draft did not stop adoption in Wifi= . By contrast advancing a number of PAKEs will kick the issue to WGs withou= t the capacity to evaluate the issues.

>>
>> There is plenty of terrible crypto in IEEE standards
>
> =E2=80=A6 and IETF standards.=C2=A0 Bringing in other good or bad prot= ocols into the discussion is irrelevant to the decision at hand. =C2=A0 =C2= =A0
>>
>> we don't issue drafts for because it is so terrible.
>
> Since when did the IETF mandate a security proof =E2=80=A6 =C2=A0 Ther= e are terrible protocols with proofs, so why does the lack of a proof made = something =E2=80=98terrible=E2=80=99.
>
> Paul
>
>
>
>> To the extent our publication leads to use of dragonfly as opposed= to known - good protocols, it's a problem.
>
>
>
>
>> >
>> > Considering how difficult previous Last Call on the document = was, I would like to ask people to:
>> > 1) keep in mind that CFRG chairs believe that the RG should w= ork on PAKE requirements and after that on other PAKE proposals. This was s= uggested by our previous co-chair David McGrew:
>> > =C2=A0=C2=A0http://www.ietf.org/mail-archive/web/cfrg/curren= t/msg03723.html
>>
>> Why doesn't this apply to dragonfly, but only other proposals?=
>>
>> > 2) be professional, in particular no ad hominem attacks
>> > 3) be constructive. In particular if you would like a disclai= mer being added to the document, please suggest specific text.
>> > 4) simple statements of support for publishing the document o= r objection to publishing it are fine and encouraged. Sending them directly= to RG chairs is fine. But please avoid saying "but what about PAKEXXX= ?", due to 1).
>> > 5) unlike IETF, IRTF RGs are not required to reach rough cons= ensus. However I would like to see us try.
>> >
>> > Best Regards,
>> > Alexey,
>> > on behalf of chairs.
>> >
>> > _______________________________________________
>> > Cfrg mailing list
>> >=C2=A0Cfrg@irtf.org
>> >=C2=A0ht= tp://www.irtf.org/mailman/listinfo/cfrg
>
>

--001a11c2cad4dbda130504f11599-- From nobody Wed Oct 8 15:51:18 2014 Return-Path: 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 983821A1A47 for ; Wed, 8 Oct 2014 15:51:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_39=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no 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 XW4o3vnj6squ for ; Wed, 8 Oct 2014 15:51:15 -0700 (PDT) Received: from mx0a-0016f401.pphosted.com (mx0a-0016f401.pphosted.com [67.231.148.174]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7B4D1A6F07 for ; Wed, 8 Oct 2014 15:51:14 -0700 (PDT) Received: from pps.filterd (m0045849.ppops.net [127.0.0.1]) by mx0a-0016f401.pphosted.com (8.14.5/8.14.5) with SMTP id s98Mp3nu031986; Wed, 8 Oct 2014 15:51:13 -0700 Received: from sc-owa.marvell.com ([199.233.58.135]) by mx0a-0016f401.pphosted.com with ESMTP id 1pw0mtt0wm-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 08 Oct 2014 15:51:12 -0700 Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by SC-OWA.marvell.com ([::1]) with mapi; Wed, 8 Oct 2014 15:51:12 -0700 From: Paul Lambert To: Watson Ladd Date: Wed, 8 Oct 2014 15:51:09 -0700 Thread-Topic: [Cfrg] draft-irtf-cfrg-dragonfly document status Thread-Index: Ac/jSlumLFPinmc/QJab72u2MW9Egw== Message-ID: References: <54357A2A.2010800@isode.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_D05B0D7D5055Apaulmarvellcom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.28, 0.0.0000 definitions=2014-10-08_09:2014-10-08,2014-10-08,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1410080204 Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/SiAAXPZNLSa1-Cwq-XgS6yJmdQs Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] draft-irtf-cfrg-dragonfly document status X-BeenThere: cfrg@irtf.org 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: Wed, 08 Oct 2014 22:51:17 -0000 --_000_D05B0D7D5055Apaulmarvellcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On Oct 8, 2014 3:26 PM, "Paul Lambert" > wrote: > > >> >> On Oct 8, 2014 10:53 AM, "Alexey Melnikov" > wrote: >> > >> > Hi, >> > My apologies for taking so long on this. But I felt I needed to review= mailing list discussions to make up my own mind on this topic. >> > >> > After reviewing mailing list discussions about this draft, I would lik= e to do another RGLC on it. I've seen negative comments on the mailing list= , but I've also seen some interest in this work and I am also aware that so= me variants of the algorithm are already implemented/deployed. Also, there = were a couple of new revisions of the draft and it is not clear whether peo= ple who reported original problems are happy with how they got resolved. So= I would like to see a bit more positive feedback on the latest version, in= particular I would like to know if specific issues raised by earlier revie= ws are addressed in the latest version. > > This draft should be published as an RFC. There is considerable value in= having a published stable reference document. The market should be allow= ed to do the estimations of risk and value to field this protocol. Just as they did with RC4 and renegotiation? > > Versions of the protocol have been adopted and fied. This protocol was fi= rst introduced into IEEE 802.11s in 2008. The base protocol exchange has a= lso been adopted in the Wi-Fi Alliance. The protocol has been improved by= the review in the cfrg and if published, the specification would positivel= y impact the application of the protocol in other forums. > >> My comment (there is no security proof, and alternatives with better pro= vable security) has been acknowledged to be unresolveable. > > Yes, this may be considered a negative point by some but not all. While= not a proof, the protocol has been analyzed: > Cryptanalysis of the Dragonfly Key Exchange Protocol > It was interested that the only issue mentioned was a small subgroup atta= ck if the public key is not validated =85. which it always should. This analysis ignores Rene Struik's timing attack, my reflection attack, an= d other comments incorporated into the draft. Yes, the review provided by the cfrg process has been very useful. The pro= tocol has been improved. Now that it has been through multiple revisions i= t should be published. Paul >> >> The draft authors knew this from the very beginning. >> >> I don't think we should approve a protocol that doesn't have a security = proof, particularly given that we are going to work on alternatives. > > =93=85 Going to work on =85=94 is the issue. The draft under discussion = has been on IETF servers for 2 years. It has been used in other industry f= orums for four or five years. Plenty of alternatives have been put forward in those two years, including = EKE+Elligator, SPAKE2, JPAKE, and SMP based solutions. The failure to ad= vance these is inexplicable. > > Yes, the cfrg should work as quickly as possible to make alternatives. S= topping the progression of this draft does not accelerate new work, but doe= s prevent existing applications from utilizing a reviewed and improved spec= ification. The nonexistence of this draft did not stop adoption in Wifi. By contrast a= dvancing a number of PAKEs will kick the issue to WGs without the capacity = to evaluate the issues. >> >> There is plenty of terrible crypto in IEEE standards > > =85 and IETF standards. Bringing in other good or bad protocols into the= discussion is irrelevant to the decision at hand. >> >> we don't issue drafts for because it is so terrible. > > Since when did the IETF mandate a security proof =85 There are terrible= protocols with proofs, so why does the lack of a proof made something =91t= errible=92. > > Paul > > > >> To the extent our publication leads to use of dragonfly as opposed to kn= own - good protocols, it's a problem. > > > > >> > >> > Considering how difficult previous Last Call on the document was, I wo= uld like to ask people to: >> > 1) keep in mind that CFRG chairs believe that the RG should work on PA= KE requirements and after that on other PAKE proposals. This was suggested = by our previous co-chair David McGrew: >> > http://www.ietf.org/mail-archive/web/cfrg/current/msg03723.html >> >> Why doesn't this apply to dragonfly, but only other proposals? >> >> > 2) be professional, in particular no ad hominem attacks >> > 3) be constructive. In particular if you would like a disclaimer being= added to the document, please suggest specific text. >> > 4) simple statements of support for publishing the document or objecti= on to publishing it are fine and encouraged. Sending them directly to RG ch= airs is fine. But please avoid saying "but what about PAKEXXX?", due to 1). >> > 5) unlike IETF, IRTF RGs are not required to reach rough consensus. Ho= wever I would like to see us try. >> > >> > Best Regards, >> > Alexey, >> > on behalf of chairs. >> > >> > _______________________________________________ >> > Cfrg mailing list >> > Cfrg@irtf.org >> > http://www.irtf.org/mailman/listinfo/cfrg > > --_000_D05B0D7D5055Apaulmarvellcom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable


On Oct 8, 2014 3:26 PM, "Paul Lambert" <paul@marvell.com> wrote:
>
>
>>
>> On Oct 8, 2014 10:53 AM, "Alexey Melnikov" <alexey.melnikov@isode.com> wro= te:
>> >
>> > Hi,
>> > My apologies for taking so long on this. But I felt I needed = to review mailing list discussions to make up my own mind on this topic. >> >
>> > After reviewing mailing list discussions about this draft, I = would like to do another RGLC on it. I've seen negative comments on the mai= ling list, but I've also seen some interest in this work and I am also awar= e that some variants of the algorithm are already implemented/deployed. Als= o, there were a couple of new revisions of the draft and it is not clear wh= ether people who reported original problems are happy with how they got res= olved. So I would like to see a bit more positive feedback on the latest ve= rsion, in particular I would like to know if specific issues raised by earl= ier reviews are addressed in the latest version.
>
> This draft should be published as an RFC.  There is considerable = value in having a published stable reference document.   The market sh= ould be allowed to do the estimations of risk and value to field this proto= col.  

Just as they did with RC4 and renegotiation? =

>
> Versions of the protocol have been adopted and fied. This protocol was= first  introduced into IEEE 802.11s in 2008. The base protocol exchan= ge has also been adopted in the Wi-Fi  Alliance.  The protocol ha= s been improved by the review in the cfrg and if published, the specificati= on would positively impact the application of the protocol in other forums.=
>
>> My comment (there is no security proof, and alternatives with bett= er provable security) has been acknowledged to be unresolveable.
>
> Yes, this may be considered a negative point by some but not all. &nbs= p; While not a proof, the protocol has been analyzed: 
> Cryptanalysis of the Dragonfly Key Exchange Protocol
> It was interested that the only issue mentioned was a small subgroup a= ttack if the public key is not validated =85. which it always sho= uld.

This analysis ignores Rene Struik's timing attack, m= y reflection attack, and other comments incorporated into the draft.


Yes, the review provided by the cfrg p= rocess has been very useful.  The protocol has been improved.  No= w that it has been through multiple revisions it should be published.
=

Paul



=

>>
>> The draft authors knew this from the very beginning.
>>
>> I don't think we should approve a protocol that doesn't have a sec= urity proof, particularly given that we are going to work on alternatives.<= br> >
> =93=85 Going to work on =85=94 is the issue.  The draft under dis= cussion has been on IETF servers for 2 years.  It has been used in oth= er industry forums for four or five years.

Plenty of alte= rnatives have been put forward in those two years, including EKE+Elliga= tor,  SPAKE2,  JPAKE,  and SMP based solutions. The failure = to advance these is inexplicable.

>
> Yes, the cfrg should work as quickly as possible to make alternatives.=   Stopping the progression of this draft does not accelerate new work,= but does prevent existing applications from utilizing a reviewed and impro= ved specification.

The nonexistence of this draft did not= stop adoption in Wifi. By contrast advancing a number of PAKEs will kick t= he issue to WGs without the capacity to evaluate the issues.

>>
>> There is plenty of terrible crypto in IEEE standards
>
> =85 and IETF standards.  Bringing in other good or bad protocols = into the discussion is irrelevant to the decision at hand.     >>
>> we don't issue drafts for because it is so terrible.
>
> Since when did the IETF mandate a security proof =85   There are = terrible protocols with proofs, so why does the lack of a proof made someth= ing =91terrible=92.
>
> Paul
>
>
>
>> To the extent our publication leads to use of dragonfly as opposed= to known - good protocols, it's a problem.
>
>
>
>
>> >
>> > Considering how difficult previous Last Call on the document = was, I would like to ask people to:
>> > 1) keep in mind that CFRG chairs believe that the RG should w= ork on PAKE requirements and after that on other PAKE proposals. This was s= uggested by our previous co-chair David McGrew:
>> >   http://www.ietf.org/mail-archive/web/cfrg/curren= t/msg03723.html
>>
>> Why doesn't this apply to dragonfly, but only other proposals?
>>
>> > 2) be professional, in particular no ad hominem attacks
>> > 3) be constructive. In particular if you would like a disclai= mer being added to the document, please suggest specific text.
>> > 4) simple statements of support for publishing the document o= r objection to publishing it are fine and encouraged. Sending them directly= to RG chairs is fine. But please avoid saying "but what about PAKEXXX= ?", due to 1).
>> > 5) unlike IETF, IRTF RGs are not required to reach rough cons= ensus. However I would like to see us try.
>> >
>> > Best Regards,
>> > Alexey,
>> > on behalf of chairs.
>> >
>> > _______________________________________________
>> > Cfrg mailing list
>> > Cfrg@irtf.org
>> > ht= tp://www.irtf.org/mailman/listinfo/cfrg
>
>



--_000_D05B0D7D5055Apaulmarvellcom_-- From nobody Wed Oct 8 15:51:49 2014 Return-Path: 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 4E3F51A014B for ; Wed, 8 Oct 2014 15:51:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.901 X-Spam-Level: X-Spam-Status: No, score=-2.901 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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 ZKcNxMjOGm9O for ; Wed, 8 Oct 2014 15:51:46 -0700 (PDT) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D7511A6F07 for ; Wed, 8 Oct 2014 15:51:46 -0700 (PDT) Received: from maildlpprd55.lss.emc.com (maildlpprd55.lss.emc.com [10.106.48.159]) by mailuogwprd52.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s98MpiKC026528 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 8 Oct 2014 18:51:45 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com s98MpiKC026528 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=rsa.com; s=jan2013; t=1412808705; bh=7d3vvZQ98zSh3gZBvhB8wdaLMrY=; h=From:To:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=ssbon7EIcZolwzE8HbAEBjQLiHT2et8GYbnnQysuaSRE8NEA/A9vfkGrn2UHwiFyI qlMwz79Tinn8P2eTth5NQC9I96ZkeC5Dnw1ELtJ0v7uGp95gYaCVU56nId8SKkEuQr 2NpjNhFlLluLLABFjSy/Y9YvY39CwLzekABQ84EY= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com s98MpiKC026528 Received: from mailusrhubprd01.lss.emc.com (mailusrhubprd01.lss.emc.com [10.253.24.19]) by maildlpprd55.lss.emc.com (RSA Interceptor) for ; Wed, 8 Oct 2014 18:51:18 -0400 Received: from mxhub23.corp.emc.com (mxhub23.corp.emc.com [128.222.70.135]) by mailusrhubprd01.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s98MpaeX028128 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 8 Oct 2014 18:51:36 -0400 Received: from mx17a.corp.emc.com ([169.254.1.209]) by mxhub23.corp.emc.com ([128.222.70.135]) with mapi; Wed, 8 Oct 2014 18:51:36 -0400 From: "Parkinson, Sean" To: "cfrg@irtf.org" Date: Wed, 8 Oct 2014 18:51:34 -0400 Thread-Topic: [Cfrg] When's the decision? Thread-Index: Ac/jHdkNXXV86vegQryVW7j10pACTgAKmhcA Message-ID: <2FBC676C3BBFBB4AA82945763B361DE608F1D021@MX17A.corp.emc.com> References: <20141008173154.15169.qmail@cr.yp.to> In-Reply-To: <20141008173154.15169.qmail@cr.yp.to> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd01.lss.emc.com X-RSA-Classifications: public Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/SGlE2GAJRC7HwYTwOXntk6oB7qg Subject: Re: [Cfrg] When's the decision? X-BeenThere: cfrg@irtf.org 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: Wed, 08 Oct 2014 22:51:48 -0000 I have concerns about a decision being made about which curves to recommend= 'before Halloween'. I am unaware of 3rd parties implementing and confirming all the curves that= have been proposed. Making a decision on new elliptic curves based on data that hasn't been cor= roborated by a 3rd party is bad practice. I have been implementing as many of the curves as I can and my performance = results, so far, do not always match those that I have seen in papers. Also, I am concerned that, while some curves are being implemented to be co= nstant time, not all curves are being implemented to be cache attack resist= ant. Either all implementations need to be resistant or all implementations= not. Only then can a true comparison be made. Until these issues are dealt with I feel there is not sufficient informatio= n to make a decision. Sean -- Sean Parkinson | Consultant Software Engineer | RSA, The Security Division= =A0of EMC Office +61 7 3032 5232 | Fax +61 7 3032 5299 www.rsa.com From nobody Wed Oct 8 16:40:50 2014 Return-Path: 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 EE3191A1AE1 for ; Wed, 8 Oct 2014 16:40:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.267 X-Spam-Level: X-Spam-Status: No, score=-3.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_39=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_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 iwF2Gxj0tD1G for ; Wed, 8 Oct 2014 16:40:45 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id A543A1A01F7 for ; Wed, 8 Oct 2014 16:40:45 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 2624710224008; Wed, 8 Oct 2014 16:40:45 -0700 (PDT) Received: from 104.36.248.10 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Wed, 8 Oct 2014 16:40:45 -0700 (PDT) Message-ID: <73d51db893a4b847db6d8eaae7f45cf5.squirrel@www.trepanning.net> In-Reply-To: References: <54357A2A.2010800@isode.com> Date: Wed, 8 Oct 2014 16:40:45 -0700 (PDT) From: "Dan Harkins" To: "Watson Ladd" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/Hv-6HDNCQr89H_gU2d-MbM_Kpvc Cc: cfrg@irtf.org Subject: Re: [Cfrg] draft-irtf-cfrg-dragonfly document status X-BeenThere: cfrg@irtf.org 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: Wed, 08 Oct 2014 23:40:50 -0000 Watson, On Wed, October 8, 2014 3:46 pm, Watson Ladd wrote: > On Oct 8, 2014 3:26 PM, "Paul Lambert" wrote: >>> >>> On Oct 8, 2014 10:53 AM, "Alexey Melnikov" > wrote: >>> > >>> > Hi, >>> > My apologies for taking so long on this. But I felt I needed to >>> review > mailing list discussions to make up my own mind on this topic. >>> > >>> > After reviewing mailing list discussions about this draft, I would > like to do another RGLC on it. I've seen negative comments on the mailing > list, but I've also seen some interest in this work and I am also aware > that some variants of the algorithm are already implemented/deployed. > Also, > there were a couple of new revisions of the draft and it is not clear > whether people who reported original problems are happy with how they got > resolved. So I would like to see a bit more positive feedback on the > latest > version, in particular I would like to know if specific issues raised by > earlier reviews are addressed in the latest version. >> >> This draft should be published as an RFC. There is considerable value >> in > having a published stable reference document. The market should be > allowed to do the estimations of risk and value to field this protocol. > > Just as they did with RC4 and renegotiation? This has nothing to do with RC4 and renegotiation (I assume you mean in TLS). >> >> Versions of the protocol have been adopted and fied. This protocol was > first introduced into IEEE 802.11s in 2008. The base protocol exchange > has > also been adopted in the Wi-Fi Alliance. The protocol has been improved > by the review in the cfrg and if published, the specification would > positively impact the application of the protocol in other forums. >> >>> My comment (there is no security proof, and alternatives with better > provable security) has been acknowledged to be unresolveable. >> >> Yes, this may be considered a negative point by some but not all. >> While > not a proof, the protocol has been analyzed: >> Cryptanalysis of the Dragonfly Key Exchange Protocol >> It was interested that the only issue mentioned was a small subgroup > attack if the public key is not validated …. which it always should. > > This analysis ignores Rene Struik's timing attack, my reflection attack, > and other comments incorporated into the draft. And I thanked Rene, you, and others for your comments and, as you note, incorporated resolutions into the draft. Once again, thank you for helping improve the draft. All of the comments have been resolved in -04. (I will note that the reflection attack you mentioned is not possible in the IEEE 802.11 version of dragonfly, which predated your comment and this draft by a few years, and neither was small subgroup attack described by Clarke and Hao mentioned above. The -00 version of this draft was rushed, take a look at the Acknowledgements in section 4 to see just how bad, and I left some things out that I shouldn't have. All this has all been addressed in -04). >>> >>> The draft authors knew this from the very beginning. >>> >>> I don't think we should approve a protocol that doesn't have a security > proof, particularly given that we are going to work on alternatives. >> >> “… Going to work on …” is the issue. The draft under discussion >> has been > on IETF servers for 2 years. It has been used in other industry forums > for > four or five years. > > Plenty of alternatives have been put forward in those two years, including > EKE+Elligator, SPAKE2, JPAKE, and SMP based solutions. The failure to > advance these is inexplicable. Oh no, it's very easily explained. It's because no one has stepped forward to actually write the I-Ds. You have stated on numerous occasions that these should be written up but you have never actually taken on the task of actually doing it. Please, write up a draft or four. Whether or not you do, though, this really has nothing to do with the RGLC underway right now. If there was a security proof of dragonfly it would not be, nor should it be, part of this draft. It would be a stand-alone paper. The complaint about the lack of a security proof is really procedural and not technical as it is not a comment on the draft that can be resolved by changing the draft. The IRTF (and the IETF as well) has never put a security proof as a process requirement for advancement of I-Ds. You may think it should but that is an argument for a different place, not a RGLC. regards, Dan. >> >> Yes, the cfrg should work as quickly as possible to make alternatives. > Stopping the progression of this draft does not accelerate new work, but > does prevent existing applications from utilizing a reviewed and improved > specification. > > The nonexistence of this draft did not stop adoption in Wifi. By contrast > advancing a number of PAKEs will kick the issue to WGs without the > capacity > to evaluate the issues. > >>> >>> There is plenty of terrible crypto in IEEE standards >> >> … and IETF standards. Bringing in other good or bad protocols into >> the > discussion is irrelevant to the decision at hand. >>> >>> we don't issue drafts for because it is so terrible. >> >> Since when did the IETF mandate a security proof … There are >> terrible > protocols with proofs, so why does the lack of a proof made something > ‘terrible’. >> >> Paul >> >> >> >>> To the extent our publication leads to use of dragonfly as opposed to > known - good protocols, it's a problem. >> >> >> >> >>> > >>> > Considering how difficult previous Last Call on the document was, I > would like to ask people to: >>> > 1) keep in mind that CFRG chairs believe that the RG should work on > PAKE requirements and after that on other PAKE proposals. This was > suggested by our previous co-chair David McGrew: >>> > http://www.ietf.org/mail-archive/web/cfrg/current/msg03723.html >>> >>> Why doesn't this apply to dragonfly, but only other proposals? >>> >>> > 2) be professional, in particular no ad hominem attacks >>> > 3) be constructive. In particular if you would like a disclaimer >>> being > added to the document, please suggest specific text. >>> > 4) simple statements of support for publishing the document or > objection to publishing it are fine and encouraged. Sending them directly > to RG chairs is fine. But please avoid saying "but what about PAKEXXX?", > due to 1). >>> > 5) unlike IETF, IRTF RGs are not required to reach rough consensus. > However I would like to see us try. >>> > >>> > Best Regards, >>> > Alexey, >>> > on behalf of chairs. >>> > >>> > _______________________________________________ >>> > Cfrg mailing list >>> > Cfrg@irtf.org >>> > http://www.irtf.org/mailman/listinfo/cfrg >> >> > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg > From nobody Wed Oct 8 18:01:33 2014 Return-Path: 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 C7D641A87ED for ; Wed, 8 Oct 2014 18:01:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 26yKWfuXW-Nn for ; Wed, 8 Oct 2014 18:01:28 -0700 (PDT) Received: from resqmta-ch2-03v.sys.comcast.net (resqmta-ch2-03v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:35]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94B4E1A02D1 for ; Wed, 8 Oct 2014 18:01:28 -0700 (PDT) Received: from resomta-ch2-13v.sys.comcast.net ([69.252.207.109]) by resqmta-ch2-03v.sys.comcast.net with comcast id 0p1Q1p0032N9P4d01p1TsZ; Thu, 09 Oct 2014 01:01:27 +0000 Received: from [IPv6:::1] ([71.202.164.227]) by resomta-ch2-13v.sys.comcast.net with comcast id 0p1S1p0094uhcbK01p1SFR; Thu, 09 Oct 2014 01:01:27 +0000 Message-ID: <5435DE66.7080803@brainhub.org> Date: Wed, 08 Oct 2014 18:01:26 -0700 From: Andrey Jivsov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: cfrg@irtf.org References: <53F0010B.6080101@brainhub.org> <53F108CF.4040704@brainhub.org> <53F18607.3000005@brainhub.org> <5406C23E.80205@brainhub.org> <5407C176.3000109@brainhub.org> In-Reply-To: <5407C176.3000109@brainhub.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1412816487; bh=5F1GSoge9yBQiGXX/jjGvAP2xclmP90XHyP9l432xMI=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=rzBlIN94HElSaCXkjqJcxeKH7n3A8LMDEfWezp2nwbuTDCJ1x8cg0y7Ne+b50Ci4j XMmuXs2a9JEn8UuYupJjQIL0LMO/o/lf58tmBOnY9An89MXfCEIUaKg2CLwIzqrypa o7Swytv8OSUWQgq2Uc4yqavLhef0A752ZeVCZiii20fzN783/LWUWhVzBSPsJKlD0r C2wcKgwgBkDhLlgMHE5wLAXxSIVcmPYnxWyznCG3enKMkD85mcdABonDxAF0c118Q9 KlLsKuKegvuBBoKowatkb83a00TCiwkPs9JH8GYJaBgvKAW9iBu0kjj3ITvWYRddeQ u7swBbpYdy25w== Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/0CUqbQbp7ysK-QWxKUq_MLHOxxc Subject: Re: [Cfrg] Timing of libsodium, curve25519-donna, MSR ECCLib, and openssl-master X-BeenThere: cfrg@irtf.org 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: Thu, 09 Oct 2014 01:01:31 -0000 Now that the P-256 enhancements are in the OpenSSL tree, let commands speak for themselves. Type in a Linux terminal on a Haswell machine (no HT, no SpeedStep/Turboboost) and observe: 1. P-256: $ git clone git://git.openssl.org/openssl.git A $ cd A $ ./config $ make && apps/openssl speed ecdhp256 15078.1 op/s 2. X25519: $ git clone https://github.com/brainhub/curve25519-donna.git B $ cd B $ make speed-curve25519-donna-c64 && ./speed-curve25519-donna-c64 17289.4 op/s ----------------------------- 17383.6 / 15168.1 = 14.6% faster The difference is about the cost of point decompression/coordinate conversion (e.g. Edwards coordinate conversion to Montgomery + point multiplication would have about the same performance as P-256 point multiplication). From nobody Wed Oct 8 18:22:34 2014 Return-Path: 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 B49E81A8895 for ; Wed, 8 Oct 2014 18:22:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 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, J_CHICKENPOX_39=0.6, SPF_PASS=-0.001] autolearn=no 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 BmoSIhu6_3pR for ; Wed, 8 Oct 2014 18:22:30 -0700 (PDT) Received: from mail-yk0-x22d.google.com (mail-yk0-x22d.google.com [IPv6:2607:f8b0:4002:c07::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6829F1A8891 for ; Wed, 8 Oct 2014 18:22:30 -0700 (PDT) Received: by mail-yk0-f173.google.com with SMTP id 200so132755ykr.32 for ; Wed, 08 Oct 2014 18:22:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=ZK3/x92c5ZoSd2LjjsCVIVCWIc8KXlqWlfZlJdZ9ewA=; b=emP2cmc3L9k11Sd6glNN6Fms8WLvv53USoDoh4rY1T3EGgWFivCkqbdkjrbA2eMeNU c12fOVd530Kv8EuS24hw9btVS+FZes0BkrXdSRfTu1e3bUIi88ZOqTPRygkCAzCalFkf vsJjxYWp4PX0/5MQb3u00rAePEtvohckuaWZM4swRSxIRY7BrQ0P6CMoHmbwfSNyGELv 1C+wRXg+mNg8ar0xtbp80ruK/qYQiMIrwjI03jZDO+tZokrWTBFgFwu7BfZwhjwbSlV+ O6+E0xiiQTP/RdARg09I/o+fNEH++NXsBOe+Mr22c70W+YWjxzP+9tDoozsRUIA2GSwI D55g== MIME-Version: 1.0 X-Received: by 10.236.134.81 with SMTP id r57mr113150yhi.172.1412817749343; Wed, 08 Oct 2014 18:22:29 -0700 (PDT) Received: by 10.170.195.149 with HTTP; Wed, 8 Oct 2014 18:22:29 -0700 (PDT) In-Reply-To: <73d51db893a4b847db6d8eaae7f45cf5.squirrel@www.trepanning.net> References: <54357A2A.2010800@isode.com> <73d51db893a4b847db6d8eaae7f45cf5.squirrel@www.trepanning.net> Date: Wed, 8 Oct 2014 18:22:29 -0700 Message-ID: From: Watson Ladd To: Dan Harkins Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/ORc5df4ZDCaNvBkX-1WSranAPQ0 Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] draft-irtf-cfrg-dragonfly document status X-BeenThere: cfrg@irtf.org 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: Thu, 09 Oct 2014 01:22:32 -0000 On Wed, Oct 8, 2014 at 4:40 PM, Dan Harkins wrote: > > Watson, > > On Wed, October 8, 2014 3:46 pm, Watson Ladd wrote: >> On Oct 8, 2014 3:26 PM, "Paul Lambert" wrote: >>>> >>>> On Oct 8, 2014 10:53 AM, "Alexey Melnikov" >> wrote: >>>> > >>>> > Hi, >>>> > My apologies for taking so long on this. But I felt I needed to >>>> review >> mailing list discussions to make up my own mind on this topic. >>>> > >>>> > After reviewing mailing list discussions about this draft, I would >> like to do another RGLC on it. I've seen negative comments on the mailin= g >> list, but I've also seen some interest in this work and I am also aware >> that some variants of the algorithm are already implemented/deployed. >> Also, >> there were a couple of new revisions of the draft and it is not clear >> whether people who reported original problems are happy with how they go= t >> resolved. So I would like to see a bit more positive feedback on the >> latest >> version, in particular I would like to know if specific issues raised by >> earlier reviews are addressed in the latest version. >>> >>> This draft should be published as an RFC. There is considerable value >>> in >> having a published stable reference document. The market should be >> allowed to do the estimations of risk and value to field this protocol. >> >> Just as they did with RC4 and renegotiation? > > This has nothing to do with RC4 and renegotiation (I assume you mean > in TLS). I'm questioning the ability of market participants to evaluate cryptography= . > >>> >>> Versions of the protocol have been adopted and fied. This protocol was >> first introduced into IEEE 802.11s in 2008. The base protocol exchange >> has >> also been adopted in the Wi-Fi Alliance. The protocol has been improve= d >> by the review in the cfrg and if published, the specification would >> positively impact the application of the protocol in other forums. >>> >>>> My comment (there is no security proof, and alternatives with better >> provable security) has been acknowledged to be unresolveable. >>> >>> Yes, this may be considered a negative point by some but not all. >>> While >> not a proof, the protocol has been analyzed: >>> Cryptanalysis of the Dragonfly Key Exchange Protocol >>> It was interested that the only issue mentioned was a small subgroup >> attack if the public key is not validated =E2=80=A6. which it always sho= uld. >> >> This analysis ignores Rene Struik's timing attack, my reflection attack, >> and other comments incorporated into the draft. > > And I thanked Rene, you, and others for your comments and, as you note, > incorporated resolutions into the draft. Once again, thank you for helpin= g > improve the draft. All of the comments have been resolved in -04. > > (I will note that the reflection attack you mentioned is not possible > in the IEEE 802.11 version of dragonfly, which predated your comment > and this draft by a few years, and neither was small subgroup attack > described by Clarke and Hao mentioned above. The -00 version of this > draft was rushed, take a look at the Acknowledgements in section 4 to > see just how bad, and I left some things out that I shouldn't have. All > this has all been addressed in -04). Why did the draft not track the IEEE 802.11 version? Also, as I remember from discussing this issue in the TLS WG, the CFRG draft version and the TLS draft version differed substantially, enough to make the reflection attack not work. (There were interactions with the rest of TLS that prevented it) While only tangentially relevant to the issue, this is the kind of issue which leads to all sorts of bugs in protocols that should be secure. It also is not clear how relevant the proposed draft will be > >>>> >>>> The draft authors knew this from the very beginning. >>>> >>>> I don't think we should approve a protocol that doesn't have a securit= y >> proof, particularly given that we are going to work on alternatives. >>> >>> =E2=80=9C=E2=80=A6 Going to work on =E2=80=A6=E2=80=9D is the issue. T= he draft under discussion >>> has been >> on IETF servers for 2 years. It has been used in other industry forums >> for >> four or five years. >> >> Plenty of alternatives have been put forward in those two years, includi= ng >> EKE+Elligator, SPAKE2, JPAKE, and SMP based solutions. The failure to >> advance these is inexplicable. > > Oh no, it's very easily explained. It's because no one has stepped forw= ard > to actually write the I-Ds. You have stated on numerous occasions that th= ese > should be written up but you have never actually taken on the task of > actually doing it. Please, write up a draft or four. Whether or not you = do, > though, this really has nothing to do with the RGLC underway right now. JPAKE was described in a series of drafts that weren't made WG work items. I see no reason that the eventual disposition of SPAKE2, SMP, or EKE+Elligator drafts would be any different, and thus see no reason to write the drafts. > > If there was a security proof of dragonfly it would not be, nor should = it > be, part of this draft. It would be a stand-alone paper. The complaint ab= out > the lack of a security proof is really procedural and not technical as it= is > not a comment on the draft that can be resolved by changing the draft. > The IRTF (and the IETF as well) has never put a security proof as a proce= ss > requirement for advancement of I-Ds. You may think it should but that > is an argument for a different place, not a RGLC. It could be resolved by opening the draft, deleting the contents, inserting contents describing a protocol with a security proof and referring to the proof published elsewhere, and submitting the new version, so clearly it is an issue with the contents of the draft. I think what you meant to say is it couldn't be resolved without substantially changing the protocol, which also isn't true: if the shared secret was a hash of all the messages, and the peer-scalars were removed, the result would be a secure PAKE with a security proof. But unfortunately it would be a patented one. There are plenty of drafts that have piled up in various nooks and crannies that never get adopted as WG items, despite requests from authors. I don't see why we need to publish this draft, and I don't see why we need to publish a draft for a protocol inferior to alternatives that have been well-studied and are well-regarded. The argument you are making seems to be that anything will get published, provided it's sufficiently polished, no matter how much better the alternatives are. Sincerely, Watson Ladd > > regards, > > Dan. > >>> >>> Yes, the cfrg should work as quickly as possible to make alternatives. >> Stopping the progression of this draft does not accelerate new work, but >> does prevent existing applications from utilizing a reviewed and improve= d >> specification. >> >> The nonexistence of this draft did not stop adoption in Wifi. By contras= t >> advancing a number of PAKEs will kick the issue to WGs without the >> capacity >> to evaluate the issues. >> >>>> >>>> There is plenty of terrible crypto in IEEE standards >>> >>> =E2=80=A6 and IETF standards. Bringing in other good or bad protocols = into >>> the >> discussion is irrelevant to the decision at hand. >>>> >>>> we don't issue drafts for because it is so terrible. >>> >>> Since when did the IETF mandate a security proof =E2=80=A6 There are >>> terrible >> protocols with proofs, so why does the lack of a proof made something >> =E2=80=98terrible=E2=80=99. >>> >>> Paul >>> >>> >>> >>>> To the extent our publication leads to use of dragonfly as opposed to >> known - good protocols, it's a problem. >>> >>> >>> >>> >>>> > >>>> > Considering how difficult previous Last Call on the document was, I >> would like to ask people to: >>>> > 1) keep in mind that CFRG chairs believe that the RG should work on >> PAKE requirements and after that on other PAKE proposals. This was >> suggested by our previous co-chair David McGrew: >>>> > http://www.ietf.org/mail-archive/web/cfrg/current/msg03723.html >>>> >>>> Why doesn't this apply to dragonfly, but only other proposals? >>>> >>>> > 2) be professional, in particular no ad hominem attacks >>>> > 3) be constructive. In particular if you would like a disclaimer >>>> being >> added to the document, please suggest specific text. >>>> > 4) simple statements of support for publishing the document or >> objection to publishing it are fine and encouraged. Sending them directl= y >> to RG chairs is fine. But please avoid saying "but what about PAKEXXX?", >> due to 1). >>>> > 5) unlike IETF, IRTF RGs are not required to reach rough consensus. >> However I would like to see us try. >>>> > >>>> > Best Regards, >>>> > Alexey, >>>> > on behalf of chairs. >>>> > >>>> > _______________________________________________ >>>> > Cfrg mailing list >>>> > Cfrg@irtf.org >>>> > http://www.irtf.org/mailman/listinfo/cfrg >>> >>> >> _______________________________________________ >> Cfrg mailing list >> Cfrg@irtf.org >> http://www.irtf.org/mailman/listinfo/cfrg >> > --=20 "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Wed Oct 8 18:33:37 2014 Return-Path: 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 3981F1A88FF for ; Wed, 8 Oct 2014 18:33:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 Ax96YPh3f4JA for ; Wed, 8 Oct 2014 18:33:34 -0700 (PDT) Received: from mail-yh0-x22d.google.com (mail-yh0-x22d.google.com [IPv6:2607:f8b0:4002:c01::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E2BC1A88FE for ; Wed, 8 Oct 2014 18:33:34 -0700 (PDT) Received: by mail-yh0-f45.google.com with SMTP id b6so144433yha.32 for ; Wed, 08 Oct 2014 18:33:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=J74nz1VGNetJJH/Yr6xDC/oHl/HrpiTivlmUv3rWyAM=; b=ZJyKn/0TBQZyZCGJbgQNAdHIrYlPH/NZLlkU+QjZtHsgTaXl3bfwm6tQQoq2zaEzm0 1IKyvVD1MBnTajoELpOaEA5tDHgE8NzpbHTj7FBaaAcskpfj/X9TbjoemC1dmhSIrQ++ rO5gCgH2YLNeuyxs8zPQGYoltJ+02CHmlqJ014MzLIvc75PnCMvd+NGx0LzJn1xvTBab ApprSWfWooql13ejL7WpuvDWJy+P72BMymDMrMPhSvAUgTxTD23yKmUejNeWm/OliN0s /B7VpcDIMFQ+2nBeQQqlcUaZRIIE7Lgue9rqqys3AUwmaXqxyOk/cWjvEvol5xa/sQ+L 3HZg== MIME-Version: 1.0 X-Received: by 10.236.132.231 with SMTP id o67mr8910412yhi.146.1412818413778; Wed, 08 Oct 2014 18:33:33 -0700 (PDT) Received: by 10.170.195.149 with HTTP; Wed, 8 Oct 2014 18:33:33 -0700 (PDT) In-Reply-To: <2FBC676C3BBFBB4AA82945763B361DE608F1D021@MX17A.corp.emc.com> References: <20141008173154.15169.qmail@cr.yp.to> <2FBC676C3BBFBB4AA82945763B361DE608F1D021@MX17A.corp.emc.com> Date: Wed, 8 Oct 2014 18:33:33 -0700 Message-ID: From: Watson Ladd To: "Parkinson, Sean" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/wb83OmYkjXvNLaHiC-7gxXifP7A Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] When's the decision? X-BeenThere: cfrg@irtf.org 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: Thu, 09 Oct 2014 01:33:36 -0000 On Wed, Oct 8, 2014 at 3:51 PM, Parkinson, Sean wr= ote: > I have concerns about a decision being made about which curves to recomme= nd 'before Halloween'. > I am unaware of 3rd parties implementing and confirming all the curves th= at have been proposed. > Making a decision on new elliptic curves based on data that hasn't been c= orroborated by a 3rd party is bad practice. As far as I can tell, the implementations are all publicly available, and I believe recent eBATS has included quite a few. > > I have been implementing as many of the curves as I can and my performanc= e results, so far, do not always match those that I have seen in papers. How good are your implementations? Being fast is hard. > > Also, I am concerned that, while some curves are being implemented to be = constant time, not all curves are being implemented to be cache attack resi= stant. Either all implementations need to be resistant or all implementatio= ns not. Only then can a true comparison be made. All of them should be: this is annoying but straightforward to check by looking at implementations. > > Until these issues are dealt with I feel there is not sufficient informat= ion to make a decision. Most of this information is independent of which parameters are picked. > > Sean > -- > Sean Parkinson | Consultant Software Engineer | RSA, The Security Divisio= n of EMC > Office +61 7 3032 5232 | Fax +61 7 3032 5299 > www.rsa.com > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg --=20 "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Wed Oct 8 18:56:08 2014 Return-Path: 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 9662D1A8940 for ; Wed, 8 Oct 2014 18:56:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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 NIMTXuz3k9bh for ; Wed, 8 Oct 2014 18:56:03 -0700 (PDT) Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9551C1A893F for ; Wed, 8 Oct 2014 18:56:03 -0700 (PDT) Received: from maildlpprd02.lss.emc.com (maildlpprd02.lss.emc.com [10.253.24.34]) by mailuogwprd02.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s991twWe006096 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 8 Oct 2014 21:56:00 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd02.lss.emc.com s991twWe006096 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=rsa.com; s=jan2013; t=1412819760; bh=iMG3h0MXT4Jg5rfAAZYcjuzo3Ig=; h=From:To:CC:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=wUN9Xp34thMS+Aq+bEbRQo34qZb5xhT6n10pNepL9NQrgYYl10OToh7w6UQbogwUf WzIyL3V8bF6klGNgda6xfGcJqwds+HqrQnq+WF1+TwiXylFnSEYq618Q5kPyUdsUur LmE6/0Cpeb1ryIOBMTjtni17QGvaYdwtbCu+WgWI= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd02.lss.emc.com s991twWe006096 Received: from mailusrhubprd03.lss.emc.com (mailusrhubprd03.lss.emc.com [10.253.24.21]) by maildlpprd02.lss.emc.com (RSA Interceptor); Wed, 8 Oct 2014 21:55:25 -0400 Received: from mxhub32.corp.emc.com (mxhub32.corp.emc.com [128.222.70.172]) by mailusrhubprd03.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s991tl2g023105 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 8 Oct 2014 21:55:47 -0400 Received: from mx17a.corp.emc.com ([169.254.1.209]) by mxhub32.corp.emc.com ([128.222.70.172]) with mapi; Wed, 8 Oct 2014 21:55:46 -0400 From: "Parkinson, Sean" To: Watson Ladd Date: Wed, 8 Oct 2014 21:55:45 -0400 Thread-Topic: [Cfrg] When's the decision? Thread-Index: Ac/jYQ0p9045dS/3TWG2Bp0aKNa3gwAALJ9A Message-ID: <2FBC676C3BBFBB4AA82945763B361DE608F1D036@MX17A.corp.emc.com> References: <20141008173154.15169.qmail@cr.yp.to> <2FBC676C3BBFBB4AA82945763B361DE608F1D021@MX17A.corp.emc.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd03.lss.emc.com X-RSA-Classifications: DLM_1, public Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/7GfwYUcdvDiAu8c2ROdQ1BUVs7g Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] When's the decision? X-BeenThere: cfrg@irtf.org 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: Thu, 09 Oct 2014 01:56:05 -0000 Tm90IGFsbCBjdXJ2ZXMgYXJlIGltcGxlbWVudGVkIGluIGEgY29tbW9uIHBsYWNlLiBDb21wYXJp c29ucyBuZWVkIHRvIGJlIG1hZGUgYmV0d2VlbiAnZXF1YWwnIGltcGxlbWVudGF0aW9ucy4NCklz IHRoZXJlIGEgY29tcGxldGUgbGlzdCBvZiBjdXJ2ZXMgdW5kZXIgY29uc2lkZXJhdGlvbj8NCg0K Rm9yIGxlZ2FsIHJlYXNvbnMgSSdtIG5vdCBnb2luZyB0byBiZSBhYmxlIHRvIGxvb2sgYXQgc29t ZSBsaWJyYXJpZXMuDQpJZiBzb21lb25lIGNhbiBjb25maXJtIG9uZSB3YXkgb3IgYW5vdGhlciBp dCB3b3VsZCBiZSBhcHByZWNpYXRlZC4NCg0KSSBiZWxpZXZlIG1pdGlnYXRpbmcgdGhlIGNhY2hl IGF0dGFjayBoYXMgYSBzaWduaWZpY2FudCBlZmZlY3Qgb24gdGhlIHBlcmZvcm1hbmNlIG9mIFR3 aXN0ZWQgRWR3YXJkcyBjdXJ2ZXMuIElmIHdlIGlnbm9yZSB0aGlzIGF0dGFjayB0aGVuIGhvdyBh IE1vbnRnb21lcnkgY3VydmUgaXMgaW1wbGVtZW50ZWQgY2hhbmdlcyBhbmQgdGhpcyBtYXkgc3dp bmcgdGhlIGFkdmFudGFnZSBiYWNrIHRvIHVzaW5nIE1vbnRnb21lcnkgZm9yIGtleSBleGNoYW5n ZSBhbmQgVHdpc3RlZCBFZHdhcmRzIGZvciBzaWduYXR1cmVzLg0KDQpJZiBhIGxhcmdlciBiaXQg bGVuZ3RoIGN1cnZlIHdhcyBhcyBmYXN0IGFzIG9yIGZhc3RlciB0aGFuIGEgY3VydmUgdGhhdCBp cyBhIG11bHRpcGxlIG9mIDEyOCBiaXRzIHdvdWxkIHRoaXMgY2hhbmdlIHRoZSBkZWNpc2lvbj8N Cg0KU2Vhbg0KLS0NClNlYW4gUGFya2luc29uIHwgQ29uc3VsdGFudCBTb2Z0d2FyZSBFbmdpbmVl ciB8IFJTQSwgVGhlIFNlY3VyaXR5IERpdmlzaW9uwqBvZiBFTUMNCk9mZmljZSArNjEgNyAzMDMy IDUyMzIgfCBGYXggKzYxIDcgMzAzMiA1Mjk5DQp3d3cucnNhLmNvbQ0KDQoNCi0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBXYXRzb24gTGFkZCBbbWFpbHRvOndhdHNvbmJsYWRkQGdt YWlsLmNvbV0gDQpTZW50OiBUaHVyc2RheSwgOSBPY3RvYmVyIDIwMTQgMTE6MzQgQU0NClRvOiBQ YXJraW5zb24sIFNlYW4NCkNjOiBjZnJnQGlydGYub3JnDQpTdWJqZWN0OiBSZTogW0NmcmddIFdo ZW4ncyB0aGUgZGVjaXNpb24/DQoNCk9uIFdlZCwgT2N0IDgsIDIwMTQgYXQgMzo1MSBQTSwgUGFy a2luc29uLCBTZWFuIDxzZWFuLnBhcmtpbnNvbkByc2EuY29tPiB3cm90ZToNCj4gSSBoYXZlIGNv bmNlcm5zIGFib3V0IGEgZGVjaXNpb24gYmVpbmcgbWFkZSBhYm91dCB3aGljaCBjdXJ2ZXMgdG8g cmVjb21tZW5kICdiZWZvcmUgSGFsbG93ZWVuJy4NCj4gSSBhbSB1bmF3YXJlIG9mIDNyZCBwYXJ0 aWVzIGltcGxlbWVudGluZyBhbmQgY29uZmlybWluZyBhbGwgdGhlIGN1cnZlcyB0aGF0IGhhdmUg YmVlbiBwcm9wb3NlZC4NCj4gTWFraW5nIGEgZGVjaXNpb24gb24gbmV3IGVsbGlwdGljIGN1cnZl cyBiYXNlZCBvbiBkYXRhIHRoYXQgaGFzbid0IGJlZW4gY29ycm9ib3JhdGVkIGJ5IGEgM3JkIHBh cnR5IGlzIGJhZCBwcmFjdGljZS4NCg0KQXMgZmFyIGFzIEkgY2FuIHRlbGwsIHRoZSBpbXBsZW1l bnRhdGlvbnMgYXJlIGFsbCBwdWJsaWNseSBhdmFpbGFibGUsIGFuZCBJIGJlbGlldmUgcmVjZW50 IGVCQVRTIGhhcyBpbmNsdWRlZCBxdWl0ZSBhIGZldy4NCj4NCj4gSSBoYXZlIGJlZW4gaW1wbGVt ZW50aW5nIGFzIG1hbnkgb2YgdGhlIGN1cnZlcyBhcyBJIGNhbiBhbmQgbXkgcGVyZm9ybWFuY2Ug cmVzdWx0cywgc28gZmFyLCBkbyBub3QgYWx3YXlzIG1hdGNoIHRob3NlIHRoYXQgSSBoYXZlIHNl ZW4gaW4gcGFwZXJzLg0KDQpIb3cgZ29vZCBhcmUgeW91ciBpbXBsZW1lbnRhdGlvbnM/IEJlaW5n IGZhc3QgaXMgaGFyZC4NCg0KPg0KPiBBbHNvLCBJIGFtIGNvbmNlcm5lZCB0aGF0LCB3aGlsZSBz b21lIGN1cnZlcyBhcmUgYmVpbmcgaW1wbGVtZW50ZWQgdG8gYmUgY29uc3RhbnQgdGltZSwgbm90 IGFsbCBjdXJ2ZXMgYXJlIGJlaW5nIGltcGxlbWVudGVkIHRvIGJlIGNhY2hlIGF0dGFjayByZXNp c3RhbnQuIEVpdGhlciBhbGwgaW1wbGVtZW50YXRpb25zIG5lZWQgdG8gYmUgcmVzaXN0YW50IG9y IGFsbCBpbXBsZW1lbnRhdGlvbnMgbm90LiBPbmx5IHRoZW4gY2FuIGEgdHJ1ZSBjb21wYXJpc29u IGJlIG1hZGUuDQoNCkFsbCBvZiB0aGVtIHNob3VsZCBiZTogdGhpcyBpcyBhbm5veWluZyBidXQg c3RyYWlnaHRmb3J3YXJkIHRvIGNoZWNrIGJ5IGxvb2tpbmcgYXQgaW1wbGVtZW50YXRpb25zLg0K Pg0KPiBVbnRpbCB0aGVzZSBpc3N1ZXMgYXJlIGRlYWx0IHdpdGggSSBmZWVsIHRoZXJlIGlzIG5v dCBzdWZmaWNpZW50IGluZm9ybWF0aW9uIHRvIG1ha2UgYSBkZWNpc2lvbi4NCg0KTW9zdCBvZiB0 aGlzIGluZm9ybWF0aW9uIGlzIGluZGVwZW5kZW50IG9mIHdoaWNoIHBhcmFtZXRlcnMgYXJlIHBp Y2tlZC4NCg0KPg0KPiBTZWFuDQo+IC0tDQo+IFNlYW4gUGFya2luc29uIHwgQ29uc3VsdGFudCBT b2Z0d2FyZSBFbmdpbmVlciB8IFJTQSwgVGhlIFNlY3VyaXR5IA0KPiBEaXZpc2lvbiBvZiBFTUMg T2ZmaWNlICs2MSA3IDMwMzIgNTIzMiB8IEZheCArNjEgNyAzMDMyIDUyOTkgDQo+IHd3dy5yc2Eu Y29tDQo+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+IENmcmcgbWFpbGluZyBsaXN0DQo+IENmcmdAaXJ0Zi5vcmcNCj4gaHR0cDovL3d3dy5pcnRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NmcmcNCg0KDQoNCi0tDQoiVGhvc2Ugd2hvIHdvdWxkIGdp dmUgdXAgRXNzZW50aWFsIExpYmVydHkgdG8gcHVyY2hhc2UgYSBsaXR0bGUgVGVtcG9yYXJ5IFNh ZmV0eSBkZXNlcnZlIG5laXRoZXIgIExpYmVydHkgbm9yIFNhZmV0eS4iDQotLSBCZW5qYW1pbiBG cmFua2xpbg0K From nobody Wed Oct 8 19:02:38 2014 Return-Path: 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 8BEEA1A8977 for ; Wed, 8 Oct 2014 19:02:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.586 X-Spam-Level: X-Spam-Status: No, score=-3.586 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786] 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 AyLoEho8-mgx for ; Wed, 8 Oct 2014 19:02:32 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C09A1A8974 for ; Wed, 8 Oct 2014 19:02:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1412820153; x=1444356153; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=UDo2FcMYi8D5X3DYvWB5t5FKKQ8PYEwHEdJH4TwOFfA=; b=dBloquBC+MvZ0taKfajwKhgoILSZ6bd1KvBYRnk6JyYnDkcnOD4s5Wc9 ufpCZFxGAVmSo3Nai7g4tgHxzXJlT5KG7+zoy5UrLuh2isyTmr4GfO54Q 5+MvQbrq545O5KEfkV0DYiWM6GVktQ1acf2mi4Eh03PkmFe5JyXgesLqR E=; X-IronPort-AV: E=Sophos;i="5.04,630,1406548800"; d="scan'208";a="281725252" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.106 - Outgoing - Outgoing Received: from uxchange10-fe2.uoa.auckland.ac.nz ([130.216.4.106]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 09 Oct 2014 15:02:28 +1300 Received: from UXCN10-TDC05.UoA.auckland.ac.nz ([169.254.9.70]) by uxchange10-fe2.UoA.auckland.ac.nz ([169.254.27.86]) with mapi id 14.03.0174.001; Thu, 9 Oct 2014 15:02:26 +1300 From: Peter Gutmann To: "'cfrg@irtf.org'" Thread-Topic: [Cfrg] draft-irtf-cfrg-dragonfly document status Thread-Index: Ac/jZRJm/JHh8KuIQ2Ogq3JzevkqGg== Date: Thu, 9 Oct 2014 02:02:25 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C739B9C583C@uxcn10-tdc05.UoA.auckland.ac.nz> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/3MA8O70BBO3uuGp9wSbZZw0VMA0 Subject: Re: [Cfrg] draft-irtf-cfrg-dragonfly document status X-BeenThere: cfrg@irtf.org 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: Thu, 09 Oct 2014 02:02:37 -0000 Watson Ladd writes:=0A= =0A= >I'm questioning the ability of market participants to evaluate cryptograph= y.=0A= =0A= Market participants are almost totally unable to evaluate cryptography,=0A= because they're bankers, shopkeepers, hardware engineers, software develope= rs,=0A= and so on, not security geeks. In my experience of dealing with lots (and= =0A= lots and lots) of users of crypto, products are evaluated, in the rare case= s=0A= when they've evaluated on something other than "this is what the vendor sol= d=0A= us", as:=0A= =0A= 1. The standard says do this (with a side-order of "we've always used doubl= e=0A= rot-13 and if you squint at the standard just right then there's nothing= =0A= there prohibiting this so we'll keep using it", which is why I've been a= n=0A= advocate of strong MUST NOTs in standards in the past).=0A= =0A= 2. We ran a speed test and their AES is 15% faster than your AES, we'll go= =0A= with their TLS/SSH/SMIME/whatever stack.=0A= =0A= Occasionally if they're a very large corporate or bank they'll hire in a st= ar=0A= mathematician from somewhere who'll advise them on what crypto to use, whic= h=0A= will invariably be something whose ideal target platform is a slide project= or.=0A= =0A= So, market participants cannot, and more importantly should not be required= to=0A= evaluate crypto. That's what we're here for. If we can't do that then we'= re=0A= not doing our job.=0A= =0A= Peter.= From nobody Wed Oct 8 19:05:25 2014 Return-Path: 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 4506F1A8978 for ; Wed, 8 Oct 2014 19:05:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.555 X-Spam-Level: * X-Spam-Status: No, score=1.555 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.982, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no 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 ikFnZkDkyMjW for ; Wed, 8 Oct 2014 19:05:21 -0700 (PDT) Received: from aspartame.shiftleft.org (199-116-74-168-v301.PUBLIC.monkeybrains.net [199.116.74.168]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A9471A897A for ; Wed, 8 Oct 2014 19:05:20 -0700 (PDT) Received: from [10.184.148.249] (unknown [209.36.6.242]) by aspartame.shiftleft.org (Postfix) with ESMTPSA id 5155B3AA13; Wed, 8 Oct 2014 19:03:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=shiftleft.org; s=sldo; t=1412820234; bh=AUA0aKoEVwpb7MvWgxSeLRGz8yGQaYoR+Iff4PmVrJc=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=O91KnDm29+s0tJLaibqoosRw5g0PZOuQRuLTg66M029TpVjG2FR0Y/o5OwgzM2u+Z gGPFiUN70t/3TI4NQQNtWDsFfiWElDmgYZMNuAlkiqMP5QR9cQbb+xK0YpMnUFotf3 k5i9/CQDCEhr3SuLkWFIV26WLAmG0PwQMrN4yl2c= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Michael Hamburg In-Reply-To: <5435DE66.7080803@brainhub.org> Date: Wed, 8 Oct 2014 19:05:18 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <29E067B7-C1F3-427C-8E4A-14F2096A71E4@shiftleft.org> References: <53F0010B.6080101@brainhub.org> <53F108CF.4040704@brainhub.org> <53F18607.3000005@brainhub.org> <5406C23E.80205@brainhub.org> <5407C176.3000109@brainhub.org> <5435DE66.7080803@brainhub.org> To: Andrey Jivsov X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/u5HNJDDlY8brRcNcFLKVf0FJ9Qg Cc: cfrg@irtf.org Subject: Re: [Cfrg] Timing of libsodium, curve25519-donna, MSR ECCLib, and openssl-master X-BeenThere: cfrg@irtf.org 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: Thu, 09 Oct 2014 02:05:23 -0000 Whoa, they improved the performance by 50% since the paper and initial = patch?! > On Oct 8, 2014, at 6:01 PM, Andrey Jivsov wrote: >=20 > Now that the P-256 enhancements are in the OpenSSL tree, let commands = speak for themselves. >=20 > Type in a Linux terminal on a Haswell machine (no HT, no = SpeedStep/Turboboost) and observe: >=20 > 1. P-256: >=20 > $ git clone git://git.openssl.org/openssl.git A > $ cd A > $ ./config > $ make && apps/openssl speed ecdhp256 >=20 > 15078.1 op/s >=20 > 2. X25519: >=20 > $ git clone https://github.com/brainhub/curve25519-donna.git B > $ cd B > $ make speed-curve25519-donna-c64 && ./speed-curve25519-donna-c64 >=20 > 17289.4 op/s >=20 > ----------------------------- >=20 > 17383.6 / 15168.1 =3D 14.6% faster >=20 > The difference is about the cost of point decompression/coordinate = conversion (e.g. Edwards coordinate conversion to Montgomery + point = multiplication would have about the same performance as P-256 point = multiplication). >=20 > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg From nobody Wed Oct 8 20:42:36 2014 Return-Path: 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 05FC31A8AD8 for ; Wed, 8 Oct 2014 20:42:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.555 X-Spam-Level: * X-Spam-Status: No, score=1.555 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.982, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no 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 0bEhhwxO5hrG for ; Wed, 8 Oct 2014 20:42:33 -0700 (PDT) Received: from aspartame.shiftleft.org (199-116-74-168-v301.PUBLIC.monkeybrains.net [199.116.74.168]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D225E1A8AD6 for ; Wed, 8 Oct 2014 20:42:33 -0700 (PDT) Received: from [192.168.1.124] (unknown [192.168.1.1]) by aspartame.shiftleft.org (Postfix) with ESMTPSA id BE60D3AA13; Wed, 8 Oct 2014 20:41:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=shiftleft.org; s=sldo; t=1412826067; bh=VKAL5ZKAIu2B9g8XWaiuD73A4A4bhDJ3myo4wGm8L5E=; h=Date:From:To:CC:Subject:References:In-Reply-To:From; b=cJyfmAuiyaEd82ZdScD3MvtKCHmm+Q8US3lUbkIxkmDBd8brSmZl1Dg1a8DZPrbGm w4Pjnb995uY8vPkt4RnJCn5f4REo0ysQiFQ1BsOlIXkgEU3WJHCO1LkKCNd0i2m7kr qTKHWFZ7mbVPqZjqkiq6imXCfVFTdKNpby3ENqE8= Message-ID: <54360428.6090801@shiftleft.org> Date: Wed, 08 Oct 2014 20:42:32 -0700 From: Mike Hamburg User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: "Parkinson, Sean" , Watson Ladd References: <20141008173154.15169.qmail@cr.yp.to> <2FBC676C3BBFBB4AA82945763B361DE608F1D021@MX17A.corp.emc.com> <2FBC676C3BBFBB4AA82945763B361DE608F1D036@MX17A.corp.emc.com> In-Reply-To: <2FBC676C3BBFBB4AA82945763B361DE608F1D036@MX17A.corp.emc.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/SL-ZgRaK5RW82e3Qt73MDbCnWno Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] When's the decision? X-BeenThere: cfrg@irtf.org 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: Thu, 09 Oct 2014 03:42:35 -0000 On 10/08/2014 06:55 PM, Parkinson, Sean wrote: > Not all curves are implemented in a common place. Comparisons need to be made between 'equal' implementations. > Is there a complete list of curves under consideration? Supposedly we're still in the "collecting requirements" phase. But IIRC, these have come up: * Curve25519 * MS NUMS ed-{256,384,512}-mers * The untwisted Edwards curves which are isogenous to the NUMS curves, or some other minor variant * Curve41417 * Ed448-Goldilocks * E-521 > For legal reasons I'm not going to be able to look at some libraries. > If someone can confirm one way or another it would be appreciated. > > I believe mitigating the cache attack has a significant effect on the performance of Twisted Edwards curves. If we ignore this attack then how a Montgomery curve is implemented changes and this may swing the advantage back to using Montgomery for key exchange and Twisted Edwards for signatures. The Goldilocks microbenchmarks include measurements of a 5-bit SABS fixed-window algorithm with and without constant-time table lookups. By those numbers, the lookup costs about 6% of the total time on Haswell, 10% on Tegra2 (ARM Cortex-A9, no NEON) and a whopping 14% on BeagleBone (ARM Cortex-A8, NEON). This is a large part of why the Montgomery ladder is faster, especially on NEON. But it's still not *that* much faster. > If a larger bit length curve was as fast as or faster than a curve that is a multiple of 128 bits would this change the decision? > > Sean This is basically the point of Ed448-Goldilocks. It's received a mixed response in this forum, since some people would prefer the most constrained curve, for some definition of "constrained" which doesn't consider performance. Cheers, -- Mike > -- > Sean Parkinson | Consultant Software Engineer | RSA, The Security Division of EMC > Office +61 7 3032 5232 | Fax +61 7 3032 5299 > www.rsa.com > > > -----Original Message----- > From: Watson Ladd [mailto:watsonbladd@gmail.com] > Sent: Thursday, 9 October 2014 11:34 AM > To: Parkinson, Sean > Cc: cfrg@irtf.org > Subject: Re: [Cfrg] When's the decision? > > On Wed, Oct 8, 2014 at 3:51 PM, Parkinson, Sean wrote: >> I have concerns about a decision being made about which curves to recommend 'before Halloween'. >> I am unaware of 3rd parties implementing and confirming all the curves that have been proposed. >> Making a decision on new elliptic curves based on data that hasn't been corroborated by a 3rd party is bad practice. > As far as I can tell, the implementations are all publicly available, and I believe recent eBATS has included quite a few. >> I have been implementing as many of the curves as I can and my performance results, so far, do not always match those that I have seen in papers. > How good are your implementations? Being fast is hard. > >> Also, I am concerned that, while some curves are being implemented to be constant time, not all curves are being implemented to be cache attack resistant. Either all implementations need to be resistant or all implementations not. Only then can a true comparison be made. > All of them should be: this is annoying but straightforward to check by looking at implementations. >> Until these issues are dealt with I feel there is not sufficient information to make a decision. > Most of this information is independent of which parameters are picked. > >> Sean >> -- >> Sean Parkinson | Consultant Software Engineer | RSA, The Security >> Division of EMC Office +61 7 3032 5232 | Fax +61 7 3032 5299 >> www.rsa.com >> >> _______________________________________________ >> Cfrg mailing list >> Cfrg@irtf.org >> http://www.irtf.org/mailman/listinfo/cfrg > > > -- > "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." > -- Benjamin Franklin > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg From nobody Wed Oct 8 21:13:33 2014 Return-Path: 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 CF0471A8BC3 for ; Wed, 8 Oct 2014 21:13:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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 4EYLflVe5HPF for ; Wed, 8 Oct 2014 21:13:27 -0700 (PDT) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94B021A8AE3 for ; Wed, 8 Oct 2014 21:13:27 -0700 (PDT) Received: from maildlpprd53.lss.emc.com (maildlpprd53.lss.emc.com [10.106.48.157]) by mailuogwprd53.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s994DOwh027575 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Oct 2014 00:13:25 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com s994DOwh027575 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=rsa.com; s=jan2013; t=1412828005; bh=P+YDGIapy6ptIdVv/feKGxXyh1Q=; h=From:To:CC:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=TKmsUizWgE2loMMhzWavGn8nZEBSNK6M82MGoBOv6aHYpWM0bRlVuIvX7va5wpA3Q PKTJQtZsDrieTUJjqrfSQnyupG+mKI3dqma293czCKtyBq5e2Yn09TQwVl75Yfmji5 FRq7RnYsbaZHvGfdib09UX/r9WIwOdeA7QHWePL0= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com s994DOwh027575 Received: from mailusrhubprd01.lss.emc.com (mailusrhubprd01.lss.emc.com [10.253.24.19]) by maildlpprd53.lss.emc.com (RSA Interceptor); Thu, 9 Oct 2014 00:12:44 -0400 Received: from mxhub32.corp.emc.com (mxhub32.corp.emc.com [128.222.70.172]) by mailusrhubprd01.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s994D83u020740 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 9 Oct 2014 00:13:08 -0400 Received: from mx17a.corp.emc.com ([169.254.1.209]) by mxhub32.corp.emc.com ([128.222.70.172]) with mapi; Thu, 9 Oct 2014 00:13:08 -0400 From: "Parkinson, Sean" To: Mike Hamburg , Watson Ladd Date: Thu, 9 Oct 2014 00:13:04 -0400 Thread-Topic: [Cfrg] When's the decision? Thread-Index: Ac/jcxMtwd6yY766TvWuqe8d9B3vqwAAHAMQ Message-ID: <2FBC676C3BBFBB4AA82945763B361DE608F1D049@MX17A.corp.emc.com> References: <20141008173154.15169.qmail@cr.yp.to> <2FBC676C3BBFBB4AA82945763B361DE608F1D021@MX17A.corp.emc.com> <2FBC676C3BBFBB4AA82945763B361DE608F1D036@MX17A.corp.emc.com> <54360428.6090801@shiftleft.org> In-Reply-To: <54360428.6090801@shiftleft.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd01.lss.emc.com X-RSA-Classifications: DLM_1, public Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/fa_ZbHY1BqmoF-XQ5CN78lV72-4 Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] When's the decision? X-BeenThere: cfrg@irtf.org 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: Thu, 09 Oct 2014 04:13:31 -0000 VGhhbmtzIE1pa2UuIFRoZXNlIGFyZSB0aGUgY3VydmVzIEkgd2FzIHRoaW5raW5nIGFyZSB1bmRl ciBjb25zaWRlcmF0aW9uLg0KDQpJIHRob3VnaHQgdGhlIG1pdGlnYXRpb24gdG8gdGhlIGNhY2hl IHNpZGUtY2hhbm5lbCBhdHRhY2sgaW4gT3BlblNTTCB3YXMgdG8gcmVhZC93cml0ZSBhbGwgZW50 cmllcyByYXRoZXIgdGhhbiB0byB1c2UgYW4gaW5kZXggdGhhdCBpcyBkYXRhIGRlcGVuZGVudC4g UGxlYXNlIGNvcnJlY3QgbWUgaWYgSSdtIHdyb25nLg0KDQpTZWFuDQotLQ0KU2VhbiBQYXJraW5z b24gfCBDb25zdWx0YW50IFNvZnR3YXJlIEVuZ2luZWVyIHwgUlNBLCBUaGUgU2VjdXJpdHkgRGl2 aXNpb27CoG9mIEVNQw0KT2ZmaWNlICs2MSA3IDMwMzIgNTIzMiB8IEZheCArNjEgNyAzMDMyIDUy OTkNCnd3dy5yc2EuY29tDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IE1p a2UgSGFtYnVyZyBbbWFpbHRvOm1pa2VAc2hpZnRsZWZ0Lm9yZ10gDQpTZW50OiBUaHVyc2RheSwg OSBPY3RvYmVyIDIwMTQgMTo0MyBQTQ0KVG86IFBhcmtpbnNvbiwgU2VhbjsgV2F0c29uIExhZGQN CkNjOiBjZnJnQGlydGYub3JnDQpTdWJqZWN0OiBSZTogW0NmcmddIFdoZW4ncyB0aGUgZGVjaXNp b24/DQoNCg0KT24gMTAvMDgvMjAxNCAwNjo1NSBQTSwgUGFya2luc29uLCBTZWFuIHdyb3RlOg0K PiBOb3QgYWxsIGN1cnZlcyBhcmUgaW1wbGVtZW50ZWQgaW4gYSBjb21tb24gcGxhY2UuIENvbXBh cmlzb25zIG5lZWQgdG8gYmUgbWFkZSBiZXR3ZWVuICdlcXVhbCcgaW1wbGVtZW50YXRpb25zLg0K PiBJcyB0aGVyZSBhIGNvbXBsZXRlIGxpc3Qgb2YgY3VydmVzIHVuZGVyIGNvbnNpZGVyYXRpb24/ DQpTdXBwb3NlZGx5IHdlJ3JlIHN0aWxsIGluIHRoZSAiY29sbGVjdGluZyByZXF1aXJlbWVudHMi IHBoYXNlLg0KDQpCdXQgSUlSQywgdGhlc2UgaGF2ZSBjb21lIHVwOg0KKiBDdXJ2ZTI1NTE5DQoq IE1TIE5VTVMgZWQtezI1NiwzODQsNTEyfS1tZXJzDQoqIFRoZSB1bnR3aXN0ZWQgRWR3YXJkcyBj dXJ2ZXMgd2hpY2ggYXJlIGlzb2dlbm91cyB0byB0aGUgTlVNUyBjdXJ2ZXMsIG9yIHNvbWUgb3Ro ZXIgbWlub3IgdmFyaWFudA0KKiBDdXJ2ZTQxNDE3DQoqIEVkNDQ4LUdvbGRpbG9ja3MNCiogRS01 MjENCg0KPiBGb3IgbGVnYWwgcmVhc29ucyBJJ20gbm90IGdvaW5nIHRvIGJlIGFibGUgdG8gbG9v ayBhdCBzb21lIGxpYnJhcmllcy4NCj4gSWYgc29tZW9uZSBjYW4gY29uZmlybSBvbmUgd2F5IG9y IGFub3RoZXIgaXQgd291bGQgYmUgYXBwcmVjaWF0ZWQuDQo+DQo+IEkgYmVsaWV2ZSBtaXRpZ2F0 aW5nIHRoZSBjYWNoZSBhdHRhY2sgaGFzIGEgc2lnbmlmaWNhbnQgZWZmZWN0IG9uIHRoZSBwZXJm b3JtYW5jZSBvZiBUd2lzdGVkIEVkd2FyZHMgY3VydmVzLiBJZiB3ZSBpZ25vcmUgdGhpcyBhdHRh Y2sgdGhlbiBob3cgYSBNb250Z29tZXJ5IGN1cnZlIGlzIGltcGxlbWVudGVkIGNoYW5nZXMgYW5k IHRoaXMgbWF5IHN3aW5nIHRoZSBhZHZhbnRhZ2UgYmFjayB0byB1c2luZyBNb250Z29tZXJ5IGZv ciBrZXkgZXhjaGFuZ2UgYW5kIFR3aXN0ZWQgRWR3YXJkcyBmb3Igc2lnbmF0dXJlcy4NClRoZSBH b2xkaWxvY2tzIG1pY3JvYmVuY2htYXJrcyBpbmNsdWRlIG1lYXN1cmVtZW50cyBvZiBhIDUtYml0 IFNBQlMgZml4ZWQtd2luZG93IGFsZ29yaXRobSB3aXRoIGFuZCB3aXRob3V0IGNvbnN0YW50LXRp bWUgdGFibGUgbG9va3Vwcy4gIEJ5IHRob3NlIG51bWJlcnMsIHRoZSBsb29rdXAgY29zdHMgYWJv dXQgNiUgb2YgdGhlIHRvdGFsIHRpbWUgb24gSGFzd2VsbCwgMTAlIG9uIFRlZ3JhMiAoQVJNIENv cnRleC1BOSwgbm8gTkVPTikgYW5kIGEgd2hvcHBpbmcgMTQlIG9uIEJlYWdsZUJvbmUgKEFSTSBD b3J0ZXgtQTgsIE5FT04pLiAgVGhpcyBpcyBhIGxhcmdlIHBhcnQgb2Ygd2h5IHRoZSBNb250Z29t ZXJ5IGxhZGRlciBpcyBmYXN0ZXIsIGVzcGVjaWFsbHkgb24gTkVPTi4gQnV0IGl0J3Mgc3RpbGwg bm90ICp0aGF0KiBtdWNoIGZhc3Rlci4NCj4gSWYgYSBsYXJnZXIgYml0IGxlbmd0aCBjdXJ2ZSB3 YXMgYXMgZmFzdCBhcyBvciBmYXN0ZXIgdGhhbiBhIGN1cnZlIHRoYXQgaXMgYSBtdWx0aXBsZSBv ZiAxMjggYml0cyB3b3VsZCB0aGlzIGNoYW5nZSB0aGUgZGVjaXNpb24/DQo+DQo+IFNlYW4NClRo aXMgaXMgYmFzaWNhbGx5IHRoZSBwb2ludCBvZiBFZDQ0OC1Hb2xkaWxvY2tzLiAgSXQncyByZWNl aXZlZCBhIG1peGVkIHJlc3BvbnNlIGluIHRoaXMgZm9ydW0sIHNpbmNlIHNvbWUgcGVvcGxlIHdv dWxkIHByZWZlciB0aGUgbW9zdCBjb25zdHJhaW5lZCBjdXJ2ZSwgZm9yIHNvbWUgZGVmaW5pdGlv biBvZiAiY29uc3RyYWluZWQiIHdoaWNoIGRvZXNuJ3QgY29uc2lkZXIgcGVyZm9ybWFuY2UuDQoN CkNoZWVycywNCi0tIE1pa2UNCg0KDQo+IC0tDQo+IFNlYW4gUGFya2luc29uIHwgQ29uc3VsdGFu dCBTb2Z0d2FyZSBFbmdpbmVlciB8IFJTQSwgVGhlIFNlY3VyaXR5IA0KPiBEaXZpc2lvbiBvZiBF TUMgT2ZmaWNlICs2MSA3IDMwMzIgNTIzMiB8IEZheCArNjEgNyAzMDMyIDUyOTkgDQo+IHd3dy5y c2EuY29tDQo+DQo+DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IFdhdHNv biBMYWRkIFttYWlsdG86d2F0c29uYmxhZGRAZ21haWwuY29tXQ0KPiBTZW50OiBUaHVyc2RheSwg OSBPY3RvYmVyIDIwMTQgMTE6MzQgQU0NCj4gVG86IFBhcmtpbnNvbiwgU2Vhbg0KPiBDYzogY2Zy Z0BpcnRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW0NmcmddIFdoZW4ncyB0aGUgZGVjaXNpb24/DQo+ DQo+IE9uIFdlZCwgT2N0IDgsIDIwMTQgYXQgMzo1MSBQTSwgUGFya2luc29uLCBTZWFuIDxzZWFu LnBhcmtpbnNvbkByc2EuY29tPiB3cm90ZToNCj4+IEkgaGF2ZSBjb25jZXJucyBhYm91dCBhIGRl Y2lzaW9uIGJlaW5nIG1hZGUgYWJvdXQgd2hpY2ggY3VydmVzIHRvIHJlY29tbWVuZCAnYmVmb3Jl IEhhbGxvd2VlbicuDQo+PiBJIGFtIHVuYXdhcmUgb2YgM3JkIHBhcnRpZXMgaW1wbGVtZW50aW5n IGFuZCBjb25maXJtaW5nIGFsbCB0aGUgY3VydmVzIHRoYXQgaGF2ZSBiZWVuIHByb3Bvc2VkLg0K Pj4gTWFraW5nIGEgZGVjaXNpb24gb24gbmV3IGVsbGlwdGljIGN1cnZlcyBiYXNlZCBvbiBkYXRh IHRoYXQgaGFzbid0IGJlZW4gY29ycm9ib3JhdGVkIGJ5IGEgM3JkIHBhcnR5IGlzIGJhZCBwcmFj dGljZS4NCj4gQXMgZmFyIGFzIEkgY2FuIHRlbGwsIHRoZSBpbXBsZW1lbnRhdGlvbnMgYXJlIGFs bCBwdWJsaWNseSBhdmFpbGFibGUsIGFuZCBJIGJlbGlldmUgcmVjZW50IGVCQVRTIGhhcyBpbmNs dWRlZCBxdWl0ZSBhIGZldy4NCj4+IEkgaGF2ZSBiZWVuIGltcGxlbWVudGluZyBhcyBtYW55IG9m IHRoZSBjdXJ2ZXMgYXMgSSBjYW4gYW5kIG15IHBlcmZvcm1hbmNlIHJlc3VsdHMsIHNvIGZhciwg ZG8gbm90IGFsd2F5cyBtYXRjaCB0aG9zZSB0aGF0IEkgaGF2ZSBzZWVuIGluIHBhcGVycy4NCj4g SG93IGdvb2QgYXJlIHlvdXIgaW1wbGVtZW50YXRpb25zPyBCZWluZyBmYXN0IGlzIGhhcmQuDQo+ DQo+PiBBbHNvLCBJIGFtIGNvbmNlcm5lZCB0aGF0LCB3aGlsZSBzb21lIGN1cnZlcyBhcmUgYmVp bmcgaW1wbGVtZW50ZWQgdG8gYmUgY29uc3RhbnQgdGltZSwgbm90IGFsbCBjdXJ2ZXMgYXJlIGJl aW5nIGltcGxlbWVudGVkIHRvIGJlIGNhY2hlIGF0dGFjayByZXNpc3RhbnQuIEVpdGhlciBhbGwg aW1wbGVtZW50YXRpb25zIG5lZWQgdG8gYmUgcmVzaXN0YW50IG9yIGFsbCBpbXBsZW1lbnRhdGlv bnMgbm90LiBPbmx5IHRoZW4gY2FuIGEgdHJ1ZSBjb21wYXJpc29uIGJlIG1hZGUuDQo+IEFsbCBv ZiB0aGVtIHNob3VsZCBiZTogdGhpcyBpcyBhbm5veWluZyBidXQgc3RyYWlnaHRmb3J3YXJkIHRv IGNoZWNrIGJ5IGxvb2tpbmcgYXQgaW1wbGVtZW50YXRpb25zLg0KPj4gVW50aWwgdGhlc2UgaXNz dWVzIGFyZSBkZWFsdCB3aXRoIEkgZmVlbCB0aGVyZSBpcyBub3Qgc3VmZmljaWVudCBpbmZvcm1h dGlvbiB0byBtYWtlIGEgZGVjaXNpb24uDQo+IE1vc3Qgb2YgdGhpcyBpbmZvcm1hdGlvbiBpcyBp bmRlcGVuZGVudCBvZiB3aGljaCBwYXJhbWV0ZXJzIGFyZSBwaWNrZWQuDQo+DQo+PiBTZWFuDQo+ PiAtLQ0KPj4gU2VhbiBQYXJraW5zb24gfCBDb25zdWx0YW50IFNvZnR3YXJlIEVuZ2luZWVyIHwg UlNBLCBUaGUgU2VjdXJpdHkgDQo+PiBEaXZpc2lvbiBvZiBFTUMgT2ZmaWNlICs2MSA3IDMwMzIg NTIzMiB8IEZheCArNjEgNyAzMDMyIDUyOTkgDQo+PiB3d3cucnNhLmNvbQ0KPj4NCj4+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBDZnJnIG1haWxp bmcgbGlzdA0KPj4gQ2ZyZ0BpcnRmLm9yZw0KPj4gaHR0cDovL3d3dy5pcnRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2NmcmcNCj4NCj4NCj4gLS0NCj4gIlRob3NlIHdobyB3b3VsZCBnaXZlIHVwIEVz c2VudGlhbCBMaWJlcnR5IHRvIHB1cmNoYXNlIGEgbGl0dGxlIFRlbXBvcmFyeSBTYWZldHkgZGVz ZXJ2ZSBuZWl0aGVyICBMaWJlcnR5IG5vciBTYWZldHkuIg0KPiAtLSBCZW5qYW1pbiBGcmFua2xp bg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBD ZnJnIG1haWxpbmcgbGlzdA0KPiBDZnJnQGlydGYub3JnDQo+IGh0dHA6Ly93d3cuaXJ0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9jZnJnDQoNCg== From nobody Wed Oct 8 22:03:01 2014 Return-Path: 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 31D9C1A90B9 for ; Wed, 8 Oct 2014 22:03:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 ATXEnorxyy3x for ; Wed, 8 Oct 2014 22:02:58 -0700 (PDT) Received: from resqmta-ch2-07v.sys.comcast.net (resqmta-ch2-07v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:39]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FAA31A90B8 for ; Wed, 8 Oct 2014 22:02:57 -0700 (PDT) Received: from resomta-ch2-09v.sys.comcast.net ([69.252.207.105]) by resqmta-ch2-07v.sys.comcast.net with comcast id 0t2i1p0042GyhjZ01t2xzo; Thu, 09 Oct 2014 05:02:57 +0000 Received: from [192.168.1.2] ([71.202.164.227]) by resomta-ch2-09v.sys.comcast.net with comcast id 0t2v1p00K4uhcbK01t2wiL; Thu, 09 Oct 2014 05:02:56 +0000 Message-ID: <543616FF.4010503@brainhub.org> Date: Wed, 08 Oct 2014 22:02:55 -0700 From: Andrey Jivsov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: Michael Hamburg References: <53F0010B.6080101@brainhub.org> <53F108CF.4040704@brainhub.org> <53F18607.3000005@brainhub.org> <5406C23E.80205@brainhub.org> <5407C176.3000109@brainhub.org> <5435DE66.7080803@brainhub.org> <29E067B7-C1F3-427C-8E4A-14F2096A71E4@shiftleft.org> In-Reply-To: <29E067B7-C1F3-427C-8E4A-14F2096A71E4@shiftleft.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1412830977; bh=NzSekbc60S8TrIe7VVRaLGKt8UsO/gOh+vZTVPEEsW0=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=kPSFDELCUq4smc62TO/jqo/0Z1AMCRv0sOfAALaA6lhn5emmsTEOjvlOEynUkzq7o Ue/20lg/i02t9rvoayG/snsCpU5vLonGNPIPl4pLFalyTmWzKv5wamPapS7bXhk+ku +omts/r0o6JCH7Xxt6aoWH+3xR3pWAC4J7CEmNTfkcylXfpRFmtbdgZFhRQ1vWb51Z jIhgXUC6McjraJtwVgmWOzV5dQlJI5bW+E6T6pFcF796QDBgj6OQoc49vvg8fxLBu5 c3J2NzvkM4jFdGJBEsI4Y/deHy+sra82sMJFEEEN0v7u7mbBrUsBDYXmnFKdwjLL1L z0qKsTuhQDs8Q== Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/ldWr8lfpj-oyrR4vy6v9TSTskGU Cc: cfrg@irtf.org Subject: Re: [Cfrg] Timing of libsodium, curve25519-donna, MSR ECCLib, and openssl-master X-BeenThere: cfrg@irtf.org 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: Thu, 09 Oct 2014 05:03:00 -0000 On 10/08/2014 07:05 PM, Michael Hamburg wrote: > Whoa, they improved the performance by 50% since the paper and initial patch?! on 09/03/2014 I reported 40% advantage of Curve25519-donna (17384.8/12348.9=1.40). Now it's 14% (17383.6/15168.1=1.146). That's on an AVX2 machine. On my older i5 machine (not an AVX2 machine) the ratio is also improved. With the same instructions as quoted below: was 14131.5/5231.7=2.7 (reported on 09/03/2013) now: 14251.3/11105.2=1.27 (apparently due to Montgomery-style assembler code specialized for P-256 prime) This is even more interesting. These performance improvements apparently cover most of x86 CPUs in use today, clients and servers. > >> On Oct 8, 2014, at 6:01 PM, Andrey Jivsov wrote: >> >> Now that the P-256 enhancements are in the OpenSSL tree, let commands speak for themselves. >> >> Type in a Linux terminal on a Haswell machine (no HT, no SpeedStep/Turboboost) and observe: >> >> 1. P-256: >> >> $ git clone git://git.openssl.org/openssl.git A >> $ cd A >> $ ./config >> $ make && apps/openssl speed ecdhp256 >> >> 15078.1 op/s >> >> 2. X25519: >> >> $ git clone https://github.com/brainhub/curve25519-donna.git B >> $ cd B >> $ make speed-curve25519-donna-c64 && ./speed-curve25519-donna-c64 >> >> 17289.4 op/s >> >> ----------------------------- >> >> 17383.6 / 15168.1 = 14.6% faster >> >> The difference is about the cost of point decompression/coordinate conversion (e.g. Edwards coordinate conversion to Montgomery + point multiplication would have about the same performance as P-256 point multiplication). >> >> _______________________________________________ >> Cfrg mailing list >> Cfrg@irtf.org >> http://www.irtf.org/mailman/listinfo/cfrg From nobody Wed Oct 8 22:05:52 2014 Return-Path: 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 1D3421A90BB for ; Wed, 8 Oct 2014 22:05:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 DTgZBWNWbkeb for ; Wed, 8 Oct 2014 22:05:49 -0700 (PDT) Received: from mail-yh0-x231.google.com (mail-yh0-x231.google.com [IPv6:2607:f8b0:4002:c01::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46A661A90BA for ; Wed, 8 Oct 2014 22:05:49 -0700 (PDT) Received: by mail-yh0-f49.google.com with SMTP id a41so259468yho.8 for ; Wed, 08 Oct 2014 22:05:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7vrBmUuGuI4ta2puVbHVShJwCpQ/J0OxrTD81CHK1UI=; b=Pc/KNFcXN9mxpmys79K2xxuH0ukMB9LWtaA1MtDhNgYI/AlIeKatAeo/9BfMvF4Ag9 m3jOHToum1VzBDWunR1n8/8mY24cWDpYNMHaLIAl/whN9GeBzlGynS5J3rKIAUA4SlYC 373rZs9Q4EFwfo+0RZ7JGUorn1zfj81msjcglSpXy/INbxrICX672Sj3rJWmvTLlVVsF J3wBwtpOCDfS9tKxTqGDmx+M6BHMVZ0DfCP2K4euXNBU/I9SW/4IXbxslIh7cJ3v3liU gBIHm275gbpiTzAQZu8W0GGk+Fc9i75BxHfRIq4VA79JFi7DurQ8pAkk1i0DT6I+c5/m cjOA== MIME-Version: 1.0 X-Received: by 10.236.66.164 with SMTP id h24mr8047047yhd.157.1412831148461; Wed, 08 Oct 2014 22:05:48 -0700 (PDT) Received: by 10.170.195.149 with HTTP; Wed, 8 Oct 2014 22:05:48 -0700 (PDT) In-Reply-To: <543616FF.4010503@brainhub.org> References: <53F0010B.6080101@brainhub.org> <53F108CF.4040704@brainhub.org> <53F18607.3000005@brainhub.org> <5406C23E.80205@brainhub.org> <5407C176.3000109@brainhub.org> <5435DE66.7080803@brainhub.org> <29E067B7-C1F3-427C-8E4A-14F2096A71E4@shiftleft.org> <543616FF.4010503@brainhub.org> Date: Wed, 8 Oct 2014 22:05:48 -0700 Message-ID: From: Watson Ladd To: Andrey Jivsov Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/oXyjeTzWEAgaJPm8BwFaI0s8Pf4 Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] Timing of libsodium, curve25519-donna, MSR ECCLib, and openssl-master X-BeenThere: cfrg@irtf.org 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: Thu, 09 Oct 2014 05:05:51 -0000 On Wed, Oct 8, 2014 at 10:02 PM, Andrey Jivsov wrote: > On 10/08/2014 07:05 PM, Michael Hamburg wrote: >> >> Whoa, they improved the performance by 50% since the paper and initial >> patch?! > > > on 09/03/2014 I reported 40% advantage of Curve25519-donna > (17384.8/12348.9=1.40). Now it's 14% (17383.6/15168.1=1.146). That's on an > AVX2 machine. > > On my older i5 machine (not an AVX2 machine) the ratio is also improved. > With the same instructions as quoted below: > > was 14131.5/5231.7=2.7 (reported on 09/03/2013) > now: 14251.3/11105.2=1.27 > (apparently due to Montgomery-style assembler code specialized for P-256 > prime) > > This is even more interesting. These performance improvements apparently > cover most of x86 CPUs in use today, clients and servers. Wouldn't the speedups from reducing the number of field operations by changing the curve shape stack on top of these? I don't really see the relevance to picking which wire format to use. > > >> >>> On Oct 8, 2014, at 6:01 PM, Andrey Jivsov wrote: >>> >>> Now that the P-256 enhancements are in the OpenSSL tree, let commands >>> speak for themselves. >>> >>> Type in a Linux terminal on a Haswell machine (no HT, no >>> SpeedStep/Turboboost) and observe: >>> >>> 1. P-256: >>> >>> $ git clone git://git.openssl.org/openssl.git A >>> $ cd A >>> $ ./config >>> $ make && apps/openssl speed ecdhp256 >>> >>> 15078.1 op/s >>> >>> 2. X25519: >>> >>> $ git clone https://github.com/brainhub/curve25519-donna.git B >>> $ cd B >>> $ make speed-curve25519-donna-c64 && ./speed-curve25519-donna-c64 >>> >>> 17289.4 op/s >>> >>> ----------------------------- >>> >>> 17383.6 / 15168.1 = 14.6% faster >>> >>> The difference is about the cost of point decompression/coordinate >>> conversion (e.g. Edwards coordinate conversion to Montgomery + point >>> multiplication would have about the same performance as P-256 point >>> multiplication). >>> >>> _______________________________________________ >>> Cfrg mailing list >>> Cfrg@irtf.org >>> http://www.irtf.org/mailman/listinfo/cfrg > > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Wed Oct 8 22:20:46 2014 Return-Path: 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 AEFC51A90CE for ; Wed, 8 Oct 2014 22:20:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no 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 VROvIpgaKma2 for ; Wed, 8 Oct 2014 22:20:42 -0700 (PDT) Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACE7B1A90C8 for ; Wed, 8 Oct 2014 22:20:40 -0700 (PDT) Received: by mail-la0-f51.google.com with SMTP id ge10so436855lab.24 for ; Wed, 08 Oct 2014 22:20:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=9hI03x24ZOmwyAxFg/b/GaeS/3Kb50NYb6GqozSjlP4=; b=XNQyFnvOIK+HERqkDrhNIpktw/FnekTwsdDooA2ebvhQQGn0giUPOxKVzpvY81k4nI CQ7D5hjPCofvu0k3SljmtpmySnhg6HCHKdd9aBm/yt487kUgHpUDXzUiGoK569mUuhHj 27ltQgJ9Em4H7qAGw5h5jISn5BnKLfpVhXQjlTwqLOV74iJLFhTfJbnoLhuP9WfHBfo8 jR0tu1+8K5YWwiP4937OR/KHk+P8BJ1UWxR7Cz2J3wlqao7C4sA4lgN7lk0fmC3Gq7aR 2g45oyyqu3JeCDEjd2dFe6OAE4jkE7eMNSCGMKIHkUShzX85a4M1tnX0FfsDfj9TzaSe p/Sw== MIME-Version: 1.0 X-Received: by 10.152.205.38 with SMTP id ld6mr401027lac.97.1412832038993; Wed, 08 Oct 2014 22:20:38 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.66.196 with HTTP; Wed, 8 Oct 2014 22:20:38 -0700 (PDT) In-Reply-To: <54360428.6090801@shiftleft.org> References: <20141008173154.15169.qmail@cr.yp.to> <2FBC676C3BBFBB4AA82945763B361DE608F1D021@MX17A.corp.emc.com> <2FBC676C3BBFBB4AA82945763B361DE608F1D036@MX17A.corp.emc.com> <54360428.6090801@shiftleft.org> Date: Thu, 9 Oct 2014 01:20:38 -0400 X-Google-Sender-Auth: 2PZG7GctvXwB0bdoWEAYqcT0xnY Message-ID: From: Phillip Hallam-Baker To: Mike Hamburg Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/01qG7E6eIUS2Be3b7HKACjpzaec Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] When's the decision? X-BeenThere: cfrg@irtf.org 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: Thu, 09 Oct 2014 05:20:43 -0000 On Wed, Oct 8, 2014 at 11:42 PM, Mike Hamburg wrote: > > This is basically the point of Ed448-Goldilocks. It's received a mixed > response in this forum, since some people would prefer the most constrained > curve, for some definition of "constrained" which doesn't consider > performance. I am happy to consider performance but only if the differences are large and consistent. This is not a competition where more is better. I don't want more than exactly one high strength curve and exactly one exceptionally high curve. I don't want to see any options or parameters either. Either we are all doing the twist again or nobody is. Either we are all doing compression or not. And if there isn't a clear basis for a decision we can throw darts. Some performance issues are show stoppers. Anything that is not less than a clean multiple of a power of 2 is going to cause severe performance hits on future architectures. 512 bit memory buses are common in graphics cards, 521 bit buses are not. If ED448 is twice as fast as the exactly 512 bit curve then there is a decisive performance advantage. Anything less than 20% is noise. The point is elimination, to vote people off the island so we can have a winner, not to get more people in. From nobody Wed Oct 8 22:47:18 2014 Return-Path: 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 EB0921A90DB for ; Wed, 8 Oct 2014 22:47:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 e1J4cnfGxsyc for ; Wed, 8 Oct 2014 22:47:16 -0700 (PDT) Received: from resqmta-ch2-08v.sys.comcast.net (resqmta-ch2-08v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:40]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B6501A90C4 for ; Wed, 8 Oct 2014 22:47:16 -0700 (PDT) Received: from resomta-ch2-01v.sys.comcast.net ([69.252.207.97]) by resqmta-ch2-08v.sys.comcast.net with comcast id 0tnB1p00226dK1R01tnFyv; Thu, 09 Oct 2014 05:47:15 +0000 Received: from [192.168.1.2] ([71.202.164.227]) by resomta-ch2-01v.sys.comcast.net with comcast id 0tnE1p00L4uhcbK01tnFPm; Thu, 09 Oct 2014 05:47:15 +0000 Message-ID: <54362162.8070506@brainhub.org> Date: Wed, 08 Oct 2014 22:47:14 -0700 From: Andrey Jivsov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: Watson Ladd References: <53F0010B.6080101@brainhub.org> <53F108CF.4040704@brainhub.org> <53F18607.3000005@brainhub.org> <5406C23E.80205@brainhub.org> <5407C176.3000109@brainhub.org> <5435DE66.7080803@brainhub.org> <29E067B7-C1F3-427C-8E4A-14F2096A71E4@shiftleft.org> <543616FF.4010503@brainhub.org> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1412833635; bh=PRdn4Tj/5+VV4vJ8G5zbjtcE75idAJYxzSLjakkD/74=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=WGhDs5Ge5L+LAE1oNVvb7ujdudieNuxlXVdjr3cQ6WSr9bj+Q6nCaY9HCbhY3togG zG6AEJ1HQVoWXNvnboaj7c9LaYIfP63L26TJePoE74BUyBKPzjG0Sgztor5CTsNvDM Meylehd9MiDSlTaCZLbgp3O2Wehnz9bQJg9Os8DQHddv0efITgQCMTc6pAGp/pdW7L as9Hy3+5LKmMsLp27eLPItk35shEnD0YWdk+daorslGdSHtmRDii66vCHtLYhgNyOv j5SUuQRv7sB11eTEHE/vhvuShduD4pZnYDy+eS8RWqx407pXRJBOfvADthjTxB0TSS 4cXzZzEiAM3sQ== Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/sIiWJU2waq2UW7rZZUWTNZ-fK2c Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] Timing of libsodium, curve25519-donna, MSR ECCLib, and openssl-master X-BeenThere: cfrg@irtf.org 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: Thu, 09 Oct 2014 05:47:18 -0000 On 10/08/2014 10:05 PM, Watson Ladd wrote: >> was 14131.5/5231.7=2.7 (reported on 09/03/2013) >> >now: 14251.3/11105.2=1.27 >> >(apparently due to Montgomery-style assembler code specialized for P-256 >> >prime) >> > >> >This is even more interesting. These performance improvements apparently >> >cover most of x86 CPUs in use today, clients and servers. > Wouldn't the speedups from reducing the number of field operations by > changing the curve shape stack on top of these? I don't really see the > relevance to picking which wire format to use. > Just to be clear, I was saying that the apparent factor of ~2 improvement of P-256 on non-AVX2 machine appears to be due to highly tuned Montgomery modulo prime reduction code, hardcoded for P-256 prime. Montgomery curve has fewer underlying filed operations. The performance benefit will be lower than due to prime reduction/hardware/instruction assistance. However, given that the numbers are fairly close now, we can expect change in leadership depending on the mix of features. For example, a hypothetical mix of the P-256 underlying field operations found in the code that I timed and a Montgomery curve on top would probably move such an implementation into the lead in the tests I performed. P-256 has an advantage that it's in standards, widely deployed, can do point additions (without penalty of coordinate conversion), and you can get X.509 certs with it. It would have been easier to argue on its disadvantages if it had worse performance than it appears to have. I am aware of other disadvantages of P-256. In your other e-mail, Watson, regarding AVX2/vector operations + X25519, it's an interesting question. The issues here are: * will this hide some benefits of the 2^n-1 prime? * increase code complexity? * it seems that this is of no use to mobile devices (in the near future anyway) * but servers will benefit from this. From nobody Wed Oct 8 23:11:38 2014 Return-Path: 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 AB13C1A90FD for ; Wed, 8 Oct 2014 23:11:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.267 X-Spam-Level: X-Spam-Status: No, score=-3.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_39=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_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 9XiNKTO9HgOO for ; Wed, 8 Oct 2014 23:11:33 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id E9C1E1A90FB for ; Wed, 8 Oct 2014 23:11:32 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 611C010224008; Wed, 8 Oct 2014 23:11:32 -0700 (PDT) Received: from 104.36.248.10 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Wed, 8 Oct 2014 23:11:32 -0700 (PDT) Message-ID: <237f9c809efcbb3e3ffb9df7fe666981.squirrel@www.trepanning.net> In-Reply-To: References: <54357A2A.2010800@isode.com> <73d51db893a4b847db6d8eaae7f45cf5.squirrel@www.trepanning.net> Date: Wed, 8 Oct 2014 23:11:32 -0700 (PDT) From: "Dan Harkins" To: "Watson Ladd" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/WaMVoCxD56pcFmbsfqeSU2dZlb0 Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] draft-irtf-cfrg-dragonfly document status X-BeenThere: cfrg@irtf.org 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: Thu, 09 Oct 2014 06:11:36 -0000 Watson, On Wed, October 8, 2014 6:22 pm, Watson Ladd wrote: > On Wed, Oct 8, 2014 at 4:40 PM, Dan Harkins wrote: >> >> Watson, >> >> On Wed, October 8, 2014 3:46 pm, Watson Ladd wrote: >>> On Oct 8, 2014 3:26 PM, "Paul Lambert" wrote: >>>>> >>>>> On Oct 8, 2014 10:53 AM, "Alexey Melnikov" >>>>> >>> wrote: >>>>> > >>>>> > Hi, >>>>> > My apologies for taking so long on this. But I felt I needed to >>>>> review >>> mailing list discussions to make up my own mind on this topic. >>>>> > >>>>> > After reviewing mailing list discussions about this draft, I would >>> like to do another RGLC on it. I've seen negative comments on the >>> mailing >>> list, but I've also seen some interest in this work and I am also aware >>> that some variants of the algorithm are already implemented/deployed. >>> Also, >>> there were a couple of new revisions of the draft and it is not clear >>> whether people who reported original problems are happy with how they >>> got >>> resolved. So I would like to see a bit more positive feedback on the >>> latest >>> version, in particular I would like to know if specific issues raised >>> by >>> earlier reviews are addressed in the latest version. >>>> >>>> This draft should be published as an RFC. There is considerable value >>>> in >>> having a published stable reference document. The market should be >>> allowed to do the estimations of risk and value to field this protocol. >>> >>> Just as they did with RC4 and renegotiation? >> >> This has nothing to do with RC4 and renegotiation (I assume you mean >> in TLS). > > I'm questioning the ability of market participants to evaluate > cryptography. Well then you are making very odd comments. Market participants had nothing to do with defining renegotiation. But, again, this has nothing to do with the draft in question. >>>> Versions of the protocol have been adopted and fied. This protocol was >>> first introduced into IEEE 802.11s in 2008. The base protocol exchange >>> has >>> also been adopted in the Wi-Fi Alliance. The protocol has been >>> improved >>> by the review in the cfrg and if published, the specification would >>> positively impact the application of the protocol in other forums. >>>> >>>>> My comment (there is no security proof, and alternatives with better >>> provable security) has been acknowledged to be unresolveable. >>>> >>>> Yes, this may be considered a negative point by some but not all. >>>> While >>> not a proof, the protocol has been analyzed: >>>> Cryptanalysis of the Dragonfly Key Exchange Protocol >>>> It was interested that the only issue mentioned was a small subgroup >>> attack if the public key is not validated …. which it always should. >>> >>> This analysis ignores Rene Struik's timing attack, my reflection >>> attack, >>> and other comments incorporated into the draft. >> >> And I thanked Rene, you, and others for your comments and, as you >> note, >> incorporated resolutions into the draft. Once again, thank you for >> helping >> improve the draft. All of the comments have been resolved in -04. >> >> (I will note that the reflection attack you mentioned is not possible >> in the IEEE 802.11 version of dragonfly, which predated your comment >> and this draft by a few years, and neither was small subgroup attack >> described by Clarke and Hao mentioned above. The -00 version of this >> draft was rushed, take a look at the Acknowledgements in section 4 to >> see just how bad, and I left some things out that I shouldn't have. All >> this has all been addressed in -04). > > Why did the draft not track the IEEE 802.11 version? Also, as I > remember from discussing this issue in the TLS WG, the CFRG draft > version and the TLS draft version differed substantially, enough to > make the reflection attack not work. (There were interactions with the > rest of TLS that prevented it) While only tangentially relevant to the > issue, this is the kind of issue which leads to all sorts of bugs in > protocols that should be secure. The draft was intended to be a generic instantiation of a key exchange that had been defined in 3 different protocols, each of which has its own idiosyncrasies. I dealt with the reflection issue in the IEEE 802.11 instantiation because it was for mesh networks and there is no notion of a "server" or a "client" or an "initiator" or a "responder" in a mesh, everyone is an equal peer who can actually each view themselves as the "initiator" if the timing is right. The reflection attack was something that needed addressing in the protocol as opposed to, say, the TLS variant which is not susceptible to that attack due to the nature of TLS. Again, in my haste to generalize the key exchange I removed stuff that should not have been removed. But, as I mentioned, it is in the latest draft that is subject of the RGLC, thanks to the useful and constructive comments of RG members, including you. > It also is not clear how relevant the proposed draft will be > >> >>>>> >>>>> The draft authors knew this from the very beginning. >>>>> >>>>> I don't think we should approve a protocol that doesn't have a >>>>> security >>> proof, particularly given that we are going to work on alternatives. >>>> >>>> “… Going to work on …” is the issue. The draft under >>>> discussion >>>> has been >>> on IETF servers for 2 years. It has been used in other industry forums >>> for >>> four or five years. >>> >>> Plenty of alternatives have been put forward in those two years, >>> including >>> EKE+Elligator, SPAKE2, JPAKE, and SMP based solutions. The failure >>> to >>> advance these is inexplicable. >> >> Oh no, it's very easily explained. It's because no one has stepped >> forward >> to actually write the I-Ds. You have stated on numerous occasions that >> these >> should be written up but you have never actually taken on the task of >> actually doing it. Please, write up a draft or four. Whether or not you >> do, >> though, this really has nothing to do with the RGLC underway right now. > > JPAKE was described in a series of drafts that weren't made WG work > items. I see no reason that the eventual disposition of SPAKE2, SMP, > or EKE+Elligator drafts would be any different, and thus see no reason > to write the drafts. The disposition is due to the diligence and hard work of the editor of the I-D. If you want drafts to be produced in a RG (or WG) the best way to do that is to socialize the idea, write the draft, and advocate for it. If you sit back and send periodic emails criticizing everyone else for not doing what you, in your wisdom from the comfort of your couch, see as necessary nothing will get done. >> If there was a security proof of dragonfly it would not be, nor should >> it >> be, part of this draft. It would be a stand-alone paper. The complaint >> about >> the lack of a security proof is really procedural and not technical as >> it is >> not a comment on the draft that can be resolved by changing the draft. >> The IRTF (and the IETF as well) has never put a security proof as a >> process >> requirement for advancement of I-Ds. You may think it should but that >> is an argument for a different place, not a RGLC. > > It could be resolved by opening the draft, deleting the contents, > inserting contents describing a protocol with a security proof and > referring to the proof published elsewhere, and submitting the new > version, so clearly it is an issue with the contents of the draft. No, I'm talking about other protocols which have security proofs behind the that have been specified in IRTF or IETF RFCs. Look at SRP (RFC 2945). The security proof is not in the RFC. And if a security proof of dragonfly comes around there is no reason why it should be part of this I-D or a subsequent RFC. > I think what you meant to say is it couldn't be resolved without > substantially changing the protocol, which also isn't true: if the > shared secret was a hash of all the messages, and the peer-scalars > were removed, the result would be a secure PAKE with a security proof. > But unfortunately it would be a patented one. No, that's not what I mean at all. I mean that security proofs are usually stand-alone papers (in the proceedings of the such-and-such symposium of secure communications), not parts of RFCs. This is no different. > There are plenty of drafts that have piled up in various nooks and > crannies that never get adopted as WG items, despite requests from > authors. I don't see why we need to publish this draft, and I don't > see why we need to publish a draft for a protocol inferior to > alternatives that have been well-studied and are well-regarded. The > argument you are making seems to be that anything will get published, > provided it's sufficiently polished, no matter how much better the > alternatives are. If you have any further technical comments on the I-D, I encourage their mention. regards, Dan. > Sincerely, > Watson Ladd > >> >> regards, >> >> Dan. >> >>>> >>>> Yes, the cfrg should work as quickly as possible to make alternatives. >>> Stopping the progression of this draft does not accelerate new work, >>> but >>> does prevent existing applications from utilizing a reviewed and >>> improved >>> specification. >>> >>> The nonexistence of this draft did not stop adoption in Wifi. By >>> contrast >>> advancing a number of PAKEs will kick the issue to WGs without the >>> capacity >>> to evaluate the issues. >>> >>>>> >>>>> There is plenty of terrible crypto in IEEE standards >>>> >>>> … and IETF standards. Bringing in other good or bad protocols into >>>> the >>> discussion is irrelevant to the decision at hand. >>>>> >>>>> we don't issue drafts for because it is so terrible. >>>> >>>> Since when did the IETF mandate a security proof … There are >>>> terrible >>> protocols with proofs, so why does the lack of a proof made something >>> ‘terrible’. >>>> >>>> Paul >>>> >>>> >>>> >>>>> To the extent our publication leads to use of dragonfly as opposed to >>> known - good protocols, it's a problem. >>>> >>>> >>>> >>>> >>>>> > >>>>> > Considering how difficult previous Last Call on the document was, I >>> would like to ask people to: >>>>> > 1) keep in mind that CFRG chairs believe that the RG should work on >>> PAKE requirements and after that on other PAKE proposals. This was >>> suggested by our previous co-chair David McGrew: >>>>> > http://www.ietf.org/mail-archive/web/cfrg/current/msg03723.html >>>>> >>>>> Why doesn't this apply to dragonfly, but only other proposals? >>>>> >>>>> > 2) be professional, in particular no ad hominem attacks >>>>> > 3) be constructive. In particular if you would like a disclaimer >>>>> being >>> added to the document, please suggest specific text. >>>>> > 4) simple statements of support for publishing the document or >>> objection to publishing it are fine and encouraged. Sending them >>> directly >>> to RG chairs is fine. But please avoid saying "but what about >>> PAKEXXX?", >>> due to 1). >>>>> > 5) unlike IETF, IRTF RGs are not required to reach rough consensus. >>> However I would like to see us try. >>>>> > >>>>> > Best Regards, >>>>> > Alexey, >>>>> > on behalf of chairs. >>>>> > >>>>> > _______________________________________________ >>>>> > Cfrg mailing list >>>>> > Cfrg@irtf.org >>>>> > http://www.irtf.org/mailman/listinfo/cfrg >>>> >>>> >>> _______________________________________________ >>> Cfrg mailing list >>> Cfrg@irtf.org >>> http://www.irtf.org/mailman/listinfo/cfrg >>> >> > > > > -- > "Those who would give up Essential Liberty to purchase a little > Temporary Safety deserve neither Liberty nor Safety." > -- Benjamin Franklin > From nobody Wed Oct 8 23:43:08 2014 Return-Path: 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 9F04A1A9114 for ; Wed, 8 Oct 2014 23:43:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.555 X-Spam-Level: * X-Spam-Status: No, score=1.555 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.982, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no 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 Y2gPgbXWIp1f for ; Wed, 8 Oct 2014 23:43:03 -0700 (PDT) Received: from aspartame.shiftleft.org (199-116-74-168-v301.PUBLIC.monkeybrains.net [199.116.74.168]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7728C1A9113 for ; Wed, 8 Oct 2014 23:43:03 -0700 (PDT) Received: from [192.168.1.124] (unknown [192.168.1.1]) by aspartame.shiftleft.org (Postfix) with ESMTPSA id 8300FF2208; Wed, 8 Oct 2014 23:41:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=shiftleft.org; s=sldo; t=1412836896; bh=J1qij6Oku2wiCFUzVlYJV1kqV9/cZFnlvzWhm9OPQmQ=; h=Date:From:To:CC:Subject:References:In-Reply-To:From; b=XgStZqHD78RaWJB4e2x+2Nzx/KQNYw5SV8oQWqlKdOEmbc9KFkKFuLf8KhWAV39O9 ANglWvCcp1DdQygCuJnnnhY3O6sfZL9kHe+DEV192PXphIAeM/zP8jcswmEszKsPxz hKI6Gf2gJ6Sv2c7U5FPv85rbdI4YjxQo4AP/xoVo= Message-ID: <54362E75.8050407@shiftleft.org> Date: Wed, 08 Oct 2014 23:43:01 -0700 From: Mike Hamburg User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Phillip Hallam-Baker References: <20141008173154.15169.qmail@cr.yp.to> <2FBC676C3BBFBB4AA82945763B361DE608F1D021@MX17A.corp.emc.com> <2FBC676C3BBFBB4AA82945763B361DE608F1D036@MX17A.corp.emc.com> <54360428.6090801@shiftleft.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/j7OhdpDwjCfSlabFXLQy0Hc6fyI Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] When's the decision? X-BeenThere: cfrg@irtf.org 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: Thu, 09 Oct 2014 06:43:04 -0000 On 10/8/2014 10:20 PM, Phillip Hallam-Baker wrote: > On Wed, Oct 8, 2014 at 11:42 PM, Mike Hamburg wrote: > >> This is basically the point of Ed448-Goldilocks. It's received a mixed >> response in this forum, since some people would prefer the most constrained >> curve, for some definition of "constrained" which doesn't consider >> performance. > I am happy to consider performance but only if the differences are > large and consistent. > > This is not a competition where more is better. I don't want more than > exactly one high strength curve and exactly one exceptionally high > curve. I don't want to see any options or parameters either. Either we > are all doing the twist again or nobody is. Either we are all doing > compression or not. I agree, which is why I prefer "NUMS but untwisted" over the current NUMS. Everyone else avoided specifying twisted curves because of the incomplete addition formulas. > And if there isn't a clear basis for a decision we can throw darts. > > Some performance issues are show stoppers. Anything that is not less > than a clean multiple of a power of 2 is going to cause severe > performance hits on future architectures. 512 bit memory buses are > common in graphics cards, 521 bit buses are not. Maybe. It depends what's the limiting factor in the algorithm. It might not be the memory bus. > If ED448 is twice as fast as the exactly 512 bit curve then there is a > decisive performance advantage. Anything less than 20% is noise. Ed448 is about twice as fast as ed-512-mers, and about 6% slower than ed-384-mers using currently published implementations. That is, using the last round of benchmarks I took on my SBR machine before selling it, and the published NUMS numbers. The footing is surely not entirely even. The Ed448 software uses a Montgomery ladder for ECDH and has a unified compressed point format, whereas MS ECCLib uses fixed-window Edwards with no point compression. Ed448 uses vectorized Karatsuba with C+asm as its lowest level (except on NEON where it's basically all asm), and ECCLib uses Comba in all asm. They're benchmarked on different platforms with different loops. And so on. Ed448 also has a pretty efficient ARM NEON implementation. I believe it will have a larger advantage over NUMS on that platform, because I kept 32-bit vector performance in mind when designing it. > The point is elimination, to vote people off the island so we can have > a winner, not to get more people in. Sounds like a plan. -- Mike From nobody Wed Oct 8 23:52:21 2014 Return-Path: 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 F29E01A910F for ; Wed, 8 Oct 2014 23:52:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.555 X-Spam-Level: * X-Spam-Status: No, score=1.555 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.982, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no 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 7T4eSqoaZpY9 for ; Wed, 8 Oct 2014 23:52:19 -0700 (PDT) Received: from aspartame.shiftleft.org (199-116-74-168-v301.PUBLIC.monkeybrains.net [199.116.74.168]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4ADFA1A0007 for ; Wed, 8 Oct 2014 23:52:19 -0700 (PDT) Received: from [192.168.1.124] (unknown [192.168.1.1]) by aspartame.shiftleft.org (Postfix) with ESMTPSA id B7E60F2208; Wed, 8 Oct 2014 23:50:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=shiftleft.org; s=sldo; t=1412837452; bh=VjPTOOst2JblbKkLPcKGVA6e3bEWxpPKnPjrvU/EDM4=; h=Date:From:To:CC:Subject:References:In-Reply-To:From; b=NaZ66LhxmCK/s97fYsBJg1LcdR50wqHEknsc7EHx8oFEJLXAFWlOprm7PD1F2kgRR 0a31HwSzGeWfhv9873DC5TQJic68pXUZxd94r5+OpLS1gI28Z15lDEbuLBQeaTtAJa eHeFkU1kJc9b7vQ8Jqr/UizYvMt9PCFAY/uQKdLU= Message-ID: <543630A2.5060904@shiftleft.org> Date: Wed, 08 Oct 2014 23:52:18 -0700 From: Mike Hamburg User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Andrey Jivsov , Watson Ladd References: <53F0010B.6080101@brainhub.org> <53F108CF.4040704@brainhub.org> <53F18607.3000005@brainhub.org> <5406C23E.80205@brainhub.org> <5407C176.3000109@brainhub.org> <5435DE66.7080803@brainhub.org> <29E067B7-C1F3-427C-8E4A-14F2096A71E4@shiftleft.org> <543616FF.4010503@brainhub.org> <54362162.8070506@brainhub.org> In-Reply-To: <54362162.8070506@brainhub.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/tb6ZVMdNdwysG98XhXXbZXp90pE Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] Timing of libsodium, curve25519-donna, MSR ECCLib, and openssl-master X-BeenThere: cfrg@irtf.org 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: Thu, 09 Oct 2014 06:52:20 -0000 On 10/8/2014 10:47 PM, Andrey Jivsov wrote: > > Montgomery curve has fewer underlying filed operations. The > performance benefit will be lower than due to prime > reduction/hardware/instruction assistance. However, given that the > numbers are fairly close now, we can expect change in leadership > depending on the mix of features. For example, a hypothetical mix of > the P-256 underlying field operations found in the code that I timed > and a Montgomery curve on top would probably move such an > implementation into the lead in the tests I performed. Yeah, or getting Shay and Vlad to hand-tune an x25519 implementation :-) > P-256 has an advantage that it's in standards, widely deployed, can do > point additions (without penalty of coordinate conversion), and you > can get X.509 certs with it. It would have been easier to argue on its > disadvantages if it had worse performance than it appears to have. I > am aware of other disadvantages of P-256. > > In your other e-mail, Watson, regarding AVX2/vector operations + > X25519, it's an interesting question. The issues here are: > * will this hide some benefits of the 2^n-1 prime? Possibly. You probably won't be able to use Langley and Bernstein's carry handling techniques, but fewer coefficients is always good. > * increase code complexity? Compared to a version without handwritten asm? The field arithmetic will definitely be more complex. > * it seems that this is of no use to mobile devices (in the near > future anyway) Curve25519 performs quite well on ARM NEON. > * but servers will benefit from this. Cheers, -- Mike From nobody Thu Oct 9 00:24:15 2014 Return-Path: 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 8DE451A9127 for ; Thu, 9 Oct 2014 00:24:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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 athJsXZJliPs for ; Thu, 9 Oct 2014 00:24:03 -0700 (PDT) Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E98801A0029 for ; Thu, 9 Oct 2014 00:24:02 -0700 (PDT) Received: from maildlpprd02.lss.emc.com (maildlpprd02.lss.emc.com [10.253.24.34]) by mailuogwprd02.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s997NuBO010787 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Oct 2014 03:23:57 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd02.lss.emc.com s997NuBO010787 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=rsa.com; s=jan2013; t=1412839437; bh=FYGh7TtNnVi3v4Eo7RWi1fEA9Yo=; h=From:To:CC:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=jW7BoYjOK+Sd0jew2Pdj2/prS9D1tKkYkxdBjheKx1HlhvCfyz4/St5m7aXp+E8GB GN5FQ/9A5MXSb1Ww/wEWMJ0t/TeZgJUvlMjMN1XjWKMmJWeY/ltHLMEOsljzpFUAgy CGqmb5dm6FsD1rmBjlSAkr65O0XvnGi7f3QYbyqo= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd02.lss.emc.com s997NuBO010787 Received: from mailusrhubprd52.lss.emc.com (mailusrhubprd52.lss.emc.com [10.106.48.25]) by maildlpprd02.lss.emc.com (RSA Interceptor); Thu, 9 Oct 2014 03:23:03 -0400 Received: from mxhub32.corp.emc.com (mxhub32.corp.emc.com [128.222.70.172]) by mailusrhubprd52.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s997NOKH027018 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 9 Oct 2014 03:23:24 -0400 Received: from mx17a.corp.emc.com ([169.254.1.209]) by mxhub32.corp.emc.com ([128.222.70.172]) with mapi; Thu, 9 Oct 2014 03:23:23 -0400 From: "Parkinson, Sean" To: Phillip Hallam-Baker Date: Thu, 9 Oct 2014 03:23:22 -0400 Thread-Topic: [Cfrg] When's the decision? Thread-Index: Ac/jgMbiloImE2+hTne/4dJE9fpW6gAEQQ/w Message-ID: <2FBC676C3BBFBB4AA82945763B361DE608F1D066@MX17A.corp.emc.com> References: <20141008173154.15169.qmail@cr.yp.to> <2FBC676C3BBFBB4AA82945763B361DE608F1D021@MX17A.corp.emc.com> <2FBC676C3BBFBB4AA82945763B361DE608F1D036@MX17A.corp.emc.com> <54360428.6090801@shiftleft.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd52.lss.emc.com X-RSA-Classifications: public Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/h7hXmCIwa3fvCuUSW6n_eV0nMWw Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] When's the decision? X-BeenThere: cfrg@irtf.org 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: Thu, 09 Oct 2014 07:24:13 -0000 UGhpbGxpcCwNCkkgY2FuIGFncmVlIHRoYXQgc3RlcHBpbmcganVzdCBvdmVyIGEgcG93ZXIgb2Yg MiBpcyBvbmx5IGdvaW5nIHRvIGh1cnQgcGVyZm9ybWFuY2UgaW4gdGhlIGZ1dHVyZS4NCg0KU2Vh bg0KLS0NClNlYW4gUGFya2luc29uIHwgQ29uc3VsdGFudCBTb2Z0d2FyZSBFbmdpbmVlciB8IFJT QSwgVGhlIFNlY3VyaXR5IERpdmlzaW9uwqBvZiBFTUMNCk9mZmljZSArNjEgNyAzMDMyIDUyMzIg fCBGYXggKzYxIDcgMzAzMiA1Mjk5DQp3d3cucnNhLmNvbQ0KDQoNCi0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQpGcm9tOiBoYWxsYW1AZ21haWwuY29tIFttYWlsdG86aGFsbGFtQGdtYWlsLmNv bV0gT24gQmVoYWxmIE9mIFBoaWxsaXAgSGFsbGFtLUJha2VyDQpTZW50OiBUaHVyc2RheSwgOSBP Y3RvYmVyIDIwMTQgMzoyMSBQTQ0KVG86IE1pa2UgSGFtYnVyZw0KQ2M6IFBhcmtpbnNvbiwgU2Vh bjsgV2F0c29uIExhZGQ7IGNmcmdAaXJ0Zi5vcmcNClN1YmplY3Q6IFJlOiBbQ2ZyZ10gV2hlbidz IHRoZSBkZWNpc2lvbj8NCg0KT24gV2VkLCBPY3QgOCwgMjAxNCBhdCAxMTo0MiBQTSwgTWlrZSBI YW1idXJnIDxtaWtlQHNoaWZ0bGVmdC5vcmc+IHdyb3RlOg0KDQo+DQo+IFRoaXMgaXMgYmFzaWNh bGx5IHRoZSBwb2ludCBvZiBFZDQ0OC1Hb2xkaWxvY2tzLiAgSXQncyByZWNlaXZlZCBhIA0KPiBt aXhlZCByZXNwb25zZSBpbiB0aGlzIGZvcnVtLCBzaW5jZSBzb21lIHBlb3BsZSB3b3VsZCBwcmVm ZXIgdGhlIG1vc3QgDQo+IGNvbnN0cmFpbmVkIGN1cnZlLCBmb3Igc29tZSBkZWZpbml0aW9uIG9m ICJjb25zdHJhaW5lZCIgd2hpY2ggZG9lc24ndCANCj4gY29uc2lkZXIgcGVyZm9ybWFuY2UuDQoN CkkgYW0gaGFwcHkgdG8gY29uc2lkZXIgcGVyZm9ybWFuY2UgYnV0IG9ubHkgaWYgdGhlIGRpZmZl cmVuY2VzIGFyZSBsYXJnZSBhbmQgY29uc2lzdGVudC4NCg0KVGhpcyBpcyBub3QgYSBjb21wZXRp dGlvbiB3aGVyZSBtb3JlIGlzIGJldHRlci4gSSBkb24ndCB3YW50IG1vcmUgdGhhbiBleGFjdGx5 IG9uZSBoaWdoIHN0cmVuZ3RoIGN1cnZlIGFuZCBleGFjdGx5IG9uZSBleGNlcHRpb25hbGx5IGhp Z2ggY3VydmUuIEkgZG9uJ3Qgd2FudCB0byBzZWUgYW55IG9wdGlvbnMgb3IgcGFyYW1ldGVycyBl aXRoZXIuIEVpdGhlciB3ZSBhcmUgYWxsIGRvaW5nIHRoZSB0d2lzdCBhZ2FpbiBvciBub2JvZHkg aXMuIEVpdGhlciB3ZSBhcmUgYWxsIGRvaW5nIGNvbXByZXNzaW9uIG9yIG5vdC4NCg0KQW5kIGlm IHRoZXJlIGlzbid0IGEgY2xlYXIgYmFzaXMgZm9yIGEgZGVjaXNpb24gd2UgY2FuIHRocm93IGRh cnRzLg0KDQoNClNvbWUgcGVyZm9ybWFuY2UgaXNzdWVzIGFyZSBzaG93IHN0b3BwZXJzLiBBbnl0 aGluZyB0aGF0IGlzIG5vdCBsZXNzIHRoYW4gYSBjbGVhbiBtdWx0aXBsZSBvZiBhIHBvd2VyIG9m IDIgaXMgZ29pbmcgdG8gY2F1c2Ugc2V2ZXJlIHBlcmZvcm1hbmNlIGhpdHMgb24gZnV0dXJlIGFy Y2hpdGVjdHVyZXMuIDUxMiBiaXQgbWVtb3J5IGJ1c2VzIGFyZSBjb21tb24gaW4gZ3JhcGhpY3Mg Y2FyZHMsIDUyMSBiaXQgYnVzZXMgYXJlIG5vdC4NCg0KSWYgRUQ0NDggaXMgdHdpY2UgYXMgZmFz dCBhcyB0aGUgZXhhY3RseSA1MTIgYml0IGN1cnZlIHRoZW4gdGhlcmUgaXMgYSBkZWNpc2l2ZSBw ZXJmb3JtYW5jZSBhZHZhbnRhZ2UuIEFueXRoaW5nIGxlc3MgdGhhbiAyMCUgaXMgbm9pc2UuDQoN Cg0KVGhlIHBvaW50IGlzIGVsaW1pbmF0aW9uLCB0byB2b3RlIHBlb3BsZSBvZmYgdGhlIGlzbGFu ZCBzbyB3ZSBjYW4gaGF2ZSBhIHdpbm5lciwgbm90IHRvIGdldCBtb3JlIHBlb3BsZSBpbi4NCg== From nobody Thu Oct 9 01:32:10 2014 Return-Path: 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 047191A0078 for ; Thu, 9 Oct 2014 01:32:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.086 X-Spam-Level: X-Spam-Status: No, score=-3.086 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.786] 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 UtYo_OYPSOJZ for ; Thu, 9 Oct 2014 01:32:06 -0700 (PDT) Received: from a.mx.secunet.com (a.mx.secunet.com [195.81.216.161]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 875581A005F for ; Thu, 9 Oct 2014 01:32:06 -0700 (PDT) Received: from localhost (alg1 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id 10F081A007F; Thu, 9 Oct 2014 10:31:59 +0200 (CEST) X-Virus-Scanned: by secunet Received: from a.mx.secunet.com ([127.0.0.1]) by localhost (a.mx.secunet.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id EY2K6WwCwcUl; Thu, 9 Oct 2014 10:31:54 +0200 (CEST) Received: from mail-essen-02.secunet.de (unknown [10.53.40.205]) by a.mx.secunet.com (Postfix) with ESMTP id 0EFD71A0066; Thu, 9 Oct 2014 10:31:54 +0200 (CEST) Received: from MAIL-ESSEN-01.secunet.de ([fe80::1c79:38b7:821e:46b4]) by mail-essen-02.secunet.de ([fe80::4431:e661:14d0:41ce%16]) with mapi id 14.03.0195.001; Thu, 9 Oct 2014 10:31:58 +0200 From: =?iso-8859-1?Q?Schmidt=2C_J=F6rn-Marc?= To: Alexey Melnikov , "cfrg@irtf.org" Thread-Topic: [Cfrg] draft-irtf-cfrg-dragonfly document status Thread-Index: AQHP4yDZW8PY/F3jXUaU7rwmuJrGsZwnb+tw Date: Thu, 9 Oct 2014 08:31:58 +0000 Message-ID: <38634A9C401D714A92BB13BBA9CCD34F13E26818@mail-essen-01.secunet.de> References: <54357A2A.2010800@isode.com> In-Reply-To: <54357A2A.2010800@isode.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.209.2.99] x-exclaimer-md-config: 2c86f778-e09b-4440-8b15-867914633a10 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/z2XxVvjIOsalIuIkVocpYmoawyg Subject: Re: [Cfrg] draft-irtf-cfrg-dragonfly document status X-BeenThere: cfrg@irtf.org 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: Thu, 09 Oct 2014 08:32:09 -0000 Hi, >1) keep in mind that CFRG chairs believe that the RG should work on PAKE r= equirements and after that on other PAKE proposals. This was suggested by o= ur previous co-chair David McGrew >http://www.ietf.org/mail-archive/web/cfrg/current/msg03723.html So why don't we start right now with a discussion on the requirements (inde= pendent from the current dragonfly draft)? Some aspects I can think of right now:=20 - Royalty-free use/Free of Patents - Security (What kind of model are we considering)? - Support various types of elliptic curves=20 - Good performance, i.e. easy to implement, number of exchanged messages (= and sizes), computational costs Further, I think we should keep the requirements for a mapping if the schem= e is used with elliptic curves in mind: - No mapping required - Mapping on the curve (e.g. SWU, integrated Mapping) - Uniform representation (e.g. Elligator, Elligator squared) Finally, it might help to collect also use cases for PAKE protocols (A look= at the "curves" list might also be useful, e.g. https://moderncrypto.org/m= ail-archive/curves/2014/000077.html). What else do we need to consider? How should we prioritize the requirements= ? Cheers, J=F6rn From nobody Thu Oct 9 01:41:48 2014 Return-Path: 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 955C81ACCE9 for ; Thu, 9 Oct 2014 01:41:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-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 C-wWmXSw7VO3 for ; Thu, 9 Oct 2014 01:41:45 -0700 (PDT) Received: from entima.net (entima.net [78.129.143.175]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E681D1A9168 for ; Thu, 9 Oct 2014 01:41:44 -0700 (PDT) In-Reply-To: References: <2A0EFB9C05D0164E98F19BB0AF3708C71D2FD0953A@USMBX1.msg.corp.akamai.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 From: Alyssa Rowan Date: Thu, 09 Oct 2014 09:41:35 +0100 To: cfrg@irtf.org Message-ID: <86CF878A-9687-436B-8781-D5F22FFE57F1@akr.io> Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/GOZjoA8YflibxDvPwkgnYi_GeYQ Subject: Re: [Cfrg] Alternatives to McGrew's hash based signatures X-BeenThere: cfrg@irtf.org 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: Thu, 09 Oct 2014 08:41:47 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 8 October 2014 16:07:19 BST, Watson Ladd wrote: >> Some might find "signatures are 41Kb" a bit of a stopping point. >Some might find that being unable to use a key if restored from a backup is a stopping point. But that's what the McGrew draft does. Stateful signatures are unpleasant to implement. Difficulties with serialisation/paralellisation, etc. >Maybe we need both. Maybe we do: these are different schemes with different sets of desirable properties? - -- /akr -----BEGIN PGP SIGNATURE----- Version: APG v1.1.1 iQI3BAEBCgAhBQJUNko/GhxBbHlzc2EgUm93YW4gPGFrckBha3IuaW8+AAoJEOyE jtkWi2t6xo4P/RZaaBsHenKsTr5PM3LnmFkPqPcvcBoEl0gzAC5m6IXMJwR0WiRf nwEqqu4NW6j2m8IaVEoaDBFBXPln9lwVpddX/IgxIBirxeS8b26eo3tt8+5J5Gwz rvWiXZnXSP0I/j76xeEXyA5PSA9a6BSft8pp58RftcB2HPjWOku7RBxVnQNoxmyZ UvNwJZPpQI+Uo09QWJ8EczshyxZ/HODvbX6KnpZiL/Z8sckTcgpNEMxZkf11YCZt +Kg+QNLCnR4RMT1FPo4nggHwxVVeNZB+g17wj/7ySpJjXVk76ZUScMDU60Rk9nNA bWVBs7KH+kGaww4gvfIPwZp00uGd0a0e+KmhCqmA7KMA2LUfHE054gEyXUELlHkg r7NLUGMDRag1Uh5Fpbt85OZvZMQL+ma1phZRssMxYBvqRXs7w6naE1+/xC/56B+y vzGhM3h5nuBK0+5FRhFlSmz4+ykYG7mx+6KhWfLH2uxkheuXkQwNTJyN14OMp+/A yKklhBzjC5Iak0PIcSIIV2cLKzZUGcm2V2bHWCxqVtEX7FDad9E/iWeFLdl3hsbD di6rFXLfOtiAtGqu+4NHLmvhx+iFU5s9WxBhcLr6aPP+WbG174qEGzvebEVBEPNq uSxa3AInZy8VrIVu1vruCoWswaAM5LI4gciNAzP6kBg1DY/+QBCk4NlP =IKO+ -----END PGP SIGNATURE----- From nobody Thu Oct 9 04:04:10 2014 Return-Path: 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 628151ACD45 for ; Thu, 9 Oct 2014 04:04:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.386 X-Spam-Level: X-Spam-Status: No, score=-2.386 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.786] 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 K0IVQmgsKQhb for ; Thu, 9 Oct 2014 04:04:07 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id E199B1A0275 for ; Thu, 9 Oct 2014 04:04:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 01D19BDF8; Thu, 9 Oct 2014 12:04:06 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vrUSxlm0gffW; Thu, 9 Oct 2014 12:04:04 +0100 (IST) Received: from [10.87.48.8] (unknown [86.42.22.80]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 7D638BDCF; Thu, 9 Oct 2014 12:04:04 +0100 (IST) Message-ID: <54366BA1.1010603@cs.tcd.ie> Date: Thu, 09 Oct 2014 12:04:01 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: =?UTF-8?B?IlNjaG1pZHQsIErDtnJuLU1hcmMi?= , Alexey Melnikov , "cfrg@irtf.org" References: <54357A2A.2010800@isode.com> <38634A9C401D714A92BB13BBA9CCD34F13E26818@mail-essen-01.secunet.de> In-Reply-To: <38634A9C401D714A92BB13BBA9CCD34F13E26818@mail-essen-01.secunet.de> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/SW5sNtAsFjos8n0BPBK2DDMjtPI Subject: [Cfrg] PAKEs in general (was; Re: draft-irtf-cfrg-dragonfly document status) X-BeenThere: cfrg@irtf.org 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: Thu, 09 Oct 2014 11:04:08 -0000 On 09/10/14 09:31, Schmidt, Jörn-Marc wrote: >> 1) keep in mind that CFRG chairs believe that the RG should work on >> PAKE requirements and after that on other PAKE proposals. This was >> suggested by our previous co-chair David McGrew >>> http://www.ietf.org/mail-archive/web/cfrg/current/msg03723.html > > So why don't we start right now with a discussion on the requirements > (independent from the current dragonfly draft)? I'll just note that there were also voices (incl. mine) saying: "I really don't care about work on PAKEs. Seems like a waste of time to me. But go ahead and spend time on that if you wish." My own logic for that is that such work seems to me to be fine cryptographic work, but of no use at all for IETF protocols. And yes, I know there are some folks who disagree with that in general, or who see specific niches cases where PAKEs might be useful. As it happens, I don't, but like I say just that's a personal opinion and not something with IETF consensus, so don't take my comment as being "from the IETF" or similar. For my money, I'd much prefer to see the additional curves discussion reach a conclusion. And to the extent that work on PAKEs distracts from that, which is hard to evaluate, I see working on PAKEs as a slight negative. S. From nobody Thu Oct 9 07:55:42 2014 Return-Path: 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 7D46B1A1B0D for ; Thu, 9 Oct 2014 07:55:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 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, J_CHICKENPOX_39=0.6, SPF_PASS=-0.001] autolearn=no 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 qKTsYBSVifI1 for ; Thu, 9 Oct 2014 07:55:38 -0700 (PDT) Received: from mail-yh0-x22f.google.com (mail-yh0-x22f.google.com [IPv6:2607:f8b0:4002:c01::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C62EE1A1A9D for ; Thu, 9 Oct 2014 07:55:37 -0700 (PDT) Received: by mail-yh0-f47.google.com with SMTP id c41so781390yho.6 for ; Thu, 09 Oct 2014 07:55:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=AqlfHeWgP3tndJ7802TiR2SPQoG6kYBBGYLA264RbfM=; b=MlvrXdCQm7beVciz6vg52QDUE1U1wflJLMnhYHLuwgScRaJaEXuiV/j+rc5WNOIZJj vBxpwzZS3sGQK6K4QXcJbXgrhqyywVrNETWgPTqVTNDFttXHEmYhLt5R8zIXCQ0M9Q0y XCD3nIaxCHuBI2QOhYvk46nfkqnJiklZ2hekkZCrugxuLdH5WGs+Z8eY/wMaLlxEIl75 Zkthc+hnavECtts+GJE46agvO0ZzeGmC772AftuDgidaBc+vQp/sIgoDDth/w5N0ty3F +w/2z+RgpvbsRlLPLnay85PdukZSDOObhgPBkkMfHS0JZCmYRYdHVjndEAYwTAOWCTaa 4cxA== MIME-Version: 1.0 X-Received: by 10.236.172.161 with SMTP id t21mr26564283yhl.65.1412866536968; Thu, 09 Oct 2014 07:55:36 -0700 (PDT) Received: by 10.170.195.149 with HTTP; Thu, 9 Oct 2014 07:55:36 -0700 (PDT) In-Reply-To: <237f9c809efcbb3e3ffb9df7fe666981.squirrel@www.trepanning.net> References: <54357A2A.2010800@isode.com> <73d51db893a4b847db6d8eaae7f45cf5.squirrel@www.trepanning.net> <237f9c809efcbb3e3ffb9df7fe666981.squirrel@www.trepanning.net> Date: Thu, 9 Oct 2014 07:55:36 -0700 Message-ID: From: Watson Ladd To: Dan Harkins Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/1DM5U5V5GnuSzVb9mdE3HeSlf-8 Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] draft-irtf-cfrg-dragonfly document status X-BeenThere: cfrg@irtf.org 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: Thu, 09 Oct 2014 14:55:40 -0000 On Wed, Oct 8, 2014 at 11:11 PM, Dan Harkins wrote: > > Watson, > > On Wed, October 8, 2014 6:22 pm, Watson Ladd wrote: >> On Wed, Oct 8, 2014 at 4:40 PM, Dan Harkins wrote: >>> >>> Watson, >>> >>> On Wed, October 8, 2014 3:46 pm, Watson Ladd wrote: >>>> On Oct 8, 2014 3:26 PM, "Paul Lambert" wrote: >>>>>> >>>>>> On Oct 8, 2014 10:53 AM, "Alexey Melnikov" >>>>>> >>>> wrote: >>>>>> > >>>>>> > Hi, >>>>>> > My apologies for taking so long on this. But I felt I needed to >>>>>> review >>>> mailing list discussions to make up my own mind on this topic. >>>>>> > >>>>>> > After reviewing mailing list discussions about this draft, I would >>>> like to do another RGLC on it. I've seen negative comments on the >>>> mailing >>>> list, but I've also seen some interest in this work and I am also awar= e >>>> that some variants of the algorithm are already implemented/deployed. >>>> Also, >>>> there were a couple of new revisions of the draft and it is not clear >>>> whether people who reported original problems are happy with how they >>>> got >>>> resolved. So I would like to see a bit more positive feedback on the >>>> latest >>>> version, in particular I would like to know if specific issues raised >>>> by >>>> earlier reviews are addressed in the latest version. >>>>> >>>>> This draft should be published as an RFC. There is considerable valu= e >>>>> in >>>> having a published stable reference document. The market should be >>>> allowed to do the estimations of risk and value to field this protocol= . >>>> >>>> Just as they did with RC4 and renegotiation? >>> >>> This has nothing to do with RC4 and renegotiation (I assume you mean >>> in TLS). >> >> I'm questioning the ability of market participants to evaluate >> cryptography. > > Well then you are making very odd comments. Market participants had > nothing to do with defining renegotiation. But, again, this has nothing t= o > do with the draft in question. Did you read Peter's email? At some point we need to have a substantive discussion of the security of dragonfly, because people outside the CFRG don't have the training to do so. The fact that dragonfly is hard to analyze is a negative not a positive. > >>>>> Versions of the protocol have been adopted and fied. This protocol wa= s >>>> first introduced into IEEE 802.11s in 2008. The base protocol exchang= e >>>> has >>>> also been adopted in the Wi-Fi Alliance. The protocol has been >>>> improved >>>> by the review in the cfrg and if published, the specification would >>>> positively impact the application of the protocol in other forums. >>>>> >>>>>> My comment (there is no security proof, and alternatives with better >>>> provable security) has been acknowledged to be unresolveable. >>>>> >>>>> Yes, this may be considered a negative point by some but not all. >>>>> While >>>> not a proof, the protocol has been analyzed: >>>>> Cryptanalysis of the Dragonfly Key Exchange Protocol >>>>> It was interested that the only issue mentioned was a small subgroup >>>> attack if the public key is not validated =E2=80=A6. which it always s= hould. >>>> >>>> This analysis ignores Rene Struik's timing attack, my reflection >>>> attack, >>>> and other comments incorporated into the draft. >>> >>> And I thanked Rene, you, and others for your comments and, as you >>> note, >>> incorporated resolutions into the draft. Once again, thank you for >>> helping >>> improve the draft. All of the comments have been resolved in -04. >>> >>> (I will note that the reflection attack you mentioned is not possible >>> in the IEEE 802.11 version of dragonfly, which predated your comment >>> and this draft by a few years, and neither was small subgroup attack >>> described by Clarke and Hao mentioned above. The -00 version of this >>> draft was rushed, take a look at the Acknowledgements in section 4 to >>> see just how bad, and I left some things out that I shouldn't have. All >>> this has all been addressed in -04). >> >> Why did the draft not track the IEEE 802.11 version? Also, as I >> remember from discussing this issue in the TLS WG, the CFRG draft >> version and the TLS draft version differed substantially, enough to >> make the reflection attack not work. (There were interactions with the >> rest of TLS that prevented it) While only tangentially relevant to the >> issue, this is the kind of issue which leads to all sorts of bugs in >> protocols that should be secure. > > The draft was intended to be a generic instantiation of a key > exchange that had been defined in 3 different protocols, each of > which has its own idiosyncrasies. I dealt with the reflection issue in > the IEEE 802.11 instantiation because it was for mesh networks and > there is no notion of a "server" or a "client" or an "initiator" or a > "responder" in a mesh, everyone is an equal peer who can actually > each view themselves as the "initiator" if the timing is right. The > reflection attack was something that needed addressing in the > protocol as opposed to, say, the TLS variant which is not susceptible > to that attack due to the nature of TLS. Again, in my haste to generalize > the key exchange I removed stuff that should not have been removed. > But, as I mentioned, it is in the latest draft that is subject of the RGL= C, > thanks to the useful and constructive comments of RG members, > including you. Yes, it is now fixed. What else is wrong? > >> It also is not clear how relevant the proposed draft will be >> >>> >>>>>> >>>>>> The draft authors knew this from the very beginning. >>>>>> >>>>>> I don't think we should approve a protocol that doesn't have a >>>>>> security >>>> proof, particularly given that we are going to work on alternatives. >>>>> >>>>> =E2=80=9C=E2=80=A6 Going to work on =E2=80=A6=E2=80=9D is the issue. = The draft under >>>>> discussion >>>>> has been >>>> on IETF servers for 2 years. It has been used in other industry forum= s >>>> for >>>> four or five years. >>>> >>>> Plenty of alternatives have been put forward in those two years, >>>> including >>>> EKE+Elligator, SPAKE2, JPAKE, and SMP based solutions. The failure >>>> to >>>> advance these is inexplicable. >>> >>> Oh no, it's very easily explained. It's because no one has stepped >>> forward >>> to actually write the I-Ds. You have stated on numerous occasions that >>> these >>> should be written up but you have never actually taken on the task of >>> actually doing it. Please, write up a draft or four. Whether or not yo= u >>> do, >>> though, this really has nothing to do with the RGLC underway right now. >> >> JPAKE was described in a series of drafts that weren't made WG work >> items. I see no reason that the eventual disposition of SPAKE2, SMP, >> or EKE+Elligator drafts would be any different, and thus see no reason >> to write the drafts. > > The disposition is due to the diligence and hard work of the editor of > the I-D. If you want drafts to be produced in a RG (or WG) the best way > to do that is to socialize the idea, write the draft, and advocate for it= . > If you sit back and send periodic emails criticizing everyone else for no= t > doing what you, in your wisdom from the comfort of your couch, see as > necessary nothing will get done. And Feng Hao wasn't working hard enough promoting JPAKE? Again, there was significant development of various alternatives on the CFRG mailing list, and if what you need is an RFC draft to consider an alternative, that's easy to write. I feel the issue is that you don't believe the CFRG actually analyzes alternatives, merely edits drafts describing protocols, whereas I think the CFRG analyses alternatives, and the actual draft writing is trivial in comparison. I'll happily write the drafts this weekend. But I doubt that any degree of hard work will lead to adoption or publication. > >>> If there was a security proof of dragonfly it would not be, nor shoul= d >>> it >>> be, part of this draft. It would be a stand-alone paper. The complaint >>> about >>> the lack of a security proof is really procedural and not technical as >>> it is >>> not a comment on the draft that can be resolved by changing the draft. >>> The IRTF (and the IETF as well) has never put a security proof as a >>> process >>> requirement for advancement of I-Ds. You may think it should but that >>> is an argument for a different place, not a RGLC. >> >> It could be resolved by opening the draft, deleting the contents, >> inserting contents describing a protocol with a security proof and >> referring to the proof published elsewhere, and submitting the new >> version, so clearly it is an issue with the contents of the draft. > > No, I'm talking about other protocols which have security proofs > behind the that have been specified in IRTF or IETF RFCs. Look at > SRP (RFC 2945). The security proof is not in the RFC. And if a security > proof of dragonfly comes around there is no reason why it should be > part of this I-D or a subsequent RFC. But isn't the existence of the proof relevant, even if it's not in the RFC? Furthermore, a security proof will not come around: I agree with the original assessment that "this is not the kind of protocol we prove secure". I've tried several times without success, and I don't think I'm the only one trying. > >> I think what you meant to say is it couldn't be resolved without >> substantially changing the protocol, which also isn't true: if the >> shared secret was a hash of all the messages, and the peer-scalars >> were removed, the result would be a secure PAKE with a security proof. >> But unfortunately it would be a patented one. > > No, that's not what I mean at all. I mean that security proofs are > usually stand-alone papers (in the proceedings of the such-and-such > symposium of secure communications), not parts of RFCs. This is no > different. > >> There are plenty of drafts that have piled up in various nooks and >> crannies that never get adopted as WG items, despite requests from >> authors. I don't see why we need to publish this draft, and I don't >> see why we need to publish a draft for a protocol inferior to >> alternatives that have been well-studied and are well-regarded. The >> argument you are making seems to be that anything will get published, >> provided it's sufficiently polished, no matter how much better the >> alternatives are. > > If you have any further technical comments on the I-D, I encourage > their mention. How do I know we didn't make more mistakes? > > regards, > > Dan. > >> Sincerely, >> Watson Ladd >> >>> >>> regards, >>> >>> Dan. >>> >>>>> >>>>> Yes, the cfrg should work as quickly as possible to make alternatives= . >>>> Stopping the progression of this draft does not accelerate new work, >>>> but >>>> does prevent existing applications from utilizing a reviewed and >>>> improved >>>> specification. >>>> >>>> The nonexistence of this draft did not stop adoption in Wifi. By >>>> contrast >>>> advancing a number of PAKEs will kick the issue to WGs without the >>>> capacity >>>> to evaluate the issues. >>>> >>>>>> >>>>>> There is plenty of terrible crypto in IEEE standards >>>>> >>>>> =E2=80=A6 and IETF standards. Bringing in other good or bad protocol= s into >>>>> the >>>> discussion is irrelevant to the decision at hand. >>>>>> >>>>>> we don't issue drafts for because it is so terrible. >>>>> >>>>> Since when did the IETF mandate a security proof =E2=80=A6 There ar= e >>>>> terrible >>>> protocols with proofs, so why does the lack of a proof made something >>>> =E2=80=98terrible=E2=80=99. >>>>> >>>>> Paul >>>>> >>>>> >>>>> >>>>>> To the extent our publication leads to use of dragonfly as opposed t= o >>>> known - good protocols, it's a problem. >>>>> >>>>> >>>>> >>>>> >>>>>> > >>>>>> > Considering how difficult previous Last Call on the document was, = I >>>> would like to ask people to: >>>>>> > 1) keep in mind that CFRG chairs believe that the RG should work o= n >>>> PAKE requirements and after that on other PAKE proposals. This was >>>> suggested by our previous co-chair David McGrew: >>>>>> > http://www.ietf.org/mail-archive/web/cfrg/current/msg03723.html >>>>>> >>>>>> Why doesn't this apply to dragonfly, but only other proposals? >>>>>> >>>>>> > 2) be professional, in particular no ad hominem attacks >>>>>> > 3) be constructive. In particular if you would like a disclaimer >>>>>> being >>>> added to the document, please suggest specific text. >>>>>> > 4) simple statements of support for publishing the document or >>>> objection to publishing it are fine and encouraged. Sending them >>>> directly >>>> to RG chairs is fine. But please avoid saying "but what about >>>> PAKEXXX?", >>>> due to 1). >>>>>> > 5) unlike IETF, IRTF RGs are not required to reach rough consensus= . >>>> However I would like to see us try. >>>>>> > >>>>>> > Best Regards, >>>>>> > Alexey, >>>>>> > on behalf of chairs. >>>>>> > >>>>>> > _______________________________________________ >>>>>> > Cfrg mailing list >>>>>> > Cfrg@irtf.org >>>>>> > http://www.irtf.org/mailman/listinfo/cfrg >>>>> >>>>> >>>> _______________________________________________ >>>> Cfrg mailing list >>>> Cfrg@irtf.org >>>> http://www.irtf.org/mailman/listinfo/cfrg >>>> >>> >> >> >> >> -- >> "Those who would give up Essential Liberty to purchase a little >> Temporary Safety deserve neither Liberty nor Safety." >> -- Benjamin Franklin >> > --=20 "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Thu Oct 9 08:55:05 2014 Return-Path: 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 C9FE31A1B98 for ; Thu, 9 Oct 2014 08:55:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] 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 3Eme3HkX-1Wk for ; Thu, 9 Oct 2014 08:54:59 -0700 (PDT) Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 980031A1BF7 for ; Thu, 9 Oct 2014 08:54:57 -0700 (PDT) Received: by mail-wi0-f174.google.com with SMTP id cc10so13637787wib.1 for ; Thu, 09 Oct 2014 08:54:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=e44qcYrLpn9mK/3ouKVUbgGlh0+6gfA9UY7rICZFAXA=; b=W1KXCK51evQLrHzrKzMlKRDBxumJBxEMQuNywSfNYvdmLLgZ1dWitaLjbPlr72vWvc Mjt+c59+fY1AaYtSR9Lcy0DS2f47vZeIxK8Evkc+8whYhzR2jcH9TR2UPJ58d/RcT76+ q4qUf1NvAGl0Zz90XWtsNFN/z0ivwK5w33n864s1MU54DAqXJuubv6YisixIrjA+kR2O Ms48Y2XdNSkG2RSH0CXh9LQlvIPuxM1D6eW8ieDW/jv+mPevkfQ7qFzjViR6MVKCKxo1 beUqB4++q/2DavDkRbyLf3SYJ/qnwuf+p2MF98YTWNPIPMCGSBZgtI7rd+9+jG0kgDvj hi8g== X-Gm-Message-State: ALoCoQkCIXVnLNLBK0tAqqA7/NQIrMTgRCdX3rwtwpxrLiKySSSq3wsP1qvREYf/ynnGED6pxNKn MIME-Version: 1.0 X-Received: by 10.180.73.103 with SMTP id k7mr40780667wiv.1.1412870095971; Thu, 09 Oct 2014 08:54:55 -0700 (PDT) Received: by 10.194.87.105 with HTTP; Thu, 9 Oct 2014 08:54:55 -0700 (PDT) In-Reply-To: References: Date: Thu, 9 Oct 2014 15:54:55 +0000 Message-ID: From: Zooko Wilcox-OHearn To: Watson Ladd Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/KWNzg8tpK0aC-FqxObwoubpNDLY Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] Alternatives to McGrew's hash based signatures X-BeenThere: cfrg@irtf.org 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: Thu, 09 Oct 2014 15:55:02 -0000 Hi, thanks for the mention of SPHINCS! I'm one of the authors of SPHINCS. (Disclaimer: the other authors are the smart ones.) The reason why I care about SPHINCS is that I would never want to rely on durable update of mutable state. I come primarily from a practical/engineering background. I've been doing security audits for a living (with my company https://LeastAuthority.com). I've also worked quite a lot in the storage world=E2=80=94databases, filesystems, clo= ud storage, etc. To me, the idea that you have to guarantee that a state update (i.e. a previously unused sequence number or nonce) is durably written, or else you leak your private signing key to an attacker=E2=80=A6 that's a show-stopper. I disbelieve that any commodity hardware and software in use today can do that safely. Regards, Zooko From nobody Thu Oct 9 09:56:11 2014 Return-Path: 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 C63CE1AC7E7 for ; Thu, 9 Oct 2014 09:55:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.967 X-Spam-Level: X-Spam-Status: No, score=-1.967 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, 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 KquD_z2y0k9q for ; Thu, 9 Oct 2014 09:55:44 -0700 (PDT) Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com [67.231.156.173]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68B481AD369 for ; Thu, 9 Oct 2014 09:55:36 -0700 (PDT) Received: from pps.filterd (m0045851.ppops.net [127.0.0.1]) by mx0b-0016f401.pphosted.com (8.14.5/8.14.5) with SMTP id s99GtTXf022892; Thu, 9 Oct 2014 09:55:29 -0700 Received: from sc-owa.marvell.com ([199.233.58.135]) by mx0b-0016f401.pphosted.com with ESMTP id 1pwsx8rxuk-17 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 09 Oct 2014 09:55:29 -0700 Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by SC-OWA.marvell.com ([::1]) with mapi; Thu, 9 Oct 2014 09:55:27 -0700 From: Paul Lambert To: Stephen Farrell , =?Windows-1252?Q?=22Schmidt=2C_J=F6rn-Marc=22?= , Alexey Melnikov , "cfrg@irtf.org" Date: Thu, 9 Oct 2014 09:55:25 -0700 Thread-Topic: [Cfrg] PAKEs in general (was; Re: draft-irtf-cfrg-dragonfly document status) Thread-Index: Ac/j4dMvkUIRrTTaR3+oVa9eS2pQvA== Message-ID: References: <54357A2A.2010800@isode.com> <38634A9C401D714A92BB13BBA9CCD34F13E26818@mail-essen-01.secunet.de> <54366BA1.1010603@cs.tcd.ie> In-Reply-To: <54366BA1.1010603@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.28, 0.0.0000 definitions=2014-10-09_07:2014-10-09,2014-10-09,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1410090125 Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/q16KPx0cHXOAbnnPU6fmrbTxprY Subject: Re: [Cfrg] PAKEs in general (was; Re: draft-irtf-cfrg-dragonfly document status) X-BeenThere: cfrg@irtf.org 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: Thu, 09 Oct 2014 16:55:53 -0000 X-List-Received-Date: Thu, 09 Oct 2014 16:55:53 -0000 On 10/9/14, 4:04 AM, "Stephen Farrell" wrote: > > >On 09/10/14 09:31, Schmidt, J=F6rn-Marc wrote: >>> 1) keep in mind that CFRG chairs believe that the RG should work on >>> PAKE requirements and after that on other PAKE proposals. This was >>> suggested by our previous co-chair David McGrew >>>> http://www.ietf.org/mail-archive/web/cfrg/current/msg03723.html >> >> So why don't we start right now with a discussion on the requirements >> (independent from the current dragonfly draft)? > >I'll just note that there were also voices (incl. mine) saying: >"I really don't care about work on PAKEs. Seems like a waste of >time to me. But go ahead and spend time on that if you wish." +1 mostly. Shared passwords are architecturally problematic. They are more useable ways to authenticate. As a community we should be spending time on forward looking opportunities. The =8Cmostly' is that the Dragonfly draft should be published so it can be used a little better in a couple of specific environments where it is already being wired into systems. Specifically, IEEE 802.11 has the SAE protocol which uses the Dragonfly exchange for mesh networks. There are other peer-to-peer wireless applications that could use Dragonfly soon. In particular, the Wi-Fi industry also has a long standing issue with password based authentication being subject to brute-force attacks in the WPA2=3DPersonal authentication (aka 4-way handshake). Dragonfly in the form of SAE will potentially be dropped in as a replacement for the current hash based exchange. J-PAKE is also a =8Cnice=B9 looking PAKE algorithm with a good credentials. Someone should take the time to continue it=B9s documentation and progression =8A but I would NOT want to be using any PAKE directly in the future as a primary means of authentication. A PAKE-like construct might be incorporated as a building block in some non-password based authentication system, but is not a pressing industry need at this level of abstraction. J-PAKE is NOT a viable near term replacement for Dragonfly in the wireless market. It takes many hundreds of hours of work and years of effort to push real industry adoption of a technology in markets that involve multiple interoperating vendors. Applications, like Mozilla, can push fast and wide adoption of mechanisms like J-PAKE without having to deal with the sluggish nature of broader interoperability forums (like Wi-Fi). Dragonfly is in it=B9s 8th trimester of birth. It=B9s been pointed out that while it appears to be completely healthy, there is no =8Cproof=B9 that it=B9s genetic structure can be proven to be =8Chealthy=B9. No unresolved flaws have been identified. A vocal zealot from the Church of Formal Reduction insists that it be aborted because it has not been blessed. This =8Cbaby=B9 may not be as cute as others, but it has a planned and ready forum for adoption. Dragonfly should be published. This does not prevent other PAKE=B9s from emerging (which they should). Publishing Dragonfly is not a recommendation that it is the best PAKE, or the long term answer for global warming. Publishing Dragonfly provides a stable reference versus a transient draft. The cfrg review has helped to create a clear and correct specification that should be published. >My own logic for that is that such work seems to me to be fine >cryptographic work, but of no use at all for IETF protocols. And >yes, I know there are some folks who disagree with that in general, >or who see specific niches cases where PAKEs might be useful. As >it happens, I don't, but like I say just that's a personal opinion >and not something with IETF consensus, so don't take my comment as >being "from the IETF" or similar. Yes. Standalone PAKEs are not good general solutions for IETF protocols, but the nature of =8Cgood general solutions' are not worth debating without the context of specific usage. Starting new debate on new mechanisms is not relevant to the discussion of the clarity and correctness of a proposed RFC. Dragonfly should be published. > >For my money, I'd much prefer to see the additional curves discussion >reach a conclusion. And to the extent that work on PAKEs distracts >from that, which is hard to evaluate, I see working on PAKEs as a >slight negative. Another reason to publish Dragonfly and move on. J-PAKE or other PAKEs will be brought to this forum for review, but involved development of requirements and comparisons of =8Cbest=B9 is a waste of this forums time. Paul PS - my apologies to the list for posting my opinion again that Dragonfly be published as an RFC (oops did it again :-) I will back away for awhile to hear other voices on the list. Repetition of position does not help the consensus determination. > >S. > >_______________________________________________ >Cfrg mailing list >Cfrg@irtf.org >http://www.irtf.org/mailman/listinfo/cfrg From nobody Thu Oct 9 10:24:49 2014 Return-Path: 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 43AEE1A8BB7 for ; Thu, 9 Oct 2014 10:24:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, 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 ldH7ycxPVLDX for ; Thu, 9 Oct 2014 10:24:43 -0700 (PDT) Received: from mail-lb0-f177.google.com (mail-lb0-f177.google.com [209.85.217.177]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D80F1A88AC for ; Thu, 9 Oct 2014 10:21:22 -0700 (PDT) Received: by mail-lb0-f177.google.com with SMTP id w7so1570954lbi.8 for ; Thu, 09 Oct 2014 10:21:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=EUqVBWPQSOa2Hzh6/9zlSXR0cnCCKBkluC9YQVDn3yo=; b=Dbzfz213ZDgZ1oAsVZ943lgmBPCWWybwBI2k2GJ9aWicSEH4Au9kax0zrRj2Xr+N8T ExGnCcenRosexdL2XKSOkslCHDMUIHSsg+jmhjJTABGDPWztp7tW4nwD2Jt/wM4rK4lB szV90sVEcmKkYSpecA7x0Vfl1ocvEML8XcW4VSb4tYvJtDWgnOUZjq6rA+drfNDtNk+1 GerbNS1GYgqt2x/hdPeKXCouapf0tis7P58y3JY3LIiQ0zI47/GAk/Wb+tNTbt5gZ1/k N9f4FhQHlnIhxoVmMXJwGLVVIgm9DKq4GBjIp2Egg5NZHjUGJxbr4jZSZfNuMDAEs3Hd s1iQ== X-Gm-Message-State: ALoCoQmlDrWFZeC+SWEP5zQAt2mZg/4NQfeXmM8OloKrUfBBTT52a8VZMQ4LPZZo4M7NmsmjaWUJ X-Received: by 10.152.87.146 with SMTP id ay18mr8659683lab.72.1412875280334; Thu, 09 Oct 2014 10:21:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.36.106 with HTTP; Thu, 9 Oct 2014 10:21:00 -0700 (PDT) In-Reply-To: References: <54357A2A.2010800@isode.com> <38634A9C401D714A92BB13BBA9CCD34F13E26818@mail-essen-01.secunet.de> <54366BA1.1010603@cs.tcd.ie> From: Andy Lutomirski Date: Thu, 9 Oct 2014 10:21:00 -0700 Message-ID: To: Paul Lambert Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/-mqbDqAf4jfjWBiEjuXiiDkKgfU Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] PAKEs in general (was; Re: draft-irtf-cfrg-dragonfly document status) X-BeenThere: cfrg@irtf.org 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: Thu, 09 Oct 2014 17:24:45 -0000 On Thu, Oct 9, 2014 at 9:55 AM, Paul Lambert wrote: > > The =C5=92mostly' is that the Dragonfly draft should be published > so it can be used a little better in a couple of specific > environments where it is already being wired into systems. > Specifically, IEEE 802.11 has the SAE protocol which uses > the Dragonfly exchange for mesh networks. There are other > peer-to-peer wireless applications that could use Dragonfly > soon. In particular, the Wi-Fi industry also has a long > standing issue with password based authentication > being subject to brute-force attacks in the > WPA2=3DPersonal authentication (aka 4-way handshake). > Dragonfly in the form of SAE will potentially > be dropped in as a replacement for the current > hash based exchange. I believe that this is exactly why quite a few people (myself included) think that CFRG should think long and hard before publishing Dragonfly. To the extent that CFRG's imprimatur will enourage IEEE802.11 adoption of Dragonfly, CFRG should *not* bless Dragonfly. Let's review: IEEE802.11 adopted WEP despite best practices suggesting that the protocol, as designed, should not be used. As far as I know, no one knew how to break it when it was adopted, but no one had a compelling argument that it couldn't be broken. WEP was later upgraded to WPA2 (I'm ignoring TKIP and friends). There was no security proof for WPA2, but it seemed good enough, especially given the contraints at the time. IIRC it ended up being considerably weaker than hoped. Now apparently Dragonfly is being proposed. At least Dragonfly claims to have the right security properties. But, from reading all the discussion here, it seems that Dragonfly is only unbroken because the issues in early drafts were fixed and the known attempts to attack it don't work. But this is ridiculous for a new protocol. There are multiple simple protocols with security proofs, *especially* for balanced PAKEs. There are the various SPAKE flavors, J-PAKE, and (my favorite because it's so simple) DH-EKE. If CFRG wants to publish the Dragonfly draft with a statement that Dragonfly is not recommended for new designs, that's one thing. But publishing it as is, especially if that will be seen as a sign that it is appropriate to use in new designs, seems dangerous. --Andy From nobody Thu Oct 9 10:39:22 2014 Return-Path: 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 3410E1A7016 for ; Thu, 9 Oct 2014 10:39:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.855 X-Spam-Level: * X-Spam-Status: No, score=1.855 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_NET=0.311, MIME_8BIT_HEADER=0.3, RDNS_DYNAMIC=0.982, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no 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 vwIzRv4Yt-2X for ; Thu, 9 Oct 2014 10:39:19 -0700 (PDT) Received: from aspartame.shiftleft.org (199-116-74-168-v301.PUBLIC.monkeybrains.net [199.116.74.168]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80FA61A6FFF for ; Thu, 9 Oct 2014 10:39:19 -0700 (PDT) Received: from [192.168.1.124] (unknown [192.168.1.1]) by aspartame.shiftleft.org (Postfix) with ESMTPSA id 707C0F2208; Thu, 9 Oct 2014 10:37:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=shiftleft.org; s=sldo; t=1412876269; bh=OCPxTzUCga0+rw42gV3qtZ8u5JOmowSmheM9raPgRts=; h=Date:From:To:Subject:References:In-Reply-To:From; b=NWYXiRkvLD3nCnLHWWX7McqU+7EXmhUTo/UgUUBCia6HM0G5G4oWMzPfhloMXWul6 mKmb6U/ajYm0LqyLqPsWDmoeO/5kprrKSx2r5zX/hE5TG/86t9U5APLOBnqmdTj9T0 37lRgjxboH2A27J0dFUBKJwTioHwb9fkNIKH38QA= Message-ID: <5436C843.1030501@shiftleft.org> Date: Thu, 09 Oct 2014 10:39:15 -0700 From: Mike Hamburg User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Paul Lambert , Stephen Farrell , =?windows-1252?Q?=22Schmidt=2C_J=F6rn-Marc=22?= , Alexey Melnikov , "cfrg@irtf.org" References: <54357A2A.2010800@isode.com> <38634A9C401D714A92BB13BBA9CCD34F13E26818@mail-essen-01.secunet.de> <54366BA1.1010603@cs.tcd.ie> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/J-nuaArGBZMCVTrUZFWFXETh99o Subject: Re: [Cfrg] PAKEs in general (was; Re: draft-irtf-cfrg-dragonfly document status) X-BeenThere: cfrg@irtf.org 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: Thu, 09 Oct 2014 17:39:21 -0000 Before this topic entirely fades away, for those of you who think PAKEs are worthwhile: what properties are useful in a PAKE? Did Jorn-Marc Schmidt cover it? Do you have extra requirements on message orders, augmentation, or anything like that? I'm trying to configure SPAKE2+Elligator in a way that covers how people will actually want to use it. Feel free to respond off-list, since at least Paul and Sephen think it's not worth discussing this on list. -- Mike On 10/9/2014 9:55 AM, Paul Lambert wrote: > > On 10/9/14, 4:04 AM, "Stephen Farrell" wrote: > >> >> On 09/10/14 09:31, Schmidt, Jrn-Marc wrote: >>>> 1) keep in mind that CFRG chairs believe that the RG should work on >>>> PAKE requirements and after that on other PAKE proposals. This was >>>> suggested by our previous co-chair David McGrew >>>>> http://www.ietf.org/mail-archive/web/cfrg/current/msg03723.html >>> So why don't we start right now with a discussion on the requirements >>> (independent from the current dragonfly draft)? >> I'll just note that there were also voices (incl. mine) saying: >> "I really don't care about work on PAKEs. Seems like a waste of >> time to me. But go ahead and spend time on that if you wish." > +1 mostly. > > Shared passwords are architecturally problematic. They are > more useable ways to authenticate. As a community we should > be spending time on forward looking opportunities. > > The mostly' is that the Dragonfly draft should be published > so it can be used a little better in a couple of specific > environments where it is already being wired into systems. > Specifically, IEEE 802.11 has the SAE protocol which uses > the Dragonfly exchange for mesh networks. There are other > peer-to-peer wireless applications that could use Dragonfly > soon. In particular, the Wi-Fi industry also has a long > standing issue with password based authentication > being subject to brute-force attacks in the > WPA2=Personal authentication (aka 4-way handshake). > Dragonfly in the form of SAE will potentially > be dropped in as a replacement for the current > hash based exchange. > > J-PAKE is also a nice looking PAKE algorithm with a good > credentials. Someone should take the time to continue its > documentation and progression but I would NOT want to be > using any PAKE directly in the future as a primary means of > authentication. A PAKE-like construct might be > incorporated as a building block in some non-password > based authentication system, but is not a pressing > industry need at this level of abstraction. > > > J-PAKE is NOT a viable near term replacement for > Dragonfly in the wireless market. It takes many > hundreds of hours of work and years of effort to > push real industry adoption of a technology in > markets that involve multiple interoperating > vendors. Applications, like Mozilla, can push > fast and wide adoption of mechanisms like J-PAKE > without having to deal with the sluggish nature > of broader interoperability forums (like Wi-Fi). > > Dragonfly is in its 8th trimester of birth. Its > been pointed out that while it appears to be completely > healthy, there is no proof that its genetic structure > can be proven to be healthy. No unresolved flaws > have been identified. A vocal zealot from the Church > of Formal Reduction insists that it be aborted > because it has not been blessed. > > This baby may not be as cute as others, but it has a > planned and ready forum for adoption. Dragonfly should > be published. This does not prevent other PAKEs from > emerging (which they should). Publishing Dragonfly is > not a recommendation that it is the best PAKE, > or the long term answer for global warming. > Publishing Dragonfly provides a stable reference > versus a transient draft. The cfrg review has helped > to create a clear and correct specification that should > be published. > > > >> My own logic for that is that such work seems to me to be fine >> cryptographic work, but of no use at all for IETF protocols. And >> yes, I know there are some folks who disagree with that in general, >> or who see specific niches cases where PAKEs might be useful. As >> it happens, I don't, but like I say just that's a personal opinion >> and not something with IETF consensus, so don't take my comment as >> being "from the IETF" or similar. > Yes. Standalone PAKEs are not good general solutions for > IETF protocols, but the nature of good general solutions' > are not worth debating without the context of specific usage. > > Starting new debate on new mechanisms is not relevant > to the discussion of the clarity and correctness of a proposed > RFC. Dragonfly should be published. > > > >> For my money, I'd much prefer to see the additional curves discussion >> reach a conclusion. And to the extent that work on PAKEs distracts > >from that, which is hard to evaluate, I see working on PAKEs as a >> slight negative. > Another reason to publish Dragonfly and move on. J-PAKE or > other PAKEs will be brought to this forum for review, > but involved development of requirements and comparisons > of best is a waste of this forums time. > > > Paul > > PS - my apologies to the list for posting my opinion again > that Dragonfly be published as an RFC (oops did it again :-) > I will back away for awhile to hear other voices on the list. > Repetition of position does not help the consensus determination. > > > >> S. >> >> _______________________________________________ >> Cfrg mailing list >> Cfrg@irtf.org >> http://www.irtf.org/mailman/listinfo/cfrg > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg From nobody Thu Oct 9 10:40:24 2014 Return-Path: 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 B01AD1AD45B for ; Thu, 9 Oct 2014 10:40:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.785 X-Spam-Level: X-Spam-Status: No, score=-2.785 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.786] 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 W9cxCfLvq1Bk for ; Thu, 9 Oct 2014 10:40:18 -0700 (PDT) Received: from statler.isode.com (ext-bt.isode.com [217.34.220.158]) by ietfa.amsl.com (Postfix) with ESMTP id 1EE5C1A7016 for ; Thu, 9 Oct 2014 10:40:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1412876416; d=isode.com; s=selector; i=@isode.com; bh=BAK+iQ3EyOScHXEUupcbd9V/ATYC1newn25sKN5cRpU=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=CIZItIRStA3MgF+pS6UTezd1C9px0EaSp5Dx5+l85Oz2gPqkcgFQkBsd304OwREOxyKHCX N2JGUDsvh6dheWtduDU3geIhzIK+8uuUHWwZRG2Mw3Ry73FGY415LSEiVHXBZvbp2GIHsQ LkACHsa7lX2AlxC/5lv1D3M4+QGfTh8=; Received: from [172.20.1.47] (dhcp-47.isode.net [172.20.1.47]) by statler.isode.com (submission channel) via TCP with ESMTPA id ; Thu, 9 Oct 2014 18:40:15 +0100 Message-ID: <5436C882.7050700@isode.com> Date: Thu, 09 Oct 2014 18:40:18 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 To: Watson Ladd References: <54357A2A.2010800@isode.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------020704090509070605000003" Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/-6R2j3AtFJE-Cu0FprRRivDRpNg Cc: cfrg@irtf.org Subject: Re: [Cfrg] draft-irtf-cfrg-dragonfly document status X-BeenThere: cfrg@irtf.org 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: Thu, 09 Oct 2014 17:40:20 -0000 --------------020704090509070605000003 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi, On 08/10/2014 19:09, Watson Ladd wrote: > > On Oct 8, 2014 10:53 AM, "Alexey Melnikov" > wrote: > > > > Hi, > > My apologies for taking so long on this. But I felt I needed to > review mailing list discussions to make up my own mind on this topic. > > > > After reviewing mailing list discussions about this draft, I would > like to do another RGLC on it. I've seen negative comments on the > mailing list, but I've also seen some interest in this work and I am > also aware that some variants of the algorithm are already > implemented/deployed. Also, there were a couple of new revisions of > the draft and it is not clear whether people who reported original > problems are happy with how they got resolved. So I would like to see > a bit more positive feedback on the latest version, in particular I > would like to know if specific issues raised by earlier reviews are > addressed in the latest version. > > My comment (there is no security proof, and alternatives with better > provable security) has been acknowledged to be unresolveable. The > draft authors knew this from the very beginning. > Ok, your opinion was heard. > > I don't think we should approve a protocol that doesn't have a > security proof, particularly given that we are going to work on > alternatives. > Chairs can't promise that the RG will ever converge on requirements. We can try, but there is no guaranty that anything will come out of this later effort. > > There is plenty of terrible crypto in IEEE standards we don't issue > drafts for because it is so terrible. To the extent our publication > leads to use of dragonfly as opposed to known - good protocols, it's a > problem. > > > > > Considering how difficult previous Last Call on the document was, I > would like to ask people to: > > 1) keep in mind that CFRG chairs believe that the RG should work on > PAKE requirements and after that on other PAKE proposals. This was > suggested by our previous co-chair David McGrew: > > http://www.ietf.org/mail-archive/web/cfrg/current/msg03723.html > > Why doesn't this apply to dragonfly, but only other proposals? > Because Dragonfly got there first. I don't think it is reasonable to delay the document which is effectively done and not known to be broken. > > 2) be professional, in particular no ad hominem attacks > > > 3) be constructive. In particular if you would like a disclaimer > being added to the document, please suggest specific text. > > 4) simple statements of support for publishing the document or > objection to publishing it are fine and encouraged. Sending them > directly to RG chairs is fine. But please avoid saying "but what about > PAKEXXX?", due to 1). > > 5) unlike IETF, IRTF RGs are not required to reach rough consensus. > However I would like to see us try. > > > > Best Regards, > > Alexey, > > on behalf of chairs. > --------------020704090509070605000003 Content-Type: text/html; charset=UTF-8 Content-transfer-encoding: quoted-printable
Hi,

On 08/10/2014 19:09, Watson Ladd wrote:

On Oct 8, 2014 10:53 AM, "Alexey Melnikov" <alexey.melnikov@isode.com> wrote:
>
> Hi,
> My apologies for taking so long on this. But I felt I needed to review mailing list discussions to make up my own mind on this topic.
>
> After reviewing mailing list discussions about this draft, I would like to do another RGLC on it. I've seen negative comments on the mailing list, but I've also seen some interest in this work and I am also aware that some variants of the algorithm are already implemented/deployed. Also, there were a couple of new revisions of the draft and it is not clear whether people who reported original problems are happy with how they got resolved. So I would like to see a bit more positive feedback on the latest version, in particular I would like to know if specific issues raised by earlier reviews are addressed in the latest version.

My comment (there is no security proof, and alternatives with better provable security) has been acknowledged to be unresolveable. The draft authors knew this from the very beginning.

Ok, your opinion was heard.

I don't think we should approve a protocol that doesn't have a security proof, particularly given that we are going to work on alternatives.

Chairs can't promise that the RG will ever converge on requirements. We can try, but there is no guaranty that anything will come out of this later effort.

There is plenty of terrible crypto in IEEE standards we don't issue drafts for because it is so terrible. To the extent our publication leads to use of dragonfly as opposed to known - good protocols, it's a problem.

>
> Considering how difficult previous Last Call on the document was, I would like to ask people to:
> 1) keep in mind that CFRG chairs believe that the RG should work on PAKE requirements and after that on other PAKE proposals. This was suggested by our previous co-chair David McGrew:
> =C2=A0 http://www.ietf.org/mail-archive/web/cfrg/current/msg03723.html

Why doesn't this apply to dragonfly, but only other proposals?


Because Dragonfly got there first. I don't think it is reasonable to delay the document which is effectively done and not known to be broken.

> 2) be professional, in particular no ad hominem attacks

> 3) be constructive. In particular if you would like a disclaimer being added to the document, please suggest specific text.
> 4) simple statements of support for publishing the document or objection to publishing it are fine and encouraged. Sending them directly to RG chairs is fine. But please avoid saying "but what about PAKEXXX?", due to 1).
> 5) unlike IETF, IRTF RGs are not required to reach rough consensus. However I would like to see us try.
>
> Best Regards,
> Alexey,
> on behalf of chairs.


--------------020704090509070605000003-- From nobody Thu Oct 9 10:51:26 2014 Return-Path: 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 D1F2A1AD473 for ; Thu, 9 Oct 2014 10:51:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 6VY-qtFPXld2 for ; Thu, 9 Oct 2014 10:51:24 -0700 (PDT) Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DC001AD469 for ; Thu, 9 Oct 2014 10:51:24 -0700 (PDT) Received: by mail-lb0-f171.google.com with SMTP id z12so1657802lbi.30 for ; Thu, 09 Oct 2014 10:51:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=zSQjJcA0Kgg1CC4i8Jw+bLEzANzXPuqUVhuJiYstwkc=; b=LdFd3NV1SvWBz+VrdsqLPqTROEJtCwkt9Izi7sAJuwZ/WeNZsTETKgBqBj8ClphSeI lsqRWMGaJfRhjjhEakA3Q1wW5lJt3ObWpYifC9uApHEFwyPQEmDYMMnUADF0LNAPO8vT 6Aw2+vEKjubwo3vpyZSdb4uYmHWK916ILqUxwBsM+AGtSzobGxkTbEN/L+3FUJGTUS0e tUEp2FXcq/fYppmUOABgHZGbJFN4ZpFAjn6eLJcKmf6WlTh9RbXcUyvJUU1D9x5JnH/s qo+VIxk4EApnDasMi0zoaogs5S1832r/fXr00BgUDvqarPVH0l2rbOUqjty88vtxUzG1 Zgig== X-Received: by 10.112.180.137 with SMTP id do9mr19334531lbc.63.1412877082580; Thu, 09 Oct 2014 10:51:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.218.145 with HTTP; Thu, 9 Oct 2014 10:51:02 -0700 (PDT) In-Reply-To: References: From: David Leon Gil Date: Thu, 9 Oct 2014 13:51:02 -0400 Message-ID: To: Zooko Wilcox-OHearn Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/Tm1JiSMRyms1zUVQNJek8Z0_xUk Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] Alternatives to McGrew's hash based signatures X-BeenThere: cfrg@irtf.org 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: Thu, 09 Oct 2014 17:51:26 -0000 On Thu, Oct 9, 2014 at 11:54 AM, Zooko Wilcox-OHearn wrote: > To me, the idea that you have to guarantee that a state update (i.e. a > previously unused sequence number or nonce) is durably written, or > else you leak your private signing key to an attacker=E2=80=A6 that's a > show-stopper. I disbelieve that any commodity hardware and software in > use today can do that safely. I don't think this is out of reach, really; the only trick is writing the new key to durable storage before you write the signature. (In fact, I'd write the = key to high-durability/availability distributed storage....wait. :) (Getting to, say, a 2^-128, or other cryptographically small, probability of failure does seem out of reach.) On Thu, Oct 9, 2014 at 4:41 AM, Alyssa Rowan wrote: > Maybe we do: these are different schemes with different sets of desirable= properties? I think these schemes can be hybridized: Take a stateful hash signature system (say tree-based); but use a small SPH= INCS instance at each leaf node. In that case, the size of the SPHINCS instances only needs to be large enough for "misuse-resistance", not collision-resist= ance. (It seems possible to, instead, embed stateful leaves into a SPHINCS instance, but perhaps less convenient unless the leaves are chains.) From nobody Thu Oct 9 10:58:05 2014 Return-Path: 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 E8EEC1AD486 for ; Thu, 9 Oct 2014 10:58:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.186 X-Spam-Level: X-Spam-Status: No, score=-2.186 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_39=0.6, RP_MATCHES_RCVD=-0.786] 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 4H_5BEZakLO0 for ; Thu, 9 Oct 2014 10:58:02 -0700 (PDT) Received: from statler.isode.com (ext-bt.isode.com [217.34.220.158]) by ietfa.amsl.com (Postfix) with ESMTP id E81811AD495 for ; Thu, 9 Oct 2014 10:58:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1412877481; d=isode.com; s=selector; i=@isode.com; bh=lYpTd2YNIo+3d56jOGYB4KKLm3mg3AtgJHrIDPgnmuo=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=KSEYarkLX+E+mOakcBF5FNxuSgdfgnykfj93VbWqcEyzebw6yXUugvtejiBl3bWHbfAAm/ Q2nXj/c6Gi98kHQApT7GJwBzmqHUgr4k8D+uKW9KwXsVnoXDT3lkoyY5DkLdD3hZMmQjY+ YmIvvGKwzhOIUyDFr8buoXhMZ4mbNqI=; Received: from [172.20.1.47] (dhcp-47.isode.net [172.20.1.47]) by statler.isode.com (submission channel) via TCP with ESMTPA id ; Thu, 9 Oct 2014 18:58:00 +0100 Message-ID: <5436CCAD.7020506@isode.com> Date: Thu, 09 Oct 2014 18:58:05 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 To: Watson Ladd , Dan Harkins References: <54357A2A.2010800@isode.com> <73d51db893a4b847db6d8eaae7f45cf5.squirrel@www.trepanning.net> <237f9c809efcbb3e3ffb9df7fe666981.squirrel@www.trepanning.net> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/Ly4oWocfYBWFX4yX_Xh8cVF8A-k Cc: "cfrg@irtf.org" Subject: [Cfrg] JPAKE and a few other things (was Re: draft-irtf-cfrg-dragonfly document status) X-BeenThere: cfrg@irtf.org 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: Thu, 09 Oct 2014 17:58:04 -0000 Hi, On 09/10/2014 15:55, Watson Ladd wrote: > On Wed, Oct 8, 2014 at 11:11 PM, Dan Harkins wrote: >> Watson, >> >> On Wed, October 8, 2014 6:22 pm, Watson Ladd wrote: >>> On Wed, Oct 8, 2014 at 4:40 PM, Dan Harkins wrote: [snip] >>>>>> Versions of the protocol have been adopted and fied. This protocol wa= s >>>>> first introduced into IEEE 802.11s in 2008. The base protocol exchang= e >>>>> has >>>>> also been adopted in the Wi-Fi Alliance. The protocol has been >>>>> improved >>>>> by the review in the cfrg and if published, the specification would >>>>> positively impact the application of the protocol in other forums. >>>>>>> My comment (there is no security proof, and alternatives with better >>>>> provable security) has been acknowledged to be unresolveable. >>>>>> Yes, this may be considered a negative point by some but not all. >>>>>> While >>>>> not a proof, the protocol has been analyzed: >>>>>> Cryptanalysis of the Dragonfly Key Exchange Protocol >>>>>> It was interested that the only issue mentioned was a small subgroup >>>>> attack if the public key is not validated =E2=80=A6. which it always s= hould. >>>>> >>>>> This analysis ignores Rene Struik's timing attack, my reflection >>>>> attack, >>>>> and other comments incorporated into the draft. >>>> And I thanked Rene, you, and others for your comments and, as you >>>> note, >>>> incorporated resolutions into the draft. Once again, thank you for >>>> helping >>>> improve the draft. All of the comments have been resolved in -04. >>>> >>>> (I will note that the reflection attack you mentioned is not possibl= e >>>> in the IEEE 802.11 version of dragonfly, which predated your comment >>>> and this draft by a few years, and neither was small subgroup attack >>>> described by Clarke and Hao mentioned above. The -00 version of this >>>> draft was rushed, take a look at the Acknowledgements in section 4 to >>>> see just how bad, and I left some things out that I shouldn't have. All >>>> this has all been addressed in -04). >>> Why did the draft not track the IEEE 802.11 version? Also, as I >>> remember from discussing this issue in the TLS WG, the CFRG draft >>> version and the TLS draft version differed substantially, enough to >>> make the reflection attack not work. (There were interactions with the >>> rest of TLS that prevented it) While only tangentially relevant to the >>> issue, this is the kind of issue which leads to all sorts of bugs in >>> protocols that should be secure. >> The draft was intended to be a generic instantiation of a key >> exchange that had been defined in 3 different protocols, each of >> which has its own idiosyncrasies. I dealt with the reflection issue in >> the IEEE 802.11 instantiation because it was for mesh networks and >> there is no notion of a "server" or a "client" or an "initiator" or a >> "responder" in a mesh, everyone is an equal peer who can actually >> each view themselves as the "initiator" if the timing is right. The >> reflection attack was something that needed addressing in the >> protocol as opposed to, say, the TLS variant which is not susceptible >> to that attack due to the nature of TLS. Again, in my haste to generalize >> the key exchange I removed stuff that should not have been removed. >> But, as I mentioned, it is in the latest draft that is subject of the RGL= C, >> thanks to the useful and constructive comments of RG members, >> including you. > Yes, it is now fixed. What else is wrong? This is not a reasonable question to ask. If we start asking questions=20 like this we will never finish anything. >>> It also is not clear how relevant the proposed draft will be >>> >>>>>>> The draft authors knew this from the very beginning. >>>>>>> >>>>>>> I don't think we should approve a protocol that doesn't have a >>>>>>> security >>>>> proof, particularly given that we are going to work on alternatives. >>>>>> =E2=80=9C=E2=80=A6 Going to work on =E2=80=A6=E2=80=9D is the issue. = The draft under >>>>>> discussion >>>>>> has been >>>>> on IETF servers for 2 years. It has been used in other industry forum= s >>>>> for >>>>> four or five years. >>>>> >>>>> Plenty of alternatives have been put forward in those two years, >>>>> including >>>>> EKE+Elligator, SPAKE2, JPAKE, and SMP based solutions. The failure >>>>> to >>>>> advance these is inexplicable. >>>> Oh no, it's very easily explained. It's because no one has stepped >>>> forward >>>> to actually write the I-Ds. You have stated on numerous occasions that >>>> these >>>> should be written up but you have never actually taken on the task of >>>> actually doing it. Please, write up a draft or four. Whether or not yo= u >>>> do, >>>> though, this really has nothing to do with the RGLC underway right now. >>> JPAKE was described in a series of drafts that weren't made WG work >>> items. I see no reason that the eventual disposition of SPAKE2, SMP, >>> or EKE+Elligator drafts would be any different, and thus see no reason >>> to write the drafts. >> The disposition is due to the diligence and hard work of the editor of >> the I-D. If you want drafts to be produced in a RG (or WG) the best way >> to do that is to socialize the idea, write the draft, and advocate for it= . >> If you sit back and send periodic emails criticizing everyone else for no= t >> doing what you, in your wisdom from the comfort of your couch, see as >> necessary nothing will get done. > And Feng Hao wasn't working hard enough promoting JPAKE? Again, there > was significant development of various alternatives on the CFRG > mailing list, and if what you need is an RFC draft to consider an > alternative, that's easy to write. > > I feel the issue is that you don't believe the CFRG actually analyzes > alternatives, merely edits drafts describing protocols, whereas I > think the CFRG analyses alternatives, and the actual draft writing is > trivial in comparison. > > I'll happily write the drafts this weekend. But I doubt that any > degree of hard work will lead to adoption or publication. I would advise to ask CFRG chairs first about whether they would=20 consider acceptance of JPAKE as a RG document. So far the question=20 hasn't been asked. Best Regards, Alexey From nobody Thu Oct 9 11:05:12 2014 Return-Path: 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 698341AD4F2 for ; Thu, 9 Oct 2014 11:05:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.186 X-Spam-Level: X-Spam-Status: No, score=-2.186 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_39=0.6, RP_MATCHES_RCVD=-0.786] 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 rliIauFDypHZ for ; Thu, 9 Oct 2014 11:05:02 -0700 (PDT) Received: from statler.isode.com (ext-bt.isode.com [217.34.220.158]) by ietfa.amsl.com (Postfix) with ESMTP id 958B91A02D6 for ; Thu, 9 Oct 2014 11:05:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1412877900; d=isode.com; s=selector; i=@isode.com; bh=n34HItW4RYjPu5GjHHkWHU9g9Lxis3/Td25vkOkfEGk=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=syBTu5boQGukR8AnreJ2RQ6HIqRVeW/2pHT8ZPGAzXXTuZgkTOX5TlftYyqz857jqzKaL0 bh6h7IuneAbl3YR3N8Onkt4gqbkoABXUkEAjKHh0HWhPUlic8MmKg/3Rtvi7psgTsH16hO GTqX787r9stT78LFFvSr5Lsi+SEwkBo=; Received: from [172.20.1.47] (dhcp-47.isode.net [172.20.1.47]) by statler.isode.com (submission channel) via TCP with ESMTPA id ; Thu, 9 Oct 2014 19:05:00 +0100 Message-ID: <5436CE55.9010206@isode.com> Date: Thu, 09 Oct 2014 19:05:09 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 To: Watson Ladd References: <54357A2A.2010800@isode.com> <73d51db893a4b847db6d8eaae7f45cf5.squirrel@www.trepanning.net> <237f9c809efcbb3e3ffb9df7fe666981.squirrel@www.trepanning.net> In-Reply-To: <237f9c809efcbb3e3ffb9df7fe666981.squirrel@www.trepanning.net> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-transfer-encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/uf7h-_qQnTqSNZ4IsPxU2WWVxxU Cc: "cfrg@irtf.org" Subject: [Cfrg] Writing proposals as drafts first (was Re: draft-irtf-cfrg-dragonfly document status) X-BeenThere: cfrg@irtf.org 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: Thu, 09 Oct 2014 18:05:09 -0000 On 09/10/2014 07:11, Dan Harkins wrote: > Watson, > > On Wed, October 8, 2014 6:22 pm, Watson Ladd wrote: >> On Wed, Oct 8, 2014 at 4:40 PM, Dan Harkins wrote: >>> Watson, >>> >>> On Wed, October 8, 2014 3:46 pm, Watson Ladd wrote: >>>> On Oct 8, 2014 3:26 PM, "Paul Lambert" wrote: >>>> [snip] >> It also is not clear how relevant the proposed draft will be >> >>>>>> The draft authors knew this from the very beginning. >>>>>> >>>>>> I don't think we should approve a protocol that doesn't have a >>>>>> security >>>> proof, particularly given that we are going to work on alternatives. >>>>> =E2=80=9C=E2=80=A6 Going to work on =E2=80=A6=E2=80=9D is the issue. = The draft under >>>>> discussion >>>>> has been >>>> on IETF servers for 2 years. It has been used in other industry forums >>>> for >>>> four or five years. >>>> >>>> Plenty of alternatives have been put forward in those two years, >>>> including >>>> EKE+Elligator, SPAKE2, JPAKE, and SMP based solutions. The failure >>>> to >>>> advance these is inexplicable. >>> Oh no, it's very easily explained. It's because no one has stepped >>> forward >>> to actually write the I-Ds. You have stated on numerous occasions that >>> these >>> should be written up but you have never actually taken on the task of >>> actually doing it. Please, write up a draft or four. Whether or not you >>> do, >>> though, this really has nothing to do with the RGLC underway right now. >> JPAKE was described in a series of drafts that weren't made WG work >> items. I see no reason that the eventual disposition of SPAKE2, SMP, >> or EKE+Elligator drafts would be any different, and thus see no reason >> to write the drafts. > The disposition is due to the diligence and hard work of the editor of > the I-D. If you want drafts to be produced in a RG (or WG) the best way > to do that is to socialize the idea, write the draft, and advocate for it. At least this co-chair agrees with this. Write a proposal and email=20 chairs or ask chairs to adopt an existing draft. Best Regards, Alexey From nobody Thu Oct 9 11:09:53 2014 Return-Path: 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 0988B1AD461 for ; Thu, 9 Oct 2014 11:09:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.486 X-Spam-Level: X-Spam-Status: No, score=-2.486 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.786] 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 2Hi7bAUkdfkK for ; Thu, 9 Oct 2014 11:09:29 -0700 (PDT) Received: from statler.isode.com (ext-bt.isode.com [217.34.220.158]) by ietfa.amsl.com (Postfix) with ESMTP id 2836C1ACD33 for ; Thu, 9 Oct 2014 11:09:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1412878168; d=isode.com; s=selector; i=@isode.com; bh=VlMI6r8tZHwB/MsRZ3criiOx0lrpBSr+8++SFYHyQQU=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=k9TzqRpryVd0x8xzXtyOsKIxz56Jyj5Jx+aVLRxVMDAR8H21ycTfXKlKosjZL0d/JQ42qB b3mp17byk2bykUj6kOg7W5NROuK5t69BIZ/svxbfW8j9pKnz5an0aQQ1S4vgFLAsBktI+h AE/SWid8MU8YZUzY+uxXLUOjhHarqv0=; Received: from [172.20.1.47] (dhcp-47.isode.net [172.20.1.47]) by statler.isode.com (submission channel) via TCP with ESMTPA id ; Thu, 9 Oct 2014 19:09:27 +0100 Message-ID: <5436CF60.5000602@isode.com> Date: Thu, 09 Oct 2014 19:09:36 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 To: =?ISO-8859-1?Q?=22Schmidt=2C_J=F6rn-Marc=22?= , "cfrg@irtf.org" References: <54357A2A.2010800@isode.com> <38634A9C401D714A92BB13BBA9CCD34F13E26818@mail-essen-01.secunet.de> In-Reply-To: <38634A9C401D714A92BB13BBA9CCD34F13E26818@mail-essen-01.secunet.de> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/aSkHOMYumrZhYcMu9T8Hvq3-nmc Subject: [Cfrg] PAKE requirements X-BeenThere: cfrg@irtf.org 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: Thu, 09 Oct 2014 18:09:37 -0000 On 09/10/2014 09:31, Schmidt, J=F6rn-Marc wrote: > Hi, > >> 1) keep in mind that CFRG chairs believe that the RG should work on PAKE = requirements and after that on other PAKE proposals. This was suggested by o= ur previous co-chair David McGrew >> http://www.ietf.org/mail-archive/web/cfrg/current/msg03723.html > So why don't we start right now with a discussion on the requirements (ind= ependent from the current dragonfly draft)? I think discussing PAKE requirements in parallel is fine, although this=20 CFRG co-chair was trying to channel limited RG energy to deal with one=20 or two issue at a time :-). > Some aspects I can think of right now: > > - Royalty-free use/Free of Patents > - Security (What kind of model are we considering)? > - Support various types of elliptic curves > - Good performance, i.e. easy to implement, number of exchanged messages = (and sizes), computational costs > > Further, I think we should keep the requirements for a mapping if the sche= me is used with elliptic curves in mind: > - No mapping required > - Mapping on the curve (e.g. SWU, integrated Mapping) > - Uniform representation (e.g. Elligator, Elligator squared) > > Finally, it might help to collect also use cases for PAKE protocols (A loo= k at the "curves" list might also be useful, e.g. https://moderncrypto.org/m= ail-archive/curves/2014/000077.html). > > What else do we need to consider? How should we prioritize the requirement= s? From nobody Thu Oct 9 12:45:59 2014 Return-Path: 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 E4F1A1A0352 for ; Thu, 9 Oct 2014 12:45:58 -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 G0d3kTvbzEiR for ; Thu, 9 Oct 2014 12:45:56 -0700 (PDT) Received: from mail-yk0-x231.google.com (mail-yk0-x231.google.com [IPv6:2607:f8b0:4002:c07::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF4801A030F for ; Thu, 9 Oct 2014 12:45:55 -0700 (PDT) Received: by mail-yk0-f177.google.com with SMTP id q200so1004244ykb.22 for ; Thu, 09 Oct 2014 12:45:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=fKmSBkPIS4kjaO2P+1gKCCWGT4mSnz7/ZatUfFbve/Q=; b=adU62aNqCcokJC0dxkOK9rSnUNdNdqi/1sK7gMFWR/iur+PEKlZIhtmxA/CcNkK3Nw UGcP91E+lK/4d90SeC4M4awrr0ZE2jzaBxHGMUlnyYiaAGOCy9bPT48yJekjvTC+Asnw zYlOpEervEeBfNFxk3DcTTEEx6K7AAsQHYhBGtsh2ta4AZJV5opbF7HibKjKE8ijbCKw ZzNUufuo04sQ8kG31bsbaQ4qfz8lBL4WN7qRH+eUynHxFkoRmDheTomAgHA+z9+ekXxa 6SKDFR0ONeZ5vyZMJl7xH6FhARABPuY7VQNdIm4tNiEneIi7+GQIBH4XuhLIsOOKdqeR t+gQ== MIME-Version: 1.0 X-Received: by 10.236.228.161 with SMTP id f31mr566318yhq.44.1412883955170; Thu, 09 Oct 2014 12:45:55 -0700 (PDT) Received: by 10.170.195.149 with HTTP; Thu, 9 Oct 2014 12:45:55 -0700 (PDT) Received: by 10.170.195.149 with HTTP; Thu, 9 Oct 2014 12:45:55 -0700 (PDT) In-Reply-To: <5436C882.7050700@isode.com> References: <54357A2A.2010800@isode.com> <5436C882.7050700@isode.com> Date: Thu, 9 Oct 2014 12:45:55 -0700 Message-ID: From: Watson Ladd To: Alexey Melnikov Content-Type: multipart/alternative; boundary=001a1133352641c2a1050502aebc Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/O0DA5-xUaZn3KGCyojJN7jmw7SQ Cc: cfrg@irtf.org Subject: Re: [Cfrg] draft-irtf-cfrg-dragonfly document status X-BeenThere: cfrg@irtf.org 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: Thu, 09 Oct 2014 19:45:59 -0000 --001a1133352641c2a1050502aebc Content-Type: text/plain; charset=UTF-8 On Oct 9, 2014 10:40 AM, "Alexey Melnikov" wrote: > > Hi, > > > On 08/10/2014 19:09, Watson Ladd wrote: >> >> On Oct 8, 2014 10:53 AM, "Alexey Melnikov" wrote: >> > >> > Hi, >> > My apologies for taking so long on this. But I felt I needed to review mailing list discussions to make up my own mind on this topic. >> > >> > After reviewing mailing list discussions about this draft, I would like to do another RGLC on it. I've seen negative comments on the mailing list, but I've also seen some interest in this work and I am also aware that some variants of the algorithm are already implemented/deployed. Also, there were a couple of new revisions of the draft and it is not clear whether people who reported original problems are happy with how they got resolved. So I would like to see a bit more positive feedback on the latest version, in particular I would like to know if specific issues raised by earlier reviews are addressed in the latest version. >> >> My comment (there is no security proof, and alternatives with better provable security) has been acknowledged to be unresolveable. The draft authors knew this from the very beginning. > > Ok, your opinion was heard. > >> I don't think we should approve a protocol that doesn't have a security proof, particularly given that we are going to work on alternatives. > > Chairs can't promise that the RG will ever converge on requirements. We can try, but there is no guaranty that anything will come out of this later effort. > >> There is plenty of terrible crypto in IEEE standards we don't issue drafts for because it is so terrible. To the extent our publication leads to use of dragonfly as opposed to known - good protocols, it's a problem. >> >> > >> > Considering how difficult previous Last Call on the document was, I would like to ask people to: >> > 1) keep in mind that CFRG chairs believe that the RG should work on PAKE requirements and after that on other PAKE proposals. This was suggested by our previous co-chair David McGrew: >> > http://www.ietf.org/mail-archive/web/cfrg/current/msg03723.html >> >> Why doesn't this apply to dragonfly, but only other proposals? > > > Because Dragonfly got there first. I don't think it is reasonable to delay the document which is effectively done and not known to be broken. And this doesn't apply to Curve 25519 because? Regardless of the eventual decision on either one, it's surprising we consider alternatives for one but not the other. It's clear dragonfly will be published from what you are saying. But what I can't figure out is why. > > >> > 2) be professional, in particular no ad hominem attacks >> >> > 3) be constructive. In particular if you would like a disclaimer being added to the document, please suggest specific text. >> > 4) simple statements of support for publishing the document or objection to publishing it are fine and encouraged. Sending them directly to RG chairs is fine. But please avoid saying "but what about PAKEXXX?", due to 1). >> > 5) unlike IETF, IRTF RGs are not required to reach rough consensus. However I would like to see us try. >> > >> > Best Regards, >> > Alexey, >> > on behalf of chairs. > > --001a1133352641c2a1050502aebc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Oct 9, 2014 10:40 AM, "Alexey Melnikov" <alexey.melnikov@isode.com> wrote:
>
> Hi,
>
>
> On 08/10/2014 19:09, Watson Ladd wrote:
>>
>> On Oct 8, 2014 10:53 AM, "Alexey Melnikov" <alexey.melnikov@isode.com> wro= te:
>> >
>> > Hi,
>> > My apologies for taking so long on this. But I felt I needed = to review mailing list discussions to make up my own mind on this topic. >> >
>> > After reviewing mailing list discussions about this draft, I = would like to do another RGLC on it. I've seen negative comments on the= mailing list, but I've also seen some interest in this work and I am a= lso aware that some variants of the algorithm are already implemented/deplo= yed. Also, there were a couple of new revisions of the draft and it is not = clear whether people who reported original problems are happy with how they= got resolved. So I would like to see a bit more positive feedback on the l= atest version, in particular I would like to know if specific issues raised= by earlier reviews are addressed in the latest version.
>>
>> My comment (there is no security proof, and alternatives with bett= er provable security) has been acknowledged to be unresolveable. The draft = authors knew this from the very beginning.
>
> Ok, your opinion was heard.
>
>> I don't think we should approve a protocol that doesn't ha= ve a security proof, particularly given that we are going to work on altern= atives.
>
> Chairs can't promise that the RG will ever converge on requirement= s. We can try, but there is no guaranty that anything will come out of this= later effort.
>
>> There is plenty of terrible crypto in IEEE standards we don't = issue drafts for because it is so terrible. To the extent our publication l= eads to use of dragonfly as opposed to known - good protocols, it's a p= roblem.
>>
>> >
>> > Considering how difficult previous Last Call on the document = was, I would like to ask people to:
>> > 1) keep in mind that CFRG chairs believe that the RG should w= ork on PAKE requirements and after that on other PAKE proposals. This was s= uggested by our previous co-chair David McGrew:
>> > =C2=A0http://www.ietf.org/mail-archive/web/cfrg/current/msg0= 3723.html
>>
>> Why doesn't this apply to dragonfly, but only other proposals?=
>
>
> Because Dragonfly got there first. I don't think it is reasonable = to delay the document which is effectively done and not known to be broken.=

And this doesn't apply to Curve 25519 because? Regardles= s of the eventual decision on either one, it's surprising we consider a= lternatives for one but not the other.

It's clear dragonfly will be published from what you are= saying. But what I can't figure out is why.

>
>
>> > 2) be professional, in particular no ad hominem attacks
>>
>> > 3) be constructive. In particular if you would like a disclai= mer being added to the document, please suggest specific text.
>> > 4) simple statements of support for publishing the document o= r objection to publishing it are fine and encouraged. Sending them directly= to RG chairs is fine. But please avoid saying "but what about PAKEXXX= ?", due to 1).
>> > 5) unlike IETF, IRTF RGs are not required to reach rough cons= ensus. However I would like to see us try.
>> >
>> > Best Regards,
>> > Alexey,
>> > on behalf of chairs.
>
>

--001a1133352641c2a1050502aebc-- From nobody Thu Oct 9 13:53:19 2014 Return-Path: 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 A9C441A87E7 for ; Thu, 9 Oct 2014 13:53:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 mQHaGV4ccACd for ; Thu, 9 Oct 2014 13:53:17 -0700 (PDT) Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACD3E1A87D6 for ; Thu, 9 Oct 2014 13:53:16 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id hs14so2025733lab.17 for ; Thu, 09 Oct 2014 13:53:14 -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 :content-transfer-encoding:message-id:references:to; bh=gQAJjWc7G6VPk01esFkP+ZKWY8yyVoX4fZ3AnguAxKY=; b=TzPJH9uTbgJ1pFvQSVVbNVT+xwYxUWQTk75TR59xmGxoSKikXj/tPxEEL2NT/p/+HU vxwCm6DgFX01dkagogq6567kpa46+2knWm7seJl7k/X46wBQCxMiF9u149dNo/QsWnYd RP3TEpabBImRl8S6DRoIg8Ckxaxj0puWVBhK+G29s60ypJ7RPH7W+oQZiQv0tILBu8wC KMa5q0tWpOZCRQ5oc1Sjt8nVZNX3KGdVoqBg3kRBoo57coLjGJ5xwWXIxje5DUqeDDdK IGJkndY0f8yHrIru5ZTpRauj35COGiAQtILE3UWCSmbPgJG+YmVCMinuA3m/gkp60y0o 5gWA== X-Received: by 10.112.142.33 with SMTP id rt1mr20028441lbb.69.1412887994519; Thu, 09 Oct 2014 13:53:14 -0700 (PDT) Received: from [192.168.1.101] (IGLD-84-228-54-144.inter.net.il. [84.228.54.144]) by mx.google.com with ESMTPSA id w10sm1253301laz.28.2014.10.09.13.53.12 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 09 Oct 2014 13:53:14 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Yoav Nir In-Reply-To: Date: Thu, 9 Oct 2014 23:53:11 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <12DDE3BC-524C-4F83-908C-CDDA3D7D88A3@gmail.com> References: <54357A2A.2010800@isode.com> <38634A9C401D714A92BB13BBA9CCD34F13E26818@mail-essen-01.secunet.de> <54366BA1.1010603@cs.tcd.ie> To: Paul Lambert X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/5b4pbDC8WeKHFwU4gd_rmF8hDDY Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] PAKEs in general (was; Re: draft-irtf-cfrg-dragonfly document status) X-BeenThere: cfrg@irtf.org 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: Thu, 09 Oct 2014 20:53:18 -0000 On Oct 9, 2014, at 7:55 PM, Paul Lambert wrote: >>=20 >> I'll just note that there were also voices (incl. mine) saying: >> "I really don't care about work on PAKEs. Seems like a waste of >> time to me. But go ahead and spend time on that if you wish." >=20 > +1 mostly. >=20 > Shared passwords are architecturally problematic. They are > more useable ways to authenticate. I wish I had a dollar for every time someone said that in the last 20 = years=85 > The =8Cmostly' is that the Dragonfly draft should be published > so it can be used a little better in a couple of specific > environments where it is already being wired into systems. > Specifically, IEEE 802.11 has the SAE protocol which uses > the Dragonfly exchange for mesh networks. That=92s the part I don=92t understand. Since the first revision of this = document, the group made some suggestions for improvement that have been = incorporated into the draft.=20 We also have Dan=92t message ([1]) describing differences between the = 802.11 version and this draft, including attacks that work on earlier = versions of this draft that don=92t work on the 802.11 version. Given all that, I don=92t think this is a document that describes = existing practice, in the same vein as an SSLv3 document or a PKCS#12 = document. This is a document describing an entirely new PAKE, so it = should be judged as such. Yoav [1] http://www.ietf.org/mail-archive/web/cfrg/current/msg05210.html= From nobody Thu Oct 9 15:42:54 2014 Return-Path: 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 E31FA1A899B for ; Thu, 9 Oct 2014 15:42:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.867 X-Spam-Level: X-Spam-Status: No, score=-3.867 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_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 2ZcAsKU8aiDT for ; Thu, 9 Oct 2014 15:42:51 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id C34DB1A8989 for ; Thu, 9 Oct 2014 15:42:50 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 5B71E10224008; Thu, 9 Oct 2014 15:42:50 -0700 (PDT) Received: from 104.36.248.10 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Thu, 9 Oct 2014 15:42:50 -0700 (PDT) Message-ID: <1c121d02a9ec2fc389fa2ca7557d981f.squirrel@www.trepanning.net> In-Reply-To: <12DDE3BC-524C-4F83-908C-CDDA3D7D88A3@gmail.com> References: <54357A2A.2010800@isode.com> <38634A9C401D714A92BB13BBA9CCD34F13E26818@mail-essen-01.secunet.de> <54366BA1.1010603@cs.tcd.ie> <12DDE3BC-524C-4F83-908C-CDDA3D7D88A3@gmail.com> Date: Thu, 9 Oct 2014 15:42:50 -0700 (PDT) From: "Dan Harkins" To: "Yoav Nir" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/U1LpG4jcUm-_KMiS2-b2HhllRKY Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] PAKEs in general (was; Re: draft-irtf-cfrg-dragonfly document status) X-BeenThere: cfrg@irtf.org 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: Thu, 09 Oct 2014 22:42:53 -0000 On Thu, October 9, 2014 1:53 pm, Yoav Nir wrote: > > On Oct 9, 2014, at 7:55 PM, Paul Lambert wrote: > >>> >>> I'll just note that there were also voices (incl. mine) saying: >>> "I really don't care about work on PAKEs. Seems like a waste of >>> time to me. But go ahead and spend time on that if you wish." >> >> +1 mostly. >> >> Shared passwords are architecturally problematic. They are >> more useable ways to authenticate. > > I wish I had a dollar for every time someone said that in the last 20 > years Me too. If I got a dollar every time authentication on the Internet involved a password and I had to pay a dollar every time authentication on the Internet did not, I would be a billionaire many times over. >> The mostly' is that the Dragonfly draft should be published >> so it can be used a little better in a couple of specific >> environments where it is already being wired into systems. >> Specifically, IEEE 802.11 has the SAE protocol which uses >> the Dragonfly exchange for mesh networks. > > Thats the part I dont understand. Since the first revision of this > document, the group made some suggestions for improvement that have been > incorporated into the draft. > > We also have Dant message ([1]) describing differences between the 802.11 > version and this draft, including attacks that work on earlier versions of > this draft that dont work on the 802.11 version. I think you misunderstood my email. This draft was supposed to be a generic specification for the key exchange underlying an authentication method in several other protocols. So the point of my mail was to explain that the attacks mentioned on this list-- the small subgroup attack and the reflection attack-- are not new, they were known and addressed in the other specifications, but in my haste to get the I-D out (if you look at the Acknowledgements section you'll see that it's actually the xml2rfc boilerplate, it was that sloppy) I did not address them in the generic protocol description. After these omissions were pointed out the appropriate checks were added to subsequent versions of this draft. > Given all that, I dont think this is a document that describes existing > practice, in the same vein as an SSLv3 document or a PKCS#12 document. > This is a document describing an entirely new PAKE, so it should be judged > as such. Actually, it now closer to existing practice. It is a generic description of which there are other specific instantiations of it. There were no comment resolutions that changed the underlying protocol and to say it is an "entirely new PAKE" is just wrong. regards, Dan. > Yoav > [1] http://www.ietf.org/mail-archive/web/cfrg/current/msg05210.html > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg > From nobody Thu Oct 9 18:53:33 2014 Return-Path: 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 0AA2D1A890C for ; Thu, 9 Oct 2014 18:53:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 rKD7egInihOz for ; Thu, 9 Oct 2014 18:53:31 -0700 (PDT) Received: from mail-yh0-x231.google.com (mail-yh0-x231.google.com [IPv6:2607:f8b0:4002:c01::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F26651A8834 for ; Thu, 9 Oct 2014 18:53:30 -0700 (PDT) Received: by mail-yh0-f49.google.com with SMTP id a41so1295637yho.8 for ; Thu, 09 Oct 2014 18:53:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=TphnUcAqLlZacRhVQBEQUhlI7JkEvcUAJdTCfFCD+Y0=; b=vE9Igpq8j2NQOWwLnnoyxSjVzwxW/AJDelPojR8O86CA5KwWOHQKWXuRFBeGCaA0GS 7gUyqycbvcoVCi9PhjShQmz8CR96ZwyfS11znBH5VrzXESAFlXg0AhTrrk4mZZJYLpsz 69nRwxfy20gu3TmnOxmS4+2QD4UdgBTWcNjd4e/l62k59DjucNvcYH5Y27ObOqWwE4gy sWE7FW+UU0nQDLHnsgebNzUmRHezFZnF3p57vckIgGEl4NqNGQFcjkHcLeVqizO4ykIX X1gkpgjwstiPjzvziV7oX0KFUIfXBxn0ma456fVu54geKmF+NDA7ORo536S86+hKoLGi VRHQ== MIME-Version: 1.0 X-Received: by 10.236.94.130 with SMTP id n2mr1033419yhf.163.1412906010294; Thu, 09 Oct 2014 18:53:30 -0700 (PDT) Received: by 10.170.195.149 with HTTP; Thu, 9 Oct 2014 18:53:30 -0700 (PDT) Date: Thu, 9 Oct 2014 18:53:30 -0700 Message-ID: From: Watson Ladd To: "cfrg@irtf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/2yAS2s3PM0nV3zvZnUmtfjOURBY Subject: [Cfrg] Adoption of draft-ladd-spake2 as work item X-BeenThere: cfrg@irtf.org 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, 10 Oct 2014 01:53:32 -0000 Dear all, I'd like to formally request adoption of draft-ladd-spake2 as a work item. Currently M and N need to be chosen: I understand that Google has implemented SPAKE2 in Chromium already with a particular choice of M&N for P224. It also probably needs to be less terse. Sincerely, Watson Ladd From nobody Thu Oct 9 19:09:14 2014 Return-Path: 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 C88791A0005 for ; Thu, 9 Oct 2014 19:09:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no 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 wh7b5US9OTtd for ; Thu, 9 Oct 2014 19:09:10 -0700 (PDT) Received: from mail-lb0-x232.google.com (mail-lb0-x232.google.com [IPv6:2a00:1450:4010:c04::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DBE01A0004 for ; Thu, 9 Oct 2014 19:09:09 -0700 (PDT) Received: by mail-lb0-f178.google.com with SMTP id w7so2232569lbi.23 for ; Thu, 09 Oct 2014 19:09:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=V4qg2/PRSE3dyCLZftHQEwUNTSc4BkXOQYvZ2zhdEA4=; b=E0SmBBmp1uOgq8nwY1AbIEvGMrXpMyBzgvGYyM0d1Np1ZwvMa77CA1mta9juLJ6XFf v4LXqc6ncxbDKlpGpLkZ/AE0cin1480OZ8/WEyPf13wIZDyazYn7/NJJYbF2/UNH1xNA T/LjMDAiFwnl8BuULcKJ7r4u21snyqqbH1itQmFXn7i9GXLpacGH1pWnS+u2xrTX0F5c HeYdLpsloboyc2jI4C0O4gw6EcMRO/OFniJAfdhsLUlLFEoN5W6/p6+s54VRPwnQzM6G IKeyS5g9P+TYZdudIMNnyfG5A9Fb37RJ7Bnlk+uk6YRvApZsKJjJyDPwhp4rH3V5vZtn 0psg== MIME-Version: 1.0 X-Received: by 10.153.6.36 with SMTP id cr4mr1403416lad.40.1412906948199; Thu, 09 Oct 2014 19:09:08 -0700 (PDT) Sender: alangley@gmail.com Received: by 10.112.241.103 with HTTP; Thu, 9 Oct 2014 19:09:08 -0700 (PDT) In-Reply-To: References: Date: Thu, 9 Oct 2014 19:09:08 -0700 X-Google-Sender-Auth: ACXNw9pfNsMXQYPHObIHpl290N0 Message-ID: From: Adam Langley To: Watson Ladd Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/7Z0lSU6lO9ykxQpE_Rp6oTitJqM Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] Adoption of draft-ladd-spake2 as work item X-BeenThere: cfrg@irtf.org 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, 10 Oct 2014 02:09:12 -0000 On Thu, Oct 9, 2014 at 6:53 PM, Watson Ladd wrote: > I'd like to formally request adoption of draft-ladd-spake2 as a work > item. Currently M and N need to be chosen: I understand that Google > has implemented SPAKE2 in Chromium already with a particular choice of > M&N for P224. It also probably needs to be less terse. Indeed, and the selection method seems pretty general and obvious: https://git.chromium.org/gitweb/?p=chromium/src.git;a=blob;f=crypto/p224_spake.cc;h=31109a43503fe821d525bb055c9aab570292c6ff;hb=HEAD#l17 Cheers AGL -- Adam Langley agl@imperialviolet.org https://www.imperialviolet.org From nobody Thu Oct 9 19:23:48 2014 Return-Path: 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 5C25D1A006F for ; Thu, 9 Oct 2014 19:23:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.647 X-Spam-Level: X-Spam-Status: No, score=-3.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-2.3] 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 z5yGQN1R1aYV for ; Thu, 9 Oct 2014 19:23:43 -0700 (PDT) Received: from proper.com (Hoffman.Proper.COM [207.182.41.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EED21A006D for ; Thu, 9 Oct 2014 19:23:43 -0700 (PDT) Received: from [10.20.30.90] (142-254-17-87.dsl.dynamic.fusionbroadband.com [142.254.17.87]) (authenticated bits=0) by proper.com (8.14.9/8.14.7) with ESMTP id s9A2NeiJ063863 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 9 Oct 2014 19:23:42 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: proper.com: Host 142-254-17-87.dsl.dynamic.fusionbroadband.com [142.254.17.87] claimed to be [10.20.30.90] From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Thu, 9 Oct 2014 19:23:39 -0700 To: cfrg@irtf.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/bu-Km8RLDZuhyQEzH7QJIIzkz5k Subject: [Cfrg] Preference for focus on EC rather than PAKE X-BeenThere: cfrg@irtf.org 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, 10 Oct 2014 02:23:44 -0000 Greetings. This RG has historically done a poor job of working on = multiple disparate items at the same time. For some of us, the need for = the RG to come up with concise, understandable response to the request = from the TLS WG (which will also affect many other WGs) is about an = order of magnitude higher than the need to evaluate PAKEs. The latter = can wait until the higher-importance item is finished. --Paul Hoffman= From nobody Thu Oct 9 19:54:24 2014 Return-Path: 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 5E3EA1A0089 for ; Thu, 9 Oct 2014 19:54:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 sXrMATLPz-Y4 for ; Thu, 9 Oct 2014 19:54:21 -0700 (PDT) Received: from mail-la0-f50.google.com (mail-la0-f50.google.com [209.85.215.50]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB5961A0081 for ; Thu, 9 Oct 2014 19:54:20 -0700 (PDT) Received: by mail-la0-f50.google.com with SMTP id s18so2383701lam.37 for ; Thu, 09 Oct 2014 19:54:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=zD2bVgB2rmLRreOS4oTpqGIcO2Wzs6aOYnA23heGPzg=; b=JHi5JlPZFeWYZq4Kq16SsgGHygEiMeqUASQaFkyET1SF1OsMWmVqAlqvKlIEcPYmAl NliFUcEnd82KIwKCjAQ5KblF1XMYyA/20E8kczIRnccY3U25JZWTXmmhDRkuCiquzSXt rSCBg/bwWIV24CE6ACs45WzhGMXWMWYlDvMnSqX71ksuT1lwaqcWXztX6kGpVJxtLs+A wNvijm6eZz8VZQYKYCqTi1hxdbIOKZFxCEzGoCN/CgUSbBNxbn43MiTb8LbEIjuDvCNk XGKVOb12kIGoMo1exTne7V7UG0oMihK5ldAGI7ccnabTUoAdaO6jO0XFPsvGhPKrCmoR Eegw== X-Gm-Message-State: ALoCoQm3CAi55JWKO/EBPdb+mWm1fC7BNK+LVY0yfWiAoHQD1H4bWeC526KFFHaWLE2cCPFkBX1s MIME-Version: 1.0 X-Received: by 10.152.43.50 with SMTP id t18mr175115lal.91.1412909658865; Thu, 09 Oct 2014 19:54:18 -0700 (PDT) Sender: andrey@brainhub.org Received: by 10.25.205.131 with HTTP; Thu, 9 Oct 2014 19:54:18 -0700 (PDT) X-Originating-IP: [108.65.79.249] Received: by 10.25.205.131 with HTTP; Thu, 9 Oct 2014 19:54:18 -0700 (PDT) In-Reply-To: <543630A2.5060904@shiftleft.org> References: <53F0010B.6080101@brainhub.org> <53F108CF.4040704@brainhub.org> <53F18607.3000005@brainhub.org> <5406C23E.80205@brainhub.org> <5407C176.3000109@brainhub.org> <5435DE66.7080803@brainhub.org> <29E067B7-C1F3-427C-8E4A-14F2096A71E4@shiftleft.org> <543616FF.4010503@brainhub.org> <54362162.8070506@brainhub.org> <543630A2.5060904@shiftleft.org> Date: Thu, 9 Oct 2014 19:54:18 -0700 X-Google-Sender-Auth: zOFCYIh2UzjVtFMtpTkF0UUNjE4 Message-ID: From: Andrey Jivsov To: Mike Hamburg Content-Type: multipart/alternative; boundary=001a11c239d0511922050508aa1c Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/uYYSnKMqxOb4L6pxPXmgKucgcos Cc: cfrg@irtf.org Subject: Re: [Cfrg] Timing of libsodium, curve25519-donna, MSR ECCLib, and openssl-master X-BeenThere: cfrg@irtf.org 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, 10 Oct 2014 02:54:23 -0000 --001a11c239d0511922050508aa1c Content-Type: text/plain; charset=UTF-8 On Oct 8, 2014 11:52 PM, "Mike Hamburg" wrote: > > > On 10/8/2014 10:47 PM, Andrey Jivsov wrote: >> >> >> Montgomery curve has fewer underlying filed operations. The performance benefit will be lower than due to prime reduction/hardware/instruction assistance. However, given that the numbers are fairly close now, we can expect change in leadership depending on the mix of features. For example, a hypothetical mix of the P-256 underlying field operations found in the code that I timed and a Montgomery curve on top would probably move such an implementation into the lead in the tests I performed. > > Yeah, or getting Shay and Vlad to hand-tune an x25519 implementation :-) BTW, I may be wrong on this one, but the latest performance boost I reported yesterday is due to OpenSSL team, I believe. > >> P-256 has an advantage that it's in standards, widely deployed, can do point additions (without penalty of coordinate conversion), and you can get X.509 certs with it. It would have been easier to argue on its disadvantages if it had worse performance than it appears to have. I am aware of other disadvantages of P-256. >> >> In your other e-mail, Watson, regarding AVX2/vector operations + X25519, it's an interesting question. The issues here are: >> * will this hide some benefits of the 2^n-1 prime? > > Possibly. You probably won't be able to use Langley and Bernstein's carry handling techniques, but fewer coefficients is always good. >> >> * increase code complexity? > > Compared to a version without handwritten asm? The field arithmetic will definitely be more complex. ... and the combined code not so neat ... > >> * it seems that this is of no use to mobile devices (in the near future anyway) > > Curve25519 performs quite well on ARM NEON. My list is regarding vector operations. I was alluding that one of the driving forces for new ECC is its excellent performance on mobile devices but many of them don't have vector athithetic. Therefore, there is no immediate ownership apparent of such vectorized code (until it is in OpenSSL :-)). > >> * but servers will benefit from this. > > > Cheers, > -- Mike --001a11c239d0511922050508aa1c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Oct 8, 2014 11:52 PM, "Mike Hamburg" <mike@shiftleft.org> wrote:
>
>
> On 10/8/2014 10:47 PM, Andrey Jivsov wrote:
>>
>>
>> Montgomery curve has fewer underlying filed operations. The perfor= mance benefit will be lower than due to prime reduction/hardware/instructio= n assistance. However, given that the numbers are fairly close now, we can = expect change in leadership depending on the mix of features. For example,= =C2=A0 a hypothetical mix of the P-256 underlying field operations found in= the code that I timed and a Montgomery curve on top would probably move su= ch an implementation into the lead in the tests I performed.
>
> Yeah, or getting Shay and Vlad to hand-tune an x25519 implementation := -)

BTW, I may be wrong on this one, but the latest performance = boost I reported yesterday is due to OpenSSL team, I believe.

>
>> P-256 has an advantage that it's in standards, widely deployed= , can do point additions (without penalty of coordinate conversion), and yo= u can get X.509 certs with it. It would have been easier to argue on its di= sadvantages if it had worse performance than it appears to have. I am aware= of other disadvantages of P-256.
>>
>> In your other e-mail, Watson, regarding AVX2/vector operations + X= 25519, it's an interesting question. The issues here are:
>> * will this hide some benefits of the 2^n-1 prime?
>
> Possibly.=C2=A0 You probably won't be able to use Langley and Bern= stein's carry handling techniques, but fewer coefficients is always goo= d.
>>
>> * increase code complexity?
>
> Compared to a version without handwritten asm?=C2=A0 The field arithme= tic will definitely be more complex.

... and the combined code not so neat ...

>
>> * it seems that this is of no use to mobile devices (in the near f= uture anyway)
>
> Curve25519 performs quite well on ARM NEON.

My list is regarding vector operations. I was alluding that = one of the driving forces for new ECC is its excellent performance on mobil= e devices but many of them don't have vector athithetic. Therefore, the= re is no immediate ownership apparent of such vectorized code (until it is = in OpenSSL :-)).

>
>> * but servers will benefit from this.
>
>
> Cheers,
> -- Mike

--001a11c239d0511922050508aa1c-- From nobody Fri Oct 10 00:30:29 2014 Return-Path: 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 87A751A1AF6 for ; Fri, 10 Oct 2014 00:30:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_LOW=-0.7, UNPARSEABLE_RELAY=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 D4plMGRPQZIp for ; Fri, 10 Oct 2014 00:30:26 -0700 (PDT) Received: from mace.cs.uic.edu (mace.cs.uic.edu [131.193.32.224]) by ietfa.amsl.com (Postfix) with SMTP id F3C061A1AE3 for ; Fri, 10 Oct 2014 00:30:25 -0700 (PDT) Received: (qmail 20862 invoked by uid 1011); 10 Oct 2014 07:30:21 -0000 Received: from unknown (unknown) by unknown with QMTP; 10 Oct 2014 07:30:21 -0000 Received: (qmail 9481 invoked by uid 1001); 10 Oct 2014 07:18:47 -0000 Date: 10 Oct 2014 07:18:47 -0000 Message-ID: <20141010071847.9478.qmail@cr.yp.to> From: "D. J. Bernstein" To: cfrg@irtf.org Mail-Followup-To: cfrg@irtf.org In-Reply-To: <2FBC676C3BBFBB4AA82945763B361DE608F1D021@MX17A.corp.emc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/1XIdOEmR5GezJkytrKcysLIj4Ks Subject: [Cfrg] Publicly verifiable benchmarks X-BeenThere: cfrg@irtf.org 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, 10 Oct 2014 07:30:28 -0000 Parkinson, Sean writes: > Making a decision on new elliptic curves based on data that hasn't > been corroborated by a 3rd party is bad practice. More than 1500 implementations of various cryptographic functions have been contributed to, and are publicly available as part of, the state-of-the-art SUPERCOP benchmarking framework: http://bench.cr.yp.to/supercop.html Practically all of the implementations are free to use, and many of them are in fact widely used. Most of the researchers producing speed records for cryptography are contributing their software to the same system. The eBACS benchmarking project systematically and reproducibly measures these implementations on more than 20 different microarchitectures: http://bench.cr.yp.to/computers.html It's easy for other people to download and run the benchmarks on their favorite CPU, and to contribute the results to the central system, where detailed speed reports are posted publicly for other people to see and verify. eBACS has practically eliminated the measurement errors and disputes that plagued previous approaches to cryptographic benchmarking. eBASH, the hash component of eBACS, was mentioned 30 times in NIST's final report on the SHA-3 competition. As a concrete example, now that Mike has sent crypto_dh/ed448goldilocks in for benchmarking, eBACS is automatically filling lines into http://bench.cr.yp.to/results-dh.html http://bench.cr.yp.to/impl-dh/ed448goldilocks.html whenever machines finish benchmark runs: 529066 cycles on titan0, 689020 cycles on hydra8, 757676 cycles on h6sandy, etc. These don't exactly confirm Mike's comparisons to the Sandy Bridge numbers that Microsoft claimed in http://eprint.iacr.org/2014/130.pdf---although they do seem adequate to support his point about ed448goldilocks hitting a sweet spot on the security/speed curve while Microsoft's design strategy compromises the security/speed tradeoff: * ed448goldilocks isn't quite twice as fast as numsp512t1 (ed-512-mers): 757676 cycles vs. 1293000 cycles. * ed448goldilocks is about 23% slower than numsp384t1 (ed-384-mers): 757676 cycles vs. 617000 cycles. Of course, if Mike or anyone else thinks that ed448goldilocks can be computed more efficiently, he's welcome to prove it by contributing a better implementation of that function to SUPERCOP, and then the benchmarks will be updated appropriately. He can also raise reasonable questions about the accuracy of Microsoft's claims; if Microsoft's numbers are actually correct then Microsoft can dispel the skepticism by contributing their own code to SUPERCOP. As a more detailed example of reproducibility, let's look at what the benchmarks say about X25519 on Haswell. Checking http://bench.cr.yp.to/results-dh.html we see a median of 145907 cycles (quartiles: 144894 and 147191 cycles) for the crypto_dh/curve25519 software on an Intel Xeon E3-1275 V3. Clicking on "titan0" shows more information: the best speeds found for crypto_scalarmult/curve25519 on this machine used gcc-4.8.1 -m64 -O -march=native -mtune=native -fomit-frame-pointer to compile the "amd64-51" implementation. Anyone can use the same free implementation with the same free compiler and will obtain the same compiled code running in the same number of Haswell cycles: wget https://hyperelliptic.org/ebats/supercop-20140924.tar.bz2 tar -xf supercop-20140924.tar.bz2 cd supercop-20140924 # compile and measure everything: nohup sh data-do & # alternatively, extract X25519 as follows: mkdir x25519 cp measure-anything.c x25519 cp crypto_scalarmult/measure.c x25519 cp crypto_scalarmult/curve25519/amd64-51/* x25519 cp include/randombytes.h x25519 cp cpucycles/amd64cpuinfo.h x25519/cpucycles.h cp cpucycles/amd64cpuinfo.c x25519/cpucycles.c cp cpucycles/osfreq.c x25519/osfreq.c cd x25519 ( sed s/CRYPTO_/crypto_scalarmult_/ < api.h echo '#define crypto_scalarmult_IMPLEMENTATION "amd64-51"' echo '#define crypto_scalarmult_VERSION "-"' ) > crypto_scalarmult.h echo 'static const char cpuid[] = {0};' > cpuid.h gcc -m64 -O -march=native -mtune=native -fomit-frame-pointer \ -D COMPILER='"gcc"' \ -D LOOPS=1 \ -o measure measure-anything.c measure.c cpucycles.c \ mont* fe*.c *.s ./measure For example, on one core of Andrey's 3.4GHz i7-4770 (Haswell), this X25519 code will take the same ~146000 cycles: i.e., more than 23000 operations/second, whereas the latest Haswell-optimized OpenSSL NIST P-256 ECDH code that he measured was only 15000 operations/second. This is, by the way, rather old Curve25519 code optimized for Nehalem, the microarchitecture of the first Core i7 CPUs in 2008---but on Intel's latest Haswell CPUs it's still solidly beating NIST P-256 code that's optimized for Haswell. There's ample literature explaining that * reductions mod 2^255-19 are faster than reductions mod 2^256-2^224+2^192+2^96-1 on a broad range of platforms, and that * Montgomery scalarmult is faster than Weierstrass scalarmult, so the performance gap is unsurprising. Why did Andrey report only 17289 operations/second for X25519 on Haswell? The answer, in a nutshell, is that there's an active ecosystem of Curve25519/X25519/Ed25519 implementations, and it's easy to find implementations that prioritize simplicity over speed---including the one implementation included in Andrey's manual benchmarks. Of course, any application developer who needs more speed will look for, and find, the faster X25519 implementations. ---Dan From nobody Fri Oct 10 08:44:33 2014 Return-Path: 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 B1AD91A6FD4 for ; Fri, 10 Oct 2014 08:44:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no 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 O1Ui7vEuh5hM for ; Fri, 10 Oct 2014 08:44:30 -0700 (PDT) Received: from nm2-vm2.access.bullet.mail.gq1.yahoo.com (nm2-vm2.access.bullet.mail.gq1.yahoo.com [216.39.63.30]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B2F41A6FF7 for ; Fri, 10 Oct 2014 08:44:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sbcglobal.net; s=s1024; t=1412955867; bh=QsPDIHKz4Re3zQcCRzTsWPV1bShjWBcidaq32qaa7bk=; h=Received:Received:Received:DKIM-Signature:X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:From:Subject; b=ToLRhnCNagJxvt0Hnvfq7yOibwC5KFg/NiMewMZSRvoVrMxpKAo8gSHP9jnruUZzks2cjCW5VSsEeqodi2fD0/TpjDsFfwQMeu9qV7Kjwu3o7r1RXUlKL4htqy5tNg4uNnqejq4uRlvTuhdi1Eg8V9mlO4GkZJ0PkHHQMAnGgQQ= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=sbcglobal.net; b=gBbCKtf1puUTjdvRt/y7MEOYDXBlf3NipC5Ywi06GKzPD0ldekgUiWmUQqCG50bEh9vb4Ye7gN/qZlfXL/48IQa8KtHnsHM9GrukC20qS7ttdsdFKskyzwA0Q8akAMZyK6gXe2RwWFn9IUdsD2VAC/xpMRhPXsUOe27gpDCxJOw=; Received: from [216.39.60.171] by nm2.access.bullet.mail.gq1.yahoo.com with NNFMP; 10 Oct 2014 15:44:27 -0000 Received: from [67.195.23.145] by tm7.access.bullet.mail.gq1.yahoo.com with NNFMP; 10 Oct 2014 15:44:26 -0000 Received: from [127.0.0.1] by smtp117.sbc.mail.gq1.yahoo.com with NNFMP; 10 Oct 2014 15:44:26 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sbcglobal.net; s=s1024; t=1412955866; bh=QsPDIHKz4Re3zQcCRzTsWPV1bShjWBcidaq32qaa7bk=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=ADYjw0WH8zDLCncTnzapwWk9Ua1g8nM92iDDXQ63rc97iCr5w60FCOdUI/yE8OXegpaNUtT0n6tBKAQZ+rFFdOkNx9Wa0ZfHicwtbeUgXpC9FMSLgtnTLtWChtNpO84xLSYU0yBVwlN4xrzDW3VSUCZL4cbc7w9rHaNWt7xqM4U= X-Yahoo-Newman-Id: 892210.25832.bm@smtp117.sbc.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: fj4fkH4VM1k2.U6awmpf_VolhH0G_glUrdIeDssLgQvjis1 gUpul8cngMMkF.H2q1HxDJ1AVq5sGdRfAK9k.u2Rr44DPy434jfc92vwjUBJ QTO6LzBhGKTV8ezvBHC2HuH4uMmEbr.MGdJq.S.U1_9AjL6CzY6FbiSdVF_T XlaYSVXIFUar5NSyL4doiUkxQJoaff49s_MP.YkiYqGg83XbjDKyT.diHVXJ R583H6m0sAd0iLZzPmSzd9QU89w3nw8A7cwVjpTxC1vFjGTK3EXuRY.FbkDj rGEgXOxjpxB__VFuyDzbIAUVQQr96e6zhMg1o8fzQjVWII9nB7NcOZBAfaXn J9O03xrUbY6xBOhKWtC7IMMliR9DkPE5NJThjKY_SsoHsLlRrwYxNUK7Yvku rK3Aa4P8.L8MOm8ZxuiYlKhzu2qydbePJ3wjyg9fEdM7Q9vP9zpqj8qDD2Fd 2BmRbFYLjDUCFaFFWyeBgAM_sWRJW0nLYOacEwZC6Vz6lEgcymse7DbDK91a fvaeRvQBvU8IEeU0xVjFBBU3PvkrHjLVLMEF5tPRGU.X_qSaBovFdeTO2R08 iyMVf8MITWG7ZIwc02Lssi6vDiIuBh9eIPMtyRfIKxAeK6Mx_9FDS0QnKo1i NtEDQqrZv6kebxnrFXZUzPf7Vg1hOhGh0aClFx09Wuym3J2r0H2eq5DP1LDN csLCsQtmY62kogCGuhJAuKxp8BdkZAkw9DGk29MsNZjHigkPyYjTU.btxxCE Pr0T6TEauq53andRVoYYHRqdDIiwrtsjbXGtgPQyfHA9ii4W_WcxVZEz6KC5 K9Q-- X-Yahoo-SMTP: nOrmCa6swBAE50FabWnlVFUpgFVJ9Gbi__8U5mpvhtQq7tTV1g-- Message-ID: <5437FED9.50409@sbcglobal.net> Date: Fri, 10 Oct 2014 08:44:25 -0700 From: David Jacobson User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: cfrg@irtf.org References: <20141010071847.9478.qmail@cr.yp.to> In-Reply-To: <20141010071847.9478.qmail@cr.yp.to> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/qTvGc4xnQUZjXhqAMZV9i1fgFPo Subject: Re: [Cfrg] Publicly verifiable benchmarks X-BeenThere: cfrg@irtf.org 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, 10 Oct 2014 15:44:31 -0000 On 10/10/14, 12:18 AM, D. J. Bernstein wrote: > Parkinson, Sean writes: >> Making a decision on new elliptic curves based on data that hasn't >> been corroborated by a 3rd party is bad practice. > More than 1500 implementations of various cryptographic functions have > been contributed to, and are publicly available as part of, the > state-of-the-art SUPERCOP benchmarking framework: > > http://bench.cr.yp.to/supercop.html > > Practically all of the implementations are free to use, and many of them > are in fact widely used. Most of the researchers producing speed records > for cryptography are contributing their software to the same system. > > The eBACS benchmarking project systematically and reproducibly measures > these implementations on more than 20 different microarchitectures: > > http://bench.cr.yp.to/computers.html > > It's easy for other people to download and run the benchmarks on their > favorite CPU, and to contribute the results to the central system, where > detailed speed reports are posted publicly for other people to see and > verify. eBACS has practically eliminated the measurement errors and > disputes that plagued previous approaches to cryptographic benchmarking. > eBASH, the hash component of eBACS, was mentioned 30 times in NIST's > final report on the SHA-3 competition. > > As a concrete example, now that Mike has sent crypto_dh/ed448goldilocks > in for benchmarking, eBACS is automatically filling lines into > > http://bench.cr.yp.to/results-dh.html > http://bench.cr.yp.to/impl-dh/ed448goldilocks.html > > whenever machines finish benchmark runs: 529066 cycles on titan0, 689020 > cycles on hydra8, 757676 cycles on h6sandy, etc. These don't exactly > confirm Mike's comparisons to the Sandy Bridge numbers that Microsoft > claimed in http://eprint.iacr.org/2014/130.pdf---although they do seem > adequate to support his point about ed448goldilocks hitting a sweet spot > on the security/speed curve while Microsoft's design strategy > compromises the security/speed tradeoff: > > * ed448goldilocks isn't quite twice as fast as numsp512t1 > (ed-512-mers): 757676 cycles vs. 1293000 cycles. > > * ed448goldilocks is about 23% slower than numsp384t1 (ed-384-mers): > 757676 cycles vs. 617000 cycles. > > Of course, if Mike or anyone else thinks that ed448goldilocks can be > computed more efficiently, he's welcome to prove it by contributing a > better implementation of that function to SUPERCOP, and then the > benchmarks will be updated appropriately. He can also raise reasonable > questions about the accuracy of Microsoft's claims; if Microsoft's > numbers are actually correct then Microsoft can dispel the skepticism > by contributing their own code to SUPERCOP. > > As a more detailed example of reproducibility, let's look at what the > benchmarks say about X25519 on Haswell. Checking > > http://bench.cr.yp.to/results-dh.html > > we see a median of 145907 cycles (quartiles: 144894 and 147191 cycles) > for the crypto_dh/curve25519 software on an Intel Xeon E3-1275 V3. > Clicking on "titan0" shows more information: the best speeds found for > crypto_scalarmult/curve25519 on this machine used > > gcc-4.8.1 -m64 -O -march=native -mtune=native -fomit-frame-pointer > > to compile the "amd64-51" implementation. Anyone can use the same free > implementation with the same free compiler and will obtain the same > compiled code running in the same number of Haswell cycles: > > wget https://hyperelliptic.org/ebats/supercop-20140924.tar.bz2 > tar -xf supercop-20140924.tar.bz2 > cd supercop-20140924 > # compile and measure everything: nohup sh data-do & > # alternatively, extract X25519 as follows: > mkdir x25519 > cp measure-anything.c x25519 > cp crypto_scalarmult/measure.c x25519 > cp crypto_scalarmult/curve25519/amd64-51/* x25519 > cp include/randombytes.h x25519 > cp cpucycles/amd64cpuinfo.h x25519/cpucycles.h > cp cpucycles/amd64cpuinfo.c x25519/cpucycles.c > cp cpucycles/osfreq.c x25519/osfreq.c > cd x25519 > ( sed s/CRYPTO_/crypto_scalarmult_/ < api.h > echo '#define crypto_scalarmult_IMPLEMENTATION "amd64-51"' > echo '#define crypto_scalarmult_VERSION "-"' > ) > crypto_scalarmult.h > echo 'static const char cpuid[] = {0};' > cpuid.h > gcc -m64 -O -march=native -mtune=native -fomit-frame-pointer \ > -D COMPILER='"gcc"' \ > -D LOOPS=1 \ > -o measure measure-anything.c measure.c cpucycles.c \ > mont* fe*.c *.s > ./measure > > For example, on one core of Andrey's 3.4GHz i7-4770 (Haswell), this > X25519 code will take the same ~146000 cycles: i.e., more than 23000 > operations/second, whereas the latest Haswell-optimized OpenSSL NIST > P-256 ECDH code that he measured was only 15000 operations/second. > > This is, by the way, rather old Curve25519 code optimized for Nehalem, > the microarchitecture of the first Core i7 CPUs in 2008---but on Intel's > latest Haswell CPUs it's still solidly beating NIST P-256 code that's > optimized for Haswell. There's ample literature explaining that > > * reductions mod 2^255-19 are faster than reductions mod > 2^256-2^224+2^192+2^96-1 on a broad range of platforms, and that > > * Montgomery scalarmult is faster than Weierstrass scalarmult, > > so the performance gap is unsurprising. > > Why did Andrey report only 17289 operations/second for X25519 on > Haswell? The answer, in a nutshell, is that there's an active ecosystem > of Curve25519/X25519/Ed25519 implementations, and it's easy to find > implementations that prioritize simplicity over speed---including the > one implementation included in Andrey's manual benchmarks. Of course, > any application developer who needs more speed will look for, and find, > the faster X25519 implementations. > > ---Dan > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg > You have amassed a lot of data. Wow! But this seems to be concerned with raw speed. It would be nice if you tagged implementations (of algorithms where it matters) into according to leakage resistance. There could be a tag for optimized solely for speed, another for implementations that are timing leak resistant (either constant time or blinded), etc. --David Jacobson From nobody Fri Oct 10 12:01:01 2014 Return-Path: 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 2303C1ACE9C for ; Fri, 10 Oct 2014 12:00:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.155 X-Spam-Level: ** X-Spam-Status: No, score=2.155 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_15=0.6, RDNS_DYNAMIC=0.982, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no 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 s4PB7l0SxdaC for ; Fri, 10 Oct 2014 12:00:56 -0700 (PDT) Received: from aspartame.shiftleft.org (199-116-74-168-v301.PUBLIC.monkeybrains.net [199.116.74.168]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C82E81ACE81 for ; Fri, 10 Oct 2014 12:00:49 -0700 (PDT) Received: from [10.184.148.249] (unknown [209.36.6.242]) by aspartame.shiftleft.org (Postfix) with ESMTPSA id CD3F3F5EAE; Fri, 10 Oct 2014 11:59:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=shiftleft.org; s=sldo; t=1412967555; bh=JemY07iSwYElPTzD0xnewuBobYFQ8o2qd5Mc3hsuHM8=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=MQAP8sfcGlkLw8QuDgB0SCYjp7orpEkyX64R52l2lZoGqfBI9ZysWZn4qp0WlfKni oCp3D6VBJMen3NsDsQDaklh9jSl2ZagrvUs97guiYKYU8ckRGLrFk6urvqktbGLtcz aXjuDbd49XfqACiVhjcuktcb6JGhr0dqVyWnjG1k= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Michael Hamburg In-Reply-To: <20141010071847.9478.qmail@cr.yp.to> Date: Fri, 10 Oct 2014 12:00:44 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20141010071847.9478.qmail@cr.yp.to> To: "D. J. Bernstein" X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/FmWhLMjHWkl1mP4XTANCBWr9pSs Cc: cfrg@irtf.org Subject: Re: [Cfrg] Publicly verifiable benchmarks X-BeenThere: cfrg@irtf.org 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, 10 Oct 2014 19:00:59 -0000 I=E2=80=99ll add a +1 in favor of SUPERCOP as a = better-than-all-the-others reproducible benchmarking system. It=E2=80=99s= a bit finicky, though; in particular, typing =E2=80=9Csh do=E2=80=9D = and waiting a week isn=E2=80=99t the most convenient development cycle. = Furthermore, some of the machines on bench.cr.yp.to have quirks = (turboboost, mismatched cycle counter frequency, etc) which can make the = data difficult to interpret and reproduce. If you are considering submitting a system, I=E2=80=99d strongly = recommend testing on https://github.com/jschanck-si/supercop-fastbuild, = You should also make sure to install the compilers DJB uses (GCC 4.8.1 = and Clang 3.2 on titan0, or GCC 4.6.3 and Clang 3.0 on h6sandy, for = example) to make sure that your system compiles and runs passably well = using those compilers. I didn=E2=80=99t do this last time, which is = (part of?) why the numbers from my own benchmarks do not match DJB=E2=80=99= s numbers; see below. > On Oct 10, 2014, at 12:18 AM, D. J. Bernstein wrote: >=20 > Parkinson, Sean writes: >> Making a decision on new elliptic curves based on data that hasn't >> been corroborated by a 3rd party is bad practice. >=20 > More than 1500 implementations of various cryptographic functions have > been contributed to, and are publicly available as part of, the > state-of-the-art SUPERCOP benchmarking framework: >=20 > http://bench.cr.yp.to/supercop.html >=20 > Practically all of the implementations are free to use, and many of = them > are in fact widely used. Most of the researchers producing speed = records > for cryptography are contributing their software to the same system. >=20 > The eBACS benchmarking project systematically and reproducibly = measures > these implementations on more than 20 different microarchitectures: >=20 > http://bench.cr.yp.to/computers.html >=20 > It's easy for other people to download and run the benchmarks on their > favorite CPU, and to contribute the results to the central system, = where > detailed speed reports are posted publicly for other people to see and > verify. eBACS has practically eliminated the measurement errors and > disputes that plagued previous approaches to cryptographic = benchmarking. > eBASH, the hash component of eBACS, was mentioned 30 times in NIST's > final report on the SHA-3 competition. >=20 > As a concrete example, now that Mike has sent = crypto_dh/ed448goldilocks > in for benchmarking, eBACS is automatically filling lines into >=20 > http://bench.cr.yp.to/results-dh.html > http://bench.cr.yp.to/impl-dh/ed448goldilocks.html >=20 > whenever machines finish benchmark runs: 529066 cycles on titan0, = 689020 > cycles on hydra8, 757676 cycles on h6sandy, etc. These don't exactly > confirm Mike's comparisons to the Sandy Bridge numbers that Microsoft > claimed in http://eprint.iacr.org/2014/130.pdf---although they do seem > adequate to support his point about ed448goldilocks hitting a sweet = spot > on the security/speed curve while Microsoft's design strategy > compromises the security/speed tradeoff: >=20 > * ed448goldilocks isn't quite twice as fast as numsp512t1 > (ed-512-mers): 757676 cycles vs. 1293000 cycles. >=20 > * ed448goldilocks is about 23% slower than numsp384t1 (ed-384-mers): > 757676 cycles vs. 617000 cycles. >=20 > Of course, if Mike or anyone else thinks that ed448goldilocks can be > computed more efficiently, he's welcome to prove it by contributing a > better implementation of that function to SUPERCOP, and then the > benchmarks will be updated appropriately. He can also raise reasonable > questions about the accuracy of Microsoft's claims; if Microsoft's > numbers are actually correct then Microsoft can dispel the skepticism > by contributing their own code to SUPERCOP. For the next SUPERCOP release, please pull the latest BAT from = http://shiftleft.org/upload/ed448goldilocks-20141010.tgz The build on bench.cr.yp.to has a bug which prevents compilation on = older 64-bit clangs, such as clang 3.2 on titan0, and clang 3.0 on = h6sandy. So for example on ProteusMachine (Haswell Core i7-4790 CPU @ 3.60GHz, HT = and TB disabled) with supercop-fastbuild's = clang_-g_-O3_-march=3Dnative_-mtune=3Dnative_-fomit-frame-pointer = 4.2.1_Compatible_Ubuntu_Clang_3.5_(trunk), the timings are 160431 = keypair cycles and 479118 dh cycles. Thanks, =E2=80=94 Mike > As a more detailed example of reproducibility, let's look at what the > benchmarks say about X25519 on Haswell. Checking >=20 > http://bench.cr.yp.to/results-dh.html >=20 > we see a median of 145907 cycles (quartiles: 144894 and 147191 cycles) > for the crypto_dh/curve25519 software on an Intel Xeon E3-1275 V3. > Clicking on "titan0" shows more information: the best speeds found for > crypto_scalarmult/curve25519 on this machine used >=20 > gcc-4.8.1 -m64 -O -march=3Dnative -mtune=3Dnative = -fomit-frame-pointer >=20 > to compile the "amd64-51" implementation. Anyone can use the same free > implementation with the same free compiler and will obtain the same > compiled code running in the same number of Haswell cycles: >=20 > wget https://hyperelliptic.org/ebats/supercop-20140924.tar.bz2 > tar -xf supercop-20140924.tar.bz2 > cd supercop-20140924 > # compile and measure everything: nohup sh data-do & > # alternatively, extract X25519 as follows: > mkdir x25519 > cp measure-anything.c x25519 > cp crypto_scalarmult/measure.c x25519 > cp crypto_scalarmult/curve25519/amd64-51/* x25519 > cp include/randombytes.h x25519 > cp cpucycles/amd64cpuinfo.h x25519/cpucycles.h > cp cpucycles/amd64cpuinfo.c x25519/cpucycles.c > cp cpucycles/osfreq.c x25519/osfreq.c > cd x25519 > ( sed s/CRYPTO_/crypto_scalarmult_/ < api.h > echo '#define crypto_scalarmult_IMPLEMENTATION "amd64-51"' > echo '#define crypto_scalarmult_VERSION "-"' > ) > crypto_scalarmult.h > echo 'static const char cpuid[] =3D {0};' > cpuid.h > gcc -m64 -O -march=3Dnative -mtune=3Dnative -fomit-frame-pointer \ > -D COMPILER=3D'"gcc"' \ > -D LOOPS=3D1 \ > -o measure measure-anything.c measure.c cpucycles.c \ > mont* fe*.c *.s > ./measure >=20 > For example, on one core of Andrey's 3.4GHz i7-4770 (Haswell), this > X25519 code will take the same ~146000 cycles: i.e., more than 23000 > operations/second, whereas the latest Haswell-optimized OpenSSL NIST > P-256 ECDH code that he measured was only 15000 operations/second. >=20 > This is, by the way, rather old Curve25519 code optimized for Nehalem, > the microarchitecture of the first Core i7 CPUs in 2008---but on = Intel's > latest Haswell CPUs it's still solidly beating NIST P-256 code that's > optimized for Haswell. There's ample literature explaining that >=20 > * reductions mod 2^255-19 are faster than reductions mod > 2^256-2^224+2^192+2^96-1 on a broad range of platforms, and that >=20 > * Montgomery scalarmult is faster than Weierstrass scalarmult, >=20 > so the performance gap is unsurprising. >=20 > Why did Andrey report only 17289 operations/second for X25519 on > Haswell? The answer, in a nutshell, is that there's an active = ecosystem > of Curve25519/X25519/Ed25519 implementations, and it's easy to find > implementations that prioritize simplicity over speed---including the > one implementation included in Andrey's manual benchmarks. Of course, > any application developer who needs more speed will look for, and = find, > the faster X25519 implementations. >=20 > ---Dan >=20 > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg From nobody Sat Oct 11 04:50:25 2014 Return-Path: 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 EDDB91A03AA for ; Sat, 11 Oct 2014 04:50:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.786 X-Spam-Level: X-Spam-Status: No, score=-2.786 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.786] 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 TrMGRH26iJyg for ; Sat, 11 Oct 2014 04:50:22 -0700 (PDT) Received: from waldorf.isode.com (ext-bt.isode.com [217.34.220.158]) by ietfa.amsl.com (Postfix) with ESMTP id 9C1811A044D for ; Sat, 11 Oct 2014 04:50:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1413028221; d=isode.com; s=selector; i=@isode.com; bh=qvI1LqSf3m+l/vZdNcCLWFFeehK8t2uL4IONqABHJp0=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=EQ5CVw1e9Q5P4AGTkkluYDkcweTQ2TrzpjaqFpj3a2E8oQdsPA18qtBD1QYVOz1/baRHCX ThrE1JH38y58g6sxGvB06pAIOWuKAOHm0FzEIX+wNKhSytnGo72hTXMweKaYRSmbOi/2WP Un1XU5JiRNiyrNVktsORNxuuX7XzaIA=; Received: from [192.168.0.12] (cpc5-nmal20-2-0-cust24.19-2.cable.virginm.net [92.234.84.25]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Sat, 11 Oct 2014 12:50:21 +0100 X-SMTP-Protocol-Errors: PIPELINING From: Alexey Melnikov X-Mailer: iPad Mail (11D257) In-Reply-To: Date: Sat, 11 Oct 2014 13:02:44 +0100 Message-Id: <3BF8A484-C2E1-482F-96DA-B2F631AD832A@isode.com> References: To: Watson Ladd MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/JJwdNUU_ZqBLc-X_1lDNcoxH56g Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] Adoption of draft-ladd-spake2 as work item X-BeenThere: cfrg@irtf.org 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: Sat, 11 Oct 2014 11:50:24 -0000 Hi Watson, > On 10 Oct 2014, at 02:53, Watson Ladd wrote: > > Dear all, > > I'd like to formally request adoption of draft-ladd-spake2 as a work > item. Currently M and N need to be chosen: I understand that Google > has implemented SPAKE2 in Chromium already with a particular choice of > M&N for P224. It also probably needs to be less terse. > Ok, chairs added your request to their "to do" list. Best Regards, Alexey > Sincerely, > Watson Ladd > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg From nobody Sat Oct 11 19:54:53 2014 Return-Path: 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 CA46F1A0A6B for ; Sat, 11 Oct 2014 19:54:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_15=0.6, SPF_PASS=-0.001] autolearn=no 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 maKLxgZYnlZU for ; Sat, 11 Oct 2014 19:54:49 -0700 (PDT) Received: from resqmta-po-11v.sys.comcast.net (resqmta-po-11v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:170]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07D751A19E4 for ; Sat, 11 Oct 2014 19:54:48 -0700 (PDT) Received: from resomta-po-14v.sys.comcast.net ([96.114.154.238]) by resqmta-po-11v.sys.comcast.net with comcast id 22uo1p00158ss0Y012uoZt; Sun, 12 Oct 2014 02:54:48 +0000 Received: from [192.168.1.2] ([71.202.164.227]) by resomta-po-14v.sys.comcast.net with comcast id 22un1p00E4uhcbK012unqH; Sun, 12 Oct 2014 02:54:48 +0000 Message-ID: <5439ED77.3010701@brainhub.org> Date: Sat, 11 Oct 2014 19:54:47 -0700 From: Andrey Jivsov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: cfrg@irtf.org References: <20141010071847.9478.qmail@cr.yp.to> In-Reply-To: <20141010071847.9478.qmail@cr.yp.to> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1413082488; bh=4RXdlie6oXfQjdDs56DIU0xPyGRYdJe6OSAU2dGk6yg=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=FLglQdaTtdlFqqJ8aI/T7drHwPCbw+S1VghHrZz6jWq/8jNv9KL1mH1vcyVBwj+Sg PBMGILA7FfgpnzNM9wQF6ftxWQmRckx13444gBSfA1vxK6gF82Gc1wNOLnNFMzx/0K 4wKtPa9BmdZMoU/892G6aBRB/c+lnpVQPw+IC+qHqIQ4/vMwesAiC5RPwfyOBAQ4ew 1ib/Ugt9eoYbf4ULL+dZg3vp6WxtPIHsXCRHWT1SR1HWvW2khGgWlDZmpu0Wbv/kw3 IaFUsVlLtVp/iipvJRn5ImV4Qpa1zkvTI/56PemNrFed2GdKFk3Q+wVYhgzp/U17EY H9wU+H7fQm02A== Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/wTV6zTfn22q-rD78EkJqYUlbbr4 Subject: Re: [Cfrg] Publicly verifiable benchmarks X-BeenThere: cfrg@irtf.org 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: Sun, 12 Oct 2014 02:54:52 -0000 On 10/10/2014 12:18 AM, D. J. Bernstein wrote: > Parkinson, Sean writes: >> Making a decision on new elliptic curves based on data that hasn't >> been corroborated by a 3rd party is bad practice. > > More than 1500 implementations of various cryptographic functions have > been contributed to, and are publicly available as part of, the > state-of-the-art SUPERCOP benchmarking framework: > > http://bench.cr.yp.to/supercop.html > > Practically all of the implementations are free to use, and many of them > are in fact widely used. Most of the researchers producing speed records > for cryptography are contributing their software to the same system. > > The eBACS benchmarking project systematically and reproducibly measures > these implementations on more than 20 different microarchitectures: > > http://bench.cr.yp.to/computers.html > > It's easy for other people to download and run the benchmarks on their > favorite CPU, and to contribute the results to the central system, where > detailed speed reports are posted publicly for other people to see and > verify. eBACS has practically eliminated the measurement errors and > disputes that plagued previous approaches to cryptographic benchmarking. > eBASH, the hash component of eBACS, was mentioned 30 times in NIST's > final report on the SHA-3 competition. > > As a concrete example, now that Mike has sent crypto_dh/ed448goldilocks > in for benchmarking, eBACS is automatically filling lines into > > http://bench.cr.yp.to/results-dh.html > http://bench.cr.yp.to/impl-dh/ed448goldilocks.html > > whenever machines finish benchmark runs: 529066 cycles on titan0, 689020 > cycles on hydra8, 757676 cycles on h6sandy, etc. These don't exactly > confirm Mike's comparisons to the Sandy Bridge numbers that Microsoft > claimed in http://eprint.iacr.org/2014/130.pdf---although they do seem > adequate to support his point about ed448goldilocks hitting a sweet spot > on the security/speed curve while Microsoft's design strategy > compromises the security/speed tradeoff: > > * ed448goldilocks isn't quite twice as fast as numsp512t1 > (ed-512-mers): 757676 cycles vs. 1293000 cycles. > > * ed448goldilocks is about 23% slower than numsp384t1 (ed-384-mers): > 757676 cycles vs. 617000 cycles. > > Of course, if Mike or anyone else thinks that ed448goldilocks can be > computed more efficiently, he's welcome to prove it by contributing a > better implementation of that function to SUPERCOP, and then the > benchmarks will be updated appropriately. He can also raise reasonable > questions about the accuracy of Microsoft's claims; if Microsoft's > numbers are actually correct then Microsoft can dispel the skepticism > by contributing their own code to SUPERCOP. > > As a more detailed example of reproducibility, let's look at what the > benchmarks say about X25519 on Haswell. Checking > > http://bench.cr.yp.to/results-dh.html > > we see a median of 145907 cycles (quartiles: 144894 and 147191 cycles) > for the crypto_dh/curve25519 software on an Intel Xeon E3-1275 V3. > Clicking on "titan0" shows more information: the best speeds found for > crypto_scalarmult/curve25519 on this machine used > > gcc-4.8.1 -m64 -O -march=native -mtune=native -fomit-frame-pointer > > to compile the "amd64-51" implementation. Anyone can use the same free > implementation with the same free compiler and will obtain the same > compiled code running in the same number of Haswell cycles: > > wget https://hyperelliptic.org/ebats/supercop-20140924.tar.bz2 > tar -xf supercop-20140924.tar.bz2 > cd supercop-20140924 > # compile and measure everything: nohup sh data-do & > # alternatively, extract X25519 as follows: > mkdir x25519 > cp measure-anything.c x25519 > cp crypto_scalarmult/measure.c x25519 > cp crypto_scalarmult/curve25519/amd64-51/* x25519 > cp include/randombytes.h x25519 > cp cpucycles/amd64cpuinfo.h x25519/cpucycles.h > cp cpucycles/amd64cpuinfo.c x25519/cpucycles.c > cp cpucycles/osfreq.c x25519/osfreq.c > cd x25519 > ( sed s/CRYPTO_/crypto_scalarmult_/ < api.h > echo '#define crypto_scalarmult_IMPLEMENTATION "amd64-51"' > echo '#define crypto_scalarmult_VERSION "-"' > ) > crypto_scalarmult.h > echo 'static const char cpuid[] = {0};' > cpuid.h > gcc -m64 -O -march=native -mtune=native -fomit-frame-pointer \ > -D COMPILER='"gcc"' \ > -D LOOPS=1 \ > -o measure measure-anything.c measure.c cpucycles.c \ > mont* fe*.c *.s > ./measure Thank you for this information. I added timing code and built the "measure" program in the x25519 directory (see above) on Intel(R) Core(TM) i5-3550 CPU @ 3.30GHz, Ivy Bridge (not Haswell). 3 results are in op/sec: above x25519 variable base : openssl : curve25519-donna: 18167.7 : 11030.5 : 14098.2 18167.7/11030.5 = 65% The ./measure reported 182112 cycles for variable base before and after my changes (which looks correct: 3300000000 Hz/182112=18120 sec). Specifically, I timed the crypto_scalarmult(). I won't have access to my Haswell machine for a few days. > > For example, on one core of Andrey's 3.4GHz i7-4770 (Haswell), this > X25519 code will take the same ~146000 cycles: i.e., more than 23000 > operations/second, whereas the latest Haswell-optimized OpenSSL NIST > P-256 ECDH code that he measured was only 15000 operations/second. > > This is, by the way, rather old Curve25519 code optimized for Nehalem, > the microarchitecture of the first Core i7 CPUs in 2008---but on Intel's > latest Haswell CPUs it's still solidly beating NIST P-256 code that's > optimized for Haswell. There's ample literature explaining that > > * reductions mod 2^255-19 are faster than reductions mod > 2^256-2^224+2^192+2^96-1 on a broad range of platforms, and that > > * Montgomery scalarmult is faster than Weierstrass scalarmult, > > so the performance gap is unsurprising. > > Why did Andrey report only 17289 operations/second for X25519 on > Haswell? The answer, in a nutshell, is that there's an active ecosystem > of Curve25519/X25519/Ed25519 implementations, and it's easy to find > implementations that prioritize simplicity over speed---including the > one implementation included in Andrey's manual benchmarks. Of course, > any application developer who needs more speed will look for, and find, > the faster X25519 implementations. > > ---Dan It's natural for a developer, the consumer of these open source libraries, to test-drive the speed tests the way I did. If the sequence of steps needed to run the tests is clear and short, the results are easily verifiable. In case of openssl the results depends on: * the exact version of the source code * the exact version of the compiler and assembler tools * the options given to the config, configure * CPU OpenSSL will autodetect the gcc and build the binary by excluding or including certain highly-optimized pieces without any relevant reports. Some beneficial configuration options are not always the defaults. Not surprisingly, the openssl that comes with the latest OS I test on, Fedora Core 20, is 3+ times slower than what I report above. I find that the quickest way for me to confirm that I am timing the right code is to use the debugger. For example, I confirmed that ./measure is spending time in crypto_scalarmult_curve25519_amd64_51_ladderstep in a hand-written assembler file. http://bench.cr.yp.to looks like an excellent way to try code on platforms one doesn't own. From nobody Sat Oct 11 21:15:48 2014 Return-Path: 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 8F44F1A8851 for ; Sat, 11 Oct 2014 21:15:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 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, J_CHICKENPOX_15=0.6, SPF_PASS=-0.001] autolearn=no 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 ZlJqjbRe41iy for ; Sat, 11 Oct 2014 21:15:43 -0700 (PDT) Received: from mail-yh0-x22f.google.com (mail-yh0-x22f.google.com [IPv6:2607:f8b0:4002:c01::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 557551A87EB for ; Sat, 11 Oct 2014 21:15:43 -0700 (PDT) Received: by mail-yh0-f47.google.com with SMTP id c41so2803394yho.20 for ; Sat, 11 Oct 2014 21:15:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=PmPvkWF1YjrMrxs0Mnyo52JPcsom24z7uWiASY4yTWc=; b=S3IJw41dmryEA/v4CEsgaEiBs7LzmKHx9MmvJEhQFgBkWaqB1vxBIBgZRH16HXMKV9 6rylQXOo694btfqSWKRS1JDy24zYm7praVx/hSAr7+O3aqRwAFHN1+rc0khzlr73HLSM 9ogsGvaDu1MJdNqCrbMGNuPeZNY8ejQpt5iRqiYA2BwLamxnRZz6wtaXj3LGoIiKLbpu SMkx8TNM44HtqtwSZ/Q4zW3NXJe1rI0aBotTzpCc6XEjKemSL5JxxdDOh/IhRrxFD0oc kTUUHQ/BNWO5JcWG5l91z9TOzkaKesFdSu7aaE6WwqvItW9AGROPEnlzXJZrEiP4ylN7 WIKQ== MIME-Version: 1.0 X-Received: by 10.236.76.69 with SMTP id a45mr23175916yhe.103.1413087342299; Sat, 11 Oct 2014 21:15:42 -0700 (PDT) Received: by 10.170.195.149 with HTTP; Sat, 11 Oct 2014 21:15:42 -0700 (PDT) In-Reply-To: <5439ED77.3010701@brainhub.org> References: <20141010071847.9478.qmail@cr.yp.to> <5439ED77.3010701@brainhub.org> Date: Sat, 11 Oct 2014 21:15:42 -0700 Message-ID: From: Watson Ladd To: Andrey Jivsov Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/_cuwv4YMltBsfn5bfLiDOpgH3AM Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] Publicly verifiable benchmarks X-BeenThere: cfrg@irtf.org 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: Sun, 12 Oct 2014 04:15:45 -0000 On Sat, Oct 11, 2014 at 7:54 PM, Andrey Jivsov wrote: > On 10/10/2014 12:18 AM, D. J. Bernstein wrote: >> >> Parkinson, Sean writes: >>> >>> Making a decision on new elliptic curves based on data that hasn't >>> been corroborated by a 3rd party is bad practice. >> >> >> More than 1500 implementations of various cryptographic functions have >> been contributed to, and are publicly available as part of, the >> state-of-the-art SUPERCOP benchmarking framework: >> >> http://bench.cr.yp.to/supercop.html >> >> Practically all of the implementations are free to use, and many of them >> are in fact widely used. Most of the researchers producing speed records >> for cryptography are contributing their software to the same system. >> >> The eBACS benchmarking project systematically and reproducibly measures >> these implementations on more than 20 different microarchitectures: >> >> http://bench.cr.yp.to/computers.html >> >> It's easy for other people to download and run the benchmarks on their >> favorite CPU, and to contribute the results to the central system, where >> detailed speed reports are posted publicly for other people to see and >> verify. eBACS has practically eliminated the measurement errors and >> disputes that plagued previous approaches to cryptographic benchmarking. >> eBASH, the hash component of eBACS, was mentioned 30 times in NIST's >> final report on the SHA-3 competition. >> >> As a concrete example, now that Mike has sent crypto_dh/ed448goldilocks >> in for benchmarking, eBACS is automatically filling lines into >> >> http://bench.cr.yp.to/results-dh.html >> http://bench.cr.yp.to/impl-dh/ed448goldilocks.html >> >> whenever machines finish benchmark runs: 529066 cycles on titan0, 689020 >> cycles on hydra8, 757676 cycles on h6sandy, etc. These don't exactly >> confirm Mike's comparisons to the Sandy Bridge numbers that Microsoft >> claimed in http://eprint.iacr.org/2014/130.pdf---although they do seem >> adequate to support his point about ed448goldilocks hitting a sweet spot >> on the security/speed curve while Microsoft's design strategy >> compromises the security/speed tradeoff: >> >> * ed448goldilocks isn't quite twice as fast as numsp512t1 >> (ed-512-mers): 757676 cycles vs. 1293000 cycles. >> >> * ed448goldilocks is about 23% slower than numsp384t1 (ed-384-mers): >> 757676 cycles vs. 617000 cycles. >> >> Of course, if Mike or anyone else thinks that ed448goldilocks can be >> computed more efficiently, he's welcome to prove it by contributing a >> better implementation of that function to SUPERCOP, and then the >> benchmarks will be updated appropriately. He can also raise reasonable >> questions about the accuracy of Microsoft's claims; if Microsoft's >> numbers are actually correct then Microsoft can dispel the skepticism >> by contributing their own code to SUPERCOP. >> >> As a more detailed example of reproducibility, let's look at what the >> benchmarks say about X25519 on Haswell. Checking >> >> http://bench.cr.yp.to/results-dh.html >> >> we see a median of 145907 cycles (quartiles: 144894 and 147191 cycles) >> for the crypto_dh/curve25519 software on an Intel Xeon E3-1275 V3. >> Clicking on "titan0" shows more information: the best speeds found for >> crypto_scalarmult/curve25519 on this machine used >> >> gcc-4.8.1 -m64 -O -march=native -mtune=native -fomit-frame-pointer >> >> to compile the "amd64-51" implementation. Anyone can use the same free >> implementation with the same free compiler and will obtain the same >> compiled code running in the same number of Haswell cycles: >> >> wget https://hyperelliptic.org/ebats/supercop-20140924.tar.bz2 >> tar -xf supercop-20140924.tar.bz2 >> cd supercop-20140924 >> # compile and measure everything: nohup sh data-do & >> # alternatively, extract X25519 as follows: >> mkdir x25519 >> cp measure-anything.c x25519 >> cp crypto_scalarmult/measure.c x25519 >> cp crypto_scalarmult/curve25519/amd64-51/* x25519 >> cp include/randombytes.h x25519 >> cp cpucycles/amd64cpuinfo.h x25519/cpucycles.h >> cp cpucycles/amd64cpuinfo.c x25519/cpucycles.c >> cp cpucycles/osfreq.c x25519/osfreq.c >> cd x25519 >> ( sed s/CRYPTO_/crypto_scalarmult_/ < api.h >> echo '#define crypto_scalarmult_IMPLEMENTATION "amd64-51"' >> echo '#define crypto_scalarmult_VERSION "-"' >> ) > crypto_scalarmult.h >> echo 'static const char cpuid[] = {0};' > cpuid.h >> gcc -m64 -O -march=native -mtune=native -fomit-frame-pointer \ >> -D COMPILER='"gcc"' \ >> -D LOOPS=1 \ >> -o measure measure-anything.c measure.c cpucycles.c \ >> mont* fe*.c *.s >> ./measure > > > > Thank you for this information. I added timing code and built the "measure" > program in the x25519 directory (see above) on > > Intel(R) Core(TM) i5-3550 CPU @ 3.30GHz, Ivy Bridge (not Haswell). > > 3 results are in op/sec: > > above x25519 variable base : openssl : curve25519-donna: > > 18167.7 : 11030.5 : 14098.2 > > 18167.7/11030.5 = 65% > > The ./measure reported 182112 cycles for variable base before and after my > changes (which looks correct: 3300000000 Hz/182112=18120 sec). Specifically, > I timed the crypto_scalarmult(). > > I won't have access to my Haswell machine for a few days. > >> >> For example, on one core of Andrey's 3.4GHz i7-4770 (Haswell), this >> X25519 code will take the same ~146000 cycles: i.e., more than 23000 >> operations/second, whereas the latest Haswell-optimized OpenSSL NIST >> P-256 ECDH code that he measured was only 15000 operations/second. >> >> This is, by the way, rather old Curve25519 code optimized for Nehalem, >> the microarchitecture of the first Core i7 CPUs in 2008---but on Intel's >> latest Haswell CPUs it's still solidly beating NIST P-256 code that's >> optimized for Haswell. There's ample literature explaining that >> >> * reductions mod 2^255-19 are faster than reductions mod >> 2^256-2^224+2^192+2^96-1 on a broad range of platforms, and that >> >> * Montgomery scalarmult is faster than Weierstrass scalarmult, >> >> so the performance gap is unsurprising. >> >> Why did Andrey report only 17289 operations/second for X25519 on >> Haswell? The answer, in a nutshell, is that there's an active ecosystem >> of Curve25519/X25519/Ed25519 implementations, and it's easy to find >> implementations that prioritize simplicity over speed---including the >> one implementation included in Andrey's manual benchmarks. Of course, >> any application developer who needs more speed will look for, and find, >> the faster X25519 implementations. >> >> ---Dan > > > It's natural for a developer, the consumer of these open source libraries, > to test-drive the speed tests the way I did. If the sequence of steps needed > to run the tests is clear and short, the results are easily verifiable. > > In case of openssl the results depends on: > * the exact version of the source code > * the exact version of the compiler and assembler tools > * the options given to the config, configure > * CPU > > OpenSSL will autodetect the gcc and build the binary by excluding or > including certain highly-optimized pieces without any relevant reports. Some > beneficial configuration options are not always the defaults. Not > surprisingly, the openssl that comes with the latest OS I test on, Fedora > Core 20, is 3+ times slower than what I report above. > > I find that the quickest way for me to confirm that I am timing the right > code is to use the debugger. For example, I confirmed that ./measure is > spending time in crypto_scalarmult_curve25519_amd64_51_ladderstep in a > hand-written assembler file. Take a look at http://bench.cr.yp.to/impl-scalarmult/curve25519.html. There are multiple hand-written assembly implementations, with differing performance characteristics and portability. In particular AMD and Intel chips favor different implementations. Furthermore, there are multiple ways to compile code by fiddling with options. eBATS handles most of this transparently. Most applications will not need to go to these extremes. But for those that do, customized assembler per processor version and automated compiler tickling is not uncommon. Measurement techniques that don't account for this will not produce realistic results. Asking about minimax (the implementation with the fastest slowest speed) is a reasonable question, or maximal performance from pure C, is reasonable as these are common industrial constraints. But I think there will be very few cases where public key crypto speed is the limiting factor. Sincerely, Watson > > http://bench.cr.yp.to looks like an excellent way to try code on platforms > one doesn't own. > > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Sun Oct 12 08:00:54 2014 Return-Path: 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 52E291A1B34 for ; Sun, 12 Oct 2014 08:00:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 NtSGczDNxGt3 for ; Sun, 12 Oct 2014 08:00:51 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5ACB91A1B1D for ; Sun, 12 Oct 2014 08:00:50 -0700 (PDT) Received: by mail-wi0-f177.google.com with SMTP id fb4so5547279wid.16 for ; Sun, 12 Oct 2014 08:00:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=N701ry9hnvDzupeTcGtWuW+FJ4OLKJ3sf4aNjIjt9h8=; b=sN7VoS+5UQl/tp/eBlnIWYBi7iNMROS8oFHA1DM5NJOSwFniYefNKifMSWKnvfGIH6 /PzwdrTaoFbGx+Fv+EhnhIlvEopZkG+E44qkCQhBr8T5ty0q6Z8ZQoNPBehi83RNK3cG P5G46xhb75ZrHgAmFjltcDw3tSxmLhPrXMbB7EqB7T0Kjls1XMETrixSXMkatmk+Y6FA Iu86uJeCpeeeXkEqJGlMsuISKiQ9rPEVhVuz4qjKOu7lmXZ2F958BPJD5vR6Zp7QSRR+ oHHFRe0aGi3EXGXC0l5+p3I4Yirca3zRMS7gwV11avGWktQHtWTMwpjwWZjP7PsKHfBd s+pQ== X-Received: by 10.180.10.38 with SMTP id f6mr15075605wib.30.1413126048805; Sun, 12 Oct 2014 08:00:48 -0700 (PDT) Received: from [172.24.248.64] (dyn32-131.checkpoint.com. [194.29.32.131]) by mx.google.com with ESMTPSA id fv2sm8209699wib.2.2014.10.12.08.00.47 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 12 Oct 2014 08:00:48 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: text/plain; charset=windows-1252 From: Yoav Nir X-Priority: 3 (Normal) In-Reply-To: Date: Sun, 12 Oct 2014 18:00:45 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <59B73C9D-3292-4253-A7B0-2E1ABC73FF67@gmail.com> References: <542D48CD.9060404@isode.com> <9a348a00f974bffba1c3785464cd2032.squirrel@www.trepanning.net> <1CFF7FC2-DDC9-46AF-B574-4126379232DB@gmail.com> To: Dan Harkins X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/aQl2cJwPCBkuWRsQCzq6yVAnyUs Cc: Adam Langley , "cfrg@irtf.org" Subject: Re: [Cfrg] RGLC on draft-irtf-cfrg-chacha20-poly1305-01.txt X-BeenThere: cfrg@irtf.org 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: Sun, 12 Oct 2014 15:00:53 -0000 On Oct 7, 2014, at 1:35 AM, Dan Harkins wrote: >=20 >=20 > On Mon, October 6, 2014 2:53 pm, Adam Langley wrote: >> On Mon, Oct 6, 2014 at 2:50 PM, Yoav Nir wrote: >>> I=E2=80=99m not quite sure I follow. The construction uses a 96-bit = nonce >>> precisely >>> so that we comply with RFC 5116. What requirement of 5116 are we not >>> fitting >>> into? >>=20 >> I think Dan is just saying that the limits need to be specified. For >> example see page 8 in >> = https://tools.ietf.org/html/draft-agl-tls-chacha20poly1305-04#section-5 >> (although these values are wrong now). >=20 > I'm sorry, I meant the formation of the AAD. Is it a single blob that > gets passed to the algorithm? Does the mode allow for multiple = distinct > AAD inputs ala RFC 5297? What if the protocol I want to use with this > mode has several distinct blobs I want to use as AAD (like how IEEE = Std > 802.11 uses AAD with AEAD cipher modes-- take these bits and then > concatenate these addresses, etc)? I suspect it's all just a single > concatenated blob but it would help to say so explicitly and to define > the RFC 5116 interface. Oh, I see. OK. Our construction does not make any particular provisions = for multiple blobs of AAD. Of course the application is free to create = such a structure by making it a series of TV or TLV, or if they really = want to be fancy, a BER-encoded SEQUENCE (please don=92t), but the code = for ChaCha20-Poly1305 does not recognize such a structure. > It obviously takes AAD since section 2.8 mentions it as something to > include as input to AEAD_CHACHA20-POLY1305. So I'm suggesting you > define what AAD looks like when it is delivered to the mode: "Distinct > AAD shall be concatenated into a single input to > AEAD_CHACHA20-POLY1305", for example. OK. I=92ll add a sentence like that. Thanks, Yoav From nobody Sun Oct 12 10:23:06 2014 Return-Path: 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 A86551A6F71 for ; Sun, 12 Oct 2014 10:23:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no 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 hoHac12Tawsf for ; Sun, 12 Oct 2014 10:23:00 -0700 (PDT) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45E531A6F34 for ; Sun, 12 Oct 2014 10:23:00 -0700 (PDT) Received: by mail-lb0-f179.google.com with SMTP id l4so5382553lbv.24 for ; Sun, 12 Oct 2014 10:22:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=2wwNcOkdPKS1sc9ZbRqXyGSLe7Hy5+2yPqeechl31Lo=; b=vEzxcKcDRLZ/QQjEMVU8CBffdEd/xG4OqO7+bwIZg9fP84pf6oI6OkCxh8TjrztAq+ aif/rP9t9JuQv0C1Y7x/EcmDjGSOzYj+q5OtFD1e5++GBYN5yy87oUST6+byWCrRBNp5 oEAR+TvLCMZQ0Ll3eCOOue7hD1MHQuxpqZUtHyu7D7wmQ6XSY/dZA5MrhKyhvsvrJ1BW aOddDn14LiNW3oNijzM3gGWwxbUrGKNdRXgwO0VH1EDwo+w9QYYDolTADQu0+XwKrHR6 ttPEXdKfQ8Un0MNynmKl+98Ug2OzjQ6PXg5IirobMTIch8VO2UFFYvJbiF8ZVA8lr0Qq PklQ== MIME-Version: 1.0 X-Received: by 10.112.17.132 with SMTP id o4mr18617359lbd.52.1413134578533; Sun, 12 Oct 2014 10:22:58 -0700 (PDT) Sender: alangley@gmail.com Received: by 10.112.241.103 with HTTP; Sun, 12 Oct 2014 10:22:58 -0700 (PDT) In-Reply-To: <59B73C9D-3292-4253-A7B0-2E1ABC73FF67@gmail.com> References: <542D48CD.9060404@isode.com> <9a348a00f974bffba1c3785464cd2032.squirrel@www.trepanning.net> <1CFF7FC2-DDC9-46AF-B574-4126379232DB@gmail.com> <59B73C9D-3292-4253-A7B0-2E1ABC73FF67@gmail.com> Date: Sun, 12 Oct 2014 10:22:58 -0700 X-Google-Sender-Auth: 4_iA-NakB1QajeMlRCkO2cwzTAc Message-ID: From: Adam Langley To: Yoav Nir Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/ArYBzF678Sw0uAqSAphPD7lzLys Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] RGLC on draft-irtf-cfrg-chacha20-poly1305-01.txt X-BeenThere: cfrg@irtf.org 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: Sun, 12 Oct 2014 17:23:01 -0000 On Sun, Oct 12, 2014 at 8:00 AM, Yoav Nir wrote: >> It obviously takes AAD since section 2.8 mentions it as something to >> include as input to AEAD_CHACHA20-POLY1305. So I'm suggesting you >> define what AAD looks like when it is delivered to the mode: "Distinct >> AAD shall be concatenated into a single input to >> AEAD_CHACHA20-POLY1305", for example. > > OK. I=E2=80=99ll add a sentence like that. Note that concatenating distinct AD inputs is not safe: ["a", "bc"] is then ambiguous with ["ab", "c"]. Applications are free to use any scheme they want, but concatenation shouldn't be implicitly endorsed. Cheers AGL --=20 Adam Langley agl@imperialviolet.org https://www.imperialviolet.org From nobody Sun Oct 12 12:16:36 2014 Return-Path: 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 4580B1A70E2 for ; Sun, 12 Oct 2014 12:16:33 -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 tKoN_WRcsIkC for ; Sun, 12 Oct 2014 12:16:31 -0700 (PDT) Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6BDD1A7011 for ; Sun, 12 Oct 2014 12:16:30 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id y10so7189012wgg.3 for ; Sun, 12 Oct 2014 12:16:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:mime-version:to:cc:from:subject:date:in-reply-to :references:content-type; bh=FDa4+ff0iHfwh6nEWkoKZceqgZNUfui5B0iICn7w/eA=; b=ML8yrh5EieWr9bewV1+41Q3OLqRrwmX1GAIgG+o6SVWXRR4vwRvJtP4s4NOp6VUCp+ OGAxiaFoQQdc1Ve4TmdlKaKc+xcj4J1QM/QLfDQCJPYYg1x49b4JWPl3fc0IgKuoMFMT Ud9OMzcy66VDGLH/wlk3u0UZjDy0dGKjWyOv14VF+kIAxMjZf5ETcy2ahrQOV6n7T73u w/qanAruSF4kypr9mgLfVwP8OVujB7astjF0YEf41VW6dUtRfePZ0ATF7EzZt2iRD86j 1mvzZU7bH24A4Gn3xu3B4Ye1PAkneO4fenmhdAMX5zNimBhulp7HBRNWQgwGCPJGhLtm +jPg== X-Received: by 10.180.79.41 with SMTP id g9mr15682863wix.75.1413141389480; Sun, 12 Oct 2014 12:16:29 -0700 (PDT) Received: from [192.168.1.101] (IGLD-84-228-192-190.inter.net.il. [84.228.192.190]) by mx.google.com with ESMTPSA id ce1sm14222639wjc.2.2014.10.12.12.16.27 for (version=SSLv3 cipher=RC4-SHA bits=128/128); Sun, 12 Oct 2014 12:16:28 -0700 (PDT) Message-ID: <543ad38c.01b0c20a.3337.1f8c@mx.google.com> MIME-Version: 1.0 To: Adam Langley From: Yoav Nir Date: Sun, 12 Oct 2014 22:16:10 +0300 In-Reply-To: References: <542D48CD.9060404@isode.com> <9a348a00f974bffba1c3785464cd2032.squirrel@www.trepanning.net> <1CFF7FC2-DDC9-46AF-B574-4126379232DB@gmail.com> <59B73C9D-3292-4253-A7B0-2E1ABC73FF67@gmail.com> Content-Type: multipart/alternative; boundary="_03B93A47-7E0E-492A-9DA3-6C761A02407F_" Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/7S_ZfUl0rDYxd66FM_Vps7q0b-Y Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] RGLC on draft-irtf-cfrg-chacha20-poly1305-01.txt X-BeenThere: cfrg@irtf.org 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: Sun, 12 Oct 2014 19:16:33 -0000 --_03B93A47-7E0E-492A-9DA3-6C761A02407F_ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Yes, and section 3.3 of RFC 5116 says so, so I can just point at that. Yoav -----Original Message----- From: "Adam Langley" Sent: =E2=80=8E10/=E2=80=8E12/=E2=80=8E2014 20:22 To: "Yoav Nir" Cc: "Dan Harkins" ; "cfrg@irtf.org" Subject: Re: [Cfrg] RGLC on draft-irtf-cfrg-chacha20-poly1305-01.txt On Sun, Oct 12, 2014 at 8:00 AM, Yoav Nir wrote: >> It obviously takes AAD since section 2.8 mentions it as something to >> include as input to AEAD_CHACHA20-POLY1305. So I'm suggesting you >> define what AAD looks like when it is delivered to the mode: "Distinct >> AAD shall be concatenated into a single input to >> AEAD_CHACHA20-POLY1305", for example. > > OK. I=E2=80=99ll add a sentence like that. Note that concatenating distinct AD inputs is not safe: ["a", "bc"] is then ambiguous with ["ab", "c"]. Applications are free to use any scheme they want, but concatenation shouldn't be implicitly endorsed. Cheers AGL --=20 Adam Langley agl@imperialviolet.org https://www.imperialviolet.org --_03B93A47-7E0E-492A-9DA3-6C761A02407F_ Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"
Yes, and section 3.3 of RFC 5116 says so, so I can just p= oint at that.

Yoav
From: <= /span>Adam Langley
Sent: =E2=80=8E10/=E2=80=8E12/=E2=80=8E2014 20:22
To: Yoav Nir
Cc: Dan Harkins; cfrg@irtf.org
Subject: Re: [Cfrg] RGLC on d= raft-irtf-cfrg-chacha20-poly1305-01.txt

On Sun, Oct 12,= 2014 at 8:00 AM, Yoav Nir <ynir.ietf@gmail.com> wrote:
>>&n= bsp; It obviously takes AAD since section 2.8 mentions it as something to>> include as input to AEAD_CHACHA20-POLY1305. So I'm suggesting yo= u
>> define what AAD looks like when it is delivered to the mode: = "Distinct
>> AAD shall be concatenated into a single input to
&= gt;> AEAD_CHACHA20-POLY1305", for example.
>
> OK. I=E2=80= =99ll add a sentence like that.

Note that concatenating distinct AD = inputs is not safe: ["a", "bc"] is
then ambiguous with ["ab", "c"]. Appl= ications are free to use any
scheme they want, but concatenation shouldn= 't be implicitly endorsed.


Cheers

AGL

--
Adam = Langley agl@imperialviolet.org https://www.imperialviolet.org
= --_03B93A47-7E0E-492A-9DA3-6C761A02407F_-- From nobody Sun Oct 12 15:50:36 2014 Return-Path: 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 BD3BE1A9125 for ; Sun, 12 Oct 2014 15:50:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_MED=-2.3, 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 z3lv2GXZ2EKi for ; Sun, 12 Oct 2014 15:50:30 -0700 (PDT) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 508081A9128 for ; Sun, 12 Oct 2014 15:50:30 -0700 (PDT) Received: from maildlpprd54.lss.emc.com (maildlpprd54.lss.emc.com [10.106.48.158]) by mailuogwprd54.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s9CMoRbI017656 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 12 Oct 2014 18:50:27 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com s9CMoRbI017656 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=rsa.com; s=jan2013; t=1413154228; bh=PQNN/f7XWfd7Ikm1WDofCSo1pyY=; h=From:To:CC:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=mWpXiFx0iFyc2Gchhl9jzwhmu0iNp3kqHR1KW1I6QwNsQBJNhoVraX1MBaiAu11bI eXHo4f2IBCQEr7vFp8OYc29O9347SWDBmx7wD+eaPlxs3VDdeZJSNwf1F+i10BM1/k 4mS/dQCzflD+aa2rw8JDt1CuuWD8ZnAKNPuzRDVs= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com s9CMoRbI017656 Received: from mailusrhubprd01.lss.emc.com (mailusrhubprd01.lss.emc.com [10.253.24.19]) by maildlpprd54.lss.emc.com (RSA Interceptor); Sun, 12 Oct 2014 18:49:58 -0400 Received: from mxhub24.corp.emc.com (mxhub24.corp.emc.com [128.222.70.136]) by mailusrhubprd01.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s9CMo7Lc030213 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 12 Oct 2014 18:50:08 -0400 Received: from mx17a.corp.emc.com ([169.254.1.210]) by mxhub24.corp.emc.com ([128.222.70.136]) with mapi; Sun, 12 Oct 2014 18:50:07 -0400 From: "Parkinson, Sean" To: Yoav Nir Date: Sun, 12 Oct 2014 18:50:04 -0400 Thread-Topic: Feedback on: draft-irtf-cfrg-chacha20-poly1305-01 Thread-Index: Ac/mLayTjrBjTuD2QyiFE9j68lZxywAP8kRw Message-ID: <2FBC676C3BBFBB4AA82945763B361DE60A76B074@MX17A.corp.emc.com> References: <2FBC676C3BBFBB4AA82945763B361DE608F1CF62@MX17A.corp.emc.com> <07860BA8-4940-4C00-8248-AE08D7A991CA@gmail.com> In-Reply-To: <07860BA8-4940-4C00-8248-AE08D7A991CA@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_2FBC676C3BBFBB4AA82945763B361DE60A76B074MX17Acorpemccom_" MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd01.lss.emc.com X-RSA-Classifications: public Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/R946-ase50UZmvypgkdjb3xeAek Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] Feedback on: draft-irtf-cfrg-chacha20-poly1305-01 X-BeenThere: cfrg@irtf.org 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: Sun, 12 Oct 2014 22:50:34 -0000 --_000_2FBC676C3BBFBB4AA82945763B361DE60A76B074MX17Acorpemccom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Yoav, I was intrigued by the idea of using these algorithms and thought I would h= ave a go at implementing them based on the draft. Here are some comments I have that could help clarify the descriptions for = implementers. First of all I would like to say that I was able to quickly implement the a= lgorithms so I think all of the details are there. What I'm going to sugges= t are things that will make it a simpler for an implementer to pick out wh= at they need to do and make it easier to verify the implementation. 1. The ChaCha quarter round description (2.1) is not really C co= de. It is a mathematical description. The steps are ordered and therefore s= hould be numbered. The worked example is good for clarity and should use va= lues that show up edge cases: b=3D0xffeeddcc, a=3D0x77777777. Rotate by 7 r= ather than 16 and it is clearer that you have rotated the correct direction= . 2. In the worked example in 2.2.1 it might be helpful to highlig= ht the modified values using, say, a bold font if possible. 3. In section 2.3, the state and the block are mixed in together= . How about separating the 'inner block' (where the quarter rounds are perf= ormed) out into its own section? 4. In section 2.3, putting the adding of the original input word= s into an algorithm description would help implementers 'tick-off' that the= y have got all the parts done. Something like: chacha20_block(key, counter, nonce): state =3D key | counter | nonce working_state =3D state for i=3D1 upto 10 inner_block(working_state) state +=3D working_state serialize(state) 5. In section 2.3, saying there are 20 rounds but combining the = two rounds into one step is confusing. Saying there are 10 rounds of the fo= llowing 8 steps explicitly could remove the confusion. 6. In section 2.3, the whole endian thing is very confusing. Tha= nkfully the worked example makes this clear. 7. In section 2.4, an algorithmic representation of the block co= unter incrementing would be helpful. Something like: chacha20_encrypt(key, counter, nonce, plaintext): for counter=3D1 upto ceil(length of plaintext in bytes / 64) key_stream =3D chacha20_block(key, counter, nonce) encrypted_message +=3D plaintext[((counter-1)*64)..(counter*64-1)] ^ k= ey_stream 8. In section 2.4, say that a key-stream block can be XOR-ed wit= h a plaintext block before proceeding. Implementation detail should, I thin= k, be kept for a later section. 9. In section 2.4, a minor quibble but, copying the plaintext an= d ciphertext into test code is a little difficult. 10. In section 2.5, a proper algorithmic description would be nice= . Something like: clamp(r): r &=3D 0x0fffff0c0ffffffc0ffffffcffffffff poly1305_mac(msg, tag, key): r =3D clamp(le_bytes_to_num(tag)) s =3D le_num(key) accumulator =3D 0 p =3D (1<<130)-5 for i=3D1 upto ceil(msg length in bytes / 16) n =3D le_bytes_to_num([0x01] | msg[((i-1)*16)..(i*16)]) a +=3D n a =3D (r * a) % p a +=3D s num_to_16_le_bytes(a) 11. In section 2.6, an algorithmic description would be good too: poly1305_key_gen(key, iv, constant): counter =3D 0 chacha20_block(key, counter, constant | iv)[0..31] 12. In section 2.8 there is a lot of text and an algorithmic descr= iption would be better. Something like: chacha20_aead_encrypt(aad, key, iv, constant, plaintext): k =3D poly1305_key_gen(key, iv, constant) ciphertext =3D chacha_encrypt(key, 1, constant | iv, plaintext) mac_data =3D aad | [0]*((16 - (aad.length & 15)) & 15) mac_data |=3D ciphertext | [0]*((16 - (ciphertext.length & 15)) & 15) mac_data |=3D num_to_4_le_bytes(aad.length) mac_data |=3D num_to_4_le_bytes(ciphertext.length) tag =3D poly1305_mac(mac_data, k[0..15], k[16..31]) (ciphertext, tag) Hope this is helpful, Sean -- Sean Parkinson | Consultant Software Engineer | RSA, The Security Division = of EMC Office +61 7 3032 5232 | Fax +61 7 3032 5299 www.rsa.com --_000_2FBC676C3BBFBB4AA82945763B361DE60A76B074MX17Acorpemccom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Yoav,

 

I was intrig= ued by the idea of using these algorithms and thought I would have a go at = implementing them based on the draft.

He= re are some comments I have that could help clarify the descriptions for im= plementers.

 

=

First of all I would like to say that I was able to quickly i= mplement the algorithms so I think all of the details are there. What IR= 17;m going to suggest are things  that will make it a simpler for an i= mplementer to pick out what they need to do and make it easier to verify th= e implementation.

1.   &n= bsp;        The ChaCha quarter round des= cription (2.1) is not really C code. It is a mathematical description. The = steps are ordered and therefore should be numbered. The worked example is g= ood for clarity and should use values that show up edge cases: b=3D0xffeedd= cc, a=3D0x77777777. Rotate by 7 rather than 16 and it is clearer that you h= ave rotated the correct direction.

2.&nb= sp;           In the work= ed example in 2.2.1 it might be helpful to highlight the modified values us= ing, say, a bold font if possible.

3.&nb= sp;           In section = 2.3, the state and the block are mixed in together. How about separating th= e ‘inner block’ (where the quarter rounds are performed) out in= to its own section?

4.  &nbs= p;         In section 2.3, putting = the adding of the original input words into an algorithm description would = help implementers ‘tick-off’ that they have got all the parts d= one. Something like:

chacha20_block(key, counter, nonce):

state =3D key | counter | nonce

working_state =3D state

=

for i=3D1 upto 10

     inner_block(workin= g_state)

state +=3D = working_state

serial= ize(state)

5.    &nb= sp;       In section 2.3, saying there are 20= rounds but combining the two rounds into one step is confusing. Saying the= re are 10 rounds of the following 8 steps explicitly could remove the confu= sion.

6.     &n= bsp;      In section 2.3, the whole endian thing i= s very confusing. Thankfully the worked example makes this clear.

7.        = ;    In section 2.4, an algorithmic representation of the bl= ock counter incrementing would be helpful. Something like:

chacha20_encrypt(key, counter, nonce= , plaintext):

for co= unter=3D1 upto ceil(length of plaintext in bytes / 64)

     key_stream =3D = chacha20_block(key, counter, nonce)

     encrypted_message +=3D plaintext[(= (counter-1)*64)..(counter*64-1)] ^ key_stream

8.            = In section 2.4, say that a key-stream block can be XOR-ed with a plaintext = block before proceeding. Implementation detail should, I think, be kept for= a later section.

9.   &n= bsp;        In section 2.4, a minor quib= ble but, copying the plaintext and ciphertext into test code is a little di= fficult.

10.    &nbs= p;     In section 2.5, a proper algorithmic description= would be nice. Something like:

clamp(r): r &=3D 0x0fffff0c0ffffffc0ffffffcffffffff<= span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'>

poly1305_mac(msg, tag, key)= :

r =3D clamp(le_byt= es_to_num(tag))

s = =3D le_num(key)

accu= mulator =3D 0

p =3D = (1<<130)-5

for= i=3D1 upto ceil(msg length in bytes / 16)

     n =3D le_bytes_to_num([0x01= ] | msg[((i-1)*16)..(i*16)])

     a +=3D n

     a =3D (r * a) % p

a +=3D s=

num_to_16_le_bytes(a)

11.        &nbs= p; In section 2.6, an algorithmic description would be good too:=

poly1305_key_gen(key, iv, cons= tant):

counter =3D 0= =

chacha20_block(key,= counter, constant | iv)[0..31]

<= span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'>12. = ;         In section 2.8 there is a= lot of text and an algorithmic description would be better. Something like= :

chacha20_aead_encr= ypt(aad, key, iv, constant, plaintext):

k =3D poly1305_key_gen(key, iv, constant)

ciphertext =3D chacha_encrypt(key= , 1, constant | iv, plaintext)

mac_data =3D aad | [0]*((16 – (aad.length & 15)) &= 15)

mac_data |=3D c= iphertext | [0]*((16 – (ciphertext.length & 15)) & 15)=

mac_data |=3D num_to_4_le_= bytes(aad.length)

ma= c_data |=3D num_to_4_le_bytes(ciphertext.length)

tag =3D poly1305_mac(mac_data, k[0..15], k[16.= .31])

(ciphertext, t= ag)

 

Hope this is helpful,

Sean

--

Sean Parkinson | Consultant Software Engineer | RSA, The Security Divisi= on of EMC

Office +61 7 3032 5232 | Fax += 61 7 3032 5299

www.rsa.com

&n= bsp;

= --_000_2FBC676C3BBFBB4AA82945763B361DE60A76B074MX17Acorpemccom_-- From nobody Sun Oct 12 15:58:55 2014 Return-Path: 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 CC9041A9125 for ; Sun, 12 Oct 2014 15:58:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.001 X-Spam-Level: X-Spam-Status: No, score=-1.001 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-2.3, 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 sWZsYZO7-A0F for ; Sun, 12 Oct 2014 15:58:43 -0700 (PDT) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B3FC1A87A4 for ; Sun, 12 Oct 2014 15:58:43 -0700 (PDT) Received: from maildlpprd56.lss.emc.com (maildlpprd56.lss.emc.com [10.106.48.160]) by mailuogwprd53.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s9CMwV0d007117 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 12 Oct 2014 18:58:32 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com s9CMwV0d007117 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=rsa.com; s=jan2013; t=1413154712; bh=sOZnHw5X8TrG50iI62e0IM9Esfs=; h=From:To:CC:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=Msxj+xqAXlO1RrUk8LIORMYLR9hnKqMlFQJpRqTdUK4dYzsNQQqzvF8qb/tK26ol3 jSvCqchlJ7QhtMPwD2p/PcgcX/uWm19T9MwcIRoJ0Kr8hlGWbbnReoF9yGgRbXUEfm ejSfg0vfVTYtvd8+ZHypu8zi7f5TTLv0gc5yguGk= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com s9CMwV0d007117 Received: from mailusrhubprd02.lss.emc.com (mailusrhubprd02.lss.emc.com [10.253.24.20]) by maildlpprd56.lss.emc.com (RSA Interceptor); Sun, 12 Oct 2014 18:57:50 -0400 Received: from mxhub03.corp.emc.com (mxhub03.corp.emc.com [10.254.141.105]) by mailusrhubprd02.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s9CMw9Vb013931 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 12 Oct 2014 18:58:10 -0400 Received: from mx17a.corp.emc.com ([169.254.1.210]) by mxhub03.corp.emc.com ([10.254.141.105]) with mapi; Sun, 12 Oct 2014 18:58:08 -0400 From: "Parkinson, Sean" To: "djb@cr.yp.to" Date: Sun, 12 Oct 2014 18:58:07 -0400 Thread-Topic: [Cfrg] Publicly verifiable benchmarks Thread-Index: Ac/l01yrAL/KVl2rTruiGBepwBK1qgAnE5+A Message-ID: <2FBC676C3BBFBB4AA82945763B361DE60A76B077@MX17A.corp.emc.com> References: <20141010071847.9478.qmail@cr.yp.to> <5439ED77.3010701@brainhub.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd02.lss.emc.com X-RSA-Classifications: Source Code, DLM_1, public Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/xoGKG6T8HUXgLB4Tyfi6OguQRbs Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] Publicly verifiable benchmarks X-BeenThere: cfrg@irtf.org 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: Sun, 12 Oct 2014 22:58:52 -0000 Is there a REST API to the benchmark data? Sean -- Sean Parkinson | Consultant Software Engineer | RSA, The Security Division= =A0of EMC Office +61 7 3032 5232 | Fax +61 7 3032 5299 www.rsa.com -----Original Message----- From: Cfrg [mailto:cfrg-bounces@irtf.org] On Behalf Of Watson Ladd Sent: Sunday, 12 October 2014 2:16 PM To: Andrey Jivsov Cc: cfrg@irtf.org Subject: Re: [Cfrg] Publicly verifiable benchmarks On Sat, Oct 11, 2014 at 7:54 PM, Andrey Jivsov wrote: > On 10/10/2014 12:18 AM, D. J. Bernstein wrote: >> >> Parkinson, Sean writes: >>> >>> Making a decision on new elliptic curves based on data that hasn't=20 >>> been corroborated by a 3rd party is bad practice. >> >> >> More than 1500 implementations of various cryptographic functions=20 >> have been contributed to, and are publicly available as part of, the=20 >> state-of-the-art SUPERCOP benchmarking framework: >> >> http://bench.cr.yp.to/supercop.html >> >> Practically all of the implementations are free to use, and many of=20 >> them are in fact widely used. Most of the researchers producing speed=20 >> records for cryptography are contributing their software to the same sys= tem. >> >> The eBACS benchmarking project systematically and reproducibly=20 >> measures these implementations on more than 20 different microarchitectu= res: >> >> http://bench.cr.yp.to/computers.html >> >> It's easy for other people to download and run the benchmarks on=20 >> their favorite CPU, and to contribute the results to the central=20 >> system, where detailed speed reports are posted publicly for other=20 >> people to see and verify. eBACS has practically eliminated the=20 >> measurement errors and disputes that plagued previous approaches to cryp= tographic benchmarking. >> eBASH, the hash component of eBACS, was mentioned 30 times in NIST's=20 >> final report on the SHA-3 competition. >> >> As a concrete example, now that Mike has sent=20 >> crypto_dh/ed448goldilocks in for benchmarking, eBACS is automatically=20 >> filling lines into >> >> http://bench.cr.yp.to/results-dh.html >> http://bench.cr.yp.to/impl-dh/ed448goldilocks.html >> >> whenever machines finish benchmark runs: 529066 cycles on titan0,=20 >> 689020 cycles on hydra8, 757676 cycles on h6sandy, etc. These don't=20 >> exactly confirm Mike's comparisons to the Sandy Bridge numbers that=20 >> Microsoft claimed in http://eprint.iacr.org/2014/130.pdf---although=20 >> they do seem adequate to support his point about ed448goldilocks=20 >> hitting a sweet spot on the security/speed curve while Microsoft's=20 >> design strategy compromises the security/speed tradeoff: >> >> * ed448goldilocks isn't quite twice as fast as numsp512t1 >> (ed-512-mers): 757676 cycles vs. 1293000 cycles. >> >> * ed448goldilocks is about 23% slower than numsp384t1 (ed-384-mers): >> 757676 cycles vs. 617000 cycles. >> >> Of course, if Mike or anyone else thinks that ed448goldilocks can be=20 >> computed more efficiently, he's welcome to prove it by contributing a=20 >> better implementation of that function to SUPERCOP, and then the=20 >> benchmarks will be updated appropriately. He can also raise=20 >> reasonable questions about the accuracy of Microsoft's claims; if=20 >> Microsoft's numbers are actually correct then Microsoft can dispel=20 >> the skepticism by contributing their own code to SUPERCOP. >> >> As a more detailed example of reproducibility, let's look at what the=20 >> benchmarks say about X25519 on Haswell. Checking >> >> http://bench.cr.yp.to/results-dh.html >> >> we see a median of 145907 cycles (quartiles: 144894 and 147191=20 >> cycles) for the crypto_dh/curve25519 software on an Intel Xeon E3-1275 V= 3. >> Clicking on "titan0" shows more information: the best speeds found=20 >> for >> crypto_scalarmult/curve25519 on this machine used >> >> gcc-4.8.1 -m64 -O -march=3Dnative -mtune=3Dnative=20 >> -fomit-frame-pointer >> >> to compile the "amd64-51" implementation. Anyone can use the same=20 >> free implementation with the same free compiler and will obtain the=20 >> same compiled code running in the same number of Haswell cycles: >> >> wget https://hyperelliptic.org/ebats/supercop-20140924.tar.bz2 >> tar -xf supercop-20140924.tar.bz2 >> cd supercop-20140924 >> # compile and measure everything: nohup sh data-do & >> # alternatively, extract X25519 as follows: >> mkdir x25519 >> cp measure-anything.c x25519 >> cp crypto_scalarmult/measure.c x25519 >> cp crypto_scalarmult/curve25519/amd64-51/* x25519 >> cp include/randombytes.h x25519 >> cp cpucycles/amd64cpuinfo.h x25519/cpucycles.h >> cp cpucycles/amd64cpuinfo.c x25519/cpucycles.c >> cp cpucycles/osfreq.c x25519/osfreq.c >> cd x25519 >> ( sed s/CRYPTO_/crypto_scalarmult_/ < api.h >> echo '#define crypto_scalarmult_IMPLEMENTATION "amd64-51"' >> echo '#define crypto_scalarmult_VERSION "-"' >> ) > crypto_scalarmult.h >> echo 'static const char cpuid[] =3D {0};' > cpuid.h >> gcc -m64 -O -march=3Dnative -mtune=3Dnative -fomit-frame-pointer \ >> -D COMPILER=3D'"gcc"' \ >> -D LOOPS=3D1 \ >> -o measure measure-anything.c measure.c cpucycles.c \ >> mont* fe*.c *.s >> ./measure > > > > Thank you for this information. I added timing code and built the "measur= e" > program in the x25519 directory (see above) on > > Intel(R) Core(TM) i5-3550 CPU @ 3.30GHz, Ivy Bridge (not Haswell). > > 3 results are in op/sec: > > above x25519 variable base : openssl : curve25519-donna: > > 18167.7 : 11030.5 : 14098.2 > > 18167.7/11030.5 =3D 65% > > The ./measure reported 182112 cycles for variable base before and=20 > after my changes (which looks correct: 3300000000 Hz/182112=3D18120=20 > sec). Specifically, I timed the crypto_scalarmult(). > > I won't have access to my Haswell machine for a few days. > >> >> For example, on one core of Andrey's 3.4GHz i7-4770 (Haswell), this >> X25519 code will take the same ~146000 cycles: i.e., more than 23000=20 >> operations/second, whereas the latest Haswell-optimized OpenSSL NIST >> P-256 ECDH code that he measured was only 15000 operations/second. >> >> This is, by the way, rather old Curve25519 code optimized for=20 >> Nehalem, the microarchitecture of the first Core i7 CPUs in=20 >> 2008---but on Intel's latest Haswell CPUs it's still solidly beating=20 >> NIST P-256 code that's optimized for Haswell. There's ample=20 >> literature explaining that >> >> * reductions mod 2^255-19 are faster than reductions mod >> 2^256-2^224+2^192+2^96-1 on a broad range of platforms, and=20 >> that >> >> * Montgomery scalarmult is faster than Weierstrass scalarmult, >> >> so the performance gap is unsurprising. >> >> Why did Andrey report only 17289 operations/second for X25519 on=20 >> Haswell? The answer, in a nutshell, is that there's an active=20 >> ecosystem of Curve25519/X25519/Ed25519 implementations, and it's easy=20 >> to find implementations that prioritize simplicity over=20 >> speed---including the one implementation included in Andrey's manual=20 >> benchmarks. Of course, any application developer who needs more speed=20 >> will look for, and find, the faster X25519 implementations. >> >> ---Dan > > > It's natural for a developer, the consumer of these open source=20 > libraries, to test-drive the speed tests the way I did. If the=20 > sequence of steps needed to run the tests is clear and short, the results= are easily verifiable. > > In case of openssl the results depends on: > * the exact version of the source code > * the exact version of the compiler and assembler tools > * the options given to the config, configure > * CPU > > OpenSSL will autodetect the gcc and build the binary by excluding or=20 > including certain highly-optimized pieces without any relevant=20 > reports. Some beneficial configuration options are not always the=20 > defaults. Not surprisingly, the openssl that comes with the latest OS=20 > I test on, Fedora Core 20, is 3+ times slower than what I report above. > > I find that the quickest way for me to confirm that I am timing the=20 > right code is to use the debugger. For example, I confirmed that=20 > ./measure is spending time in=20 > crypto_scalarmult_curve25519_amd64_51_ladderstep in a hand-written assemb= ler file. Take a look at http://bench.cr.yp.to/impl-scalarmult/curve25519.html. There are multiple hand-written assembly implementations, with differing pe= rformance characteristics and portability. In particular AMD and Intel chip= s favor different implementations. Furthermore, there are multiple ways to = compile code by fiddling with options. eBATS handles most of this transparently. Most applications will not need to go to these extremes. But for those that= do, customized assembler per processor version and automated compiler tick= ling is not uncommon. Measurement techniques that don't account for this wi= ll not produce realistic results. Asking about minimax (the implementation = with the fastest slowest speed) is a reasonable question, or maximal perfor= mance from pure C, is reasonable as these are common industrial constraints= . But I think there will be very few cases where public key crypto speed is= the limiting factor. Sincerely, Watson > > http://bench.cr.yp.to looks like an excellent way to try code on=20 > platforms one doesn't own. > > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg -- "Those who would give up Essential Liberty to purchase a little Temporary S= afety deserve neither Liberty nor Safety." -- Benjamin Franklin _______________________________________________ Cfrg mailing list Cfrg@irtf.org http://www.irtf.org/mailman/listinfo/cfrg From nobody Mon Oct 13 04:32:30 2014 Return-Path: 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 85BAE1A212A for ; Mon, 13 Oct 2014 04:32:29 -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 Oe3eNpIn-iof for ; Mon, 13 Oct 2014 04:32:27 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 218571A3B9C for ; Mon, 13 Oct 2014 04:32:26 -0700 (PDT) Received: by mail-wi0-f177.google.com with SMTP id fb4so7128497wid.16 for ; Mon, 13 Oct 2014 04:32:25 -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=XGbFoFmXVGLFts7OxRiXB74ryAVkrKQiPqETNhfOvRo=; b=0G+RsDEoymT9EXjDDuQfC/AhiBOg0NCKS/X6MU4Wrj/MUOq9j7+z/FlDq7Fp/sEDnF MC3bYPEoZqLSPJvcjJ++WGjLHwY4CPxEUpq9gMt3R5NBZRK6rPSSAXUlWxcm74bDDkC5 jsIAzZtuKldpn+N8Z+7Cyu5vfyd13j1jld9K4BqWLSstjixor/UAsEX/nFFWaq9G3352 V3QH9jiAdzdbbij7oz02oAHOA6BkzWa0TF1QquxtBM8uLUFl453du64lIj9LupKAI6ev 0MiU4Wllwx3lwRtEVCq8yVD6Y6dmmqvNY+dyvoupTi8g6M2Yx5aAL4mZeK0Q7agJCqHd 7yZg== X-Received: by 10.194.2.8 with SMTP id 8mr2515268wjq.85.1413199945804; Mon, 13 Oct 2014 04:32:25 -0700 (PDT) Received: from [172.24.248.64] (dyn32-131.checkpoint.com. [194.29.32.131]) by mx.google.com with ESMTPSA id lp8sm11858141wic.17.2014.10.13.04.32.24 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 13 Oct 2014 04:32:25 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_329381CE-3319-4055-A3DE-027148CF9560" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Yoav Nir In-Reply-To: <542D48CD.9060404@isode.com> Date: Mon, 13 Oct 2014 14:32:23 +0300 Message-Id: <55183415-AD02-4BAB-86F4-73C53C5FA616@gmail.com> References: <542D48CD.9060404@isode.com> To: "cfrg@irtf.org" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/VVNMnBwXrHscsBM7LoZGpeO8jeM Subject: Re: [Cfrg] RGLC on draft-irtf-cfrg-chacha20-poly1305-01.txt X-BeenThere: cfrg@irtf.org 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: Mon, 13 Oct 2014 11:32:29 -0000 --Apple-Mail=_329381CE-3319-4055-A3DE-027148CF9560 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Oct 2, 2014, at 3:45 PM, Alexey Melnikov = wrote: > The authors of "ChaCha20 and Poly1305 for IETF protocols", = draft-irtf-cfrg-chacha20-poly1305-01.txt believe the draft is ready for = a RGLC. >=20 > This starts a two week research group last call, to end on 17 Oct = 2014. >=20 > The draft is available at = http://datatracker.ietf.org/doc/draft-irtf-cfrg-chacha20-poly1305/ >=20 > Please do comment on the list, indicating whether you believe this = draft is ready for publication. Please send your comments, indication of = support for the publication or objections to the publication to the = mailing list or directly to the RG chairs (cfrg-chairs@tools.ietf.org). >=20 > Alexey, > As a co-chair. Hi. I haven=92t submitted anything yet, but I=92ve made a few changes to my = local copy: I=92ve added the AEAD parameters from RFC 5116. I=92ve added the sentence suggested by Dan Harkins about combining = several chunks of associated data (pretty much passing the = responsibility for assembly/reassembly to the application) I=92ve changed the worked example for quarter-round, as suggested by = Sean Parkinson (chose an example with the rotate-left amount not 16, = because a rotate-left of 16 bits is similar to rotate-right of 16 bits) I=92ve added pseudo-code =93implementations=94 to some of the = algorithms, as suggested by Sean Parkinson Things I didn=92t do: I did not change the counter/nonce split back to 64/64 as James Cloos = suggested, because (a) that=92s against a SHOULD in RFC 5116, and (b) = it=92s useful for multi-sender protocols, and (c) we had consensus for = the change, and I don=92t think we have consensus for the change back. I did not switch to XChaCha as suggested by David Leon Gil I did not incorporate the test vectors suggested by David because (a) = they depend on suggested changes to hot the counter/nonce split, and (b) = it might be addressed by limiting the amount of data that is allowed to = be encrypted, which is in the draft (unless I totally misunderstood the = suggestion) For the (unpublished) draft with the changes, see: - TXT version: = https://docs.google.com/document/d/1FnL6L_Ce_fnlqeRxSdoEUCbBQzz4m8r9ciy1dH= 9toC8/pub - HTML-ized version: = https://docs.google.com/document/d/1SSICS0HBl0lot1hZJ8-XT7Q6JVJr9b0zQ6ZZUH= 4D-B0/pub Yoav= --Apple-Mail=_329381CE-3319-4055-A3DE-027148CF9560 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On Oct 2, 2014, at 3:45 PM, Alexey = Melnikov <alexey.melnikov@isode.com>= ; wrote:

The authors of "ChaCha20 and Poly1305 for IETF protocols", = draft-irtf-cfrg-chacha20-poly1305-01.txt believe the draft is ready for = a RGLC.

This starts a two week research group last call, to end = on 17 Oct 2014.

The draft is available at http://datatracker.ietf.org/doc/draft-irtf-cfrg-chacha20-poly1305/
Please do comment on the list, indicating whether you believe this = draft is ready for publication. Please send your comments, indication of = support for the publication or objections to the publication to the = mailing list or directly to the RG chairs (cfrg-chairs@tools.ietf.org)= .

Alexey,
As a = co-chair.

Hi.

I = haven=92t submitted anything yet, but I=92ve made a few changes to my = local copy:
  • I=92ve added the = AEAD parameters from RFC 5116.
  • I=92ve added the sentence = suggested by Dan Harkins about combining several chunks of associated = data (pretty much passing the responsibility for assembly/reassembly to = the application)
  • I=92ve changed the worked example for = quarter-round, as suggested by Sean Parkinson (chose an example with the = rotate-left amount not 16, because a rotate-left of 16 bits is similar = to rotate-right of 16 bits)
  • I=92ve added pseudo-code = =93implementations=94 to some of the algorithms, as suggested by Sean = Parkinson

Things I didn=92t = do:
  • I did not change the = counter/nonce split back to 64/64 as James Cloos suggested, because (a) = that=92s against a SHOULD in RFC 5116, and (b) it=92s useful for = multi-sender protocols, and (c) we had consensus for the change, and I = don=92t think we have consensus for the change back.
  • I did not = switch to XChaCha as suggested by David Leon Gil
  • I did not = incorporate the test vectors suggested by David because (a) they depend = on suggested changes to hot the counter/nonce split, and (b) it might be = addressed by limiting the amount of data that is allowed to be = encrypted, which is in the draft (unless I totally misunderstood the = suggestion)

For the (unpublished) = draft with the changes, see:

Yoav
= --Apple-Mail=_329381CE-3319-4055-A3DE-027148CF9560-- From nobody Mon Oct 13 04:36:23 2014 Return-Path: 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 61EA81A896D for ; Mon, 13 Oct 2014 04:36:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.014 X-Spam-Level: X-Spam-Status: No, score=-0.014 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_LOW=-0.7, THIS_AD=0.086, UNPARSEABLE_RELAY=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 Kj51nWrA9o1F for ; Mon, 13 Oct 2014 04:36:16 -0700 (PDT) Received: from mace.cs.uic.edu (mace.cs.uic.edu [131.193.32.224]) by ietfa.amsl.com (Postfix) with SMTP id D43FA1A6F20 for ; Mon, 13 Oct 2014 04:36:15 -0700 (PDT) Received: (qmail 27398 invoked by uid 1011); 13 Oct 2014 11:36:12 -0000 Received: from unknown (unknown) by unknown with QMTP; 13 Oct 2014 11:36:12 -0000 Received: (qmail 30290 invoked by uid 1001); 13 Oct 2014 11:36:07 -0000 Date: 13 Oct 2014 11:36:07 -0000 Message-ID: <20141013113607.30288.qmail@cr.yp.to> From: "D. J. Bernstein" To: cfrg@irtf.org Mail-Followup-To: cfrg@irtf.org In-Reply-To: <2FBC676C3BBFBB4AA82945763B361DE60A76B077@MX17A.corp.emc.com> <5439ED77.3010701@brainhub.org> <5437FED9.50409@sbcglobal.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/-vIfw6tfWxS4jqbcAoQPc2Fr6l8 Subject: Re: [Cfrg] Publicly verifiable benchmarks X-BeenThere: cfrg@irtf.org 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: Mon, 13 Oct 2014 11:36:18 -0000 More notes on how SUPERCOP documents various things. Andrey Jivsov writes: > Intel(R) Core(TM) i5-3550 CPU @ 3.30GHz, Ivy Bridge (not Haswell). http://bench.cr.yp.to/computers.html lists four "IB+AES" machines (Ivy Bridge is actually two different microarchitectures: Core i3 CPUs don't have AES instructions), namely hydra8, ares, khazaddum, and h9ivy. The last column of the table shows that the latest reports contributed from ares and khazaddum are from 2013 and 2012, which is why they're marked in gray; hydra8 and h9ivy are reasonably up to date. If you then check, for example, http://bench.cr.yp.to/results-dh.html#amd64-hydra8 you see that crypto_dh/curve25519 takes 182544 cycles (quartiles: 182424 and 182664) on hydra8. As I mentioned, this X25519 code was actually written years ago (optimized for Nehalem), so you can also find the same speed in the 2013 report from ares, but in general it's good to focus on the up-to-date speed reports. Parkinson, Sean writes: > Is there a REST API to the benchmark data? The underlying compressed database is hundreds of gigabytes, creating serious performance problems for most standard tools. We're working on supporting more client-side manipulation of data but for the moment the best way to get additional reports onto the web pages is to talk to us. David Jacobson writes: > It would be nice if you tagged implementations (of algorithms where it > matters) into according to leakage resistance. Yes. Some implementors advertise constant-time software, but right now SUPERCOP doesn't provide a structured mechanism for this advertisement. One of the difficulties here is that some people are more stringent than others in what they mean by "constant time"; I'll write a separate message about this. Michael Hamburg writes: > some of the machines on bench.cr.yp.to have quirks > (turboboost, mismatched cycle counter frequency, etc) which can make > the data difficult to interpret and reproduce. Turbo Boost is noted as "boost" in red (as is Turbo Core), and is also easy to spot as unusually large gaps between the quartiles. See, e.g., http://bench.cr.yp.to/results-dh.html#amd64-hydra3. The SUPERCOP documentation has a "Reducing randomness in benchmarks" section that tells people how to turn off hyperthreading and Turbo Boost. Eventually we'd like to measure what the actual Turbo Boost speedup is, but this isn't as easy as it sounds. Some CPUs don't give the OS full control over clock frequencies. Of course, clock frequency makes far less of a difference in cycle counts than it makes in other metrics such as operations per second, but it does sometimes make a noticeable difference, especially for code that doesn't fit into L1 cache. Clicking on machine names shows pages such as http://bench.cr.yp.to/web-impl/armeabi-h7green-crypto_dh.html with a "CPU cycles/second" line showing the range of frequencies observed by SUPERCOP (highly variable for h7green---this particular Cortex-A9 CPU seems quite hard to control), along with information about which cycle counter SUPERCOP is using (in this case cpucycles/cortex.c). > You should also make sure to install the compilers DJB uses (GCC 4.8.1 > and Clang 3.2 on titan0, or GCC 4.6.3 and Clang 3.0 on h6sandy, for > example) to make sure that your system compiles and runs passably well > using those compilers. The compiler versions are noted parenthetically in the same machine pages mentioned above. But they do change every now and then when systems are upgraded (for example, titan0 just switched to gcc 4.8.2), and when people contribute more machines they usually have different compilers. The real-world situation is that people use many different compilers, and it isn't safe to assume that those compilers all behave the same way. Of course, asm code produces much less variability. ---Dan From nobody Mon Oct 13 04:42:53 2014 Return-Path: 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 D810B1A8903 for ; Mon, 13 Oct 2014 04:42:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.685 X-Spam-Level: X-Spam-Status: No, score=-2.685 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.786] 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 VqqnDVfXO-ka for ; Mon, 13 Oct 2014 04:42:48 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id C95721A8859 for ; Mon, 13 Oct 2014 04:42:15 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 595224757B; Mon, 13 Oct 2014 11:42:14 +0000 (GMT) Received: from prod-mail-relay07.akamai.com (prod-mail-relay07.akamai.com [172.17.121.112]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 4D8794757A; Mon, 13 Oct 2014 11:42:14 +0000 (GMT) Received: from email.msg.corp.akamai.com (usma1ex-cas2.msg.corp.akamai.com [172.27.123.31]) by prod-mail-relay07.akamai.com (Postfix) with ESMTP id 49E0E80044; Mon, 13 Oct 2014 11:42:14 +0000 (GMT) Received: from usma1ex-cashub5.kendall.corp.akamai.com (172.27.105.21) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.913.22; Mon, 13 Oct 2014 07:41:54 -0400 Received: from USMBX1.msg.corp.akamai.com ([169.254.1.71]) by USMA1EX-CASHUB5.kendall.corp.akamai.com ([172.27.105.21]) with mapi; Mon, 13 Oct 2014 07:41:54 -0400 From: "Salz, Rich" To: Yoav Nir , "cfrg@irtf.org" Date: Mon, 13 Oct 2014 07:41:53 -0400 Thread-Topic: [Cfrg] RGLC on draft-irtf-cfrg-chacha20-poly1305-01.txt Thread-Index: Ac/m2W2JysOywrowRrGgOoDZTkzQggAATh4w Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C71D39ECE09C@USMBX1.msg.corp.akamai.com> References: <542D48CD.9060404@isode.com> <55183415-AD02-4BAB-86F4-73C53C5FA616@gmail.com> In-Reply-To: <55183415-AD02-4BAB-86F4-73C53C5FA616@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_2A0EFB9C05D0164E98F19BB0AF3708C71D39ECE09CUSMBX1msgcorp_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/LNzkRBQGizOK4D_m5BuxfAhgav0 Subject: Re: [Cfrg] RGLC on draft-irtf-cfrg-chacha20-poly1305-01.txt X-BeenThere: cfrg@irtf.org 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: Mon, 13 Oct 2014 11:42:50 -0000 --_000_2A0EFB9C05D0164E98F19BB0AF3708C71D39ECE09CUSMBX1msgcorp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ship it -- Principal Security Engineer, Akamai Technologies IM: rsalz@jabber.me Twitter: RichSalz --_000_2A0EFB9C05D0164E98F19BB0AF3708C71D39ECE09CUSMBX1msgcorp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Ship it

 

-- 

Principal Security Engineer, Akamai Technologies

IM: rsalz@jabber.me Twitter: RichS= alz

= --_000_2A0EFB9C05D0164E98F19BB0AF3708C71D39ECE09CUSMBX1msgcorp_-- From nobody Mon Oct 13 04:43:41 2014 Return-Path: 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 C688D1A8859 for ; Mon, 13 Oct 2014 04:43:39 -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 xFsdsmr3myYX for ; Mon, 13 Oct 2014 04:43:38 -0700 (PDT) Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 689FD1A0191 for ; Mon, 13 Oct 2014 04:43:38 -0700 (PDT) Received: by mail-wg0-f45.google.com with SMTP id m15so8559366wgh.16 for ; Mon, 13 Oct 2014 04:43:37 -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=l2HXTEE8hhNtapmiABQCr13koieX3aPb5d7yTa8xTn4=; b=Llo56xJz1EBaj6W0ZdYNoWCemRkYGsa6m5ZhHVDXs3OziQ34ofEThVybAveCoBSGio px0K6f6lA0NaqYUtJTVgAlZE3nW6BBtNpfyzK4/uex/+n5Uvbmn7lXOC6xoQxEBheYfL vkC5/Xgg4iHLMK+Fv8RNtkCRbD6l7wNTdzospwSwID+0mCawSqP2gjkZsOjNU39YHcZH YIS/H1wfdowDC9UO7U7GSZROVZ17Je+fDO3+ms6hpszSiw0Yz6Eqlosf6mml834APY8E h/wly4x0Jt0EzQYYHqasRxSYlg3z5eEXUl2xERx2kP5Q+Mtb3ApfrSAs68Y49gkYkd8w 9QMQ== X-Received: by 10.180.72.98 with SMTP id c2mr428351wiv.18.1413200616947; Mon, 13 Oct 2014 04:43:36 -0700 (PDT) Received: from [172.24.248.64] (dyn32-131.checkpoint.com. [194.29.32.131]) by mx.google.com with ESMTPSA id t9sm16339872wjf.41.2014.10.13.04.43.36 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 13 Oct 2014 04:43:36 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_3BC2C292-6F1D-48F2-909F-60189BE86C8C" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Yoav Nir In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C71D39ECE09C@USMBX1.msg.corp.akamai.com> Date: Mon, 13 Oct 2014 14:43:35 +0300 Message-Id: <2E9FA634-8722-4DE8-AA2C-5863926CFE00@gmail.com> References: <542D48CD.9060404@isode.com> <55183415-AD02-4BAB-86F4-73C53C5FA616@gmail.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D39ECE09C@USMBX1.msg.corp.akamai.com> To: Rich Salz X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/DB9585w8sKz6tam6yXaEiwQI73E Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] RGLC on draft-irtf-cfrg-chacha20-poly1305-01.txt X-BeenThere: cfrg@irtf.org 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: Mon, 13 Oct 2014 11:43:39 -0000 --Apple-Mail=_3BC2C292-6F1D-48F2-909F-60189BE86C8C Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Just waiting for RGLC to end. On Oct 13, 2014, at 2:41 PM, Salz, Rich wrote: > Ship it > > -- > Principal Security Engineer, Akamai Technologies > IM: rsalz@jabber.me Twitter: RichSalz --Apple-Mail=_3BC2C292-6F1D-48F2-909F-60189BE86C8C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Just = waiting for RGLC to end.

On Oct 13, 2014, = at 2:41 PM, Salz, Rich <rsalz@akamai.com> = wrote:

Ship it
 
-- 
Principal Security Engineer, Akamai = Technologies
IM: rsalz@jabber.me Twitter: = RichSalz

= --Apple-Mail=_3BC2C292-6F1D-48F2-909F-60189BE86C8C-- From nobody Mon Oct 13 05:24:29 2014 Return-Path: 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 C1FEA1A8A0C for ; Mon, 13 Oct 2014 05:24:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 C5AcfwomAeJ7 for ; Mon, 13 Oct 2014 05:24:22 -0700 (PDT) Received: from emh04.mail.saunalahti.fi (emh04.mail.saunalahti.fi [62.142.5.110]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5EF41A8A16 for ; Mon, 13 Oct 2014 05:24:22 -0700 (PDT) Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh04.mail.saunalahti.fi (Postfix) with ESMTP id 648A11A2674; Mon, 13 Oct 2014 15:24:19 +0300 (EEST) Date: Mon, 13 Oct 2014 15:24:19 +0300 From: Ilari Liusvaara To: Yoav Nir Message-ID: <20141013122419.GA28433@LK-Perkele-VII> References: <542D48CD.9060404@isode.com> <55183415-AD02-4BAB-86F4-73C53C5FA616@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <55183415-AD02-4BAB-86F4-73C53C5FA616@gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/kAB8YDpjfVHPvKRib9in1DJtjfU Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] RGLC on draft-irtf-cfrg-chacha20-poly1305-01.txt X-BeenThere: cfrg@irtf.org 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: Mon, 13 Oct 2014 12:24:25 -0000 On Mon, Oct 13, 2014 at 02:32:23PM +0300, Yoav Nir wrote: > > Hi. > > I haven’t submitted anything yet, but I’ve made a few changes to > my local copy: > I’ve added the AEAD parameters from RFC 5116. - Isn't K_LEN = 32, not 16? - Isn't A_MAX = 2^64 - 1, not 2^64? - AFAIK, RFC5116 requries returning the ciphertext and tag as single octet string (most likely concatenation). - RFC5116 requires specifying relation between plaintext and ciphertext lengths (most likely |C|=|P|+16). - RFC5116 recomends specifying just how badly things blow up if nonce is reused (AFAIK, XOR of plaintexts is revealed and arbitrary messages with that nonce may be forged). Also, writing IANA consideration to register this (AEAD_CHACHA20_POLY1305?) could be useful (as already suggested by someone). Apparently the registry is called "AEAD algorithms" (at least it is that way on IANA site, even if I can't find that in RFC 5116). -Ilari From nobody Mon Oct 13 05:41:40 2014 Return-Path: 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 DE9AC1A3B9D for ; Mon, 13 Oct 2014 05:41:38 -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 FemlVo8sb_oM for ; Mon, 13 Oct 2014 05:41:37 -0700 (PDT) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 309BB1A0310 for ; Mon, 13 Oct 2014 05:41:37 -0700 (PDT) Received: by mail-wg0-f41.google.com with SMTP id b13so8588521wgh.12 for ; Mon, 13 Oct 2014 05:41:35 -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=2oia2N8MGCF0wAP5FNz0KqQkmtvs9aN0zQCExZ3D5AM=; b=vUbkcTkGt5ceTpEBA0103nLdmGbgc4kM4zUqtG4R9e0tfn3CPCKRbDV8aqK+HOOVPA +RME4hjuV9k8q4Ui3hLxk6X2AYd9Jl4P+5sU5JSgROXsTNswNPtKiHRh5RXc6yz4OxzQ +8bmUTEc9FfJmQ23pHNR/3tqE2YMVGc+2ErneVJEAOY9YhkRCKLFu1yV6hho762E36ZL 7H9nu9A98fN5HkDDehjzQ5ez2Ah8f2nm6Zi8SAqbiZzL/KHC9OUQ5Kia+OuKUt5IPF6f 1RjpDAWd7Gh2lSunp4snsl4f8zo8NSSIrL+eZnLnRaVwf8ck1aR1IpnJPlGG2hOP6znF lbLg== X-Received: by 10.194.219.193 with SMTP id pq1mr20921447wjc.5.1413204095723; Mon, 13 Oct 2014 05:41:35 -0700 (PDT) Received: from [172.24.248.64] (dyn32-131.checkpoint.com. [194.29.32.131]) by mx.google.com with ESMTPSA id i5sm17753185wjz.0.2014.10.13.05.41.34 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 13 Oct 2014 05:41:35 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_AAD48FA4-371C-4B37-A5DC-59204E140CED" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Yoav Nir In-Reply-To: <20141013122419.GA28433@LK-Perkele-VII> Date: Mon, 13 Oct 2014 15:41:31 +0300 Message-Id: <8F77D0C2-1C1F-4302-8757-5284BA1236A0@gmail.com> References: <542D48CD.9060404@isode.com> <55183415-AD02-4BAB-86F4-73C53C5FA616@gmail.com> <20141013122419.GA28433@LK-Perkele-VII> To: Ilari Liusvaara X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/Jo0N4OFzC-AhVI9NvdXUTtHJZPs Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] RGLC on draft-irtf-cfrg-chacha20-poly1305-01.txt X-BeenThere: cfrg@irtf.org 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: Mon, 13 Oct 2014 12:41:39 -0000 --Apple-Mail=_AAD48FA4-371C-4B37-A5DC-59204E140CED Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Oct 13, 2014, at 3:24 PM, Ilari Liusvaara = wrote: > On Mon, Oct 13, 2014 at 02:32:23PM +0300, Yoav Nir wrote: >>=20 >> Hi. >>=20 >> I haven=92t submitted anything yet, but I=92ve made a few changes to >> my local copy: >> I=92ve added the AEAD parameters from RFC 5116. >=20 > - Isn't K_LEN =3D 32, not 16? Argh, shouldn=92t write drafts after midnight. > - Isn't A_MAX =3D 2^64 - 1, not 2^64? Yes, see above. Fixed in my copy and Google docs. > - AFAIK, RFC5116 requries returning the ciphertext and tag as single > octet string (most likely concatenation). An AEAD algorithm MAY structure its ciphertext output in any way; for example, the ciphertext can incorporate an authentication tag. Following that, I calculated C_MAX to be P_MAX + 16. > - RFC5116 requires specifying relation between plaintext and > ciphertext lengths (most likely |C|=3D|P|+16). Yes. > - RFC5116 recomends specifying just how badly things blow up > if nonce is reused (AFAIK, XOR of plaintexts is revealed and > arbitrary messages with that nonce may be forged). Same authentication key and same keystream, so at least the XOR of the = plaintexts is revealed and the same one-time Poly1305 is used. So if you = know the plaintext and can choose the nonce, you will be able to encrypt = another arbitrary message, but you will still fail tag calculation. I=92ll= add something to the security considerations. > Also, writing IANA consideration to register this > (AEAD_CHACHA20_POLY1305?) could be useful (as already suggested by > someone). Apparently the registry is called "AEAD algorithms" (at > least it is that way on IANA site, even if I can't find that in > RFC 5116).=20 Will do. Yoav --Apple-Mail=_AAD48FA4-371C-4B37-A5DC-59204E140CED Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252

Same authentication key and same = keystream, so at least the XOR of the plaintexts is revealed and the = same one-time Poly1305 is used. So if you know the plaintext and can = choose the nonce, you will be able to encrypt another arbitrary message, = but you will still fail tag calculation. I=92ll add something to the = security considerations.

Also, = writing IANA consideration to register this
(AEAD_CHACHA20_POLY1305?) = could be useful (as already suggested by
someone). Apparently the = registry is called "AEAD algorithms" (at
least it is that way on IANA = site, even if I can't find that in
RFC 5116). =

Will = do.

Yoav

= --Apple-Mail=_AAD48FA4-371C-4B37-A5DC-59204E140CED-- From nobody Mon Oct 13 06:32:35 2014 Return-Path: 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 AB2771A8A99 for ; Mon, 13 Oct 2014 06:32:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 lD5Tc4wjDq3F for ; Mon, 13 Oct 2014 06:32:31 -0700 (PDT) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3950B1A1A19 for ; Mon, 13 Oct 2014 06:32:31 -0700 (PDT) Received: by mail-wi0-f182.google.com with SMTP id n3so7428365wiv.15 for ; Mon, 13 Oct 2014 06:32:29 -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 :content-transfer-encoding:message-id:references:to; bh=FlxWchbkY5+DpBdPg8KoUECve+y0BXZXP0xC/eQRWDg=; b=dUylL79DcGDW2Wo80cVXUCEytbPBNU7XPZJZWoJ5FnXokxSNdaGu/MdTyEr8nA0QZ5 y9kNGU0As/Wqs5AMd+5WKsqWYVqu9c6apF+hrHgM/Jk9/xEqJ0FAyEgAQPPx3CGyPuf/ PiZFQblQRd7ZXwqZkOcSffCqsRv7WIZ3IvokBBIqPGYcDvDHbsOD0hdxGGYvpa7+5X1H YxFuu9gh7RLL9SpveGhMkNwzOQ6UfLOP5FGcatOlvtBMmgi+xnUTELb0NfJFygDP+t4t JBVta7724hUzCZ1O1i10fTx2SEJA1WtnvhW4pPtImN+hrk1zu2dzxumlQd2sH2FHGxjM Xc1w== X-Received: by 10.180.80.39 with SMTP id o7mr874401wix.82.1413207149733; Mon, 13 Oct 2014 06:32:29 -0700 (PDT) Received: from [172.24.248.64] (dyn32-131.checkpoint.com. [194.29.32.131]) by mx.google.com with ESMTPSA id bc5sm14724033wjb.14.2014.10.13.06.32.28 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 13 Oct 2014 06:32:29 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Yoav Nir In-Reply-To: <8F77D0C2-1C1F-4302-8757-5284BA1236A0@gmail.com> Date: Mon, 13 Oct 2014 16:32:25 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <9D2FBF7A-A31F-4C6D-A0D3-066CAD48152A@gmail.com> References: <542D48CD.9060404@isode.com> <55183415-AD02-4BAB-86F4-73C53C5FA616@gmail.com> <20141013122419.GA28433@LK-Perkele-VII> <8F77D0C2-1C1F-4302-8757-5284BA1236A0@gmail.com> To: Ilari Liusvaara X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/yYvIuBWtC1dtRGouva3fp91IjPU Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] RGLC on draft-irtf-cfrg-chacha20-poly1305-01.txt X-BeenThere: cfrg@irtf.org 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: Mon, 13 Oct 2014 13:32:32 -0000 On Oct 13, 2014, at 3:41 PM, Yoav Nir wrote: >=20 >=20 >> - RFC5116 recomends specifying just how badly things blow up >> if nonce is reused (AFAIK, XOR of plaintexts is revealed and >> arbitrary messages with that nonce may be forged). >=20 > Same authentication key and same keystream, so at least the XOR of the = plaintexts is revealed and the same one-time Poly1305 is used. So if you = know the plaintext and can choose the nonce, you will be able to encrypt = another arbitrary message, but you will still fail tag calculation. I=92ll= add something to the security considerations. >=20 >> Also, writing IANA consideration to register this >> (AEAD_CHACHA20_POLY1305?) could be useful (as already suggested by >> someone). Apparently the registry is called "AEAD algorithms" (at >> least it is that way on IANA site, even if I can't find that in >> RFC 5116).=20 >=20 > Will do. >=20 OK. Done and done. Thanks Yoav From nobody Mon Oct 13 08:39:20 2014 Return-Path: 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 BD7081A1A40 for ; Mon, 13 Oct 2014 08:39:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-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 7cPlx6vFtVsA for ; Mon, 13 Oct 2014 08:39:15 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0793.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::793]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 321651A1A3A for ; Mon, 13 Oct 2014 08:39:15 -0700 (PDT) Received: from DM2PR03CA0029.namprd03.prod.outlook.com (10.141.96.28) by DM2PR0301MB1213.namprd03.prod.outlook.com (25.160.219.154) with Microsoft SMTP Server (TLS) id 15.0.1049.19; Mon, 13 Oct 2014 15:38:52 +0000 Received: from BN1BFFO11FD027.protection.gbl (2a01:111:f400:7c10::1:129) by DM2PR03CA0029.outlook.office365.com (2a01:111:e400:2428::28) with Microsoft SMTP Server (TLS) id 15.0.1049.19 via Frontend Transport; Mon, 13 Oct 2014 15:38:52 +0000 Received: from mail.microsoft.com (131.107.125.37) by BN1BFFO11FD027.mail.protection.outlook.com (10.58.144.90) with Microsoft SMTP Server (TLS) id 15.0.1039.16 via Frontend Transport; Mon, 13 Oct 2014 15:38:51 +0000 Received: from TK5EX14MBXC286.redmond.corp.microsoft.com ([169.254.1.93]) by TK5EX14MLTC101.redmond.corp.microsoft.com ([157.54.79.193]) with mapi id 14.03.0210.003; Mon, 13 Oct 2014 15:38:15 +0000 From: Mike Jones To: "cfrg@irtf.org" Thread-Topic: CFRG meeting at IETF 91 Thread-Index: Ac/m+7cWfUhctuX0TX+mLagvjdAODA== Date: Mon, 13 Oct 2014 15:38:13 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739439BB0974B@TK5EX14MBXC286.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.35] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739439BB0974BTK5EX14MBXC286r_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(438002)(199003)(164054003)(189002)(120916001)(6806004)(16236675004)(99396003)(15975445006)(19300405004)(2501002)(92566001)(92726001)(15202345003)(69596002)(19580395003)(68736004)(44976005)(97736003)(76482002)(21056001)(85852003)(85806002)(85306004)(84326002)(64706001)(512954002)(54356999)(20776003)(87936001)(50986999)(31966008)(86362001)(2656002)(33656002)(71186001)(84676001)(19625215002)(26826002)(4396001)(110136001)(77096002)(80022003)(46102003)(55846006)(106466001)(19617315012)(66066001)(81156004)(107886001)(2351001)(86612001)(104016003)(229853001)(107046002)(95666004); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0301MB1213; H:mail.microsoft.com; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:DM2PR0301MB1213; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 03630A6A4A Received-SPF: Pass (protection.outlook.com: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=protection.outlook.com; client-ip=131.107.125.37; helo=mail.microsoft.com; Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/Azo-15fskA9FoPgBgIWUia6OGwM Subject: [Cfrg] CFRG meeting at IETF 91 X-BeenThere: cfrg@irtf.org 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: Mon, 13 Oct 2014 15:39:17 -0000 --_000_4E1F6AAD24975D4BA5B16804296739439BB0974BTK5EX14MBXC286r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable When will the CRFG meeting be at IETF 91 in Honolulu? It isn't listed in t= he agenda at https://datatracker.ietf.org/meeting/91/agenda.html. Thanks, -- Mike --_000_4E1F6AAD24975D4BA5B16804296739439BB0974BTK5EX14MBXC286r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

When will the CRFG meeting be at IETF 91 in Honolulu= ?  It isn’t listed in the agenda at https://dat= atracker.ietf.org/meeting/91/agenda.html.

 

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p; Thanks,

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p; -- Mike

 

--_000_4E1F6AAD24975D4BA5B16804296739439BB0974BTK5EX14MBXC286r_-- From nobody Mon Oct 13 09:24:08 2014 Return-Path: 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 225F21A1AD7 for ; Mon, 13 Oct 2014 09:23:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.785 X-Spam-Level: X-Spam-Status: No, score=-2.785 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.786] 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 CDJq6Nuz34h4 for ; Mon, 13 Oct 2014 09:23:55 -0700 (PDT) Received: from statler.isode.com (ext-bt.isode.com [217.34.220.158]) by ietfa.amsl.com (Postfix) with ESMTP id B11741A037D for ; Mon, 13 Oct 2014 09:23:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1413217432; d=isode.com; s=selector; i=@isode.com; bh=g61v+ra9iT7j6nVyEYrJqolZt8QcYRXvQz/0/Jpnoig=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=D1SNEj3mmXEYBYSU0TdX0uRmel0IH0PHeMhPN8d9DPlP9/Yt1Ir5IO/OVvlLUDQ2WU012F ZomVrPAHlJ4zuRLyOozqQOzS8L0Lp/oMynQaJWTFEEuqppnPgq9dGXECno3iUVA3GyE1rg MjuoO0Nm9aIZx5R/gn6ridBe+DDGi7A=; Received: from [172.20.1.47] (dhcp-47.isode.net [172.20.1.47]) by statler.isode.com (submission channel) via TCP with ESMTPA id ; Mon, 13 Oct 2014 17:23:52 +0100 Message-ID: <543BFCA9.6070509@isode.com> Date: Mon, 13 Oct 2014 17:24:09 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 To: Mike Jones , "cfrg@irtf.org" References: <4E1F6AAD24975D4BA5B16804296739439BB0974B@TK5EX14MBXC286.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739439BB0974B@TK5EX14MBXC286.redmond.corp.microsoft.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------090000070604000508030402" Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/dK5HGQUEvd0opnBoTjdKSR9Vlzs Subject: [Cfrg] No CFRG meeting in Honolulu X-BeenThere: cfrg@irtf.org 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: Mon, 13 Oct 2014 16:23:57 -0000 This is a multi-part message in MIME format. --------------090000070604000508030402 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 13/10/2014 16:38, Mike Jones wrote: > > When will the CRFG meeting be at IETF 91 in Honolulu? It isn't listed > in the agenda at https://datatracker.ietf.org/meeting/91/agenda.html. > > Chairs decided not to meet in Honolulu. We will continue to progress work on the mailing list before Honolulu. --------------090000070604000508030402 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 13/10/2014 16:38, Mike Jones wrote:

When will the CRFG meeting be at IETF 91 in Honolulu?  It isn’t listed in the agenda at https://datatracker.ietf.org/meeting/91/agenda.html.


Chairs decided not to meet in Honolulu. We will continue to progress work on the mailing list before Honolulu.


--------------090000070604000508030402-- From nobody Mon Oct 13 09:30:10 2014 Return-Path: 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 05F371A1B28 for ; Mon, 13 Oct 2014 09:30:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no 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 N6CC0Id3OBww for ; Mon, 13 Oct 2014 09:30:01 -0700 (PDT) Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E366A1A01BA for ; Mon, 13 Oct 2014 09:29:55 -0700 (PDT) Received: by mail-la0-f52.google.com with SMTP id hz20so6847641lab.25 for ; Mon, 13 Oct 2014 09:29:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=1W5OqELv999cqGwoajesT+WsdmwQhI2iY/lf0FdtdW8=; b=H1C836TUI8oMVtIafHOCZ38ZBKWDdG0zkdtKSwKMmP0tJ0IG2wQxs/q9zSQWHBkIrH IeKUe6i945EHrwXpKYW7YQc6YQSefHX15K4I9EH2OF+ik2AxeeQ4ySCRr2vJ+KHh+62s QaoiBAhiqb1/PifMx0/a4EgbOZzcPM1X1UJPPGSBzVS7t+CWmrWV//oLYn64Ezesic84 U8T8yXpNqeDjv6k9cbcmvxjB3xiV21dax9pbUVMvblsCXOhvYB/T6u6BeocbkkhKTIb8 +ZVF5Xp5KT7w1ggBeRniaWzkhka/CPXza8PHlj/TvNBWPIzarVohCx5mNxoUGMnDMlWY ArVw== MIME-Version: 1.0 X-Received: by 10.112.149.105 with SMTP id tz9mr25253942lbb.5.1413217793603; Mon, 13 Oct 2014 09:29:53 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.66.196 with HTTP; Mon, 13 Oct 2014 09:29:53 -0700 (PDT) In-Reply-To: <543BFCA9.6070509@isode.com> References: <4E1F6AAD24975D4BA5B16804296739439BB0974B@TK5EX14MBXC286.redmond.corp.microsoft.com> <543BFCA9.6070509@isode.com> Date: Mon, 13 Oct 2014 12:29:53 -0400 X-Google-Sender-Auth: a8BkMF57FKUDdJNuWGoMoDfCXmo Message-ID: From: Phillip Hallam-Baker To: Alexey Melnikov Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/sPMvvRXrGsqlNW9YUlEE5JhO-SI Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] No CFRG meeting in Honolulu X-BeenThere: cfrg@irtf.org 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: Mon, 13 Oct 2014 16:30:02 -0000 Well just as well I didn't use CFRG and the ECC discussions when I made the justification for my travel to management. Given the ECC discussion going on, I expected it to meet. On Mon, Oct 13, 2014 at 12:24 PM, Alexey Melnikov wrote: > On 13/10/2014 16:38, Mike Jones wrote: > > When will the CRFG meeting be at IETF 91 in Honolulu? It isn=E2=80=99t l= isted in > the agenda at https://datatracker.ietf.org/meeting/91/agenda.html. > > > Chairs decided not to meet in Honolulu. We will continue to progress work= on > the mailing list before Honolulu. > > > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg > From nobody Mon Oct 13 09:34:28 2014 Return-Path: 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 7454E1A1B2A for ; Mon, 13 Oct 2014 09:34:26 -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 RCu7AM6lP1iJ for ; Mon, 13 Oct 2014 09:34:25 -0700 (PDT) Received: from mail-yh0-x232.google.com (mail-yh0-x232.google.com [IPv6:2607:f8b0:4002:c01::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4C081A1B26 for ; Mon, 13 Oct 2014 09:34:24 -0700 (PDT) Received: by mail-yh0-f50.google.com with SMTP id a41so3800362yho.9 for ; Mon, 13 Oct 2014 09:34:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=T4/7Z+CkgVDG9Qcumo/K0rYDTZqM7jKSiyMHYtxh+jQ=; b=MDITu2mYMJO9vmUoBgDe48K5Gx+MS67RQGrgPDdS/g0iOQmrodLBeLG282TKkE2C/B QkNb6HFMFoVgQ0ndTmQbJzVKqwN+wWza/TBUfvn9dIzBHL8xdXSMFh7NIcv5JsQZHTRG R7zgljKYxX7TbQvcokZJoxSIEhndRRTW3dWudiaFShBHz+5iDLrGrfyUVmA4wJK36c6E ThLN9kWNh2pEMN9VeVs/y/57dQjSfyoCIVaD0oKvd/gSyAZJHBgvHHTvjPd3LJnLLKgd Pr6nGWLyf3dG7KhRyuNbyuwST5LoPqTydu5AwSTMzD1K17SRa+Ci7uH5xU4hLfL8R8Hb J/tA== MIME-Version: 1.0 X-Received: by 10.236.134.202 with SMTP id s50mr38676681yhi.4.1413218064186; Mon, 13 Oct 2014 09:34:24 -0700 (PDT) Received: by 10.170.195.149 with HTTP; Mon, 13 Oct 2014 09:34:24 -0700 (PDT) Received: by 10.170.195.149 with HTTP; Mon, 13 Oct 2014 09:34:24 -0700 (PDT) In-Reply-To: References: <4E1F6AAD24975D4BA5B16804296739439BB0974B@TK5EX14MBXC286.redmond.corp.microsoft.com> <543BFCA9.6070509@isode.com> Date: Mon, 13 Oct 2014 09:34:24 -0700 Message-ID: From: Watson Ladd To: Phillip Hallam-Baker Content-Type: multipart/alternative; boundary=20cf303a2ee1b4c518050550787f Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/w5t2N7tpOGQxT72SAAfjxMIOjYk Cc: cfrg@irtf.org Subject: Re: [Cfrg] No CFRG meeting in Honolulu X-BeenThere: cfrg@irtf.org 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: Mon, 13 Oct 2014 16:34:26 -0000 --20cf303a2ee1b4c518050550787f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Oct 13, 2014 9:30 AM, "Phillip Hallam-Baker" wrote: > > Well just as well I didn't use CFRG and the ECC discussions when I > made the justification for my travel to management. > > Given the ECC discussion going on, I expected it to meet. What more needs to be said? The costs and benefits of the various options have been outlined at length. As far as I can tell, we're waiting on a decision. > > On Mon, Oct 13, 2014 at 12:24 PM, Alexey Melnikov > wrote: > > On 13/10/2014 16:38, Mike Jones wrote: > > > > When will the CRFG meeting be at IETF 91 in Honolulu? It isn=E2=80=99t= listed in > > the agenda at https://datatracker.ietf.org/meeting/91/agenda.html. > > > > > > Chairs decided not to meet in Honolulu. We will continue to progress work on > > the mailing list before Honolulu. > > > > > > > > _______________________________________________ > > Cfrg mailing list > > Cfrg@irtf.org > > http://www.irtf.org/mailman/listinfo/cfrg > > > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg --20cf303a2ee1b4c518050550787f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Oct 13, 2014 9:30 AM, "Phillip Hallam-Baker" <phill@hallambaker.com> wrote:
>
> Well just as well I didn't use CFRG and the ECC discussions when I=
> made the justification for my travel to management.
>
> Given the ECC discussion going on, I expected it to meet.

What more needs to be said? The costs and benefits of the va= rious options have been outlined at length. As far as I can tell, we're= waiting on a decision.
>
> On Mon, Oct 13, 2014 at 12:24 PM, Alexey Melnikov
> <alexey.melnikov@isode= .com> wrote:
> > On 13/10/2014 16:38, Mike Jones wrote:
> >
> > When will the CRFG meeting be at IETF 91 in Honolulu?=C2=A0 It is= n=E2=80=99t listed in
> > the agenda at https://datatracker.ietf.org/meeting/91/agenda.html.
> >
> >
> > Chairs decided not to meet in Honolulu. We will continue to progr= ess work on
> > the mailing list before Honolulu.
> >
> >
> >
> > _______________________________________________
> > Cfrg mailing list
> > Cfrg@irtf.org
> > http://www.= irtf.org/mailman/listinfo/cfrg
> >
>
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> http://www.irtf.= org/mailman/listinfo/cfrg

--20cf303a2ee1b4c518050550787f-- From nobody Mon Oct 13 09:36:50 2014 Return-Path: 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 0BF401A1B42 for ; Mon, 13 Oct 2014 09:36:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.786, 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 Jdru5UZnJ5kz for ; Mon, 13 Oct 2014 09:36:47 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 451E41A1B18 for ; Mon, 13 Oct 2014 09:36:47 -0700 (PDT) Received: from [192.168.10.188] ([195.50.187.121]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MIuft-1XbEZP1cMb-002UZV; Mon, 13 Oct 2014 18:36:42 +0200 Message-ID: <543BFF97.9000805@gmx.net> Date: Mon, 13 Oct 2014 18:36:39 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: Phillip Hallam-Baker , Alexey Melnikov References: <4E1F6AAD24975D4BA5B16804296739439BB0974B@TK5EX14MBXC286.redmond.corp.microsoft.com> <543BFCA9.6070509@isode.com> In-Reply-To: OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="wo5nBc9OQQUsUGt3Gip76vHujvhphGDUH" X-Provags-ID: V03:K0:tXMAE6vGAnavBkzzatFDU0z1UTcw19ogTJ2s33hVqPOds0jeaOL 3pjAfKnamIKrg6u79ziq+HCxPB7G01LmEhLaqRdUlJKM5e4no/KUcVkUM2u3QUGICsvZG+L xggG+l6h2Z4owBbRHiL/rFC71hLp4uJ70B13/irrtMDV69OuSJmVM6vL1Kbjm9Tbt0fmCZE G94WdpLRspw9RdLPYTfaw== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/dyj4CGJk4iVaW1SYTMkljhFT7xk Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] No CFRG meeting in Honolulu X-BeenThere: cfrg@irtf.org 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: Mon, 13 Oct 2014 16:36:49 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --wo5nBc9OQQUsUGt3Gip76vHujvhphGDUH Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable This is somewhat surprising to me given all the discussions on this list.= What was the reason for deciding not to meet? I am hoping to see a lot of progress and face-to-face time is one way to make that progress happen. Ciao Hannes On 10/13/2014 06:29 PM, Phillip Hallam-Baker wrote: > Well just as well I didn't use CFRG and the ECC discussions when I > made the justification for my travel to management. >=20 > Given the ECC discussion going on, I expected it to meet. >=20 > On Mon, Oct 13, 2014 at 12:24 PM, Alexey Melnikov > wrote: >> On 13/10/2014 16:38, Mike Jones wrote: >> >> When will the CRFG meeting be at IETF 91 in Honolulu? It isn=E2=80=99= t listed in >> the agenda at https://datatracker.ietf.org/meeting/91/agenda.html. >> >> >> Chairs decided not to meet in Honolulu. We will continue to progress w= ork on >> the mailing list before Honolulu. >> >> >> >> _______________________________________________ >> Cfrg mailing list >> Cfrg@irtf.org >> http://www.irtf.org/mailman/listinfo/cfrg >> >=20 > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg >=20 --wo5nBc9OQQUsUGt3Gip76vHujvhphGDUH Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJUO/+XAAoJEGhJURNOOiAtkL0H/jHcQW8jaGqqe1hU1IJVvnIK QYVZWyvNwXydBAyjNOe305MOYUPe7hp4g0XmgwZRHCw89vpqWh74nOVWQY2EWEc4 aN2cvnun33pgNq0H/oYTS7VPri3mnO/0v01BLU5/ujeyXfU0bekj+xyPhDmDjr3T AJ49GSio+b+M6CdygVbzjjFGKg8BhHl2UG+EcNlLG094JPwXWgU9gh0gfR0WsQ+r SI07hK+Fy3yYXC+37g5vaNuDD1snro8m74wkqRvTHI3arFBNbfjQjz/upVqJjdGd p+tkVcvkjYIraVP4H6n3Ydafyy/A4TB8kNPnP30W8ahPQVIyi2iLf9uOMemVoi8= =BG/c -----END PGP SIGNATURE----- --wo5nBc9OQQUsUGt3Gip76vHujvhphGDUH-- From nobody Mon Oct 13 09:41:46 2014 Return-Path: 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 EBE741A1B46 for ; Mon, 13 Oct 2014 09:41:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=no 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 KP4wGEtp99Uo for ; Mon, 13 Oct 2014 09:41:45 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D3BE1A1B45 for ; Mon, 13 Oct 2014 09:41:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s9DGfbKN013200; Mon, 13 Oct 2014 18:41:37 +0200 (CEST) Received: from [192.168.217.113] (p54893EA6.dip0.t-ipconnect.de [84.137.62.166]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id F201F5B8; Mon, 13 Oct 2014 18:41:36 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Carsten Bormann In-Reply-To: Date: Mon, 13 Oct 2014 18:41:35 +0200 X-Mao-Original-Outgoing-Id: 434911294.925013-80159c19f86bfbd3ee9936b6704f6e66 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E1F6AAD24975D4BA5B16804296739439BB0974B@TK5EX14MBXC286.redmond.corp.microsoft.com> <543BFCA9.6070509@isode.com> To: Watson Ladd X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/SdY0bLUS8rDJCg-anVKhKVGV-UQ Cc: cfrg@irtf.org Subject: Re: [Cfrg] No CFRG meeting in Honolulu X-BeenThere: cfrg@irtf.org 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: Mon, 13 Oct 2014 16:41:46 -0000 > What more needs to be said? The costs and benefits of the various = options have been outlined at length. As far as I can tell, we're = waiting on a decision.=20 That now is the strongest possible reason to have a face-to-face = meeting. Gr=FC=DFe, Carsten From nobody Mon Oct 13 10:02:37 2014 Return-Path: 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 19D8B1A1ACF for ; Mon, 13 Oct 2014 10:02:36 -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 Fuy6U6MijKqY for ; Mon, 13 Oct 2014 10:02:34 -0700 (PDT) Received: from mail-yh0-x234.google.com (mail-yh0-x234.google.com [IPv6:2607:f8b0:4002:c01::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7567C1A1AE1 for ; Mon, 13 Oct 2014 10:02:22 -0700 (PDT) Received: by mail-yh0-f52.google.com with SMTP id f10so3819457yha.11 for ; Mon, 13 Oct 2014 10:02:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=eEfTELD5J/gjDAapTlTOMsCR0PR2KDVjCWvRXB/x5X0=; b=gB1wR6A60B9My+o3POGRhwu2LikkMcLl+WdcqNUHbDsu0xNT8Tlx8Yqfpvt/f0EaVg oq5FlZ2JocR4nIMw42VlzQ+A/eQeVmWiHSbG0VS6vYbI6FJoahhjztEwFv/dQeXm53Dy RoKmxLePOqw0oY0rohdGOg7cghnro5C5t4DsAfgvusDyHx2ka/ltO9+v31xL9rl2J4Fh 28m+hXndly8AHiYC54/ckqe66FIToon5ZmEwhaG9jgDpokqnQGe8LxZBYptYj9zm/qCX J6eGYME/9fFLxYTEmQ7Om4UBWeOf8dPror7iE/LlJDPFwWTnWevvb6xMsDXBy740hzJk B/Cg== MIME-Version: 1.0 X-Received: by 10.236.150.138 with SMTP id z10mr5673415yhj.138.1413219741703; Mon, 13 Oct 2014 10:02:21 -0700 (PDT) Received: by 10.170.195.149 with HTTP; Mon, 13 Oct 2014 10:02:21 -0700 (PDT) Received: by 10.170.195.149 with HTTP; Mon, 13 Oct 2014 10:02:21 -0700 (PDT) In-Reply-To: References: <4E1F6AAD24975D4BA5B16804296739439BB0974B@TK5EX14MBXC286.redmond.corp.microsoft.com> <543BFCA9.6070509@isode.com> Date: Mon, 13 Oct 2014 10:02:21 -0700 Message-ID: From: Watson Ladd To: Carsten Bormann Content-Type: multipart/alternative; boundary=20cf302efb32b1a40b050550dc3c Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/EPSr7MXtmeUvuLFQCa6qC4omkk4 Cc: cfrg@irtf.org Subject: Re: [Cfrg] No CFRG meeting in Honolulu X-BeenThere: cfrg@irtf.org 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: Mon, 13 Oct 2014 17:02:36 -0000 --20cf302efb32b1a40b050550dc3c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Oct 13, 2014 9:41 AM, "Carsten Bormann" wrote: > > > What more needs to be said? The costs and benefits of the various options have been outlined at length. As far as I can tell, we're waiting on a decision. > > That now is the strongest possible reason to have a face-to-face meeting. Why can't you send an email saying what you want to say? If the conversation can't happen over email, why would it work face to face? I don't have thousands of dollars to go to Hawaii for the week. Furthermore, while the formula and field choices are almost irrelevant, the point format and coordinate choice have security implications. I'd like to see a clear record of how these decisions were made, which f2f does not lend itself to. Sincerely, Watson Ladd > > Gr=C3=BC=C3=9Fe, Carsten --20cf302efb32b1a40b050550dc3c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Oct 13, 2014 9:41 AM, "Carsten Bormann" <cabo@tzi.org> wrote:
>
> > What more needs to be said? The costs and benefits of the various= options have been outlined at length. As far as I can tell, we're wait= ing on a decision.
>
> That now is the strongest possible reason to have a face-to-face meeti= ng.

Why can't you send an email saying what you want to say?= If the conversation can't happen over email, why would it work face to= face?

I don't have thousands of dollars to go to Hawaii for th= e week. Furthermore,=C2=A0 while the formula and field choices are almost i= rrelevant,=C2=A0 the point format and coordinate choice have security impli= cations. I'd like to see a clear record of how these decisions were mad= e, which f2f does not lend itself to.

Sincerely,
Watson Ladd

>
> Gr=C3=BC=C3=9Fe, Carsten

--20cf302efb32b1a40b050550dc3c-- From nobody Mon Oct 13 10:49:58 2014 Return-Path: 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 AD6441A1AB3 for ; Mon, 13 Oct 2014 10:49:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.641 X-Spam-Level: * X-Spam-Status: No, score=1.641 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.982, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, THIS_AD=0.086] autolearn=no 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 7JWjKrUMNhuv for ; Mon, 13 Oct 2014 10:49:54 -0700 (PDT) Received: from aspartame.shiftleft.org (199-116-74-168-v301.PUBLIC.monkeybrains.net [199.116.74.168]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 726E41A1BC3 for ; Mon, 13 Oct 2014 10:49:51 -0700 (PDT) Received: from [192.168.1.129] (unknown [192.168.1.1]) by aspartame.shiftleft.org (Postfix) with ESMTPSA id 2FDE0F5EAE; Mon, 13 Oct 2014 10:48:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=shiftleft.org; s=sldo; t=1413222487; bh=MzC9FiWfou8JK04GK6Yy68OQywkg4XAdJqH80rO2VMY=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=kA1vuaAEPiI8GRgAePDZxmPCPZ53Kt64J56TZ/WEthz8KK6HSXTd9ozREb+j5p8zm 0cRTUmCw52h9xg+JIaAdGD+pugOd3V2qOATnqe2OPSQH9bqzV+JWVobaSw0hVl7kC5 oi3dKhrGzKZHFP0EgHcRYeOB7HVwem/9GAu+6gAM= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Michael Hamburg In-Reply-To: <20141013113607.30288.qmail@cr.yp.to> Date: Mon, 13 Oct 2014 10:49:49 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <89BF5E7A-69A6-4B7B-8BE7-49599566CAC4@shiftleft.org> References: <20141013113607.30288.qmail@cr.yp.to> To: "D. J. Bernstein" X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/oL94jGcCaAyoXdfhxx3BQ-UmYLQ Cc: cfrg@irtf.org Subject: Re: [Cfrg] Publicly verifiable benchmarks X-BeenThere: cfrg@irtf.org 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: Mon, 13 Oct 2014 17:49:55 -0000 > On Oct 13, 2014, at 4:36 AM, D. J. Bernstein wrote: > David Jacobson writes: >> It would be nice if you tagged implementations (of algorithms where = it >> matters) into according to leakage resistance. >=20 > Yes. Some implementors advertise constant-time software, but right now > SUPERCOP doesn't provide a structured mechanism for this = advertisement. > One of the difficulties here is that some people are more stringent = than > others in what they mean by "constant time"; I'll write a separate > message about this. You used to have int timingattacks(void) { =E2=80=A6 }. Or was that = just a BATMAN thing? >=20 > Michael Hamburg writes: >> some of the machines on bench.cr.yp.to have quirks >> (turboboost, mismatched cycle counter frequency, etc) which can make >> the data difficult to interpret and reproduce. >=20 > Turbo Boost is noted as "boost" in red (as is Turbo Core), and is also > easy to spot as unusually large gaps between the quartiles. See, e.g., > http://bench.cr.yp.to/results-dh.html#amd64-hydra3. >=20 > The SUPERCOP documentation has a "Reducing randomness in benchmarks" > section that tells people how to turn off hyperthreading and Turbo > Boost. Eventually we'd like to measure what the actual Turbo Boost > speedup is, but this isn't as easy as it sounds. It sure doesn=E2=80=99t sound easy. > Some CPUs don't give the OS full control over clock frequencies. Of > course, clock frequency makes far less of a difference in cycle counts > than it makes in other metrics such as operations per second, but it > does sometimes make a noticeable difference, especially for code that > doesn't fit into L1 cache. At least on Intel CPUs, the counter read by RDTSC runs at a constant = rate which may or may not have anything to do with the CPU=E2=80=99s = actual frequency. So for example, on a Haswell MacBook Air 1.7GHz = (boost to 3.3GHz), the counter runs at 2.2GHz even when TurboBoost is = disabled. This also means that unless you have privilege to read the = pcr cycle counter, boosting does ruin the cycle counts just as much as = the ops/second. In the past I=E2=80=99ve seen data on bench.cr.yp.to which looked like = it may have been affected by this problem: it showed reasonable = quartiles but noticeably faster or slower speeds across all benchmarks. = But that was some time ago, so maybe it=E2=80=99s gone now. > Of course, asm code produces much less variability. That=E2=80=99s a good point. The downside is that you have to target a = specific architecture (eg choose for each directory what vector support = you have), but that=E2=80=99s no different from what most library = packagers do. Cheers, =E2=80=94 Mike= From nobody Mon Oct 13 10:50:30 2014 Return-Path: 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 645FA1A6EE7 for ; Mon, 13 Oct 2014 10:50:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.786 X-Spam-Level: X-Spam-Status: No, score=-2.786 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.786] 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 6jwjdU8YrbH0 for ; Mon, 13 Oct 2014 10:50:15 -0700 (PDT) Received: from waldorf.isode.com (ext-bt.isode.com [217.34.220.158]) by ietfa.amsl.com (Postfix) with ESMTP id DE1681A6EE6 for ; Mon, 13 Oct 2014 10:50:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1413222614; d=isode.com; s=selector; i=@isode.com; bh=q/YADumKP6scVjmsErX8IkeQ3naUW16YaL+WO5bGHUM=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=b/xWtu/55OISMKrMs9QLmLh4aJ5S2t+FNTKzL0eJfwj3lftPJYXO7dYcCSpMwtgMLuGciu yaLZetcncUgN3xTxL7Bx6GwISdru2xDdi60dCldTflBuNYlQg0EcycfhDHNLQuTZmu6HiG EJRRfEvT3L1WHNmQjjS8GicnPLOnR4M=; Received: from [172.20.1.47] (dhcp-47.isode.net [172.20.1.47]) by waldorf.isode.com (submission channel) via TCP with ESMTPA id ; Mon, 13 Oct 2014 18:50:13 +0100 Message-ID: <543C10E5.90302@isode.com> Date: Mon, 13 Oct 2014 18:50:29 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 To: Hannes Tschofenig References: <4E1F6AAD24975D4BA5B16804296739439BB0974B@TK5EX14MBXC286.redmond.corp.microsoft.com> <543BFCA9.6070509@isode.com> <543BFF97.9000805@gmx.net> In-Reply-To: <543BFF97.9000805@gmx.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/b5xJTFEvBA73pGVSg_LTNPu9Ziw Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] No CFRG meeting in Honolulu X-BeenThere: cfrg@irtf.org 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: Mon, 13 Oct 2014 17:50:22 -0000 On 13/10/2014 17:36, Hannes Tschofenig wrote: > This is somewhat surprising to me given all the discussions on this list. > > What was the reason for deciding not to meet? People who can make ECC discussion productive will not be able to make it to Honolulu. > I am hoping to see a lot of progress and face-to-face time is one way to > make that progress happen. From nobody Mon Oct 13 10:56:55 2014 Return-Path: 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 924C61A6F6B for ; Mon, 13 Oct 2014 10:56:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-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 wGXErKRsjPsk for ; Mon, 13 Oct 2014 10:56:51 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0690.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::690]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FF781A6F63 for ; Mon, 13 Oct 2014 10:55:31 -0700 (PDT) Received: from DBXPR03MB383.eurprd03.prod.outlook.com (10.141.10.15) by DBXPR03MB382.eurprd03.prod.outlook.com (10.141.10.12) with Microsoft SMTP Server (TLS) id 15.0.1044.10; Mon, 13 Oct 2014 17:55:09 +0000 Received: from DBXPR03MB383.eurprd03.prod.outlook.com ([10.141.10.15]) by DBXPR03MB383.eurprd03.prod.outlook.com ([10.141.10.15]) with mapi id 15.00.1049.012; Mon, 13 Oct 2014 17:55:08 +0000 From: "Paterson, Kenny" To: Mike Jones , "cfrg@irtf.org" Thread-Topic: [Cfrg] CFRG meeting at IETF 91 Thread-Index: AQHP5w7Tl48+2WnGrE6St536Aa3eMA== Date: Mon, 13 Oct 2014 17:55:08 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [77.54.68.129] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:DBXPR03MB382; x-exchange-antispam-report-test: UriScan:; x-forefront-prvs: 03630A6A4A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(51704005)(479174003)(199003)(164054003)(24454002)(189002)(36756003)(101416001)(2656002)(87936001)(85852003)(1511001)(64706001)(74482002)(46102003)(80022003)(66066001)(2421001)(20776003)(120916001)(31966008)(107886001)(106356001)(92726001)(86362001)(4396001)(76482002)(85306004)(40100003)(122556002)(83506001)(97736003)(21056001)(95666004)(105586002)(15975445006)(2561002)(106116001)(19580405001)(50986999)(19580395003)(2501002)(92566001)(54356999); DIR:OUT; SFP:1101; SCL:1; SRVR:DBXPR03MB382; H:DBXPR03MB383.eurprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: rhul.ac.uk Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/xkm3273aI2LtZUhHF4Huv9M2OvQ Subject: Re: [Cfrg] CFRG meeting at IETF 91 X-BeenThere: cfrg@irtf.org 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: Mon, 13 Oct 2014 17:56:53 -0000 Dear Mike, CFRG will not meet during IETF 91. The chairs hope to move things along as much as possible on the lists in the run-up to the meeting - we have the on-going work on ECC, the work on ChaCha20+Poly1305, and a few other items to keep us busy. Regards Kenny=20 On 13/10/2014 16:38, "Mike Jones" wrote: >When will the CRFG meeting be at IETF 91 in Honolulu? It isn=B9t listed i= n >the agenda at >https://datatracker.ietf.org/meeting/91/agenda.html. >=20 > Thanks, > -- Mike >=20 > From nobody Tue Oct 14 02:36:52 2014 Return-Path: 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 431F61A7000 for ; Tue, 14 Oct 2014 02:36:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_LOW=-0.7, UNPARSEABLE_RELAY=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 xRThhF_R6kv8 for ; Tue, 14 Oct 2014 02:36:49 -0700 (PDT) Received: from mace.cs.uic.edu (mace.cs.uic.edu [131.193.32.224]) by ietfa.amsl.com (Postfix) with SMTP id C70AB1A6FFE for ; Tue, 14 Oct 2014 02:36:48 -0700 (PDT) Received: (qmail 29452 invoked by uid 1011); 14 Oct 2014 09:36:45 -0000 Received: from unknown (unknown) by unknown with QMTP; 14 Oct 2014 09:36:45 -0000 Received: (qmail 24708 invoked by uid 1001); 14 Oct 2014 09:36:40 -0000 Date: 14 Oct 2014 09:36:40 -0000 Message-ID: <20141014093640.24706.qmail@cr.yp.to> From: "D. J. Bernstein" To: cfrg@irtf.org Mail-Followup-To: cfrg@irtf.org In-Reply-To: <2FBC676C3BBFBB4AA82945763B361DE608F1D021@MX17A.corp.emc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/ksz0OgikTS3e0JVDEHa6xRKJZec Subject: [Cfrg] Constant-time implementations X-BeenThere: cfrg@irtf.org 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: Tue, 14 Oct 2014 09:36:51 -0000 Parkinson, Sean writes: > Also, I am concerned that, while some curves are being implemented to > be constant time, not all curves are being implemented to be cache > attack resistant. When I say "constant time", I don't merely mean making the _total_ time constant: I mean systematically avoiding all data flow from secrets to the CPU's instruction timing, providing full immunity to cache-timing attacks, branch-prediction attacks, etc. On typical CPUs this means avoiding all data flow from secrets to branch conditions, load addresses, and store addresses. On some CPUs there are other timing leaks: for example, if there are early-abort multipliers, then for me "constant time" says, for each multiplication instruction in the code, that the abort condition is independent of secret data. Unfortunately, I've often seen "constant time" used for code that doesn't even try to meet the same requirements, or that tries and fails: * OpenSSL added "constant-time" code where there was no dependence on secret data in the choice of _cache lines_ being accessed. However, https://cryptojedi.org/peter/data/chesrump-20130822.pdf showed that this strategy actually produces variable timings and is thus inadequate to guarantee protection against cache-timing attacks. * Section 1.2 of http://cr.yp.to/hecdh/kummer-20140218.pdf gives two examples of DH implementations that were incorrectly claimed to take constant time. I _think_ that all of the CFRG curve proposers are imposing the same stringent requirements upon their speed reports that I impose upon mine. For example, Microsoft says that one "should" avoid "leaking access patterns" and should write "code which does not contain branches depending on secret data". However, I haven't seen a clear statement of exactly what protections _are_ actually provided by Microsoft's ECCLib. Everything that ECCLib says---"regular, constant-time execution" and "full protection against timing and cache attacks" and "no correlation between timing and secret data"---is something that could just as easily have been said about the broken OpenSSL code mentioned above. It would be helpful for Microsoft to clarify the situation. I don't mean to suggest that there's a huge performance difference between constant-time ECC and non-constant-time ECC---usually the gap is below 20%. I do mean to suggest that getting things right takes work. What really bugs me about the NIST curves (and the Brainpool curves and to a smaller extent Microsoft's curves) isn't their slowness but rather their excessive complexity, leading to security problems: http://cr.yp.to/talks/2013.05.31/slides-dan+tanja-20130531-4x3.pdf We know how to eliminate many of these problems by choosing our cryptographic systems more carefully. ---Dan From nobody Tue Oct 14 06:14:16 2014 Return-Path: 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 9F1701A87EB for ; Tue, 14 Oct 2014 06:14:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] 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 knEWCp66bGsu for ; Tue, 14 Oct 2014 06:14:10 -0700 (PDT) Received: from nm15-vm2.access.bullet.mail.gq1.yahoo.com (nm15-vm2.access.bullet.mail.gq1.yahoo.com [216.39.63.43]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFE671A8822 for ; Tue, 14 Oct 2014 06:14:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sbcglobal.net; s=s1024; t=1413292449; bh=1uwLOnIHtkfHaqCqqmvMqVAWJCWzvbsBShc8YlLYiDI=; h=Date:From:To:Subject:References:In-Reply-To:From:Subject; b=jGd/CFNsq10ilWG2XlCdP4b/uOGLyipBipMyFrwy6/OgSapCWaRfrs1JT9451Udq+hLdqInPUZHLSGShipWPf0EVgjz+vPcuU21MB5xs3D9Kjou/+tG7lHeQSNP7wWo1PKQtrOgAzq1/v3qJ77QTNwezE11jR/JRBQR1N1HOtGM= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=sbcglobal.net; b=WudH8zW89hz9gNRtufi3tyes/dJgf1a+79UrXeHugQwuQrEgU3oYGw1XR4yMlX03OBmJ5icuH0/rCIVPKrgiFz/wJRla96p/pM74FXTdLPJ4mi/4VTVEiPcSVzTsx84RNHfIuSfPErc18H6Td0/ddMKyIFojICPS5da+c51+yLo=; Received: from [216.39.60.171] by nm15.access.bullet.mail.gq1.yahoo.com with NNFMP; 14 Oct 2014 13:14:09 -0000 Received: from [67.195.23.147] by tm7.access.bullet.mail.gq1.yahoo.com with NNFMP; 14 Oct 2014 13:14:09 -0000 Received: from [127.0.0.1] by smtp119.sbc.mail.gq1.yahoo.com with NNFMP; 14 Oct 2014 13:14:09 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sbcglobal.net; s=s1024; t=1413292449; bh=1uwLOnIHtkfHaqCqqmvMqVAWJCWzvbsBShc8YlLYiDI=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=cHgBIlb90HHOORr6Jv/qjlRzhU1UOFcSe9aEfiH9HSfRkfQyu6qF8NylSlE/nYW009MkKtmywYcrFK9JTGCQBioX+C/eocEGeUT3HoJqg6eB15loSPYFPpEucHdBKPXy+YAapZuHZ4ks0ZY+fMDZIc6vTydvnu4REsLEi4vKIj0= X-Yahoo-Newman-Id: 690351.31478.bm@smtp119.sbc.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 1epc_HcVM1nL3aNzH3uflRBWqXS3b9RcNJf3beodmI9LiKm KjVdqz3_LG0e3WtgMsHig_N0OxvC1MA1iQ6qwC1lhAy4c7ptVP3hQJ8ycDdp v0Jz0zeKFZ8EQVjDS_5BEUGl2aVwDeLXyaD4mSFBYnmQIBNZHjMw9T50Plax KdamETxz6K6K_d0ZmXL4EfcSmB3jUR4rsziGwDDCOA83.njQ09.Elkz3NCmq nJp3xklvbU4uHA4Y9UQ2w5QtAq2FGJRAE1x_KGg0vUUT38.qRnWppOId.TK5 OMzgtUZTGrWoqR0mgnElsZurVo4TnBo.e_yCzt2Wq2tUOsIxuMQTLfVbVNvF 9ajIFccPGl2esA8ESlgujE8qGJN_dbxNxVKjEp8lttj3yZIECQ5pbu6KfDtt 36G6XS07DnhQnGSqMHXp9Z44HFw0GBgeDqZ6cG6RQjT6q0bSoW0264OYLUL1 0z7aDZV5ZYZUEz0vZwF3ural.M1hCvOd64ZV1oao6yAN1ORT9dK6aSRv454t mWnrfQb.4gtMzKrEO7YFY4NNmK_EE_HK2BZSGVrZXII_0y.9UaA54KIz4uNG d5LT5nexEyJkOqYHSvYyd1b8gUixTDHHY51SFb53bRS_Sbdfv.yIEEwdLQQo 76PDVR_TtV_M1iuKHGjIu9a3RSazEzkOYSUT7RHbzCx2lHxAjgmhfrtAx8WS XMmAewXRg1QBgabm0G2ZRdFKID9V3E_Gu7dxvVciEr7kkIFg- X-Yahoo-SMTP: nOrmCa6swBAE50FabWnlVFUpgFVJ9Gbi__8U5mpvhtQq7tTV1g-- Message-ID: <543D21A0.3000109@sbcglobal.net> Date: Tue, 14 Oct 2014 06:14:08 -0700 From: David Jacobson User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: cfrg@irtf.org References: <20141014093640.24706.qmail@cr.yp.to> In-Reply-To: <20141014093640.24706.qmail@cr.yp.to> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/GeWqEkeffZ6gcT9XS8W-PTHMvBA Subject: Re: [Cfrg] Constant-time implementations X-BeenThere: cfrg@irtf.org 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: Tue, 14 Oct 2014 13:14:13 -0000 On 10/14/14, 2:36 AM, D. J. Bernstein wrote: > Parkinson, Sean writes: >> Also, I am concerned that, while some curves are being implemented to >> be constant time, not all curves are being implemented to be cache >> attack resistant. > When I say "constant time", I don't merely mean making the _total_ time > constant: I mean systematically avoiding all data flow from secrets to > the CPU's instruction timing, providing full immunity to cache-timing > attacks, branch-prediction attacks, etc. > > On typical CPUs this means avoiding all data flow from secrets to branch > conditions, load addresses, and store addresses. On some CPUs there are > other timing leaks: for example, if there are early-abort multipliers, > then for me "constant time" says, for each multiplication instruction in > the code, that the abort condition is independent of secret data. > > Unfortunately, I've often seen "constant time" used for code that > doesn't even try to meet the same requirements, or that tries and fails: > > * OpenSSL added "constant-time" code where there was no dependence on > secret data in the choice of _cache lines_ being accessed. However, > https://cryptojedi.org/peter/data/chesrump-20130822.pdf showed that > this strategy actually produces variable timings and is thus > inadequate to guarantee protection against cache-timing attacks. > > * Section 1.2 of http://cr.yp.to/hecdh/kummer-20140218.pdf gives two > examples of DH implementations that were incorrectly claimed to > take constant time. > > I _think_ that all of the CFRG curve proposers are imposing the same > stringent requirements upon their speed reports that I impose upon mine. > For example, Microsoft says that one "should" avoid "leaking access > patterns" and should write "code which does not contain branches > depending on secret data". However, I haven't seen a clear statement of > exactly what protections _are_ actually provided by Microsoft's ECCLib. > Everything that ECCLib says---"regular, constant-time execution" and > "full protection against timing and cache attacks" and "no correlation > between timing and secret data"---is something that could just as easily > have been said about the broken OpenSSL code mentioned above. It would > be helpful for Microsoft to clarify the situation. > > I don't mean to suggest that there's a huge performance difference > between constant-time ECC and non-constant-time ECC---usually the gap is > below 20%. I do mean to suggest that getting things right takes work. > What really bugs me about the NIST curves (and the Brainpool curves and > to a smaller extent Microsoft's curves) isn't their slowness but rather > their excessive complexity, leading to security problems: > > http://cr.yp.to/talks/2013.05.31/slides-dan+tanja-20130531-4x3.pdf > > We know how to eliminate many of these problems by choosing our > cryptographic systems more carefully. > > ---Dan > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg > Sometimes data dependent branches cannot be avoided without a serious performance penalty. I'm thinking of modular inversion using the binary method. But it that case it is easy to use blinding. 1/k = b * (1 / (b * k)) where b is a random blinding value. In this case, I think it is still fair consider this leakage resistant, even though the inversion is actually full of data dependent branches. Of course, the time to compute b has to be included in the benchmark. But do those blinding values have to be generated with heavy-weight schemes such as the algorithms in NIST SP 800-90A, or is it, in practice, safe to use something fast like the keystream from RC4? --David Jacobson From nobody Tue Oct 14 06:22:53 2014 Return-Path: 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 7EC661A8842 for ; Tue, 14 Oct 2014 06:22:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no 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 BkDVw4nsrBKz for ; Tue, 14 Oct 2014 06:22:49 -0700 (PDT) Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0083F1A8836 for ; Tue, 14 Oct 2014 06:22:48 -0700 (PDT) Received: by mail-la0-f46.google.com with SMTP id gi9so8388776lab.5 for ; Tue, 14 Oct 2014 06:22:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=cOB/iFbXIQIUoaQja6Qy54swHVi0uO0JJxpzNYCXhnE=; b=znw/noPhUCva2JBQme7TVKuyzktk/u5ylj14aUYzv91UOzthVZcGWeW1AQt7Xfyh4p yA+DWSjLBvJL/wYLn3ydpG8aCTrsni7aFh12KBYdnUo7AsEnXu1herLuqByScr/AAEaI EDdahaEZbdAXNsDFWK2rY6t/3fe0cuvEgf859cDWfaLbsMOqIB3mkFbJB27z8IurYL7s GUXjO0Js+dwTqFduCTbyRIiYBuhG92huLQuAyzrkc50l8U2whkKlK+Ktqb56Hd/r1ug/ EF5xV6OOKLPxMW44p2ibnZDRbwZbJ/dsmhjjZBSusvGI6IJlHjk6XpAJzhn/e3G1TG7w cRag== MIME-Version: 1.0 X-Received: by 10.112.169.66 with SMTP id ac2mr5241304lbc.73.1413292967218; Tue, 14 Oct 2014 06:22:47 -0700 (PDT) Sender: alangley@gmail.com Received: by 10.112.241.103 with HTTP; Tue, 14 Oct 2014 06:22:47 -0700 (PDT) In-Reply-To: <543D21A0.3000109@sbcglobal.net> References: <20141014093640.24706.qmail@cr.yp.to> <543D21A0.3000109@sbcglobal.net> Date: Tue, 14 Oct 2014 06:22:47 -0700 X-Google-Sender-Auth: n1qo18If1BAI-IS3vDkPtiURA8k Message-ID: From: Adam Langley To: David Jacobson Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/CJGyVu--HUhiZUoJPZHrh8d0diQ Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] Constant-time implementations X-BeenThere: cfrg@irtf.org 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: Tue, 14 Oct 2014 13:22:51 -0000 On Tue, Oct 14, 2014 at 6:14 AM, David Jacobson wrote: > Sometimes data dependent branches cannot be avoided without a serious > performance penalty. I'm thinking of modular inversion using the binary > method. But it that case it is easy to use blinding. > > 1/k = b * (1 / (b * k)) > > where b is a random blinding value. In practice, field inversion is done using Fermat's little theorem. I agree that a blinded binary inversion should be faster, but Fermat's little theorem is simple and safe. Quoting from the curve25591 paper: "[Inversion] is about 7% of the Curve25519 computation. An extended-Euclid inversion of z, randomized to protect against timing attacks, might be faster, but the maximum potential speedup is very small, while the cost in code complexity is large." Cheers AGL -- Adam Langley agl@imperialviolet.org https://www.imperialviolet.org From nobody Tue Oct 14 06:49:13 2014 Return-Path: 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 D44551A882D for ; Tue, 14 Oct 2014 06:49:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 Fmt3Xuf2djqP for ; Tue, 14 Oct 2014 06:49:05 -0700 (PDT) Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26C041A8787 for ; Tue, 14 Oct 2014 06:49:04 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id b6so8267587lbj.17 for ; Tue, 14 Oct 2014 06:49:03 -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 :content-transfer-encoding:message-id:references:to; bh=gvqzQOiw4wvk7KGqoKE7GT+/glLVIDbr4yf+yehKQZ8=; b=HFlPPVmZ37C5xt9FleBC+/h8CnUn9kqZyHbFYTFEu0IyY+ZMm02RXhnrjxxO//JKhD /W3h/mJHgwjCKmkmLJr8i775CF9N2x51AIOvXopLd30Ak/56M0T7u5HFtFEj8gXjrgD+ VPifbggDEp0AIQ/sUBZP5zie6dBCsGNu8ETIuU29emP9NYQou9pOyDSMNFZBUPjsLr8v qb+X47WTytXuH+N4+Vv/Ekrne6/vcosJL+gSei2asAJ8v6auU8irIVexLqA8zlH0FkO7 geAt3IwOcYYHWxcEvueYbcYfxSaZYG1BR7KXFa+QtDhB2jqD01pa23hOXtow3lLyxIvV QaTg== X-Received: by 10.152.1.42 with SMTP id 10mr5700073laj.4.1413294543397; Tue, 14 Oct 2014 06:49:03 -0700 (PDT) Received: from [192.168.1.104] (IGLD-84-228-192-190.inter.net.il. [84.228.192.190]) by mx.google.com with ESMTPSA id b2sm5624673laf.34.2014.10.14.06.49.02 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 14 Oct 2014 06:49:02 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Yoav Nir In-Reply-To: Date: Tue, 14 Oct 2014 16:49:02 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <7421C78D-A667-419B-8576-DA837AF20188@gmail.com> References: <20141014093640.24706.qmail@cr.yp.to> <543D21A0.3000109@sbcglobal.net> To: "cfrg@irtf.org" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/ubPriDgLZUg4OOtJysjcoaNCrWE Subject: Re: [Cfrg] Constant-time implementations X-BeenThere: cfrg@irtf.org 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: Tue, 14 Oct 2014 13:49:07 -0000 Doesn=92t it become better (or at least safer) at some point to set a = timer before beginning the operation and then not use the results until = the timer expires? Sure this has a cost in memory, but any fool can write an implementation = with an upper bound on processing time, whereas true constant time is = both hard and has a 20% overhead (according to DJB=92s message = upthread). Yoav From nobody Tue Oct 14 08:00:54 2014 Return-Path: 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 BA8151A88DC for ; Tue, 14 Oct 2014 08:00:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 y_3LNZZzv0RX for ; Tue, 14 Oct 2014 08:00:50 -0700 (PDT) Received: from mail-yh0-x235.google.com (mail-yh0-x235.google.com [IPv6:2607:f8b0:4002:c01::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E55F1A87AF for ; Tue, 14 Oct 2014 08:00:50 -0700 (PDT) Received: by mail-yh0-f53.google.com with SMTP id b6so5137850yha.12 for ; Tue, 14 Oct 2014 08:00:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=GMtAnF8v/RnlPGgA8j4tgsURRQRT+gIssDUq7avju2I=; b=KY+77IER1FB4nuajDHgrxwYtiT0Pqad8GRlPFGq1loeb1jO93R+jalOCZYZ+XYQ2cg dCuzX4bHcryHhP06OWh1l4rDguZFAaUROH5vBYcKmH8SyAvmnTsxe3yxQfi8DIsKytZV LIO7UWJ29U5R0HYiH2w0NGYcHbUhcExdjcrfNGW8Xo9WiKbKrQkTvhyuLZopeKRrV7Of YtCoahU/5Q2mISP0ZP83c8Kn37V/avAaWJZyT97+bTSbBGSIEo7FRhcki1jmICj/bi6U 45b9e+rgopZKAl0ZvmqgpF6MZHx5Lf8LsV+mF3SoPNn5hdaeXOw5mIoZrlBpSUcNx3hT oAlg== MIME-Version: 1.0 X-Received: by 10.236.17.197 with SMTP id j45mr7542131yhj.49.1413298847800; Tue, 14 Oct 2014 08:00:47 -0700 (PDT) Received: by 10.170.195.149 with HTTP; Tue, 14 Oct 2014 08:00:47 -0700 (PDT) Date: Tue, 14 Oct 2014 08:00:47 -0700 Message-ID: From: Watson Ladd To: "cfrg@irtf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/fvCDud9o5S9dZEYH38bv6UAyDdg Subject: [Cfrg] Complexity of the Microsoft curve proposal X-BeenThere: cfrg@irtf.org 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: Tue, 14 Oct 2014 15:00:51 -0000 Dear all, Sadly DJBs linked slides aren't explicitly about the microsoft curves. So I'd like to explain why the NUMS curves, with the prefered coordinate system, are more complex than the curve and coordinate choices DJB and Mike Hamburg have made in their prefered curves. If we send twisted Edward points with a=-1, d nonsquare, and p congruent to 3 mod 4, the addition law is incomplete as a is not a square. This forces implementers to add checks required for security, but not interoperability, which will be neglected. Sending points in coordinates where a complete addition law exists, even if an incomplete one is used internally, removes this temptation. I have exploited this issue against Bouncycastle (now fixed) and several other TLS implementations. Sending regular Edwards points solves this issue: the addition law is complete so long as d is a nonsquare. If we send twisted Edwards points, we also have to check that x and y lie on the curve. Failure to make this check is exploitable as well. By contrast, sending compressed points or Montgomery coordinates removes this difficulty. The Montgomery ladder is also easy to make timing-attack resistant with high performance, and is very simple to implement. So long as p is not congruent to plus or minus 1 mod 8, taking square roots mod p is easy. Again, this is an argument about coordinates, not the curve. The curve is virtually irrelevant. Sincerely, Watson Ladd From nobody Tue Oct 14 08:05:55 2014 Return-Path: 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 523F41A88F3 for ; Tue, 14 Oct 2014 08:05:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 8C3d9BQCjWMk for ; Tue, 14 Oct 2014 08:05:49 -0700 (PDT) Received: from mail-yh0-x22a.google.com (mail-yh0-x22a.google.com [IPv6:2607:f8b0:4002:c01::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 179C11A88EE for ; Tue, 14 Oct 2014 08:05:49 -0700 (PDT) Received: by mail-yh0-f42.google.com with SMTP id t59so5129416yho.15 for ; Tue, 14 Oct 2014 08:05:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=RxIY2O/Fx/iGKuSgzV2IqOAhGam4J4QLam2CZY24vGY=; b=kzCU6GVbgHfZOhLM9m8ecaVuCjymjKs4OXq83IkDOb8jvEvf7PofhqeoU12++gRtv8 foVmVx4wRcuwHqCVhoJN9UxcqO5J17pY8H1XUIig+u/2Uzfh9qDpwOTbjUTCAw6kYucl 8ZdazpqfDWiruIcqArYMOB7JFm/r4SvTg9IUZspGrkSJhg9BPa8AIFgHCMIWc2ZBruJk A+DV7O1dvGrOdJYREzIY7mHfThCrTqwDVVc3YeDoTVKuyVn2vlOcchaBoovWZckyPaKt QpIlvMSbuUXjMG4+hiuHeQFvJ92JWfju4DrWaJR96VCMRH4iJ1LPMm5g5O8/d17DQARx xaww== MIME-Version: 1.0 X-Received: by 10.236.103.170 with SMTP id f30mr248066yhg.4.1413299147874; Tue, 14 Oct 2014 08:05:47 -0700 (PDT) Received: by 10.170.195.149 with HTTP; Tue, 14 Oct 2014 08:05:47 -0700 (PDT) In-Reply-To: <7421C78D-A667-419B-8576-DA837AF20188@gmail.com> References: <20141014093640.24706.qmail@cr.yp.to> <543D21A0.3000109@sbcglobal.net> <7421C78D-A667-419B-8576-DA837AF20188@gmail.com> Date: Tue, 14 Oct 2014 08:05:47 -0700 Message-ID: From: Watson Ladd To: Yoav Nir Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/y3I4EQ1fTYUpgX1KQf4xx_jt0nA Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] Constant-time implementations X-BeenThere: cfrg@irtf.org 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: Tue, 14 Oct 2014 15:05:52 -0000 On Tue, Oct 14, 2014 at 6:49 AM, Yoav Nir wrote: > Doesn=E2=80=99t it become better (or at least safer) at some point to set= a timer before beginning the operation and then not use the results until = the timer expires? > > Sure this has a cost in memory, but any fool can write an implementation = with an upper bound on processing time, whereas true constant time is both = hard and has a 20% overhead (according to DJB=E2=80=99s message upthread). Any fool can download tweetnacl.c and get an implementation of curve25519 that is constant-time. Likewise any fool can rip implementations out of eBATS. We don't need custom implementations and we certainly don't need people who can't write constant time code doing crypto. Furthermore, setting a timer doesn't deal with cache-based attacks. If you want more speed than current proposals provide, let me interest you in genus 2 Jacobians, endomorphisms, exotic uses of base change, long before you get any benefit from removing timing-attack resistance. Is Curve25519 really too slow? Sincerely, Watson Ladd > > Yoav > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg --=20 "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Tue Oct 14 10:43:03 2014 Return-Path: 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 D02B51A90EE for ; Tue, 14 Oct 2014 10:43:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.555 X-Spam-Level: * X-Spam-Status: No, score=1.555 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.982, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no 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 mJYOEkYZgIlh for ; Tue, 14 Oct 2014 10:43:00 -0700 (PDT) Received: from aspartame.shiftleft.org (199-116-74-168-v301.PUBLIC.monkeybrains.net [199.116.74.168]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 801971A90E9 for ; Tue, 14 Oct 2014 10:43:00 -0700 (PDT) Received: from [192.168.1.124] (unknown [192.168.1.1]) by aspartame.shiftleft.org (Postfix) with ESMTPSA id 27A113AA13; Tue, 14 Oct 2014 10:41:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=shiftleft.org; s=sldo; t=1413308470; bh=rynId8qas6cJjIT6o3XBG2f6kwqG9NwhpvlB+2MhUFQ=; h=Date:From:To:CC:Subject:References:In-Reply-To:From; b=ACOVI4UeTRJy+x14b52boD9NXtZEnjkDTpELsBD8Ze8Gp8ioiV60AzbbzMYGX1T8T KaElaS8ztBf545l0DVADMdrnwBDwCjU4OQvBFfk8EG067IYIql025ELDV63y9wRhJl /dWxitlg1Dj7t+XenN0ct9Y5HM3aCu6Ihp2WbYcA= Message-ID: <543D60A0.8070205@shiftleft.org> Date: Tue, 14 Oct 2014 10:42:56 -0700 From: Mike Hamburg User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: Watson Ladd , Yoav Nir References: <20141014093640.24706.qmail@cr.yp.to> <543D21A0.3000109@sbcglobal.net> <7421C78D-A667-419B-8576-DA837AF20188@gmail.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/gij-JUrA-NC7J3aNVN7jH1QjQu4 Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] Constant-time implementations X-BeenThere: cfrg@irtf.org 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: Tue, 14 Oct 2014 17:43:02 -0000 On 10/14/2014 08:05 AM, Watson Ladd wrote: > On Tue, Oct 14, 2014 at 6:49 AM, Yoav Nir wrote: >> Doesn’t it become better (or at least safer) at some point to set a timer before beginning the operation and then not use the results until the timer expires? >> >> Sure this has a cost in memory, but any fool can write an implementation with an upper bound on processing time, whereas true constant time is both hard and has a 20% overhead (according to DJB’s message upthread). > This ends up working very poorly for many reasons, beyond (as Watson said) not solving your problem. Estimating maximum time is difficult, especially across different platforms, and especially on a loaded system where you might miss cache or be descheduled. It will probably be more than 20% overhead, whereas DJB's dataflow-constant-time definition usually has *less than* 20% overhead (from my numbers, ~6% for Goldilocks on Haswell). Worse, you will need to figure out how to measure time, and how to sleep. That means threading libraries or busy-waiting, neither of which is appealing. It is also important to recognize that timing isn't the only side channel. In particular, constant-time array indexing (with logic operations) will be much leakier than direct lookups for a power-channel adversary. So for software which runs on a PC or server, then timing- (, cache-, branch-) invariance is the important thing, but on an embedded device, power, EM and possibly fault resistance are more important. This will necessitate blinding instead of constant-time array indexing, and usually has a much higher overhead. As Torsten said, smart cards don't even use constant-time multiply. I skimmed the ECClib code. They seem to take efforts to avoid leaking data to addresses, with a masking approach to constant-time lookups. They use cmovc; is that constant-time? IIRC it is at least on recent Intel chips. Anyway, I think the authors clearly intended to avoid dataflow to addresses or branches, though a confirmation would be nice. I agree that they should have used untwisted Edwards instead of twisted Edwards, but that's easy enough to fix: CFRG can just adopt the isogenous untwisted curves instead. Is this what you mean by "excessive complexity"? Is there another problem with those curves, that other curves with the same field size would not have? For the record, since DJB seems to be calling people out on precision: my Ed448-Goldilocks software is designed not to let secret data flow to addresses, branch conditions or operations which are variable-time on most CPUs. If it does, that's a bug. However, secret data can flow to multiply and multiply-accumulate instructions, which are variable-time on some embedded CPUs. Furthermore, my code is mostly in C and so is at the mercy of the compiler and optimizer. Finally, while I'm not using any blinded variable-time algorithms today (such as blinded EGCD), I consider them to be a safe and reasonable thing to do in the right circumstances. Cheers, -- Mike From nobody Tue Oct 14 16:54:39 2014 Return-Path: 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 0D12A1A005F for ; Tue, 14 Oct 2014 16:54:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-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 J-fC7je9fM6l for ; Tue, 14 Oct 2014 16:54:35 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0774.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:774]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E02C61A0060 for ; Tue, 14 Oct 2014 16:54:34 -0700 (PDT) Received: from DM2PR03MB495.namprd03.prod.outlook.com (10.141.85.149) by DM2PR03MB495.namprd03.prod.outlook.com (10.141.85.149) with Microsoft SMTP Server (TLS) id 15.0.1049.19; Tue, 14 Oct 2014 23:54:11 +0000 Received: from DM2PR03MB495.namprd03.prod.outlook.com ([10.141.85.149]) by DM2PR03MB495.namprd03.prod.outlook.com ([10.141.85.149]) with mapi id 15.00.1049.012; Tue, 14 Oct 2014 23:54:11 +0000 From: Craig Costello To: "watsonbladd@gmail.com" Thread-Topic: Re: [Cfrg] Complexity of the Microsoft curve proposal Thread-Index: Ac/oCgRJQ9masmK0T320ahMLKTrEgw== Date: Tue, 14 Oct 2014 23:54:11 +0000 Message-ID: <075fdb98d04b42d08e39dbc706cc21fa@DM2PR03MB495.namprd03.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [2001:4898:80e0:ee43::2] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:DM2PR03MB495; x-forefront-prvs: 03648EFF89 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(199003)(189002)(243025005)(76482002)(20776003)(92566001)(19580395003)(19300405004)(19625215002)(64706001)(31966008)(33646002)(110136001)(87936001)(15202345003)(101416001)(122556002)(40100003)(74316001)(15975445006)(16236675004)(120916001)(19617315012)(2656002)(85852003)(21056001)(99396003)(1411001)(4396001)(106356001)(107046002)(2351001)(85306004)(2501002)(105586002)(108616004)(54356999)(86362001)(50986999)(97736003)(95666004)(46102003)(80022003)(99286002)(76576001)(24736002)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR03MB495; H:DM2PR03MB495.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_075fdb98d04b42d08e39dbc706cc21faDM2PR03MB495namprd03pro_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/zeH3yEDi7JaDGYxPs1IoR7hoCdg Cc: "cfrg@ietf.org" Subject: Re: [Cfrg] Complexity of the Microsoft curve proposal X-BeenThere: cfrg@irtf.org 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: Tue, 14 Oct 2014 23:54:38 -0000 --_000_075fdb98d04b42d08e39dbc706cc21faDM2PR03MB495namprd03pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Watson, To elaborate a little on what Mike said, when p =3D=3D 3 mod 4, defining se= arches for twist-secure curves that minimize the absolute value of the Mont= gomery constant automatically minimize the absolute value of the constant o= n the isogenous (complete) Edwards curve and the absolute value of the cons= tant on the isogenous twisted Edwards curve. So regardless of whether our c= urves are implemented using Edwards coordinates, twisted Edwards coordinate= s, or Montgomery coordinates, the corresponding curve constant will be smal= l (see Section 2 of http://eprint.iacr.org/2014/027.pdf or Section 3.3 of h= ttp://eprint.iacr.org/2014/130.pdf to see that there is no problem here). On the other hand, I'm not sure if this happens when p =3D=3D 1 mod 4: for = example, the Edwards version of Curve25519 has a curve constant that's a fr= action of small numbers, which the implementation documented in http://epri= nt.iacr.org/2011/368.pdf ends up treating as a generic (large) field elemen= t. All other things being equal, I therefore think that switching between coor= dinates (if desired) slightly favors p =3D=3D 3 mod 4. Furthermore, in this= case, if the curve is defined as an a=3D1 (complete) Edwards curve, implem= enters then have the option of staying in Edwards form at the expense of 1 = field multiplication per addition operation (like the implementation of Cur= ve41417 in http://eprint.iacr.org/2014/526.pdf does) or of using Mike's iso= geny trick for enhanced performance: http://eprint.iacr.org/2014/027.pdf). In any case, this is (as you say) about the coordinates, not the curve. How= ever, changing coordinates can change the corresponding curve constant, but= when p =3D=3D 3 mod 4 small constants will remain small irrespective of th= e coordinate system. Cheers, Craig --_000_075fdb98d04b42d08e39dbc706cc21faDM2PR03MB495namprd03pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Watson,

 

To elaborate a little on what Mike said, when p =3D= =3D 3 mod 4, defining searches for twist-secure curves that minimize the ab= solute value of the Montgomery constant automatically minimize the absolute= value of the constant on the isogenous (complete) Edwards curve and the absolute value of the constant on the iso= genous twisted Edwards curve. So regardless of whether our curves are imple= mented using Edwards coordinates, twisted Edwards coordinates, or Montgomer= y coordinates, the corresponding curve constant will be small (see Section 2 of http://eprint.iacr.org/2014/027.pdf or Section 3.3 of http://eprint.iacr.org/2014/130.pdf to see that there is no problem her= e).

 

On the other hand, I’m not sure if this happen= s when p =3D=3D 1 mod 4: for example, the Edwards version of Curve25519 has= a curve constant that’s a fraction of small numbers, which the imple= mentation documented in http://eprint.iacr.org/2011= /368.pdf ends up treating as a generic (large) field element.

 

All other things being equal, I therefore think that= switching between coordinates (if desired) slightly favors p =3D=3D 3 mod = 4. Furthermore, in this case, if the curve is defined as an a=3D1 (complete= ) Edwards curve, implementers then have the option of staying in Edwards form at the expense of 1 field multiplica= tion per addition operation (like the implementation of Curve41417 in http://eprint.iacr.org/2014= /526.pdf does) or of using Mike’s isogeny trick for enhanced perf= ormance: http://eprint.iacr.org/2014= /027.pdf).

 

In any case, this is (= as you say) about the coordinates, not the curve. However, changing coordin= ates can change the corresponding curve constant, but when p =3D=3D 3 mod 4= small constants will remain small irrespective of the coordinate system.  

 

Cheers,

Craig

 

--_000_075fdb98d04b42d08e39dbc706cc21faDM2PR03MB495namprd03pro_-- From nobody Tue Oct 14 18:04:08 2014 Return-Path: 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 477181A010A for ; Tue, 14 Oct 2014 18:04:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.556 X-Spam-Level: * X-Spam-Status: No, score=1.556 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, RDNS_DYNAMIC=0.982, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no 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 7h1tLVc7ZZFK for ; Tue, 14 Oct 2014 18:04:01 -0700 (PDT) Received: from aspartame.shiftleft.org (199-116-74-168-v301.PUBLIC.monkeybrains.net [199.116.74.168]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43B471A0104 for ; Tue, 14 Oct 2014 18:04:00 -0700 (PDT) Received: from [10.184.148.249] (unknown [209.36.6.242]) by aspartame.shiftleft.org (Postfix) with ESMTPSA id 1FCD73AA13; Tue, 14 Oct 2014 18:02:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=shiftleft.org; s=sldo; t=1413334930; bh=uRhA/zE2q+BB8qBzsYiZhn4GPoBBbckejdsJKlpasNw=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=e2NlENmwhFfTnLx4IfSbDZu/Oc1LJ84esJW+C2hvnV+HuNcp/qiilPkNDDgj6Yvnp k4fhEGE8DTURdmFgvmwERWKdyOYtgdj6r+ypHbZfRxYHKMrQV8QmSLZrJFzU2wOD/p 2SgR99V30+VHkc2p4q2wwUM52NVKWpnWf8ogUK2I= Content-Type: multipart/alternative; boundary="Apple-Mail=_535C04A8-C8D0-482E-BD3E-F5163A1E8968" Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Michael Hamburg In-Reply-To: <075fdb98d04b42d08e39dbc706cc21fa@DM2PR03MB495.namprd03.prod.outlook.com> Date: Tue, 14 Oct 2014 18:03:55 -0700 Message-Id: <253D0648-0DDE-497E-8BC1-4DD2805640E4@shiftleft.org> References: <075fdb98d04b42d08e39dbc706cc21fa@DM2PR03MB495.namprd03.prod.outlook.com> To: Craig Costello X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/r_5VxxJBwyJa6J3LF-T5w_avBJ4 Cc: "cfrg@ietf.org" Subject: Re: [Cfrg] Complexity of the Microsoft curve proposal X-BeenThere: cfrg@irtf.org 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: Wed, 15 Oct 2014 01:04:05 -0000 --Apple-Mail=_535C04A8-C8D0-482E-BD3E-F5163A1E8968 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Oct 14, 2014, at 4:54 PM, Craig Costello = wrote: >=20 > Hi Watson,=20 > =20 > To elaborate a little on what Mike said, when p =3D=3D 3 mod 4, = defining searches for twist-secure curves that minimize the absolute = value of the Montgomery constant automatically minimize the absolute = value of the constant on the isogenous (complete) Edwards curve and the = absolute value of the constant on the isogenous twisted Edwards curve. = So regardless of whether our curves are implemented using Edwards = coordinates, twisted Edwards coordinates, or Montgomery coordinates, the = corresponding curve constant will be small (see Section 2 of = http://eprint.iacr.org/2014/027.pdf = or Section 3.3 of = http://eprint.iacr.org/2014/130.pdf = to see that there is no problem = here). > =20 > On the other hand, I=E2=80=99m not sure if this happens when p =3D=3D = 1 mod 4: for example, the Edwards version of Curve25519 has a curve = constant that=E2=80=99s a fraction of small numbers, which the = implementation documented in http://eprint.iacr.org/2011/368.pdf = ends up treating as a generic = (large) field element. This is because Bernstein et al specified an isomorphic curve and not an = isogenous one. They could have specified the 4-isogenous curve=20 x^2 + y^2 =3D 1 + d x^2 y ^2 where d =3D (2-A)/4 =3D -121665. [ At least if I haven=E2=80=99t made a mistake: x =3D 4v(u^2-1) / ((u^2-1)^2+4v^2) y =3D u (4v^2 - (u^2-1)^2) / (2v^2(u^2+1) - u(u^2-1)^2) dual: u =3D y^2/x^2 v =3D y(x^2+y^2-2)/x^3 ] or the curve -x^2 + y^2 =3D 1 - d x^2 y^2 which is isomorphic to that one under the map x -> ix. Both of these = curves are complete, because GF(2^255-16)(+-121665) is nonsquare. > All other things being equal, I therefore think that switching between = coordinates (if desired) slightly favors p =3D=3D 3 mod 4. There are advantages to p =3D=3D 3 mod 4, but I don=E2=80=99t think this = is one of them. Note that p =3D=3D 1 mod 4 supports curves which are = both twisted [a=3D-1] and complete, but 3 mod 4 does not. So in terms = of coordinate systems, that=E2=80=99s the simplest, fastest option. You = can recover most of that with the isogeny trick, but not all of it. > Furthermore, in this case, if the curve is defined as an a=3D1 = (complete) Edwards curve, implementers then have the option of staying = in Edwards form at the expense of 1 field multiplication per addition = operation (like the implementation of Curve41417 = inhttp://eprint.iacr.org/2014/526.pdf = does) or of using Mike=E2=80=99s = isogeny trick for enhanced = performance:http://eprint.iacr.org/2014/027.pdf = ). I think Watson=E2=80=99s points were: 1) If the NUMS curves are chosen, they should be changed to the = isogenous untwisted ones. 2) Whatever curves are chosen, they should compress points. > In any case, this is (as you say) about the coordinates, not the = curve. However, changing coordinates can change the corresponding curve = constant, but when p =3D=3D 3 mod 4 small constants will remain small = irrespective of the coordinate system. An isogeny is a bit more than just a change in coordinates, but I agree = that it=E2=80=99s reasonable to pick a curve structure, and later = discuss which isogenous or isomorphic curves and which coordinates = should be used for which protocols. I don=E2=80=99t think everyone on this list would agree with the above = statement, though. A pretty big part of Benjamin Black=E2=80=99s = argument against \w+25519 is the idea that they are different curves, = not just different coordinates for the same curve, even though the = curves are isomorphic and not just isogenous. This is also why I listed =E2=80=9CCurves isogenous to NUMS=E2=80=9D as = a separate candidate from NUMS in the =E2=80=9Ccurrent candidates=E2=80=9D= email. > Cheers, > Craig Peace, =E2=80=94 Mike --Apple-Mail=_535C04A8-C8D0-482E-BD3E-F5163A1E8968 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Oct 14, 2014, at 4:54 PM, Craig Costello <craigco@microsoft.com> wrote:

Hi = Watson, 
 
To = elaborate a little on what Mike said, when p =3D=3D 3 mod 4, defining = searches for twist-secure curves that minimize the absolute value of the = Montgomery constant automatically minimize the absolute value of the = constant on the isogenous (complete) Edwards curve and the absolute = value of the constant on the isogenous twisted Edwards curve. So = regardless of whether our curves are implemented using Edwards = coordinates, twisted Edwards coordinates, or Montgomery coordinates, the = corresponding curve constant will be small (see Section 2 of http://eprint.iacr.org/2014/027.pdf or Section 3.3 of http://eprint.iacr.org/2014/130.pdf to see that there is no = problem here).
 
On the other hand, I=E2=80=99m not sure if this happens when = p =3D=3D 1 mod 4: for example, the Edwards version of Curve25519 has a = curve constant that=E2=80=99s a fraction of small numbers, which the = implementation documented in http://eprint.iacr.org/2011/368.pdf ends up treating as a = generic (large) field element.

This is because Bernstein et al specified an = isomorphic curve and not an isogenous one.  They could have = specified the 4-isogenous curve 

x^2 + y^2 =3D 1 + d x^2 y ^2 where d =3D (2-A)/4 =3D= -121665.

[
At least if I = haven=E2=80=99t made a mistake:
  x =3D 4v(u^2-1) / = ((u^2-1)^2+4v^2)
  y =3D u (4v^2 - (u^2-1)^2) / = (2v^2(u^2+1) - u(u^2-1)^2)

dual:
  u =3D = y^2/x^2
  v =3D = y(x^2+y^2-2)/x^3
]

or the = curve

-x^2 + y^2 =3D 1 - d x^2 = y^2

which is isomorphic to that one = under the map x -> ix.  Both of these curves are complete, = because GF(2^255-16)(+-121665) is nonsquare.

All other = things being equal, I therefore think that switching between coordinates = (if desired) slightly favors p =3D=3D 3 mod = 4.

There = are advantages to p =3D=3D 3 mod 4, but I don=E2=80=99t think this is = one of them.  Note that p =3D=3D 1 mod 4 supports curves which are = both twisted [a=3D-1] and complete, but 3 mod 4 does not.  So in = terms of coordinate systems, that=E2=80=99s the simplest, fastest = option.  You can recover most of that with the isogeny trick, but = not all of it.

= Furthermore, in this case, if the curve is defined as an a=3D1 = (complete) Edwards curve, implementers then have the option of staying = in Edwards form at the expense of 1 field multiplication per addition = operation (like the implementation of Curve41417 inhttp://eprint.iacr.org/2014/526.pdf does) or of using Mike=E2=80=99= s isogeny trick for enhanced performance:http://eprint.iacr.org/2014/027.pdf).

I think Watson=E2=80=99s points = were:
1) If the NUMS curves are chosen, they should be changed = to the isogenous untwisted ones.
2) Whatever curves are = chosen, they should compress points.

In any case, this is (as you say) about = the coordinates, not the curve. However, changing coordinates can change = the corresponding curve constant, but when p =3D=3D 3 mod 4 small = constants will remain small irrespective of the coordinate = system.

An = isogeny is a bit more than just a change in coordinates, but I agree = that it=E2=80=99s reasonable to pick a curve structure, and later = discuss which isogenous or isomorphic curves and which coordinates = should be used for which protocols.

I = don=E2=80=99t think everyone on this list would agree with the above = statement, though.  A pretty big part of Benjamin Black=E2=80=99s = argument against \w+25519 is the idea that they are different curves, = not just different coordinates for the same curve, even though the = curves are isomorphic and not just isogenous.

This is also why I listed =E2=80=9CCurves = isogenous to NUMS=E2=80=9D as a separate candidate from NUMS in the = =E2=80=9Ccurrent candidates=E2=80=9D email.

Cheers,
Craig

Peace,
=E2=80=94 Mike



= --Apple-Mail=_535C04A8-C8D0-482E-BD3E-F5163A1E8968-- From nobody Wed Oct 15 17:25:30 2014 Return-Path: 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 2DE141ACEAD for ; Wed, 15 Oct 2014 17:25:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.3 X-Spam-Level: * X-Spam-Status: No, score=1.3 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_92=0.6, SPF_PASS=-0.001] autolearn=no 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 PNdC5gwKtHUC for ; Wed, 15 Oct 2014 17:25:26 -0700 (PDT) Received: from mail-yh0-x233.google.com (mail-yh0-x233.google.com [IPv6:2607:f8b0:4002:c01::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A49E1ACEAC for ; Wed, 15 Oct 2014 17:25:26 -0700 (PDT) Received: by mail-yh0-f51.google.com with SMTP id t59so1129370yho.10 for ; Wed, 15 Oct 2014 17:25:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=xLVcrlcKr7Y1mClCvrmkCHRWFpPkNl9hXIYEIyF2luo=; b=DQad9fFdNoe2OltR12An/GzRMESUMrAIdrDDVd/ydpHjEswuSQSQr8ozMoKRsxgz1E KJVFHLmONMNQRVaq5F9zbF18hCOIJ6mWxTABbKO5JhIi8lJMthPezhSoh6gscBkiIpqp xpIDRyjiASsm3xSEm8x8u0U6L1AOXXqWMqCigfV3UQbw2aAKJOySmrzhQXAnwrkv34w6 6O3lI4S5tcu1gs245kxJizLl5ugYhOS+RudzBsGy+yVw0Q+l1pBdptL9C/eTuantnQ0V YX5I/snCNkdmdjqsQ8aisSCnKOxlrvjBCnLvJZqNIkf6XR5J9Upv9+MuVfDp84Gt6gsW +eKA== MIME-Version: 1.0 X-Received: by 10.236.115.132 with SMTP id e4mr15502748yhh.10.1413419125492; Wed, 15 Oct 2014 17:25:25 -0700 (PDT) Received: by 10.170.195.149 with HTTP; Wed, 15 Oct 2014 17:25:25 -0700 (PDT) In-Reply-To: References: <075fdb98d04b42d08e39dbc706cc21fa@DM2PR03MB495.namprd03.prod.outlook.com> <253D0648-0DDE-497E-8BC1-4DD2805640E4@shiftleft.org> Date: Wed, 15 Oct 2014 17:25:25 -0700 Message-ID: From: Watson Ladd To: "cfrg@irtf.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/r-LIFOnU35egqyDERhta6lt3lh8 Subject: [Cfrg] Fwd: Complexity of the Microsoft curve proposal X-BeenThere: cfrg@irtf.org 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: Thu, 16 Oct 2014 00:25:28 -0000 On Tue, Oct 14, 2014 at 6:03 PM, Michael Hamburg wrote= : > > On Oct 14, 2014, at 4:54 PM, Craig Costello wrote= : > > Hi Watson, > > To elaborate a little on what Mike said, when p =3D=3D 3 mod 4, defining > searches for twist-secure curves that minimize the absolute value of the > Montgomery constant automatically minimize the absolute value of the > constant on the isogenous (complete) Edwards curve and the absolute value= of > the constant on the isogenous twisted Edwards curve. So regardless of > whether our curves are implemented using Edwards coordinates, twisted > Edwards coordinates, or Montgomery coordinates, the corresponding curve > constant will be small (see Section 2 of http://eprint.iacr.org/2014/027.= pdf > or Section 3.3 of http://eprint.iacr.org/2014/130.pdf to see that there i= s > no problem here). > > On the other hand, I=E2=80=99m not sure if this happens when p =3D=3D 1 m= od 4: for > example, the Edwards version of Curve25519 has a curve constant that=E2= =80=99s a > fraction of small numbers, which the implementation documented in > http://eprint.iacr.org/2011/368.pdf ends up treating as a generic (large) > field element. > > > This is because Bernstein et al specified an isomorphic curve and not an > isogenous one. They could have specified the 4-isogenous curve > > x^2 + y^2 =3D 1 + d x^2 y ^2 where d =3D (2-A)/4 =3D -121665. > > [ > At least if I haven=E2=80=99t made a mistake: > x =3D 4v(u^2-1) / ((u^2-1)^2+4v^2) > y =3D u (4v^2 - (u^2-1)^2) / (2v^2(u^2+1) - u(u^2-1)^2) > > dual: > u =3D y^2/x^2 > v =3D y(x^2+y^2-2)/x^3 > ] > > or the curve > > -x^2 + y^2 =3D 1 - d x^2 y^2 > > which is isomorphic to that one under the map x -> ix. Both of these cur= ves > are complete, because GF(2^255-16)(+-121665) is nonsquare. > > All other things being equal, I therefore think that switching between > coordinates (if desired) slightly favors p =3D=3D 3 mod 4. > > > There are advantages to p =3D=3D 3 mod 4, but I don=E2=80=99t think this = is one of them. > Note that p =3D=3D 1 mod 4 supports curves which are both twisted [a=3D-1= ] and > complete, but 3 mod 4 does not. So in terms of coordinate systems, that= =E2=80=99s > the simplest, fastest option. You can recover most of that with the isog= eny > trick, but not all of it. > > Furthermore, in this case, if the curve is defined as an a=3D1 (complete) > Edwards curve, implementers then have the option of staying in Edwards fo= rm > at the expense of 1 field multiplication per addition operation (like the > implementation of Curve41417 inhttp://eprint.iacr.org/2014/526.pdf does) = or > of using Mike=E2=80=99s isogeny trick for enhanced > performance:http://eprint.iacr.org/2014/027.pdf). > > > I think Watson=E2=80=99s points were: > 1) If the NUMS curves are chosen, they should be changed to the isogenous > untwisted ones. > 2) Whatever curves are chosen, they should compress points. That's exactly right. I want the simplest, fastest, possible solution. Simplicity matters more because most implementations need to favor correctness over speed. But speed also matters, to avoid temptation. So if twisted coordinates are complete, that works great. If not, we should use untwisted coordinates, so that simple implementations are secure implementations. Sadly 2^521-1 is likely to be the prime we need to use for the big workfactor because of performance/lack of nice primes in that range, and is 3 (mod 4), so likely untwisted Edwards coordinates will have to be used for signatures if we want to minimize the number of coordinate systems used. (The penalty for a performant multiplication with Edwards coordinates of either twistedness in code size is fairly large, and the isogeny trick requires implementing arithmetic in the group order. On the other hand, for signatures this is likely already needed. In comparison, Montgomery form is very compact in code, even when performant) Point compression incurs a slight penalty. However, it entirely eliminates a class of attacks caused by not checking the order, provided the square root routine properly checks that the square root exists. (What happens when a non-quadratic residue is square rooted by exponentiation or the p=3D5 (mod 8) method may be exploitable. Yes, after dividing by i it's a point on the twist, but I don't think that's what comes out of the formula. And then the addition formulas aren't right for the twist, so I don't know how to exploit the result or show it isn't exploitable. However, it's a barrier to exploitation in any case) The big advantage of Montgomery coordinates is that they eliminate entirely validation, so this is a non-issue for ECDH. Sadly, we can't do signatures with them in a reasonable way, so we're stuck with a step that might get skipped and cause vulnerabilities when skipped. > > In any case, this is (as you say) about the coordinates, not the curve. > However, changing coordinates can change the corresponding curve constant= , > but when p =3D=3D 3 mod 4 small constants will remain small irrespective = of the > coordinate system. > > > An isogeny is a bit more than just a change in coordinates, but I agree t= hat > it=E2=80=99s reasonable to pick a curve structure, and later discuss whic= h isogenous > or isomorphic curves and which coordinates should be used for which > protocols. > > I don=E2=80=99t think everyone on this list would agree with the above st= atement, > though. A pretty big part of Benjamin Black=E2=80=99s argument against \= w+25519 is > the idea that they are different curves, not just different coordinates f= or > the same curve, even though the curves are isomorphic and not just > isogenous.dd > > This is also why I listed =E2=80=9CCurves isogenous to NUMS=E2=80=9D as a= separate candidate > from NUMS in the =E2=80=9Ccurrent candidates=E2=80=9D email. This email, along with the "Curve, Coordinates and Computations" email is required reading for anyone who wants to understand the issues. Sadly, I can't find it in my inbox. Sincerely, Watson Ladd > > Cheers, > Craig > > > Peace, > =E2=80=94 Mike > > > -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin --=20 "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Thu Oct 16 08:51:05 2014 Return-Path: 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 C75831A7029 for ; Thu, 16 Oct 2014 08:51:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-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 mR-C-V26kvR5 for ; Thu, 16 Oct 2014 08:50:57 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0687.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::687]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 623CD1A8033 for ; Thu, 16 Oct 2014 08:50:27 -0700 (PDT) Received: from DBXPR03MB383.eurprd03.prod.outlook.com (10.141.10.15) by DBXPR03MB381.eurprd03.prod.outlook.com (10.141.10.11) with Microsoft SMTP Server (TLS) id 15.0.1044.10; Thu, 16 Oct 2014 15:50:03 +0000 Received: from DBXPR03MB383.eurprd03.prod.outlook.com ([10.141.10.15]) by DBXPR03MB383.eurprd03.prod.outlook.com ([10.141.10.15]) with mapi id 15.00.1049.012; Thu, 16 Oct 2014 15:50:03 +0000 From: "Paterson, Kenny" To: Paul Hoffman , "cfrg@irtf.org" Thread-Topic: [Cfrg] Preference for focus on EC rather than PAKE Thread-Index: AQHP5DE+nMk2iy30sUuglSKsEN07gZwy+gOA Date: Thu, 16 Oct 2014 15:50:03 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [178.166.30.213] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:DBXPR03MB381; x-exchange-antispam-report-test: UriScan:; x-forefront-prvs: 036614DD9C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(51704005)(24454002)(479174003)(199003)(189002)(46102003)(92566001)(19580405001)(107886001)(80022003)(74482002)(66066001)(21056001)(97736003)(15202345003)(86362001)(19580395003)(92726001)(99396003)(122556002)(31966008)(50986999)(106116001)(106356001)(54356999)(105586002)(76482002)(4396001)(95666004)(2656002)(15975445006)(87936001)(64706001)(120916001)(20776003)(36756003)(85306004)(107046002)(101416001)(83506001)(76176999)(2501002)(40100003)(85852003); DIR:OUT; SFP:1101; SCL:1; SRVR:DBXPR03MB381; H:DBXPR03MB383.eurprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: <7714BCECFC2F694784CBC388F4FF7685@eurprd03.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: rhul.ac.uk Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/_vbyPUYSXuooReRxs3Fc7rqg0Oo Subject: Re: [Cfrg] Preference for focus on EC rather than PAKE X-BeenThere: cfrg@irtf.org 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: Thu, 16 Oct 2014 15:51:01 -0000 Dear Paul, Sorry for the delay in picking this up. Alexei and I met a few days ago and discussed the workload of the research group (and we'll continue to meet regularly, as we're both located in the same neck of the woods in London).=20 We believe we (the co-chairs and the wider membership) will have enough cycles to do both things at the same time, though we do agree that the ECC work should have the higher priority. Regards, Kenny On 10/10/2014 03:23, "Paul Hoffman" wrote: >Greetings. This RG has historically done a poor job of working on >multiple disparate items at the same time. For some of us, the need for >the RG to come up with concise, understandable response to the request >from the TLS WG (which will also affect many other WGs) is about an order >of magnitude higher than the need to evaluate PAKEs. The latter can wait >until the higher-importance item is finished. > >--Paul Hoffman >_______________________________________________ >Cfrg mailing list >Cfrg@irtf.org >http://www.irtf.org/mailman/listinfo/cfrg From nobody Thu Oct 16 09:09:01 2014 Return-Path: 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 8A65E1A6FE1 for ; Thu, 16 Oct 2014 09:08:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-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 zCYLmz1712DZ for ; Thu, 16 Oct 2014 09:08:42 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0633.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::633]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1705A1A1B98 for ; Thu, 16 Oct 2014 09:08:42 -0700 (PDT) Received: from DBXPR03MB383.eurprd03.prod.outlook.com (10.141.10.15) by DBXPR03MB382.eurprd03.prod.outlook.com (10.141.10.12) with Microsoft SMTP Server (TLS) id 15.0.1044.10; Thu, 16 Oct 2014 16:08:18 +0000 Received: from DBXPR03MB383.eurprd03.prod.outlook.com ([10.141.10.15]) by DBXPR03MB383.eurprd03.prod.outlook.com ([10.141.10.15]) with mapi id 15.00.1049.012; Thu, 16 Oct 2014 16:08:18 +0000 From: "Paterson, Kenny" To: "cfrg@irtf.org" Thread-Topic: ECC reboot (Was: When's the decision?) Thread-Index: AQHP6VtmT0IPqoE8/UeRMNkTGwW65Q== Date: Thu, 16 Oct 2014 16:08:18 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [178.166.30.213] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:DBXPR03MB382; x-exchange-antispam-report-test: UriScan:; x-forefront-prvs: 036614DD9C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(51704005)(479174003)(199003)(24454002)(189002)(101416001)(31966008)(120916001)(20776003)(2656002)(36756003)(80022003)(46102003)(66066001)(64706001)(85852003)(74482002)(110136001)(561944003)(106356001)(107046002)(2351001)(107886001)(92726001)(85306004)(76482002)(83506001)(40100003)(122556002)(15202345003)(4396001)(95666004)(86362001)(87936001)(97736003)(21056001)(15975445006)(19580395003)(105586002)(99396003)(54356999)(106116001)(19580405001)(92566001)(50986999)(2501002); DIR:OUT; SFP:1101; SCL:1; SRVR:DBXPR03MB382; H:DBXPR03MB383.eurprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: <57E7789704835B46BAF3F11F3AEC73A7@eurprd03.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: rhul.ac.uk Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/Wm-F1wSSvBRiYxz_YKjkdCKpPDo Subject: Re: [Cfrg] ECC reboot (Was: When's the decision?) X-BeenThere: cfrg@irtf.org 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: Thu, 16 Oct 2014 16:08:52 -0000 Dear all, Watson rightly pointed out that we are far behind the originally advertised schedule for our process for selection of curves to recommend to the TLS WG. Other parties in and beyond IETF are waiting on our recommendations too. The reasons for the delay are quite complex, and I won't go into reviewing them here. Suffice to say we've had a lot of really informative technical discussion about performance of the different options, benchmarking, etc, so the slippage has not exactly been wasted. Our first task should be to finalise the requirements that we will use to guide the selection process. I think we are close, with a couple of outstanding issues: 1. Amount of "wiggle room" that should be permitted. 2. A more nuanced set of hardware requirements. I suggest we use the next *week* to try to finalise the requirements, and then November to evaluate the candidates that we currently have (along with any new candidates that might emerge) against the final set of requirements.=20 With this schedule, we'd miss the IETF 91 meeting for our decision, but I don't think having our answer by mid-Novmeber is really feasible. We should certainly be able to deliver an early Christmas present to the TLS WG. To make this work, we'd need the RG to focus on the requirements for a short additional period of time. So here's a proposal for a new schedule which I believe to be feasible: 24/10/14 (1 week from now): we finalise requirements, including hardware requirements. 31/10/14 (2 weeks from now): we agree on whatever benchmarking system we're going to use for performance measurements. (Right now, supercop seems like the front runner to me.) 30/11/14 (6 weeks from now): we deliver our recommendations to the TLS WG. Could people let me know if this looks workable, within the next 24-48 hours? Meantime, I'll send a message indicating where things stand on the requirements list. Thanks Kenny=20 On 06/10/2014 16:26, "Watson Ladd" wrote: >Dear all, >We were promised on July 27 a process running for 6 weeks. Doubling I >get 12 weeks, which is three months, of which two (August, September) >have already gone. Am I correct in supposing that we're on track for a >decision by Halloween? > >If we aren't, what remaining issues need to be addressed/when can we >expect a decision? > >Sincerely, >Watson Ladd > >_______________________________________________ >Cfrg mailing list >Cfrg@irtf.org >http://www.irtf.org/mailman/listinfo/cfrg From nobody Thu Oct 16 09:26:52 2014 Return-Path: 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 9F5FC1A877D for ; Thu, 16 Oct 2014 09:26:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.768 X-Spam-Level: * X-Spam-Status: No, score=1.768 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FUZZY_CREDIT=1.678, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 zQ3RIYgLSSkL for ; Thu, 16 Oct 2014 09:26:47 -0700 (PDT) Received: from a.mx.secunet.com (a.mx.secunet.com [195.81.216.161]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E250B1A8781 for ; Thu, 16 Oct 2014 09:26:21 -0700 (PDT) Received: from localhost (alg1 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id 55E961A0084 for ; Thu, 16 Oct 2014 18:26:14 +0200 (CEST) X-Virus-Scanned: by secunet Received: from a.mx.secunet.com ([127.0.0.1]) by localhost (a.mx.secunet.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id b45qjSiK9jo1 for ; Thu, 16 Oct 2014 18:26:10 +0200 (CEST) Received: from mail-essen-01.secunet.de (unknown [10.53.40.204]) by a.mx.secunet.com (Postfix) with ESMTP id 6B7461A007F for ; Thu, 16 Oct 2014 18:26:10 +0200 (CEST) Received: from [10.208.1.76] (10.208.1.76) by mail-essen-01.secunet.de (10.53.40.204) with Microsoft SMTP Server (TLS) id 14.3.210.2; Thu, 16 Oct 2014 18:26:15 +0200 Message-ID: <543FF1A7.8030908@secunet.com> Date: Thu, 16 Oct 2014 18:26:15 +0200 From: Johannes Merkle User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: References: In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Originating-IP: [10.208.1.76] X-EXCLAIMER-MD-CONFIG: 2c86f778-e09b-4440-8b15-867914633a10 Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/WnaZ84-qZ0lA013GBT9e-HMWKCQ Subject: Re: [Cfrg] ECC reboot (Was: When's the decision?) X-BeenThere: cfrg@irtf.org 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: Thu, 16 Oct 2014 16:26:49 -0000 with respect to the second issue, we have just published a common position paper of the ECC Brainpool on the requirements for new curves. http://eprint.iacr.org/2014/832 Most, if not all, arguments have been expressed on this list before, but this is a consolidated statement. Johannes PS: The paper has already been submitted two weeks ago and had been stuck in the queue at the IACR editors until now. Paterson, Kenny wrote on 16.10.2014 18:08: > Dear all, > > Watson rightly pointed out that we are far behind the originally > advertised schedule for our process for selection of curves to recommend > to the TLS WG. Other parties in and beyond IETF are waiting on our > recommendations too. > > The reasons for the delay are quite complex, and I won't go into reviewing > them here. Suffice to say we've had a lot of really informative technical > discussion about performance of the different options, benchmarking, etc, > so the slippage has not exactly been wasted. > > Our first task should be to finalise the requirements that we will use to > guide the selection process. I think we are close, with a couple of > outstanding issues: > > 1. Amount of "wiggle room" that should be permitted. > > 2. A more nuanced set of hardware requirements. > > > I suggest we use the next *week* to try to finalise the requirements, and > then November to evaluate the candidates that we currently have (along > with any new candidates that might emerge) against the final set of > requirements. > > With this schedule, we'd miss the IETF 91 meeting for our decision, but I > don't think having our answer by mid-Novmeber is really feasible. We > should certainly be able to deliver an early Christmas present to the TLS > WG. > > To make this work, we'd need the RG to focus on the requirements for a > short additional period of time. > > So here's a proposal for a new schedule which I believe to be feasible: > > 24/10/14 (1 week from now): we finalise requirements, including hardware > requirements. > 31/10/14 (2 weeks from now): we agree on whatever benchmarking system > we're going to use for performance measurements. (Right now, supercop > seems like the front runner to me.) > 30/11/14 (6 weeks from now): we deliver our recommendations to the TLS WG. > > Could people let me know if this looks workable, within the next 24-48 > hours? Meantime, I'll send a message indicating where things stand on the > requirements list. > > Thanks > > Kenny > > > On 06/10/2014 16:26, "Watson Ladd" wrote: > >> Dear all, >> We were promised on July 27 a process running for 6 weeks. Doubling I >> get 12 weeks, which is three months, of which two (August, September) >> have already gone. Am I correct in supposing that we're on track for a >> decision by Halloween? >> >> If we aren't, what remaining issues need to be addressed/when can we >> expect a decision? >> >> Sincerely, >> Watson Ladd >> >> _______________________________________________ >> Cfrg mailing list >> Cfrg@irtf.org >> http://www.irtf.org/mailman/listinfo/cfrg > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg > > -- Mit freundlichen Gren, Dr. Johannes Merkle Principal Beratung, Elektronische Identitten Public Sector secunet Security Networks AG Mergenthaler Allee 77 65760 Eschborn Germany Telefon +49 201 54 54-3091 Telefax +49 201 54 54-1325 Mobil +49 175 2224439 johannes.merkle@secunet.com www.secunet.com From nobody Thu Oct 16 09:35:08 2014 Return-Path: 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 58F0E1A8771 for ; Thu, 16 Oct 2014 09:35:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-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 yWFnVC3qPEIm for ; Thu, 16 Oct 2014 09:35:04 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0685.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::685]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 217721A6F21 for ; Thu, 16 Oct 2014 09:35:04 -0700 (PDT) Received: from DBXPR03MB383.eurprd03.prod.outlook.com (10.141.10.15) by DBXPR03MB382.eurprd03.prod.outlook.com (10.141.10.12) with Microsoft SMTP Server (TLS) id 15.0.1044.10; Thu, 16 Oct 2014 16:34:40 +0000 Received: from DBXPR03MB383.eurprd03.prod.outlook.com ([10.141.10.15]) by DBXPR03MB383.eurprd03.prod.outlook.com ([10.141.10.15]) with mapi id 15.00.1049.012; Thu, 16 Oct 2014 16:34:40 +0000 From: "Paterson, Kenny" To: "Parkinson, Sean" , "cfrg@irtf.org" Thread-Topic: [Cfrg] When's the decision? Thread-Index: AQHP4XoCGxb9lbfhS02i9PAKELf1JZwmeIwAgABZUQCADDoRgA== Date: Thu, 16 Oct 2014 16:34:40 +0000 Message-ID: References: <20141008173154.15169.qmail@cr.yp.to> <2FBC676C3BBFBB4AA82945763B361DE608F1D021@MX17A.corp.emc.com> In-Reply-To: <2FBC676C3BBFBB4AA82945763B361DE608F1D021@MX17A.corp.emc.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [178.166.30.213] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:DBXPR03MB382; x-exchange-antispam-report-test: UriScan:; x-forefront-prvs: 036614DD9C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(51704005)(479174003)(199003)(24454002)(189002)(101416001)(31966008)(120916001)(20776003)(2656002)(36756003)(80022003)(46102003)(66066001)(64706001)(85852003)(74482002)(106356001)(107046002)(107886001)(92726001)(85306004)(76482002)(83506001)(40100003)(122556002)(15202345003)(4396001)(95666004)(86362001)(87936001)(97736003)(21056001)(76176999)(15975445006)(19580395003)(105586002)(99396003)(54356999)(106116001)(19580405001)(92566001)(50986999)(2501002)(7059027); DIR:OUT; SFP:1101; SCL:1; SRVR:DBXPR03MB382; H:DBXPR03MB383.eurprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: <1FD4292333A4A54B85B86974A51241F2@eurprd03.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: rhul.ac.uk Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/-SNE4fjp-2FnrOtoMMIQvhJ2cYs Subject: Re: [Cfrg] When's the decision? X-BeenThere: cfrg@irtf.org 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: Thu, 16 Oct 2014 16:35:06 -0000 Sean, Are you planning to bring additional information on the issues that you refer to below to the list? Your additional input would be most welcome of course, but without concrete details, it's difficult to factor your initial comments below into our deliberations. Thanks Kenny=20 On 08/10/2014 23:51, "Parkinson, Sean" wrote: >I have concerns about a decision being made about which curves to >recommend 'before Halloween'. >I am unaware of 3rd parties implementing and confirming all the curves >that have been proposed. >Making a decision on new elliptic curves based on data that hasn't been >corroborated by a 3rd party is bad practice. > >I have been implementing as many of the curves as I can and my >performance results, so far, do not always match those that I have seen >in papers. > >Also, I am concerned that, while some curves are being implemented to be >constant time, not all curves are being implemented to be cache attack >resistant. Either all implementations need to be resistant or all >implementations not. Only then can a true comparison be made. > >Until these issues are dealt with I feel there is not sufficient >information to make a decision. > >Sean >-- >Sean Parkinson | Consultant Software Engineer | RSA, The Security >Division of EMC >Office +61 7 3032 5232 | Fax +61 7 3032 5299 >www.rsa.com > >_______________________________________________ >Cfrg mailing list >Cfrg@irtf.org >http://www.irtf.org/mailman/listinfo/cfrg From nobody Thu Oct 16 09:48:32 2014 Return-Path: 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 6D1E81A0181 for ; Thu, 16 Oct 2014 09:48:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.224 X-Spam-Level: X-Spam-Status: No, score=-0.224 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FUZZY_CREDIT=1.678, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no 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 b10LrOEuEzAd for ; Thu, 16 Oct 2014 09:48:22 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0686.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::686]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A5051A017A for ; Thu, 16 Oct 2014 09:48:22 -0700 (PDT) Received: from DBXPR03MB383.eurprd03.prod.outlook.com (10.141.10.15) by DBXPR03MB381.eurprd03.prod.outlook.com (10.141.10.11) with Microsoft SMTP Server (TLS) id 15.0.1044.10; Thu, 16 Oct 2014 16:46:16 +0000 Received: from DBXPR03MB383.eurprd03.prod.outlook.com ([10.141.10.15]) by DBXPR03MB383.eurprd03.prod.outlook.com ([10.141.10.15]) with mapi id 15.00.1049.012; Thu, 16 Oct 2014 16:46:17 +0000 From: "Paterson, Kenny" To: Johannes Merkle , "cfrg@irtf.org" Thread-Topic: [Cfrg] ECC reboot (Was: When's the decision?) Thread-Index: AQHP6VtmT0IPqoE8/UeRMNkTGwW65Zwy6RmAgAAWUQA= Date: Thu, 16 Oct 2014 16:46:16 +0000 Message-ID: References: <543FF1A7.8030908@secunet.com> In-Reply-To: <543FF1A7.8030908@secunet.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [178.166.30.213] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:DBXPR03MB381; x-exchange-antispam-report-test: UriScan:; x-forefront-prvs: 036614DD9C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(51704005)(51914003)(24454002)(479174003)(199003)(189002)(164054003)(46102003)(92566001)(561944003)(107886001)(80022003)(66066001)(74482002)(21056001)(97736003)(15202345003)(86362001)(19580405001)(19580395003)(92726001)(99396003)(122556002)(31966008)(50986999)(106116001)(106356001)(54356999)(105586002)(76482002)(4396001)(95666004)(2656002)(15975445006)(87936001)(64706001)(120916001)(20776003)(36756003)(85306004)(101416001)(107046002)(83506001)(76176999)(2501002)(40100003)(85852003)(19273905006)(563064011); DIR:OUT; SFP:1101; SCL:1; SRVR:DBXPR03MB381; H:DBXPR03MB383.eurprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: rhul.ac.uk Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/ugy2FjyzGFC_l2EzQ6L2_M-CGYE Subject: Re: [Cfrg] ECC reboot (Was: When's the decision?) X-BeenThere: cfrg@irtf.org 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: Thu, 16 Oct 2014 16:48:25 -0000 Johannes, Thanks for the pointer to this document. Everyone should read it to get a hardware-centric perspective on the problem we are trying to solve. What would now be really helpful would be if you could distill the entire 5-page document into a couple of succinct sentences that we can then debate as possible hardware-specific requirements for our process - see this post for examples of the kind of level of detail we're looking for here: http://www.ietf.org/mail-archive/web/cfrg/current/msg05068.html Thanks, Kenny=20 On 16/10/2014 17:26, "Johannes Merkle" wrote: >with respect to the second issue, we have just published a common >position paper of the ECC Brainpool on the >requirements for new curves. >http://eprint.iacr.org/2014/832 >Most, if not all, arguments have been expressed on this list before, but >this is a consolidated statement. > >Johannes > >PS: The paper has already been submitted two weeks ago and had been stuck >in the queue at the IACR editors until now. > >Paterson, Kenny wrote on 16.10.2014 18:08: >> Dear all, >>=20 >> Watson rightly pointed out that we are far behind the originally >> advertised schedule for our process for selection of curves to recommend >> to the TLS WG. Other parties in and beyond IETF are waiting on our >> recommendations too. >>=20 >> The reasons for the delay are quite complex, and I won't go into >>reviewing >> them here. Suffice to say we've had a lot of really informative >>technical >> discussion about performance of the different options, benchmarking, >>etc, >> so the slippage has not exactly been wasted. >>=20 >> Our first task should be to finalise the requirements that we will use >>to >> guide the selection process. I think we are close, with a couple of >> outstanding issues: >>=20 >> 1. Amount of "wiggle room" that should be permitted. >>=20 >> 2. A more nuanced set of hardware requirements. >>=20 >>=20 >> I suggest we use the next *week* to try to finalise the requirements, >>and >> then November to evaluate the candidates that we currently have (along >> with any new candidates that might emerge) against the final set of >> requirements.=20 >>=20 >> With this schedule, we'd miss the IETF 91 meeting for our decision, but >>I >> don't think having our answer by mid-Novmeber is really feasible. We >> should certainly be able to deliver an early Christmas present to the >>TLS >> WG. >>=20 >> To make this work, we'd need the RG to focus on the requirements for a >> short additional period of time. >>=20 >> So here's a proposal for a new schedule which I believe to be feasible: >>=20 >> 24/10/14 (1 week from now): we finalise requirements, including hardware >> requirements. >> 31/10/14 (2 weeks from now): we agree on whatever benchmarking system >> we're going to use for performance measurements. (Right now, supercop >> seems like the front runner to me.) >> 30/11/14 (6 weeks from now): we deliver our recommendations to the TLS >>WG. >>=20 >> Could people let me know if this looks workable, within the next 24-48 >> hours? Meantime, I'll send a message indicating where things stand on >>the >> requirements list. >>=20 >> Thanks >>=20 >> Kenny=20 >>=20 >>=20 >> On 06/10/2014 16:26, "Watson Ladd" wrote: >>=20 >>> Dear all, >>> We were promised on July 27 a process running for 6 weeks. Doubling I >>> get 12 weeks, which is three months, of which two (August, September) >>> have already gone. Am I correct in supposing that we're on track for a >>> decision by Halloween? >>> >>> If we aren't, what remaining issues need to be addressed/when can we >>> expect a decision? >>> >>> Sincerely, >>> Watson Ladd >>> >>> _______________________________________________ >>> Cfrg mailing list >>> Cfrg@irtf.org >>> http://www.irtf.org/mailman/listinfo/cfrg >>=20 >> _______________________________________________ >> Cfrg mailing list >> Cfrg@irtf.org >> http://www.irtf.org/mailman/listinfo/cfrg >>=20 >>=20 > > >--=20 >Mit freundlichen Gr=FC=DFen, >Dr. Johannes Merkle >Principal Beratung, Elektronische Identit=E4ten >Public Sector >secunet Security Networks AG >Mergenthaler Allee 77 >65760 Eschborn >Germany >Telefon +49 201 54 54-3091 >Telefax +49 201 54 54-1325 >Mobil +49 175 2224439 >johannes.merkle@secunet.com >www.secunet.com > >_______________________________________________ >Cfrg mailing list >Cfrg@irtf.org >http://www.irtf.org/mailman/listinfo/cfrg From nobody Thu Oct 16 10:37:50 2014 Return-Path: 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 9449B1A1A4A for ; Thu, 16 Oct 2014 10:37:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 DIzbk_YSOOYm for ; Thu, 16 Oct 2014 10:37:46 -0700 (PDT) Received: from emh07.mail.saunalahti.fi (emh07.mail.saunalahti.fi [62.142.5.117]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D1AD1A19EE for ; Thu, 16 Oct 2014 10:37:45 -0700 (PDT) Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh07.mail.saunalahti.fi (Postfix) with ESMTP id 11CA93FF7; Thu, 16 Oct 2014 20:37:41 +0300 (EEST) Date: Thu, 16 Oct 2014 20:37:41 +0300 From: Ilari Liusvaara To: "Paterson, Kenny" Message-ID: <20141016173741.GA20033@LK-Perkele-VII> References: <543FF1A7.8030908@secunet.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/SHCXZunKZnWNHWEj96YjP9ySOSE Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] ECC reboot (Was: When's the decision?) X-BeenThere: cfrg@irtf.org 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: Thu, 16 Oct 2014 17:37:48 -0000 On Thu, Oct 16, 2014 at 04:46:16PM +0000, Paterson, Kenny wrote: > Johannes, > > Thanks for the pointer to this document. Everyone should read it to get a > hardware-centric perspective on the problem we are trying to solve. > > What would now be really helpful would be if you could distill the entire > 5-page document into a couple of succinct sentences that we can then > debate as possible hardware-specific requirements for our process - see > this post for examples of the kind of level of detail we're looking for > here: What I consider short a summary of this topic: General-purpose software requires special primes, extended-sidechannel- security stuff requires (or at least is much easier with) random primes, other hardware can use either with no preference. Oh, and is there anything wrong with just using Brainpool for random primes for extended-sidechannel-security applications? It even has TLS codepoints. Oh, and Weierstrass form. And cofactor 1. And unrestricted twist cofactor. And uses SEC point formats. -Ilari From nobody Thu Oct 16 10:39:00 2014 Return-Path: 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 00C7E1A19EE for ; Thu, 16 Oct 2014 10:38:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.302 X-Spam-Level: X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_51=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no 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 Hx5HQVDtEWfH for ; Thu, 16 Oct 2014 10:38:55 -0700 (PDT) Received: from entima.net (entima.net [78.129.143.175]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 102C41A0636 for ; Thu, 16 Oct 2014 10:38:55 -0700 (PDT) Message-ID: <544002AF.1020107@akr.io> Date: Thu, 16 Oct 2014 18:38:55 +0100 From: Alyssa Rowan MIME-Version: 1.0 To: "cfrg@irtf.org" References: <543FF1A7.8030908@secunet.com> In-Reply-To: <543FF1A7.8030908@secunet.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/a3bVmrsfU6GVxunHvwUrhAU05qA Subject: Re: [Cfrg] ECC reboot (Was: When's the decision?) X-BeenThere: cfrg@irtf.org 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: Thu, 16 Oct 2014 17:38:57 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 16/10/2014 17:26, Johannes Merkle wrote: > with respect to the second issue, we have just published a common > position paper of the ECC Brainpool on the requirements for new > curves. http://eprint.iacr.org/2014/832 Most, if not all, arguments > have been expressed on this list before, but this is a consolidated > statement. Upon a read, and paraphrasing broadly (feel free to correct), what the Brainpool members seem to think meets the hardware scenario best is curves over "verifiably pseudo-random" primes, with points represented in short-Weierstrass form - because that matches best with their existing "high-assurance" pieces of hardware and the ways that they attempt to address attacks within them. They (naturally) want to minimise any changes to that general structure, to in turn minimise the costs of those changes. I note that none of the concrete, implemented proposals put forward so far are VPR. Do they have such a proposal? They have, of course, already specified a set of verifiably pseudo-random curves, which would be the Brainpool curves. I'm not totally clear what CFRG can positively add to that, because they are already specified. (An xkcd about competing standards springs to mind.) It seems that they also want a VPR curve(s?) to be mandatory-to-implement, presumably for interoperability's sake? I can see why they might want that, if VPR is the most convenient for their implementations - but from what I see from the hesitant adoption of Brainpool in the wider community, I have serious (albeit early) doubts that will reach wide consensus either here or in any downstream WG, due I suspect directly to the notoriously poor software performance characteristics of pseudo-random primes and the complexity required to correctly implement them in software. (This will of course be quantified during evaluation of any contender they put forward.) It seems to me at this stage that the requirements of the existing-hardware stakeholders of the Brainpool may be not only orthogonal, but actually (potentially) in direct opposition to the requirements of the software stakeholders - and further their requirements may (perhaps) already be satisfied by the Brainpool curves? - -- /akr -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJUQAKuAAoJEOyEjtkWi2t62L4P+gLx6CZ0GJ5+6KYdeK3eA9Dd keqBpZjlR25r74sdtqufUZaPH8AgB2q0QGX2evQKXWZj5cDblpwq1dVFk1o17wtZ k+3C8wdtavENvCHPaFsRoQYferk33HLRhj1jw7M69BJo5HTEerImySANDAosNOpD 0dj+axICdfZ2GH0NvKScBN/gFZvUOj197SxDH+eVdy3g5HL52gUd4HAN17ZWSysG kwG9MRHtTkKndO4JTLxiFCTX3DWFRXVIrUBCucJnvPDC0Rlsrgk0lLBiGHKLYhJR bwdnBxuyijnzGmOjrRanZOCCIFoq05BtmwxbGGkA5BmCbTPwcLTltd9+doCihCYb UDPfTZ5GvDaGhq6sUmUbPZnay1gvGIO18nyzxZXINkBanENQnE/Ofa2cdr0Ps9DN 40N0bcobbuaila6v/497a0krAp9D7aQ5JFN4swI5DYicpuYVDl0nOK63bRPTY+e+ gk4AKRB4gpVodU/O0a3tACvGwD7E/vf3qNbgrkqHHwXzhzhWebCRB9xtUpikbeEv /R5yhCSFFXJ4DJB9oMi+kJjG+VmgdC3vOzN0Tra19Pq+znLYe4lFOTqZ/EX+S3Ql Ua/hWfvmJyvXRe9mZt/dRjwj8GeHgRGlEnvcEjXvdmevuw5TAtZrJrBLjMfWFPNO wKHWHyo/P4Rj3NQ3NfOl =i8MQ -----END PGP SIGNATURE----- From nobody Thu Oct 16 11:00:53 2014 Return-Path: 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 8AB491A6F8F for ; Thu, 16 Oct 2014 11:00:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 KGggsWAtm1do for ; Thu, 16 Oct 2014 11:00:48 -0700 (PDT) Received: from emh02.mail.saunalahti.fi (emh02.mail.saunalahti.fi [62.142.5.108]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16AB11A6FD0 for ; Thu, 16 Oct 2014 11:00:48 -0700 (PDT) Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh02.mail.saunalahti.fi (Postfix) with ESMTP id E4B4081815; Thu, 16 Oct 2014 21:00:45 +0300 (EEST) Date: Thu, 16 Oct 2014 21:00:45 +0300 From: Ilari Liusvaara To: Alyssa Rowan Message-ID: <20141016180045.GA20823@LK-Perkele-VII> References: <543FF1A7.8030908@secunet.com> <544002AF.1020107@akr.io> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <544002AF.1020107@akr.io> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/SUJRtZa_-OUp8WvkvpwGZXA8hsE Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] ECC reboot (Was: When's the decision?) X-BeenThere: cfrg@irtf.org 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: Thu, 16 Oct 2014 18:00:50 -0000 On Thu, Oct 16, 2014 at 06:38:55PM +0100, Alyssa Rowan wrote: > > It seems to me at this stage that the requirements of the > existing-hardware stakeholders of the Brainpool may be not only > orthogonal, but actually (potentially) in direct opposition to the > requirements of the software stakeholders - and further their > requirements may (perhaps) already be satisfied by the Brainpool curves? I think the requirements are in direct opposition. And I know no reason why existing Brainpool curves wouldn't be usable for "high-security" hardware. Also, I think for other hardware, it doesn't really matter, since special primes are apparently neither advantage or disadvantage. -Ilari From nobody Thu Oct 16 11:07:07 2014 Return-Path: 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 295A41A6FEE for ; Thu, 16 Oct 2014 11:07:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, 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 BbU9emjpv6ZV for ; Thu, 16 Oct 2014 11:07:02 -0700 (PDT) Received: from mail-lb0-f171.google.com (mail-lb0-f171.google.com [209.85.217.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C5101A037C for ; Thu, 16 Oct 2014 11:07:02 -0700 (PDT) Received: by mail-lb0-f171.google.com with SMTP id z12so3293637lbi.16 for ; Thu, 16 Oct 2014 11:07:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=rUctzJ5EtVWXgJVddNMuDe9NsLX3ON1XXC9fg5qAFhM=; b=dKiopJ6LN0NchAheB0UTzRipMux+MNRQIC5AwlK+mZfTvm2D9RTokJopI+ks2BpLmS sot08q3yiKWaqoH+bd9+tuuo55crVA0csifz4OVsiRv/YIW0w+2x8xlReSoksAZq8CYk /3Yx0wA3emRH43lZdIB1Y5yhmUW79r9QWcVYbaf6lvWBCa41LFnuA1bzZNIOhJTOyb2e Fu9nGmoqx2UDaTuk3BnKIcYtw8ZhLrpMHADoBcAROS3yYj7BK+QwpstkRvaWkXRgZKkM xIFQhZkn/rEi5qPmCyC+uITrWJMUDIQPtsPLQB7l0lDpYHfmmCTivpVQZVaCA9A5Dn6n z1fg== X-Gm-Message-State: ALoCoQnb6iKv4xvI1st6U3zBrronfHeikx14aYm0HIHyStGMd0EVrdEtLEkuVJX3NYtAsVlTTr8Z X-Received: by 10.152.42.172 with SMTP id p12mr3395654lal.11.1413482820384; Thu, 16 Oct 2014 11:07:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.36.106 with HTTP; Thu, 16 Oct 2014 11:06:40 -0700 (PDT) In-Reply-To: <20141016180045.GA20823@LK-Perkele-VII> References: <543FF1A7.8030908@secunet.com> <544002AF.1020107@akr.io> <20141016180045.GA20823@LK-Perkele-VII> From: Andy Lutomirski Date: Thu, 16 Oct 2014 11:06:40 -0700 Message-ID: To: Ilari Liusvaara Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/hh50uXnkBTig6NlBPjdj6G1uEWw Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] ECC reboot (Was: When's the decision?) X-BeenThere: cfrg@irtf.org 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: Thu, 16 Oct 2014 18:07:05 -0000 On Thu, Oct 16, 2014 at 11:00 AM, Ilari Liusvaara wrote: > On Thu, Oct 16, 2014 at 06:38:55PM +0100, Alyssa Rowan wrote: >> >> It seems to me at this stage that the requirements of the >> existing-hardware stakeholders of the Brainpool may be not only >> orthogonal, but actually (potentially) in direct opposition to the >> requirements of the software stakeholders - and further their >> requirements may (perhaps) already be satisfied by the Brainpool curves? > > I think the requirements are in direct opposition. > > And I know no reason why existing Brainpool curves wouldn't be usable > for "high-security" hardware. Are the Brainpool curves really VPR? They're certainly far better in that regard than the NIST curves, but the BADA55 paper points out correctly that the "verifiably" part is weak. (The BADA55 curves themselves might actually not be so bad. They were clearly fudged, but the BADA55 property seems highly unlikely to be a cryptographic weakness, and fudging them to have some other unlikely property as well would have been rather expensive.) --Andy From nobody Thu Oct 16 11:29:55 2014 Return-Path: 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 1138D1A7018 for ; Thu, 16 Oct 2014 11:29:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-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 F8A3u5ogbojM for ; Thu, 16 Oct 2014 11:29:52 -0700 (PDT) Received: from entima.net (entima.net [78.129.143.175]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B5681A8032 for ; Thu, 16 Oct 2014 11:29:51 -0700 (PDT) Message-ID: <54400E9F.5020905@akr.io> Date: Thu, 16 Oct 2014 19:29:51 +0100 From: Alyssa Rowan MIME-Version: 1.0 To: "cfrg@irtf.org" References: In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/Jkbp6JyDKfDJfD7NhIhs4y3bZ4o Subject: Re: [Cfrg] ECC reboot (Was: When's the decision?) X-BeenThere: cfrg@irtf.org 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: Thu, 16 Oct 2014 18:29:54 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 16/10/2014 17:08, Paterson, Kenny wrote: > Our first task should be to finalise the requirements that we will > use to guide the selection process. I think we are close, with a > couple of outstanding issues: Alright, so let's try to get things in high gear and argue those out…? > 1. Amount of "wiggle room" that should be permitted. Broadly: I think what we're aiming for is probably one faster/strong curve, and one stronger/fast curve. Given the strong preferences of some to minimise the number of curves, it looks to me like ­≈384 is almost-definitely dropped, leaving us with something near ≈256 and something near ≈512. We seem to be in agreement that wiggle room on ≈256 would include fields of 2^255-19 as well as 2^256-189 in scope. For the paranoid-strong, performance-second ≈512, 2^512-569 very obviously falls within scope. I put forth that 2^521-1 also falls within scope. It's not very far away, and it's a true Mersenne prime rather than a pseudo-Mersenne, and they do not grow on trees - no others fall near our criteria (the next lowest is 2^127-1 which is way too small, and the next biggest is 2^607-1). They are very attractive - attractive enough for 4 (?) independent research groups to independently arrive on E-521, and SECG/NIST to have independently picked the same prime years ago for secp521r1. [Previous discussion countering this point: Sean Parkinson @ RSA suggested stepping over a power of 2 is "only going to hurt performance in the future". Phillip Hallam-Baker also thought anything that is not less than a clean multiple of a power of two "may cause severe performance hits on future architectures", mentioning 512-bit memory buses on graphics cards?! - although I'm not convinced that's actually primarily relevant to an implementation of a high-strength curve. We will, of course, evaluate performance of contenders in Phase II, future architectures can be more-or-less anything that works well, and performance implications usually aren't anything like so obvious… Aren't Mersennes actually particularly _good_ performance-wise?] I put forth that 2^414-17 and 2^448-2^224-1 might fall outside "wiggle room" there, although I do so very reluctantly as I think it's a shame to exclude them on that basis if they have otherwise nice properties, and they do seem to have very good performance for their strength. > 2. A more nuanced set of hardware requirements. See other thread. > So here's a proposal for a new schedule which I believe to be > feasible: 24/10/14 (1 week from now): we finalise requirements, > including hardware requirements. Optimistic? One way to find out. > 31/10/14 (2 weeks from now): we agree on whatever benchmarking > system we're going to use for performance measurements. (Right now, > supercop seems like the front runner to me.) Consider this an early +1 to SUPERCOP. > 30/11/14 (6 weeks from now): we deliver our recommendations to the > TLS WG. Let's give it a try! - -- /akr -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJUQA6fAAoJEOyEjtkWi2t6U8gQAJG9FmifkdZs2QQv+2gB8o2w fWdo6FztDHIyGaUTaOLzHdKhs7+3Ts7ozH2S418zNYNZ3rHbpi68iXxg57ekAeMo c8Nncog1ryB1K7s3BW38BZltcX2ceJrNv5Y33HEf6JwhG8lYyHDeiuSDuShXRi/B yv/UiI5uR+JmFR7kD4LDtgIB/uaNBCL4SUjIfWb1PrFe9+Y+b9boElnarDUcDifO RL1BbwiRuLAGKQCpfaw27dV86PxhCIGMj7aIP7xraBCVuSC6tFITY05H4MMZ85RE 5DSdDHcrKIcKm4bv3teLj3G4V6TUjJf7JW8ubhNQiicbN4isqumny8ZCWKLu1zRC U9CQF0oRvTLGTwIYOI6UD8+dhZ6vL2ckjIDKoSZ6vss6cwNTjSkHnR1wAnstqL8T YVOJsGj1Dth64AFpNjMRsoHEVSaU6m64QuANNBchynqOSpB9+F1EsJjpSwMk4jkU ejkRf7b73HRus6I9AwuQeZzubUQ8gqqs5t6xxM3+YMjtTlRa5ymvfaGJFA8MeKNA 8PpuiZOmWC6PKA4L7Cd3d6lKm7YZhGQBtqGVuJB83xzomDOoNQBPDLhHF8V8zXil 4avghhLlZNwWoKFcNlc46MGK7KBSu5fqrMN0hqhz+TkUKou3eTgXLAXiXReXJ/6L YzVvRl8bzJNkeTRar6Zp =9Y7p -----END PGP SIGNATURE----- From nobody Thu Oct 16 17:55:29 2014 Return-Path: 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 3901C1A8AEC for ; Thu, 16 Oct 2014 17:55:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.101 X-Spam-Level: X-Spam-Status: No, score=0.101 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, UNPARSEABLE_RELAY=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 ih4eApmDlT80 for ; Thu, 16 Oct 2014 17:55:23 -0700 (PDT) Received: from mace.cs.uic.edu (mace.cs.uic.edu [131.193.32.224]) by ietfa.amsl.com (Postfix) with SMTP id 886D91A8FD6 for ; Thu, 16 Oct 2014 17:55:21 -0700 (PDT) Received: (qmail 31914 invoked by uid 1011); 17 Oct 2014 00:55:17 -0000 Received: from unknown (unknown) by unknown with QMTP; 17 Oct 2014 00:55:17 -0000 Received: (qmail 14018 invoked by uid 1001); 17 Oct 2014 00:55:11 -0000 Date: 17 Oct 2014 00:55:11 -0000 Message-ID: <20141017005511.14016.qmail@cr.yp.to> From: "D. J. Bernstein" To: cfrg@irtf.org Mail-Followup-To: cfrg@irtf.org In-Reply-To: <201410081357.03062.manfred.lochter@bsi.bund.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/2VNzcCSEIHgJPLLJ4EIsHRDES9k Subject: [Cfrg] Primes vs. hardware side channels X-BeenThere: cfrg@irtf.org 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, 17 Oct 2014 00:55:26 -0000 The "special primes are harder to secure than general primes" claims are almost completely backwards. The correct question is what level of security can be achieved within the user's performance budget. Whether one counts hardware transistors, FPGA slices, AVR cycles, ARM cycles, or Intel cycles, the simple fact is that special primes are about half the cost of general primes (they almost eliminate reduction cost, which is about half the cost of mulmod and more than half the cost of a separate sqmod), leaving far more room for adding defenses against side-channel attacks. In the case of Brainpool's 256-bit curve, the defense under discussion consists of obscuring the bits of a 256-bit scalar s by adding a small multiple of the 256-bit group order to s, typically a 32-bit multiple. This seems safe if the bits are further obscured by a considerable level of physical noise. However, for plausibly smaller noise levels this is breakable, as illustrated by the recent paper by Schindler and Wiemers. This not-very-secure 288-bit Brainpool scalar multiplication is roughly as expensive as a 576-bit scalar multiplication on NIST P-256, using a 320-bit multiple instead of a 32-bit multiple. Nobody knows how to break a 320-bit multiple for the same plausible noise levels: the attacker needs the noise levels to be considerably lower. Less expensive curves, such as Curve25519, make room for even stronger side-channel defenses. It's easy to see, and well known, that for NIST P-256 etc. there are some scalar bits that wouldn't be obscured in this way if the multiple were smaller than about 128 bits. But such small multiples are at levels of performance that can't be achieved _at all_ by the Brainpool curves, so talking about this as a Brainpool security advantage makes no sense. The only reason I said "almost completely backwards" rather than "completely backwards" is that there are a few unusual platforms that have trouble seeing the cost advantages of special primes. For example, if someone built typical RSA-acceleration hardware years ago and is trying to resell it as ECC-acceleration hardware, he'll get * bad speeds out of Brainpool, * similarly bad speeds out of special primes, * worse speeds out of side-channel-protected Brainpool, and * even worse speeds out of side-channel-protected special primes. He won't see that competently designed special-prime hardware meets the user's performance goals with much stronger side-channel protection at vastly lower cost. The picture here is not that special primes are harder to secure than general primes; the picture is that special primes are easier to secure than general primes, except on obsolete niche hardware. The new Brainpool paper http://eprint.iacr.org/2014/832 incorrectly states that a "special shape of the prime does not improve performance in hardware" if the hardware is designed to "support arbitrary primes". In fact, anyone who can afford the hardware area for "arbitrary primes" is very close to the hardware area for arbitrary primes _plus_ several special primes. Mike Hamburg already gave an example last month: I have some limited experience in crypto hardware design, in particular working with a hardware modulo multiplier. If I recall correctly, adding support for a handful of the NIST primes (192, 224, 256 and 384 maybe?) cost about 10% area overhead in our lightweight design, for double the performance. The huge speed advantage over Brainpool again turns into an advantage in side-channel protection for any performance target, again contradicting the "special primes are harder to secure than general primes" claim. Of course, for ECC hardware designers who have more serious performance constraints, supporting "arbitrary primes" is out of the question, and choosing brainpoolP256t1 is much less pleasant than choosing a special prime, particularly with a Montgomery curve. The special prime again ends up with better side-channel protection for any performance target. To summarize, the strongest hardware designs provide the maximum side-channel protection by taking advantage of the speed of special primes. The core Brainpool objection to these stronger hardware designs is really that they don't match Brainpool's old designs. This is a transition-cost objection, raising questions such as * which hardware we're actually talking about, * how much the hardware is used in IETF protocols today, * whether the hardware would really have trouble with new curves, * how expensive new hardware for the new curves would be, * whether this is outweighed by the costs of sticking to old curves, etc. This shouldn't be misrepresented as a security objection. ---Dan From nobody Thu Oct 16 18:25:56 2014 Return-Path: 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 5E2C61A8789 for ; Thu, 16 Oct 2014 18:25:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 rPfUtgFrYTeJ for ; Thu, 16 Oct 2014 18:25:52 -0700 (PDT) Received: from mail-lb0-x22d.google.com (mail-lb0-x22d.google.com [IPv6:2a00:1450:4010:c04::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D9441A1BA4 for ; Thu, 16 Oct 2014 18:25:52 -0700 (PDT) Received: by mail-lb0-f173.google.com with SMTP id 10so3796326lbg.18 for ; Thu, 16 Oct 2014 18:25:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=pgvPSYlhvJqGYBK7KYU4+wF6Me6iGSsCn8uBzY/ndFE=; b=iNRBPHdQxi63LNW51dqn1NV55Gc3gFq50LvQzwVA1o0/QvEnNPiBIhzDZBvMIJ7Nhr 75ujOND/rUhOkY2f7GjqWk5DJvc81imVCrcvo2VEM/ayuE1Lv577M6NcHfHt54a2vPK4 3cIIT/B15n6Bxh6gcqK5B3PHX4+XIxeX86Kf/MGe1JAzH1ftDTmd7xVgaw66AdGD2x+6 4B8T1IK2Ok+4YvuQkQbOsgQ1KmCw2L0H4t8ia9cpS/pLJdVD9LuxWOOhhlqeDuolzQpC YMackAJ3yTIzX5onE6hs89CwQGN1ZItKTDsXW3CMadasrISTedKhpBuJTGWkDI5JEynY ukhw== X-Received: by 10.152.25.130 with SMTP id c2mr5317559lag.80.1413509150839; Thu, 16 Oct 2014 18:25:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.218.145 with HTTP; Thu, 16 Oct 2014 18:25:30 -0700 (PDT) In-Reply-To: <20141017005511.14016.qmail@cr.yp.to> References: <201410081357.03062.manfred.lochter@bsi.bund.de> <20141017005511.14016.qmail@cr.yp.to> From: David Leon Gil Date: Thu, 16 Oct 2014 21:25:30 -0400 Message-ID: To: "cfrg@irtf.org" , "D. J. Bernstein" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/S_5SfmzCTCTyA8xIaFSnHUMZWqM Subject: Re: [Cfrg] Primes vs. hardware side channels X-BeenThere: cfrg@irtf.org 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, 17 Oct 2014 01:25:54 -0000 On Thu, Oct 16, 2014 at 8:55 PM, D. J. Bernstein wrote: > In the case of Brainpool's 256-bit curve, the defense under discussion > consists of obscuring the bits of a 256-bit scalar s by adding a small > multiple of the 256-bit group order to s, typically a 32-bit multiple. > This seems safe if the bits are further obscured by a considerable level > of physical noise. However, for plausibly smaller noise levels this is > breakable, as illustrated by the recent paper by Schindler and Wiemers. For folks less familiar with this issue, page 85 et seq. of (the slides for) Marc Joye's FDTC 2013 keynote present a very readable explanation of why additive blinding, as described above, doesn't work: http://conferenze.dei.polimi.it/FDTC13/shared/FDTC-2013-keynote-2.pdf From nobody Thu Oct 16 23:16:42 2014 Return-Path: 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 457811A90C5 for ; Thu, 16 Oct 2014 23:16:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-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 sNaKh4cxy7cJ for ; Thu, 16 Oct 2014 23:16:38 -0700 (PDT) Received: from entima.net (entima.net [78.129.143.175]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCEDB1A8F46 for ; Thu, 16 Oct 2014 23:16:38 -0700 (PDT) Message-ID: <5440B447.5060509@akr.io> Date: Fri, 17 Oct 2014 07:16:39 +0100 From: Alyssa Rowan MIME-Version: 1.0 To: "cfrg@irtf.org" References: <20141017005511.14016.qmail@cr.yp.to> In-Reply-To: <20141017005511.14016.qmail@cr.yp.to> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/1pERfDrWN_uCQ8b8T080SgkwWYE Subject: Re: [Cfrg] Primes vs. hardware side channels X-BeenThere: cfrg@irtf.org 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, 17 Oct 2014 06:16:40 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 17/10/2014 01:55, D. J. Bernstein wrote: > This seems safe if the bits are further obscured by a considerable > level of physical noise. However, for plausibly smaller noise > levels this is breakable, as illustrated by the recent paper by > Schindler and Wiemers. In line with my previous comments, I'm just going to +1 all of this message, but particularly this bit right here. I also have a big question about whether wanting to minimise costs by reusing certifications for existing RSA hardware - and reusing that existing hardware for ECC - is necessarily sound in light of new research, new information, serious concerns raised about the efficacy and integrity of existing certification processes, wanting open alternatives, not working well with the NIST curves either, and so on. And there again is the point I made earlier: if they want Brainpool, they've already _got_ Brainpool. Nobody else seems to want it. That's why we're being asked for _new_ curves. And why they should design _new_ hardware to support them. (And protect against 'new' threats.) - -- /akr -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJUQLRHAAoJEOyEjtkWi2t6hS4P/1aSXUZOFwqJcZgl1KUGwbGa NNivBhVSKWWs1dVRa+AbwUbEtN3rbkIG3NGhKikItlrLwSGLD1PSaEbjDYHZFGAC u57iwJo5owgxNJBmrOhCZb43Tgf4QJeGr5UddbLqQLZ1/RX6dw9Aw2qJUF3BrkZ5 sqEkdu3hrTcaqh5ieSXulAZPau7WnK1BZ44Y01cv4tk/nE+zpMUQsIziyiFtSLzd pbaBjBpC3AT3Y58uFeGqyRSadYkXZdkauBuVTwPRGTijPhSD5Jg6+UJ3i+WaYxKK FymR2dBp2oLQDe2P9wd1MK16qY+B8g7nIWAXcmfv/h61bQjKSwU4tVrnV4g4ZIj4 S16i4QGajAmzTDZbwB3sfPvhiD/zcBDALhsD6yLiVQWAtvcGE+a6OYx0rqqVwDcr EAEofn7gqWnvhHABopOhxdJe6voVyEzq0LrXhKjDbGYOiTb+TiSxdfXikxgrU0IU 2eqa/n83WRuQuK1SG2v0w77kgNowTpPC5GsOLLJRm1C4IKzTcW11JyQwPhVEPX4d QqSVijf9wEJOkqK4LZLmZXTcTPpv2IqMRy98q5tXm5D69qcTGBPwKjHIWDNeGMRe rFsvuDe7t+97GcF0K8EGH31EdUWibzh7UiXl7SV8T0xd4Zf39T7ZRRuRP+vHSW8h 9dS/nCuE70ASuGsXCGwa =OzoT -----END PGP SIGNATURE----- From nobody Fri Oct 17 01:51:05 2014 Return-Path: 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 B92AF1A9139 for ; Fri, 17 Oct 2014 01:51:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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 1nE4Q0TbpBaZ for ; Fri, 17 Oct 2014 01:51:02 -0700 (PDT) Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD6421A9135 for ; Fri, 17 Oct 2014 01:51:01 -0700 (PDT) Received: from maildlpprd03.lss.emc.com (maildlpprd03.lss.emc.com [10.253.24.35]) by mailuogwprd03.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s9H8owpX014560 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 17 Oct 2014 04:51:00 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com s9H8owpX014560 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=rsa.com; s=jan2013; t=1413535860; bh=4BDkHMLPQAGDgofKcFkzvG6eWmQ=; h=From:To:CC:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=QlTBaDSQmEaKKdGG8Yq0mooQYR6bIuv/NoBMFjuAiA9kHDWErrBiczmLDesjak8oR FSQuSXPmzII8u3VB7xiO6yG+2zxN3DLvmJxPPe6Rq27s9cWCYSu3nIS/OHAa1Y2c1a 5TJ4/YeZJHRQNvyCW0P9+aSjCNZGp4Slal8w5sgw= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com s9H8owpX014560 Received: from mailusrhubprd53.lss.emc.com (mailusrhubprd53.lss.emc.com [10.106.48.18]) by maildlpprd03.lss.emc.com (RSA Interceptor); Fri, 17 Oct 2014 04:50:44 -0400 Received: from mxhub35.corp.emc.com (mxhub35.corp.emc.com [10.254.93.83]) by mailusrhubprd53.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s9H8opBP015309 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 17 Oct 2014 04:50:52 -0400 Received: from mx17a.corp.emc.com ([169.254.1.210]) by mxhub35.corp.emc.com ([::1]) with mapi; Fri, 17 Oct 2014 04:42:10 -0400 From: "Parkinson, Sean" To: "Paterson, Kenny" Date: Fri, 17 Oct 2014 04:42:09 -0400 Thread-Topic: [Cfrg] When's the decision? Thread-Index: AQHP4XoCGxb9lbfhS02i9PAKELf1JZwmeIwAgABZUQCADDoRgIAA+SiQ Message-ID: <2FBC676C3BBFBB4AA82945763B361DE60A76B232@MX17A.corp.emc.com> References: <20141008173154.15169.qmail@cr.yp.to> <2FBC676C3BBFBB4AA82945763B361DE608F1D021@MX17A.corp.emc.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd53.lss.emc.com X-RSA-Classifications: public Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/C09YgzQlFkxTFEIl-3wGyKK1DnU Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] When's the decision? X-BeenThere: cfrg@irtf.org 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, 17 Oct 2014 08:51:03 -0000 While I still think that X25519 has speed and implementation simplicity adv= antages over numsp256t1, the fact that it can only be used for key exchange= makes it difficult to recommend - you need another curve implementation an= yway. X25519 is already in use and, even if the CFRG don't recommend it, I believ= e it will be used - any speed advantage, despite code complexity cost, will= be taken by implementers. How this relates to other possible Montgomery curves I don't know. When a d= ecision is made on the stronger curve a Montgomery equivalent may appear. Sean -- Sean Parkinson | Consultant Software Engineer | RSA, The Security Division= =A0of EMC Office +61 7 3032 5232 | Fax +61 7 3032 5299 www.rsa.com -----Original Message----- From: Paterson, Kenny [mailto:Kenny.Paterson@rhul.ac.uk]=20 Sent: Friday, 17 October 2014 2:35 AM To: Parkinson, Sean; cfrg@irtf.org Subject: Re: [Cfrg] When's the decision? Sean, Are you planning to bring additional information on the issues that you ref= er to below to the list? Your additional input would be most welcome of course, but without concrete= details, it's difficult to factor your initial comments below into our del= iberations. Thanks Kenny=20 On 08/10/2014 23:51, "Parkinson, Sean" wrote: >I have concerns about a decision being made about which curves to=20 >recommend 'before Halloween'. >I am unaware of 3rd parties implementing and confirming all the curves=20 >that have been proposed. >Making a decision on new elliptic curves based on data that hasn't been=20 >corroborated by a 3rd party is bad practice. > >I have been implementing as many of the curves as I can and my=20 >performance results, so far, do not always match those that I have seen=20 >in papers. > >Also, I am concerned that, while some curves are being implemented to=20 >be constant time, not all curves are being implemented to be cache=20 >attack resistant. Either all implementations need to be resistant or=20 >all implementations not. Only then can a true comparison be made. > >Until these issues are dealt with I feel there is not sufficient=20 >information to make a decision. > >Sean >-- >Sean Parkinson | Consultant Software Engineer | RSA, The Security=20 >Division of EMC Office +61 7 3032 5232 | Fax +61 7 3032 5299=20 >www.rsa.com > >_______________________________________________ >Cfrg mailing list >Cfrg@irtf.org >http://www.irtf.org/mailman/listinfo/cfrg From nobody Fri Oct 17 02:04:33 2014 Return-Path: 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 8284A1A9162 for ; Fri, 17 Oct 2014 02:04:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 yxxdTyRCuqAB for ; Fri, 17 Oct 2014 02:04:30 -0700 (PDT) Received: from emh03.mail.saunalahti.fi (emh03.mail.saunalahti.fi [62.142.5.109]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AED61A9155 for ; Fri, 17 Oct 2014 02:04:30 -0700 (PDT) Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh03.mail.saunalahti.fi (Postfix) with ESMTP id 65AF81887F0; Fri, 17 Oct 2014 12:04:27 +0300 (EEST) Date: Fri, 17 Oct 2014 12:04:27 +0300 From: Ilari Liusvaara To: "Parkinson, Sean" Message-ID: <20141017090426.GA28822@LK-Perkele-VII> References: <20141008173154.15169.qmail@cr.yp.to> <2FBC676C3BBFBB4AA82945763B361DE608F1D021@MX17A.corp.emc.com> <2FBC676C3BBFBB4AA82945763B361DE60A76B232@MX17A.corp.emc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <2FBC676C3BBFBB4AA82945763B361DE60A76B232@MX17A.corp.emc.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/_dHv7k01JuXR83y-ZX31CKLg48w Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] When's the decision? X-BeenThere: cfrg@irtf.org 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, 17 Oct 2014 09:04:32 -0000 On Fri, Oct 17, 2014 at 04:42:09AM -0400, Parkinson, Sean wrote: > While I still think that X25519 has speed and implementation simplicity > advantages over numsp256t1, the fact that it can only be used for key > exchange makes it difficult to recommend - you need another curve > implementation anyway. One can transform it to forms that support signatures, sharing the base field implementation, which is by far the most annoying part. Unfortunately, all known EC signatures also require scalar field, which is even more annoying to implement than base field (and one can't use generic bignums there). ECDSA is practicularly annoying here, because it needs inversion in scalar field for signing. E.g. ECGDSA does not. IIRC, The MS ECCLIB software (at least 1.1) does not implement the corresponding scalar fields. I earlier posted a message that gave list of suggested operations. That also included fair amount of scalar field operations (in order to support various ECC protocols). -Ilari From nobody Fri Oct 17 02:22:04 2014 Return-Path: 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 D2C8B1A89A0 for ; Fri, 17 Oct 2014 02:22:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] 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 2q1KzTQidEnw for ; Fri, 17 Oct 2014 02:21:59 -0700 (PDT) Received: from a.mx.secunet.com (a.mx.secunet.com [195.81.216.161]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93D451ABD3B for ; Fri, 17 Oct 2014 02:21:59 -0700 (PDT) Received: from localhost (alg1 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id 029E01A0090; Fri, 17 Oct 2014 11:21:48 +0200 (CEST) X-Virus-Scanned: by secunet Received: from a.mx.secunet.com ([127.0.0.1]) by localhost (a.mx.secunet.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id dGOdIvniH6ex; Fri, 17 Oct 2014 11:21:39 +0200 (CEST) Received: from mail-essen-01.secunet.de (unknown [10.53.40.204]) by a.mx.secunet.com (Postfix) with ESMTP id 61B1D1A008F; Fri, 17 Oct 2014 11:21:39 +0200 (CEST) Received: from [10.208.1.76] (10.208.1.76) by mail-essen-01.secunet.de (10.53.40.204) with Microsoft SMTP Server (TLS) id 14.3.210.2; Fri, 17 Oct 2014 11:21:44 +0200 Message-ID: <5440DFA7.80208@secunet.com> Date: Fri, 17 Oct 2014 11:21:43 +0200 From: Johannes Merkle User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Alyssa Rowan , References: <543FF1A7.8030908@secunet.com> <544002AF.1020107@akr.io> In-Reply-To: <544002AF.1020107@akr.io> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.208.1.76] X-EXCLAIMER-MD-CONFIG: 2c86f778-e09b-4440-8b15-867914633a10 Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/0F5wc6P9DsACTdKoczGi_pzCkr0 Subject: Re: [Cfrg] ECC reboot (Was: When's the decision?) X-BeenThere: cfrg@irtf.org 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, 17 Oct 2014 09:22:02 -0000 Alyssa Rowan wrote on 16.10.2014 19:38: > I can see why they might want that, if VPR is the most convenient for their implementations - but from what I see > from the hesitant adoption of Brainpool in the wider community, this assertion is only true for software implementations. Brainpool curves are used by more than 50 million smart cards rolled out and several vpn solutions (e.g., based on IPSec) widely used within German and EU public authorities. -- Johannes From nobody Fri Oct 17 02:31:36 2014 Return-Path: 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 E59BA1AC3A5 for ; Fri, 17 Oct 2014 02:31:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 dNud9KgEpWof for ; Fri, 17 Oct 2014 02:31:28 -0700 (PDT) Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 514961AC3A1 for ; Fri, 17 Oct 2014 02:31:28 -0700 (PDT) Received: by mail-wg0-f46.google.com with SMTP id l18so471585wgh.29 for ; Fri, 17 Oct 2014 02:31:27 -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 :content-transfer-encoding:message-id:references:to; bh=8ufP9S/3ZLO6y2/BYwKMAyDBgcceemH10U6qrcQprtA=; b=bQc8B0IdGZyiGvuY3ZfuiKtxm6SBQOMsP3KEUr2YK9WkUHsdI60ikyIOUmrp7VN5H/ bTdKr/X76HB5TrmjShHEb6T+gF5gtlad4c01H7wTJ9jwqHg5YM8f3H+PjTouGOiiiZqi 4pDtmGdo6plr3wegEX2PFER0Hv1b//IdLnefEuQ1r7S6PTC+2xwS59ynQ/F4Br9nQtg/ b5eAzH/WrKF8DzAiGNsdbVcEqrmhWVdmCjf6GYH4qbqkmoUlmsAb9JvcMZn8lvMy+W9W hxo7cFXX1titQYlDA9lbkNHv4rHu4uHXHEGeglgA52kUqqtZRo+C6BXL2XUcPv2Dtn+t 7gSA== X-Received: by 10.180.9.169 with SMTP id a9mr12561530wib.7.1413538286935; Fri, 17 Oct 2014 02:31:26 -0700 (PDT) Received: from [192.168.1.104] (IGLD-84-228-54-205.inter.net.il. [84.228.54.205]) by mx.google.com with ESMTPSA id i5sm1021047wjz.0.2014.10.17.02.31.25 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 17 Oct 2014 02:31:26 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Yoav Nir In-Reply-To: <2FBC676C3BBFBB4AA82945763B361DE60A76B232@MX17A.corp.emc.com> Date: Fri, 17 Oct 2014 12:31:23 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <6BDE7CB3-CFBF-441B-B720-2C150F0934CF@gmail.com> References: <20141008173154.15169.qmail@cr.yp.to> <2FBC676C3BBFBB4AA82945763B361DE608F1D021@MX17A.corp.emc.com> <2FBC676C3BBFBB4AA82945763B361DE60A76B232@MX17A.corp.emc.com> To: "Parkinson, Sean" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/YH0woFS0tQhy9XDClrILzM1Opcs Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] When's the decision? X-BeenThere: cfrg@irtf.org 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, 17 Oct 2014 09:31:30 -0000 On Oct 17, 2014, at 11:42 AM, Parkinson, Sean = wrote: > While I still think that X25519 has speed and implementation = simplicity advantages over numsp256t1, the fact that it can only be used = for key exchange makes it difficult to recommend - you need another = curve implementation anyway. > X25519 is already in use and, even if the CFRG don't recommend it, I = believe it will be used - any speed advantage, despite code complexity = cost, will be taken by implementers. I disagree. X25519 is in use in some specialized places, sure. But a = recommendation from CFRG will lead to a standards-track document (or = two) from TLS and another one from IPsecME. That leads to = implementations in the major TLS libraries (OpenSSL, NSS, SCHANNEL) = which then means it=92s implemented in Chrome, Firefox, Internet = Explorer and on the server side, most deployments of Apache and nginx.=20= That=92s a whole different scale of =93used=94 compared with what we = have now. Yoav From nobody Fri Oct 17 02:40:12 2014 Return-Path: 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 9337F1AC3AC for ; Fri, 17 Oct 2014 02:40:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-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 fmSbkJg7tblM for ; Fri, 17 Oct 2014 02:40:06 -0700 (PDT) Received: from entima.net (entima.net [78.129.143.175]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F2CC1AC3A8 for ; Fri, 17 Oct 2014 02:40:06 -0700 (PDT) In-Reply-To: <5440DFA7.80208@secunet.com> References: <543FF1A7.8030908@secunet.com> <544002AF.1020107@akr.io> <5440DFA7.80208@secunet.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 From: Alyssa Rowan Date: Fri, 17 Oct 2014 10:40:01 +0100 To: cfrg@irtf.org Message-ID: <863EB75F-4C6D-48E8-B4F3-0795F7D1269B@akr.io> Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/GnRLKPf9ALD4tEDy2c6lEiHRluI Subject: Re: [Cfrg] ECC reboot (Was: When's the decision?) X-BeenThere: cfrg@irtf.org 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, 17 Oct 2014 09:40:10 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 17 October 2014 10:21:43 BST, Johannes Merkle wrote: >> from the hesitant adoption of Brainpool in the wider community, >this assertion is only true for software implementations. Brainpool curves are used by more than 50 million smartcards rolled out and several vpn solutions (e.g., based on IPSec) widely used within German and EU public authorities. Yes, that's exactly my point. Brainpool usage seems to be concentrated under a relatively small, interlocked group of governmental stakeholders in specialist applications - not really rolled out in the wider community like the NIST curves, let alone like RSA. Besides, those smartcards are surely already provisioned and keyed so not relevant to any new curve? - -- /akr -----BEGIN PGP SIGNATURE----- Version: APG v1.1.1 iQI3BAEBCgAhBQJUQOPxGhxBbHlzc2EgUm93YW4gPGFrckBha3IuaW8+AAoJEOyE jtkWi2t6l2wQAKQl3oAeNLEwLYvfObDgGfJmmyptkrU292k21zZQED9Gee/5zeyF XrW5bOHyp07ui/CVdes/OV2+94qQLYKim5CCw45UfAuFOW5ztueU/99hf7N6Fr6t CWk14/OonvnU5SrY8a+3TrxIhT37B0vvbdqXtznwmpIfgFMRe4qZBukjTp5kQ+WJ AMs+EumaaF/GjBUNKnevljHd+yFmFDKxkNF8Dx/SkDmztfUZdw3z4cpgn7tEMkzq XnDp76H4/Fvhy4DO/0S3aL8N/arKkA96wr7HtmVNx93dzzPhVz2XumlU/jXLRb/4 suvD3VoVEJtkhqCTskV736ZzPj6x4Krm2ysJb8ss807X6gTXziJsn7L0CW3ZjAYc NIFjIXQaVrjbZAmc5pbijYUpwlTnY5Y5s+3Is49OiTO+HGVArC5EXHAuty2xwuPe 3XX32WHmvZRwOXpPbkgidK7BuFR1oifXvtE3Qn4OvUUH9z3nd9PN58Npft3wnA6Q AGFyJ5kyJpLUCyYCEbD4qun/I2MljxbpmxBhFeAsrgSVE3fhtLvkyveYsDQoxwss KD42C9cRynYn2GHUxLNm7Kr4gvXUrsQ8Aug97EEaZSwpcfBJXl0k6xQMNNH3N9sP fv7lrV5j6NR5hwLhyawiq4cRM4LxAgegzOZH53cvuWeIOBygtCT4kh4G =RoSr -----END PGP SIGNATURE----- From nobody Fri Oct 17 02:48:02 2014 Return-Path: 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 3C2231AC3AC for ; Fri, 17 Oct 2014 02:48:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 w0e1tBtL1up4 for ; Fri, 17 Oct 2014 02:47:59 -0700 (PDT) Received: from emh03.mail.saunalahti.fi (emh03.mail.saunalahti.fi [62.142.5.109]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C4051AC3AB for ; Fri, 17 Oct 2014 02:47:58 -0700 (PDT) Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh03.mail.saunalahti.fi (Postfix) with ESMTP id DA5491887B9; Fri, 17 Oct 2014 12:47:55 +0300 (EEST) Date: Fri, 17 Oct 2014 12:47:55 +0300 From: Ilari Liusvaara To: Johannes Merkle Message-ID: <20141017094755.GA29915@LK-Perkele-VII> References: <543FF1A7.8030908@secunet.com> <544002AF.1020107@akr.io> <5440DFA7.80208@secunet.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <5440DFA7.80208@secunet.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/7aKTWfwW0n6O2Td_1v6WOhEZ3Mw Cc: cfrg@irtf.org Subject: Re: [Cfrg] ECC reboot (Was: When's the decision?) X-BeenThere: cfrg@irtf.org 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, 17 Oct 2014 09:48:01 -0000 On Fri, Oct 17, 2014 at 11:21:43AM +0200, Johannes Merkle wrote: > > Alyssa Rowan wrote on 16.10.2014 19:38: > > I can see why they might want that, if VPR is the most convenient > > for their implementations - but from what I see from the hesitant > > adoption of Brainpool in the wider community, > > this assertion is only true for software implementations. Brainpool > curves are used by more than 50 million smart cards rolled out and > several vpn solutions (e.g., based on IPSec) widely used within > German and EU public authorities. And what's wrong with just using Brainpool for implementations that need random primes for extended side channel resistance? Not rigid enough? Not standard enough? For software implementations only needing defenses against software attack (including attacks from different process in the same host/VM) there is plenty wrong with using Brainpool. If attacker can get enough access to pull off EM attacks against most of the endpoints, one has more severe problems than software vulernable to EM attack. There is a good reason (singular!) why NIST/NSA curves are used far far more in TLS than Brainpool, despite there being codepoints for both: Performance. -Ilari From nobody Fri Oct 17 02:49:12 2014 Return-Path: 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 2FE1A1AC3AB for ; Fri, 17 Oct 2014 02:49:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] 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 zZNI-Jt_pYaP for ; Fri, 17 Oct 2014 02:49:09 -0700 (PDT) Received: from a.mx.secunet.com (a.mx.secunet.com [195.81.216.161]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 319F61AC3B1 for ; Fri, 17 Oct 2014 02:49:09 -0700 (PDT) Received: from localhost (alg1 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id 34E461A0084; Fri, 17 Oct 2014 11:49:02 +0200 (CEST) X-Virus-Scanned: by secunet Received: from a.mx.secunet.com ([127.0.0.1]) by localhost (a.mx.secunet.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id jCVR32CortuY; Fri, 17 Oct 2014 11:48:53 +0200 (CEST) Received: from mail-essen-01.secunet.de (unknown [10.53.40.204]) by a.mx.secunet.com (Postfix) with ESMTP id 9B9671A008F; Fri, 17 Oct 2014 11:48:53 +0200 (CEST) Received: from [10.208.1.76] (10.208.1.76) by mail-essen-01.secunet.de (10.53.40.204) with Microsoft SMTP Server (TLS) id 14.3.210.2; Fri, 17 Oct 2014 11:48:58 +0200 Message-ID: <5440E60A.8050505@secunet.com> Date: Fri, 17 Oct 2014 11:48:58 +0200 From: Johannes Merkle User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Andy Lutomirski , Ilari Liusvaara References: <543FF1A7.8030908@secunet.com> <544002AF.1020107@akr.io> <20141016180045.GA20823@LK-Perkele-VII> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.208.1.76] X-EXCLAIMER-MD-CONFIG: 2c86f778-e09b-4440-8b15-867914633a10 Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/ie6Gp2A0820Wye_Mv9XqXW-pFQE Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] ECC reboot (Was: When's the decision?) X-BeenThere: cfrg@irtf.org 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, 17 Oct 2014 09:49:11 -0000 Andy Lutomirski wrote on 16.10.2014 20:06: > Are the Brainpool curves really VPR? They're certainly far better in > that regard than the NIST curves, but the BADA55 paper points out > correctly that the "verifiably" part is weak. This assertion is very wrong, as I have already explained on this list. The BADA55 paper took much more freedom (in several respects) than the Brainpool method did. It is also obvious that there approach worked only for one of the relevant bit lengths. As the NUMS paper correctly points out, there is no perfect rigidity as a certain degree of freedom in inevitable (e.g., there are many proposals for curves where the coefficients had been chosen to be minimal, so this approach is not fully rigid either). However, to call the rigidity of the Brainpool curves "weak" is a gross exaggeration. The Brainpool curve generation method was not just made up by BSI, but was openly discussed and agreed upon within the Brainpool group (which comprises a diversity of companies, academic institutions and public authorities), and there were no objections or reservations expressed. By the way, one of the authors of the BADA55 paper participated in that process and didn't express any objections either. -- Johannes From nobody Fri Oct 17 07:35:38 2014 Return-Path: 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 2A60A1A008A; Fri, 17 Oct 2014 07:35:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 9HqOWBPstQQl; Fri, 17 Oct 2014 07:35:34 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EF911A0079; Fri, 17 Oct 2014 07:35:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141017143534.12669.81157.idtracker@ietfa.amsl.com> Date: Fri, 17 Oct 2014 07:35:34 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/QWWcRqsyQ0YcL9jM86fQvoYkKU4 Cc: cfrg@ietf.org Subject: [Cfrg] I-D Action: draft-irtf-cfrg-chacha20-poly1305-02.txt X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.15 List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 14:35:36 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Crypto Forum Research Group Working Group of the IETF. Title : ChaCha20 and Poly1305 for IETF protocols Authors : Yoav Nir Adam Langley Filename : draft-irtf-cfrg-chacha20-poly1305-02.txt Pages : 42 Date : 2014-10-17 Abstract: This document defines the ChaCha20 stream cipher, as well as the use of the Poly1305 authenticator, both as stand-alone algorithms, and as a "combined mode", or Authenticated Encryption with Additional Data (AEAD) algorithm. This document does not introduce any new crypto, but is meant to serve as a stable reference and an implementation guide. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-irtf-cfrg-chacha20-poly1305/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-irtf-cfrg-chacha20-poly1305-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-irtf-cfrg-chacha20-poly1305-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Oct 17 08:24:58 2014 Return-Path: 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 E1B531A1AC3 for ; Fri, 17 Oct 2014 08:24:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.361 X-Spam-Level: X-Spam-Status: No, score=-0.361 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] 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 dJNCwPW0hoVS for ; Fri, 17 Oct 2014 08:24:43 -0700 (PDT) Received: from mx01.gematik.de (mail.gematik.de [195.145.148.245]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A7511A03A4 for ; Fri, 17 Oct 2014 08:24:41 -0700 (PDT) Received: from gsbeeg06.int.gematik.de (localhost [127.0.0.1]) by mx01.gematik.de (Postfix) with ESMTP id 587641600CC; Fri, 17 Oct 2014 17:24:39 +0200 (CEST) From: "Hallof, Andreas" To: 'Alyssa Rowan' , "cfrg@irtf.org" Thread-Topic: [Cfrg] ECC reboot (Was: When's the decision?) Thread-Index: Ac/qGmraGx1tfIUvTDG7EGNVqiFc/Q== Date: Fri, 17 Oct 2014 15:24:37 +0000 Message-ID: <0FC829CD89DE224E98637A5D757BC1B81F0245DD@GSBEEX01.int.gematik.de> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-olx-disclaimer: Done Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TBoneOriginalFrom: "Hallof, Andreas" X-TBoneOriginalTo: 'Alyssa Rowan' , "cfrg@irtf.org" X-TBoneDomainSigned: false Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/mxAwN4n1TcMejJTgC3D6Nq52RFI Subject: Re: [Cfrg] ECC reboot (Was: When's the decision?) X-BeenThere: cfrg@irtf.org 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, 17 Oct 2014 15:24:46 -0000 Please add to these 50+ million smartcards, another 70 million german eHeal= th-Cards.=20 Every statutory health insurance patient in Germany has a smartcards, that = is capable of=20 supporting a client-authenticated TLS-Session (RSA-based keys + dedicated T= LS-Certificate). In medium term we want to migrate to an ECC-based scheme. > Besides, those smartcards are surely already provisioned and keyed so not= relevant to any new curve? Wrong. If independent from each other three different Chipcard-Manufacturer tell m= e they prefer using=20 curves with random primes then this tells me something. Regards, Andreas Hallof=20 -- Andreas Hallof, Datenschutz und Datensicherheit / Kryptographie -----Urspr=FCngliche Nachricht----- Von: Cfrg [mailto:cfrg-bounces@irtf.org] Im Auftrag von Alyssa Rowan Gesendet: Freitag, 17. Oktober 2014 11:40 An: cfrg@irtf.org Betreff: Re: [Cfrg] ECC reboot (Was: When's the decision?) [NICHT VERSCHLUE= SSELT, ] [SIGNATUR_UNPRUEFBAR, OpenPGP] On 17 October 2014 10:21:43 BST, Johannes Merkle wrote: >> from the hesitant adoption of Brainpool in the wider community, >this assertion is only true for software implementations. Brainpool curves= are used by more than 50 million smartcards rolled out and several vpn sol= utions (e.g., based on IPSec) widely used within German and EU public autho= rities. Yes, that's exactly my point. Brainpool usage seems to be concentrated unde= r a relatively small, interlocked group of governmental stakeholders in spe= cialist applications - not really rolled out in the wider community like th= e NIST curves, let alone like RSA. Besides, those smartcards are surely already provisioned and keyed so not r= elevant to any new curve? -- /akr From nobody Fri Oct 17 08:51:23 2014 Return-Path: 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 7EBB11A1B86 for ; Fri, 17 Oct 2014 08:51:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.994 X-Spam-Level: X-Spam-Status: No, score=0.994 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.793] autolearn=no 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 V7lvPAIMZNQI for ; Fri, 17 Oct 2014 08:51:17 -0700 (PDT) Received: from mordell.elzevir.fr (unknown [IPv6:2001:4b98:dc0:41:216:3eff:feeb:c406]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FEF31A1B87 for ; Fri, 17 Oct 2014 08:51:17 -0700 (PDT) Received: from thue.elzevir.fr (thue.elzevir.fr [88.165.216.11]) by mordell.elzevir.fr (Postfix) with ESMTPS id 47D791613F; Fri, 17 Oct 2014 17:51:15 +0200 (CEST) Received: from [192.168.0.124] (unknown [192.168.0.254]) by thue.elzevir.fr (Postfix) with ESMTPSA id 95750290D9; Fri, 17 Oct 2014 17:51:14 +0200 (CEST) Message-ID: <54413AF2.7050005@elzevir.fr> Date: Fri, 17 Oct 2014 17:51:14 +0200 From: =?windows-1252?Q?Manuel_P=E9gouri=E9-Gonnard?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: "Hallof, Andreas" , 'Alyssa Rowan' , "cfrg@irtf.org" References: <0FC829CD89DE224E98637A5D757BC1B81F0245DD@GSBEEX01.int.gematik.de> In-Reply-To: <0FC829CD89DE224E98637A5D757BC1B81F0245DD@GSBEEX01.int.gematik.de> OpenPGP: id=98EED379; url=https://elzevir.fr/gpg/mpg.asc Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/goO7aKKF167555IpbcJPZ6YDOL4 Subject: Re: [Cfrg] ECC reboot (Was: When's the decision?) X-BeenThere: cfrg@irtf.org 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, 17 Oct 2014 15:51:19 -0000 On 17/10/2014 17:24, Hallof, Andreas wrote: > If independent from each other three different Chipcard-Manufacturer tell me > they prefer using curves with random primes then this tells me something. > I don't disagree with that, but unless I missed something nobody answered the following question yet: why can't people who prefer random primes use the already published and standardised (for use with PKIX and TLS and probably others) Brainpool curves? If the people who need/prefer random primes are happy with the current Brainpool curves, then the new curves only need to satisfy the rest of the world. (Assuming the CFRG decision clearly state that they are not intended as a replacement to the Brainpool curves, but as a complement.) Manuel. From nobody Fri Oct 17 09:07:48 2014 Return-Path: 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 EE4681A1B5B for ; Fri, 17 Oct 2014 09:07:44 -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 iNKR9UyGlgRh for ; Fri, 17 Oct 2014 09:07:43 -0700 (PDT) Received: from mail-qg0-x229.google.com (mail-qg0-x229.google.com [IPv6:2607:f8b0:400d:c04::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECC6C1A1A52 for ; Fri, 17 Oct 2014 09:07:42 -0700 (PDT) Received: by mail-qg0-f41.google.com with SMTP id a108so768084qge.14 for ; Fri, 17 Oct 2014 09:07:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:mime-version:message-id:in-reply-to:references:from:to:subject :content-type; bh=affzjkzrbzKBDkATT96ieaddZsR1ZdWBrhGfQOUB1dc=; b=l5JHJCohHpkekY4QLy9IcaGIhHQBdW4oJ1YGPl2yhYpGbuYD8rQlp2j148AFqAqDkl D8HeFNPKTPGXoPVKt3Efd640W1ieYfIFeobKz3LYvT95kITLNzo1LCPkVgEoZnbJ4M+J vT5ExSkh9Xt3t4+LSnAJXQyvbMdGmEJCnix48jAcX+msmzT1DR4D23YuQqWwATVdxdhs 59puAqSkiCZTJ57Uk5Qob8/wZohY+bQJ55jTkbBAHWfpmIfejO3IHB69fZgR2n6LuuoW /yz1nuPGPCRHYmBWnmUZtnocBFkIlWJUe5rtL2dNuzxYzkI1SMn4M0qWf9X1szCytufk FYTg== X-Received: by 10.224.111.201 with SMTP id t9mr13721720qap.0.1413562062048; Fri, 17 Oct 2014 09:07:42 -0700 (PDT) Received: from hedwig-63.prd.orcali.com (ec2-54-85-253-19.compute-1.amazonaws.com. [54.85.253.19]) by mx.google.com with ESMTPSA id o7sm1212317qgd.11.2014.10.17.09.07.40 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 17 Oct 2014 09:07:40 -0700 (PDT) Date: Fri, 17 Oct 2014 09:07:40 -0700 (PDT) X-Google-Original-Date: Fri, 17 Oct 2014 16:07:39 GMT MIME-Version: 1.0 X-Mailer: Nodemailer (0.5.0; +http://www.nodemailer.com/) Message-Id: <1413562059625.99476af5@Nodemailer> In-Reply-To: <54400E9F.5020905@akr.io> References: <54400E9F.5020905@akr.io> X-Orchestra-Oid: 35E76E90-2CB0-4EF9-9439-30B9AD0ADA83 X-Orchestra-Sig: 193b27009f40380fdd2da4ff5621169f2fe2de37 X-Orchestra-Thrid: TA0A48A94-F93D-4145-9A0F-E0395A71098E_1482136742507386550 X-Orchestra-Thrid-Sig: 25270b4c11286b5aa8a2cacd930854b0787e83fd X-Orchestra-Account: 016f880b96449a4a7af50f5448cf76e26ded3e5a From: "David Leon Gil" To: "Alyssa Rowan" , cfrg@irtf.org Content-Type: multipart/alternative; boundary="----Nodemailer-0.5.0-?=_1-1413562060892" Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/KCahHlTaUofgexEo9TSu2VlzFa4 Subject: Re: [Cfrg] ECC reboot (Was: When's the decision?) X-BeenThere: cfrg@irtf.org 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, 17 Oct 2014 16:07:45 -0000 ------Nodemailer-0.5.0-?=_1-1413562060892 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Re the primes 2^521-1 and 2^607-1. Mersenne may be particularly good for = hardware. Most of the large (expensive) blocks can be shared with = side-channel-protected DSP blocks. And hardware designs for Mersenne = multiplication are sufficiently old (Rader gives one), that there are no IP= issues. (And this, I submit, should be a CFRG priority.) They're obviously good software performers as well. There is no problem with generating random curves mod M521; there are = O(2^521-1) isomorphism classes. (About 1/4 are Edwards as well, IIRC.) (Because of the width of DSPs needed in some applications, the prime M607 = may not be significantly more expensive than M521 in hardware.= ) ------Nodemailer-0.5.0-?=_1-1413562060892 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Re the primes 2^521-1 and 2^607-1. = Mersenne may be particularly good for hardware. Most of the large = (expensive) blocks can be shared with side-channel-protected DSP blocks. = And hardware designs for Mersenne multiplication are sufficiently old = (Rader gives one), that there are no IP issues. (And this, I submit, should= be a CFRG priority.)

They're obviously good software performers as well.

There is no problem with generating random curves mod M521; there are = O(2^521-1) isomorphism classes. (About 1/4 are Edwards as well, IIRC.= )

(Because of the width of DSPs needed in some applications, the prime = M607 may not be significantly more expensive than M521 in hardware.)


------Nodemailer-0.5.0-?=_1-1413562060892-- From nobody Fri Oct 17 09:13:22 2014 Return-Path: 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 5ACD61A1BAC for ; Fri, 17 Oct 2014 09:13:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.26 X-Spam-Level: X-Spam-Status: No, score=-2.26 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] 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 4l85PrKilhUl for ; Fri, 17 Oct 2014 09:13:17 -0700 (PDT) Received: from mx01.gematik.de (mail.gematik.de [195.145.148.245]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 581401A1B8E for ; Fri, 17 Oct 2014 09:13:17 -0700 (PDT) Received: from gsbeeg06.int.gematik.de (localhost [127.0.0.1]) by mx01.gematik.de (Postfix) with ESMTP id E04741600C9; Fri, 17 Oct 2014 18:13:15 +0200 (CEST) From: "Hallof, Andreas" To: 'Ilari Liusvaara' , Johannes Merkle Thread-Topic: [Cfrg] ECC reboot (Was: When's the decision?) Thread-Index: AQHP6evh/eBHfwmMmUSZVajmnry++pwz6XqAgAB/qXA= Date: Fri, 17 Oct 2014 16:13:13 +0000 Message-ID: <0FC829CD89DE224E98637A5D757BC1B81F02460A@GSBEEX01.int.gematik.de> References: <543FF1A7.8030908@secunet.com> <544002AF.1020107@akr.io> <5440DFA7.80208@secunet.com> <20141017094755.GA29915@LK-Perkele-VII> In-Reply-To: <20141017094755.GA29915@LK-Perkele-VII> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-olx-disclaimer: Done Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TBoneOriginalFrom: "Hallof, Andreas" X-TBoneOriginalTo: 'Ilari Liusvaara' , Johannes Merkle X-TBoneOriginalCC: "cfrg@irtf.org" X-TBoneDomainSigned: false Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/ENIFtpKChfxer7aRjm71wsjoB-U Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] ECC reboot (Was: When's the decision?) X-BeenThere: cfrg@irtf.org 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, 17 Oct 2014 16:13:19 -0000 > And what's wrong with just using Brainpool for implementations that need = random primes for extended side channel resistance? Nothing is wrong about that.=20 The point that Mr. Merkle is addressing, is that there is a huge world outs= ide PC/Server-based TLS-Authentication. I have the impression the current discussion at the cfrg is too narrowly fo= cused on software implementations in unconstrained environments with only g= lobal timing SCA. In the infrastructure surrounding the german eHealth-Card the majority of a= ll TLS-Connection are based on smartcards on one communication-endpoint (th= e other being a server / non-smartcards). The same is true for the smartmeter-infrastructure.=20 Like it is stated in http://eprint.iacr.org/2014/832 a result of the curren= t discussion at the cfrg could be that there are two sets of curves. I have the impression the Brainpool-group would happily accept/(=3D> switch= to) the one set (with random primes), that has the necessary cryptographic= properties. Thus reducing the implementation-costs at smartcards, Web-browsers, servers= etc.. > Performance. If a ECDSA-Brainpool-based-signaturecreation cost around 90 ms on a cheap s= martcard, it is of little concern to me if it would be 20% faster or slower= . SCA-resistance is a concern for me. Regards, Andreas Hallof -- Andreas Hallof, Datenschutz und Datensicherheit / Kryptographie -----Urspr=FCngliche Nachricht----- Von: Cfrg [mailto:cfrg-bounces@irtf.org] Im Auftrag von Ilari Liusvaara Gesendet: Freitag, 17. Oktober 2014 11:48 An: Johannes Merkle Cc: cfrg@irtf.org Betreff: Re: [Cfrg] ECC reboot (Was: When's the decision?) On Fri, Oct 17, 2014 at 11:21:43AM +0200, Johannes Merkle wrote: >=20 > Alyssa Rowan wrote on 16.10.2014 19:38: > > I can see why they might want that, if VPR is the most convenient=20 > > for their implementations - but from what I see from the hesitant=20 > > adoption of Brainpool in the wider community, >=20 > this assertion is only true for software implementations. Brainpool=20 > curves are used by more than 50 million smart cards rolled out and=20 > several vpn solutions (e.g., based on IPSec) widely used within German=20 > and EU public authorities. And what's wrong with just using Brainpool for implementations that need ra= ndom primes for extended side channel resistance? Not rigid enough? Not sta= ndard enough? For software implementations only needing defenses against software attack = (including attacks from different process in the same host/VM) there is ple= nty wrong with using Brainpool. If attacker can get enough access to pull off EM attacks against most of th= e endpoints, one has more severe problems than software vulernable to EM at= tack. There is a good reason (singular!) why NIST/NSA curves are used far far mor= e in TLS than Brainpool, despite there being codepoints for both: Performance. -Ilari _______________________________________________ Cfrg mailing list Cfrg@irtf.org http://www.irtf.org/mailman/listinfo/cfrg From nobody Fri Oct 17 09:23:29 2014 Return-Path: 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 828EA1A1BC6 for ; Fri, 17 Oct 2014 09:23:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 OBGMuf5iOndW for ; Fri, 17 Oct 2014 09:23:23 -0700 (PDT) Received: from mail-yk0-x233.google.com (mail-yk0-x233.google.com [IPv6:2607:f8b0:4002:c07::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7063F1A1BA9 for ; Fri, 17 Oct 2014 09:23:23 -0700 (PDT) Received: by mail-yk0-f179.google.com with SMTP id 200so479571ykr.24 for ; Fri, 17 Oct 2014 09:23:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=PmwK3ZP4A5IyAC5RPh3GGpQyfTO8zY9GNWVo0yrKO5I=; b=k5hYXgwupCFkQQgzDmW221yIqcXxIBcvnt14lOzYxnQd1bYi+JCDvpJM1cLC6NhHYH 51RSmUfWXuiIJsR18ZGbm4o3TFmGOdySMELYOBK11pR9TCWlNtiLBO8jzyWFCcP99491 zt3olcf1nktsvOjHGaiRctS2Nn5keSIcHF51u2Sx/cgXr5eV5NoZIpGLuk11AnS49G+6 NaXKUc7TBUtD+LE0M4/VcUjs7SoJXuivzITia1I+VbinB+X6GX+ONbQpYWRPdSY+hB8M uoZhq4bLCRcMIMKJNRKioLL/b3BgysMzlbbF/WkmQ+yOlNEbenO9acvwaJ58a0l66/hq LG9Q== MIME-Version: 1.0 X-Received: by 10.236.22.37 with SMTP id s25mr5681426yhs.138.1413563002690; Fri, 17 Oct 2014 09:23:22 -0700 (PDT) Received: by 10.170.195.149 with HTTP; Fri, 17 Oct 2014 09:23:22 -0700 (PDT) In-Reply-To: <0FC829CD89DE224E98637A5D757BC1B81F02460A@GSBEEX01.int.gematik.de> References: <543FF1A7.8030908@secunet.com> <544002AF.1020107@akr.io> <5440DFA7.80208@secunet.com> <20141017094755.GA29915@LK-Perkele-VII> <0FC829CD89DE224E98637A5D757BC1B81F02460A@GSBEEX01.int.gematik.de> Date: Fri, 17 Oct 2014 09:23:22 -0700 Message-ID: From: Watson Ladd To: "Hallof, Andreas" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/j_9S8H08Fl194iDiGq764lfRRdU Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] ECC reboot (Was: When's the decision?) X-BeenThere: cfrg@irtf.org 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, 17 Oct 2014 16:23:25 -0000 On Fri, Oct 17, 2014 at 9:13 AM, Hallof, Andreas wrote: >> And what's wrong with just using Brainpool for implementations that need= random primes for extended side channel resistance? > Nothing is wrong about that. > > The point that Mr. Merkle is addressing, is that there is a huge world ou= tside PC/Server-based TLS-Authentication. > I have the impression the current discussion at the cfrg is too narrowly = focused on software implementations in unconstrained environments with only= global timing SCA. > > In the infrastructure surrounding the german eHealth-Card the majority of= all TLS-Connection are based on smartcards on one communication-endpoint (= the other being a server / non-smartcards). > The same is true for the smartmeter-infrastructure. > > Like it is stated in http://eprint.iacr.org/2014/832 a result of the curr= ent discussion at the cfrg could be that there are two sets of curves. > I have the impression the Brainpool-group would happily accept/(=3D> swit= ch to) the one set (with random primes), that has the necessary cryptograph= ic properties. > Thus reducing the implementation-costs at smartcards, Web-browsers, serve= rs etc.. What sort of decision do you think we are going to make? We obviously cannot remove curves. So Brainpool will remain in TLS. The question is about curves which make software implementations easier and faster. Why does hardware matter for the choice we are going to make? > >> Performance. > If a ECDSA-Brainpool-based-signaturecreation cost around 90 ms on a cheap= smartcard, it is of little concern to me if it would be 20% faster or slow= er. > SCA-resistance is a concern for me. > > > Regards, > Andreas Hallof > > -- > Andreas Hallof, Datenschutz und Datensicherheit / Kryptographie > > -----Urspr=C3=BCngliche Nachricht----- > Von: Cfrg [mailto:cfrg-bounces@irtf.org] Im Auftrag von Ilari Liusvaara > Gesendet: Freitag, 17. Oktober 2014 11:48 > An: Johannes Merkle > Cc: cfrg@irtf.org > Betreff: Re: [Cfrg] ECC reboot (Was: When's the decision?) > > On Fri, Oct 17, 2014 at 11:21:43AM +0200, Johannes Merkle wrote: >> >> Alyssa Rowan wrote on 16.10.2014 19:38: >> > I can see why they might want that, if VPR is the most convenient >> > for their implementations - but from what I see from the hesitant >> > adoption of Brainpool in the wider community, >> >> this assertion is only true for software implementations. Brainpool >> curves are used by more than 50 million smart cards rolled out and >> several vpn solutions (e.g., based on IPSec) widely used within German >> and EU public authorities. > > And what's wrong with just using Brainpool for implementations that need = random primes for extended side channel resistance? Not rigid enough? Not s= tandard enough? > > > For software implementations only needing defenses against software attac= k (including attacks from different process in the same host/VM) there is p= lenty wrong with using Brainpool. > > If attacker can get enough access to pull off EM attacks against most of = the endpoints, one has more severe problems than software vulernable to EM = attack. > > There is a good reason (singular!) why NIST/NSA curves are used far far m= ore in TLS than Brainpool, despite there being codepoints for both: > Performance. > > > -Ilari > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg --=20 "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Fri Oct 17 09:25:51 2014 Return-Path: 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 DF5E41A1BCE for ; Fri, 17 Oct 2014 09:25:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 EH1u86leX0jC for ; Fri, 17 Oct 2014 09:25:47 -0700 (PDT) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 309F41A1BA9 for ; Fri, 17 Oct 2014 09:25:47 -0700 (PDT) Received: by mail-wi0-f182.google.com with SMTP id n3so1702609wiv.15 for ; Fri, 17 Oct 2014 09:25:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:references :to:message-id:mime-version; bh=OF3Sviv+mRvddck8TPYfSKFhEySIDrhIhCrvn2z1dgA=; b=nXDaYhLqYPVuX/qbaTe1DTkuZd3/U/Wl8RLTDsP8rMAbVTqrrlVPAch1WGvmPrKW8o 1S1FHHBvAu7iHeCLF2UarHBQyaPVl47glduHpVyFQtVSFwfdzDAiRjbgEwHjeHiizi8l stC9IY0QXX9siIzdBTWfwYmYYZZyGidhWmIH/uUQtccQVgnjfT3dreZCli1ZUY//2VDI 4tlC8VFecUUpWQLXQpxQMKGIDNi4vw+VE+WiFrDcExGEL9HyBoduBTJU/K6u18rq6Y5w umpPaF7066hsSX1cM87Ue4gyTTlQjBTwI0LvjM6ASUW0NNxeidjBIozyUiCGbaF+rQXv C9pA== X-Received: by 10.194.122.71 with SMTP id lq7mr9253189wjb.66.1413563145817; Fri, 17 Oct 2014 09:25:45 -0700 (PDT) Received: from [192.168.1.104] (IGLD-84-228-54-205.inter.net.il. [84.228.54.205]) by mx.google.com with ESMTPSA id i5sm2243544wjz.0.2014.10.17.09.25.44 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 17 Oct 2014 09:25:45 -0700 (PDT) From: Yoav Nir Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Date: Fri, 17 Oct 2014 19:25:43 +0300 References: To: cfrg@irtf.org Message-Id: Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/lCVpml8epydtnjfhuf1Vb_EzYls Subject: [Cfrg] Fwd: Mail regarding draft-irtf-cfrg-chacha20-poly1305 X-BeenThere: cfrg@irtf.org 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, 17 Oct 2014 16:25:49 -0000 Message from David Black: > This nonce reuse warning in Section 4 somewhat on the light side: > > Consequences of repeating a nonce: If a nonce is repeated, then both > the one-time Poly1305 key and the key-stream are identical between > the messages. This reveals the XOR of the plaintexts, because the > XOR of the plaintexts is equal to the XOR of the ciphertexts. > > Here's some blunter text that could be used as a model - this was driven > into RFC 7146 by the secdir reviewer (it applies to all stream ciphers > and all modes that behave like stream ciphers): > > Of particular interest are the security considerations concerning the > use of AES GCM [RFC4106] and AES GMAC [RFC4543]; both modes are > vulnerable to catastrophic forgery attacks if a nonce is ever > repeated with a given key. > > Thanks, > --David > ---------------------------------------------------- > David L. Black, Distinguished Engineer > EMC Corporation, 176 South St., Hopkinton, MA 01748 > +1 (508) 293-7953 FAX: +1 (508) 293-7786 > david.black@emc.com Mobile: +1 (978) 394-7754 > ---------------------------------------------------- From nobody Fri Oct 17 09:34:48 2014 Return-Path: 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 E792E1A1F73 for ; Fri, 17 Oct 2014 09:34:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 4TH5r2d3ijL5 for ; Fri, 17 Oct 2014 09:34:38 -0700 (PDT) Received: from emh01.mail.saunalahti.fi (emh01.mail.saunalahti.fi [62.142.5.107]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB2671A1BF9 for ; Fri, 17 Oct 2014 09:34:37 -0700 (PDT) Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh01.mail.saunalahti.fi (Postfix) with ESMTP id 714FC9004B; Fri, 17 Oct 2014 19:34:35 +0300 (EEST) Date: Fri, 17 Oct 2014 19:34:35 +0300 From: Ilari Liusvaara To: Yoav Nir Message-ID: <20141017163435.GA23230@LK-Perkele-VII> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/wnvRFbSlzZv4kfA43d5CG5XPVuc Cc: cfrg@irtf.org Subject: Re: [Cfrg] Fwd: Mail regarding draft-irtf-cfrg-chacha20-poly1305 X-BeenThere: cfrg@irtf.org 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, 17 Oct 2014 16:34:45 -0000 On Fri, Oct 17, 2014 at 07:25:43PM +0300, Yoav Nir wrote: > Message from David Black: > > > This nonce reuse warning in Section 4 somewhat on the light side: > > > > Consequences of repeating a nonce: If a nonce is repeated, then both > > the one-time Poly1305 key and the key-stream are identical between > > the messages. This reveals the XOR of the plaintexts, because the > > XOR of the plaintexts is equal to the XOR of the ciphertexts. This is missing the fact that attacker can also generate forgeries for the (key,nonce) that was repeated. That can actually matter, if attacker can also blackhole messages or if recipient does not do nonce-based replay detection. > > Here's some blunter text that could be used as a model - this was driven > > into RFC 7146 by the secdir reviewer (it applies to all stream ciphers > > and all modes that behave like stream ciphers): > > > > Of particular interest are the security considerations concerning the > > use of AES GCM [RFC4106] and AES GMAC [RFC4543]; both modes are > > vulnerable to catastrophic forgery attacks if a nonce is ever > > repeated with a given key. Because AES-GCM equivalent to Poly1305 r depends only on key, any nonce repeat will compromise the authenticity for the whole key in catastrophic way. Whereas Chacha20-Poly1305 has r depend on both key and nonce, somewhat limiting the impact (but it is still bad). -Ilari From nobody Fri Oct 17 10:59:12 2014 Return-Path: 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 B549F1A0250 for ; Fri, 17 Oct 2014 10:59:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.556 X-Spam-Level: * X-Spam-Status: No, score=1.556 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, RDNS_DYNAMIC=0.982, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no 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 6Zn4ruvq3dIO for ; Fri, 17 Oct 2014 10:59:07 -0700 (PDT) Received: from aspartame.shiftleft.org (199-116-74-168-v301.PUBLIC.monkeybrains.net [199.116.74.168]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA4791A00BF for ; Fri, 17 Oct 2014 10:59:04 -0700 (PDT) Received: from [10.184.148.249] (unknown [209.36.6.242]) by aspartame.shiftleft.org (Postfix) with ESMTPSA id 2DE573AA49; Fri, 17 Oct 2014 10:57:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=shiftleft.org; s=sldo; t=1413568622; bh=24tiFTSPzSiXNJ5PDq1ZWVRZnb3VRbVb+oynUmc1R20=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=ReyyuwoJM0i4W2rWkF84S9LgGPadKty6MpuubqNcJk6Xq29k++InVMKHHRv/hbf1F e/rdRFASrk6eNjgeYeKWidMd+w8j83f8LeeYGHf7ZMv+ZvvFdZS4OvhZbNSTgWN1kR fS8qahq7gQKx9TOt6qVgfAiYTVll4H0DLs4DIyVM= Content-Type: multipart/alternative; boundary="Apple-Mail=_74CD0DDC-CD6C-4C27-AB29-CBF89A8F8A4F" Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Michael Hamburg In-Reply-To: Date: Fri, 17 Oct 2014 10:58:59 -0700 Message-Id: <842BF4E0-8132-42F6-BDE6-65717E004006@shiftleft.org> References: <543FF1A7.8030908@secunet.com> <544002AF.1020107@akr.io> <5440DFA7.80208@secunet.com> <20141017094755.GA29915@LK-Perkele-VII> <0FC829CD89DE224E98637A5D757BC1B81F02460A@GSBEEX01.int.gematik.de> To: Watson Ladd X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/UZT6Z0St0JWilxY9kapT9FmU9Aw Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] ECC reboot (Was: When's the decision?) X-BeenThere: cfrg@irtf.org 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, 17 Oct 2014 17:59:08 -0000 --Apple-Mail=_74CD0DDC-CD6C-4C27-AB29-CBF89A8F8A4F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Oct 17, 2014, at 9:23 AM, Watson Ladd = wrote: >=20 > On Fri, Oct 17, 2014 at 9:13 AM, Hallof, Andreas > > wrote: >>> And what's wrong with just using Brainpool for implementations that = need random primes for extended side channel resistance? >> Nothing is wrong about that. >>=20 >> The point that Mr. Merkle is addressing, is that there is a huge = world outside PC/Server-based TLS-Authentication. >> I have the impression the current discussion at the cfrg is too = narrowly focused on software implementations in unconstrained = environments with only global timing SCA. >>=20 >> In the infrastructure surrounding the german eHealth-Card the = majority of all TLS-Connection are based on smartcards on one = communication-endpoint (the other being a server / non-smartcards). >> The same is true for the smartmeter-infrastructure. >>=20 >> Like it is stated in http://eprint.iacr.org/2014/832 a result of the = current discussion at the cfrg could be that there are two sets of = curves. >> I have the impression the Brainpool-group would happily accept/(=3D> = switch to) the one set (with random primes), that has the necessary = cryptographic properties. >> Thus reducing the implementation-costs at smartcards, Web-browsers, = servers etc.. >=20 > What sort of decision do you think we are going to make? We obviously > cannot remove curves. So Brainpool will remain in TLS. The question is > about curves which make software implementations easier and faster. > Why does hardware matter for the choice we are going to make? I agree: what=E2=80=99s even the point of this tangent? Lochter et al=E2=80=99s paper asks for curves which have exactly the = same properties as the Brainpool curves. This is mostly motivated by = legacy constraints, with one secure hardware argument tossed in. It = also asks the CFRG not to do anything which would cause current = Brainpool users to flee that standard. It is eminently clear that Lochter et al are asking for the Brainpool = curves to be included in any new standard. Why would we just reroll the = constants when the entire motivation for the exercise is legacy = compatibility? It=E2=80=99s also clear that enough of this forum cares about software = performance that VPR cofactor-1 curves will not be the only curves = chosen. So is the thrust of this whole argument =E2=80=9Chave your special = curves, but make Brainpool mandatory to implement=E2=80=9D? If so, just = say so, and let the forum discuss it separately, and unblock the = discussion of new curves. Cheers, =E2=80=94 Mike --Apple-Mail=_74CD0DDC-CD6C-4C27-AB29-CBF89A8F8A4F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Oct 17, 2014, at 9:23 AM, = Watson Ladd <watsonbladd@gmail.com> wrote:

On Fri, Oct 17, 2014 at 9:13 AM, Hallof, = Andreas
<Andreas.Hallof@gematik.de> wrote:
And what's wrong with just using Brainpool for = implementations that need random primes for extended side channel = resistance?
Nothing is wrong about that.

The point that Mr. Merkle is addressing, is = that there is a huge world outside PC/Server-based = TLS-Authentication.
I have the impression the current = discussion at the cfrg is too narrowly focused on software = implementations in unconstrained environments with only global timing = SCA.

In the infrastructure surrounding the = german eHealth-Card the majority of all TLS-Connection are based on = smartcards on one communication-endpoint (the other being a server / = non-smartcards).
The same is true for the = smartmeter-infrastructure.

Like it is = stated in http://eprint.iacr.org/2014/832 a result of the current = discussion at the cfrg could be that there are two sets of curves.
I have the impression the Brainpool-group would happily = accept/(=3D> switch to) the one set (with random primes), that has = the necessary cryptographic properties.
Thus reducing the = implementation-costs at smartcards, Web-browsers, servers etc..

What sort of decision do = you think we are going to make? We obviously
cannot remove curves. So Brainpool will remain = in TLS. The question is
about curves which make = software implementations easier and faster.
Why does hardware matter for the choice we are = going to make?

I agree: what=E2=80=99s even the point of this = tangent?

Lochter= et al=E2=80=99s paper asks for curves which have exactly the same = properties as the Brainpool curves.  This is mostly motivated by = legacy constraints, with one secure hardware argument tossed in. =  It also asks the CFRG not to do anything which would cause current = Brainpool users to flee that standard.

It is eminently clear that Lochter et = al are asking for the Brainpool curves to be included in any new = standard.  Why would we just reroll the constants when the entire = motivation for the exercise is legacy compatibility?

It=E2=80=99s also clear = that enough of this forum cares about software performance that VPR = cofactor-1 curves will not be the only curves chosen.

So is the thrust of this = whole argument =E2=80=9Chave your special curves, but make Brainpool = mandatory to implement=E2=80=9D?  If so, just say so, and let the = forum discuss it separately, and unblock the discussion of new = curves.

Cheers,
=E2=80=94 Mike

= --Apple-Mail=_74CD0DDC-CD6C-4C27-AB29-CBF89A8F8A4F-- From nobody Fri Oct 17 12:19:34 2014 Return-Path: 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 C9D061A6F5A for ; Fri, 17 Oct 2014 12:19:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 oFlNUoPTaXDz for ; Fri, 17 Oct 2014 12:19:29 -0700 (PDT) Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D6CF1A6F58 for ; Fri, 17 Oct 2014 12:19:29 -0700 (PDT) Received: by mail-lb0-f176.google.com with SMTP id p9so1217849lbv.35 for ; Fri, 17 Oct 2014 12:19:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=hJhSsWBzXG0/y1p0aGsBllKn/SmSt+4+HwGPbQhssbM=; b=AjMlflu//kat3uRzPzICpuPnCRKkH4vLK1KkTYoBW8mmFRuNVdNvKAV+ormT/Mkhcd v+KLQMo2pS7x2sORV9o+Z02x98LqY1Merf0VdpwHoP6K7+mqRHyQGhkm2PPYC1UU2QrB 2dYiNMGWT2SGlid6KiS2xow/lgPYDPASkTF0Yw63m4RDg+brP0KJxTFFH2I+fXzaGxww 5NtebQfzX+QEMvoI3N2Rf7tE0JCLLv0TMFOrN3Udf33XoA0jvApu2yENf2EcYBF/JieH p4uNdd7wtUKo5x8h1D5ixv3kbhJ9bG8Jv2DsrUFbMHgY7pXPKVK42lAWh+mBGfSW+l+S HjzA== X-Received: by 10.112.147.199 with SMTP id tm7mr5306832lbb.92.1413573567303; Fri, 17 Oct 2014 12:19:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.218.145 with HTTP; Fri, 17 Oct 2014 12:19:06 -0700 (PDT) In-Reply-To: <0FC829CD89DE224E98637A5D757BC1B81F0245DD@GSBEEX01.int.gematik.de> References: <0FC829CD89DE224E98637A5D757BC1B81F0245DD@GSBEEX01.int.gematik.de> From: David Leon Gil Date: Fri, 17 Oct 2014 15:19:06 -0400 Message-ID: To: "Hallof, Andreas" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/j2kqp4vx17Q04Zn9BnFCOW3VzFk Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] ECC reboot (Was: When's the decision?) X-BeenThere: cfrg@irtf.org 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, 17 Oct 2014 19:19:31 -0000 On Fri, Oct 17, 2014 at 11:24 AM, Hallof, Andreas wrote: > If independent from each other three different Chipcard-Manufacturer tell me they prefer using curves with random primes then this tells me something. It tells you that, like most semiconductor companies, they are cheapskates. They would rather you continue to use their (existing) inadequately protected solutions, so that they can save on design costs. If they can cite published work that shows that a higher level of assurance can be achieved, given a correctly implemented masking scheme, by using a random prime, they are free to share one. (The previous citation from the manufacturers, AFAIK, shows an attack on the sort of blinding scheme Joye and others have demonstrated is inadequate -- and which does not even pass a basic smell test.) From nobody Fri Oct 17 13:22:54 2014 Return-Path: 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 398411A1AF1 for ; Fri, 17 Oct 2014 13:22:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no 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 i_8XSVYXOFvd for ; Fri, 17 Oct 2014 13:22:50 -0700 (PDT) Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C26D1A1B09 for ; Fri, 17 Oct 2014 13:22:49 -0700 (PDT) Received: by mail-la0-f43.google.com with SMTP id mc6so1331245lab.16 for ; Fri, 17 Oct 2014 13:22:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=fSiKXyb+AubIuSd+X64EBAptUx3pdXq93E0NCmY/CpU=; b=Cm05vrr7ZyiGjdgfCDkXIbQS7YUEg1vsvRy7LPuRw0PKRHpQRn3g3N733KhoBUNp3B c6zxuA0GzjBbMwoTIu+O30OK4T/Qc7icoE+SNoR9M2IWtN4vnRBl0e/kjNfWYLr7oxhR iS4viMmV5WCfXJWJ/NGzeRhaohwQ897fmpmNKvIfvNBsjBFxQ6JKh1P/eJhgOCPyLD/Z BYnlDu+4aB5H7POobGQAxnCs9Aqag/thQYSrTGYu0ng2fuz3AZ1qhKZWGP2UX1Djk4Cf +b7lXxk5zh0j79UlZRZcrvdW8fRIKB1T6MUKqpGhvNHWabGF0Bfx0vOfwWsZ+W93LipE npJA== MIME-Version: 1.0 X-Received: by 10.152.1.42 with SMTP id 10mr11488108laj.4.1413577368216; Fri, 17 Oct 2014 13:22:48 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.66.196 with HTTP; Fri, 17 Oct 2014 13:22:47 -0700 (PDT) In-Reply-To: <54400E9F.5020905@akr.io> References: <54400E9F.5020905@akr.io> Date: Fri, 17 Oct 2014 16:22:47 -0400 X-Google-Sender-Auth: NaI_WzSEMrlAwJGdt8typ5znmYA Message-ID: From: Phillip Hallam-Baker To: Alyssa Rowan Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/nN_PuHVzs1d8ZfXuswMsiLzscxo Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] ECC reboot (Was: When's the decision?) X-BeenThere: cfrg@irtf.org 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, 17 Oct 2014 20:22:52 -0000 On Thu, Oct 16, 2014 at 2:29 PM, Alyssa Rowan wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > On 16/10/2014 17:08, Paterson, Kenny wrote: > >> Our first task should be to finalise the requirements that we will >> use to guide the selection process. I think we are close, with a >> couple of outstanding issues: > > Alright, so let's try to get things in high gear and argue those out=E2= =80=A6? > >> 1. Amount of "wiggle room" that should be permitted. > > Broadly: I think what we're aiming for is probably one faster/strong > curve, and one stronger/fast curve. > > Given the strong preferences of some to minimise the number of curves, > it looks to me like =C2=AD=E2=89=88384 is almost-definitely dropped, leav= ing us > with something near =E2=89=88256 and something near =E2=89=88512. > > We seem to be in agreement that wiggle room on =E2=89=88256 would include > fields of 2^255-19 as well as 2^256-189 in scope. > > For the paranoid-strong, performance-second =E2=89=88512, 2^512-569 very > obviously falls within scope. Agree so far. > I put forth that 2^521-1 also falls within scope. It's not very far > away, and it's a true Mersenne prime rather than a pseudo-Mersenne, > and they do not grow on trees - no others fall near our criteria (the > next lowest is 2^127-1 which is way too small, and the next biggest is > 2^607-1). They are very attractive - attractive enough for 4 (?) > independent research groups to independently arrive on E-521, and > SECG/NIST to have independently picked the same prime years ago for > secp521r1. It is a Mersenne but the performance advantage is compromised by it being larger than 512 bits. That means every memory operation is going to break stride. Which is a really bad tradeoff for the marginal improvement in speed. > [Previous discussion countering this point: Sean Parkinson @ RSA > suggested stepping over a power of 2 is "only going to hurt > performance in the future". Phillip Hallam-Baker also thought anything > that is not less than a clean multiple of a power of two "may cause > severe performance hits on future architectures", mentioning 512-bit > memory buses on graphics cards?! There is a good reason for that. What we call 'graphics cards' are really just what we used to call a vector unit. Getting someone to build purpose built ECC accelerators is hard and expensive. I can buy an nvida card that with a ridiculous number of cores that I can pretty much program to do anything I like. Its not just a question of speed, its a question of the amount of microcode required to implement ECC math as a native function of the GPU. > although I'm not convinced that's > actually primarily relevant to an implementation of a high-strength > curve. We will, of course, evaluate performance of contenders in Phase > II, future architectures can be more-or-less anything that works well, > and performance implications usually aren't anything like so obvious=E2= =80=A6 > Aren't Mersennes actually particularly _good_ performance-wise?] That depends on whether you are looking for a reason to include or exclude. At the ~512 level, what I am looking for is a curve that absolutely nobody is going to be able to suggest is suspect as being bongoed. 2^512 is a round number that needs no explanation. 2^521 isn't. The Web PKI will almost certainly be based exclusively on the ~512 level curve. The roots certainly will. So the performance advantage of issuing end entity ~256 certs would be very small. Where I think ~256 keys will be used is for ephemeral mix ins. So I exchange a master session key M with the ~512 bit key, use an ephemeral ~256 to create a second session key E and then derive my encryption and authentication keys using a one way function on M and E. That preserves the ~512 work factor for confidentiality and adds a ~256 work factor for forward secrecy. So I am willing to be more flexible on ~256 than ~512 because for my applications the attacker always has to break the ~512. > I put forth that 2^414-17 and 2^448-2^224-1 might fall outside "wiggle > room" there, although I do so very reluctantly as I think it's a shame > to exclude them on that basis if they have otherwise nice properties, > and they do seem to have very good performance for their strength. I agree. They are a little faster but we have to give up a lot of security to get that speed. Its not 64 bits, its a 2^20 reduction in work factor. I want them bits. >> 31/10/14 (2 weeks from now): we agree on whatever benchmarking >> system we're going to use for performance measurements. (Right now, >> supercop seems like the front runner to me.) I think a significant performance difference is a tie breaker but not the best determinant. What I see as being convincing are: 1) Difficulty of screwing up the implementation (see Watson Ladd's post). 2) Legacy deployment. Given the way that I think we are likely to use ~256 and given the fact that DJB has established a large user base for the curve already. I am willing to suggest we just let him win on that one unless there is at least a 10%, maybe a 20% speed advantage he missed. For ~512 I want the Platinum level security, whatever it takes. From nobody Fri Oct 17 14:07:31 2014 Return-Path: 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 D5C9C1A6FED for ; Fri, 17 Oct 2014 14:07:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-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 SVZgJNhZ5IFt for ; Fri, 17 Oct 2014 14:07:18 -0700 (PDT) Received: from entima.net (entima.net [78.129.143.175]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B9D31A6FEB for ; Fri, 17 Oct 2014 14:07:18 -0700 (PDT) Message-ID: <54418508.8070006@akr.io> Date: Fri, 17 Oct 2014 22:07:20 +0100 From: Alyssa Rowan MIME-Version: 1.0 To: "cfrg@irtf.org" References: <0FC829CD89DE224E98637A5D757BC1B81F0245DD@GSBEEX01.int.gematik.de> In-Reply-To: <0FC829CD89DE224E98637A5D757BC1B81F0245DD@GSBEEX01.int.gematik.de> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/gKui6Ky0g5abhOYTJ1w32uaUbqg Subject: Re: [Cfrg] Hardware requirements, Brainpool (was: ECC reboot) X-BeenThere: cfrg@irtf.org 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, 17 Oct 2014 21:07:22 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 17/10/2014 16:24, Hallof, Andreas wrote: > (RSA-based keys + dedicated TLS-Certificate). Irrelevant. You're citing deployment (of RSA?) in (another) very limited field of specific governmental stakeholders. Brainpool is quite rarely deployed in IETF protocols worldwide, despite it being standardised for some time now and being available in some libraries: a fact that anyone with zmap and Python can easily verify. Consider: If Brainpool-style curves addressed the TLS WG's needs, they wouldn't be asking us for new curves, they'd be using the Brainpool curves they've already got, wouldn't they? The _very_ poor software performance of random primes is the reason why. No mystery there. > In medium term we want to migrate to an ECC-based scheme. And you're free to choose any you want to. Brainpool isn't magically going away for those that want it, you know. I am not expecting the NIST curves will vanish overnight either! > If independent from each other three different > Chipcard-Manufacturer tell me they prefer using curves with random > primes then this tells me something. It tells me something, too - those three are being cheap as hell. They are reusing an old rusty RSA multiplier whose blinding falls short over sparse prime fields, and they're not really willing to redesign or recertify their decade-plus-old designs to improve that, even in the face of improved attacks and 'high assurance' hardware they're shipping tens of millions of units of. There are more than 3 smartcard vendors, and some others have supported the NIST curves (which are special primes) just fine. So no, I don't find that argument compelling, or highly assuring. - -- /akr -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJUQYUIAAoJEOyEjtkWi2t6qroP/inaHS009QQMCuv577C617mQ /KqT6hGJ7y2klk6SjinYVUHNks4wTw7X0BAUkUy7TSp2u8PSb9vA0t5B5BXfUsm7 m/sh1H+Q4TniO/JSDvH27GeCC0nU0+clD/thmGAvoSZJw2VFKN2kLwrafTowGXc6 8OdbGJoO4v6vvladTHsByzV2N56d9E4rIhYxkzRe4GwnrE5aMZZEIBKp1I72bmgY Xla5/Ze2SnK8uH5t+t35lj8F6BcARHRwOQrmrxjZ1LmwNRyy+Aj/eQddl9ION/Qj 150lTXmeiSTnnjP/SK5gKCZXu2EBR8k2wrU6BreNv02oc6iIyPWKTjptqvXj1WxA eg0WZlfJ9nvCtrtuQH5OAR4MhxIauRiHU5HGtJWEj3ZKk3ARf1QAIdJyBRGl0tgi gsQ74iNYui+o7FRY5R1KbP74FFD3BaVNbAAUHgho00s50whubpYx8qjoip+banTz b2Mrv9SHfmAx1Vd9Por2CZYY7+nZmjzZYLT3c7TUENkdQzA4cbfc7DqBj5kNuZQD DYZlc3Q+/N5sDe6egNmcZuOaN83x32aOiIjF6VigJYgoOq3iw3NuapryuU1WJa5l gOM6LwsJBbv81Rz1/HEHZaSPLnwk2RAU2O8K/L21ubUuLPS+rofsIq0Xbmnjr1xT JaAkRYi72P6b9FhWkzdU =yTnT -----END PGP SIGNATURE----- From nobody Fri Oct 17 14:27:53 2014 Return-Path: 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 B17811A701C for ; Fri, 17 Oct 2014 14:27:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.454 X-Spam-Level: *** X-Spam-Status: No, score=3.454 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.982, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no 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 u0Bu4fTdyMOQ for ; Fri, 17 Oct 2014 14:27:50 -0700 (PDT) Received: from aspartame.shiftleft.org (199-116-74-168-v301.PUBLIC.monkeybrains.net [199.116.74.168]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04AFE1A6FE1 for ; Fri, 17 Oct 2014 14:27:49 -0700 (PDT) Received: from [10.184.148.249] (unknown [209.36.6.242]) by aspartame.shiftleft.org (Postfix) with ESMTPSA id 74062F5EAE; Fri, 17 Oct 2014 14:25:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=shiftleft.org; s=sldo; t=1413581148; bh=dTGLn+byutOWugYZkYOoJYFFSLQVx+ZfX6PCcubqJ7A=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=HwFBorxv/h/Y+Fp30yZ60bfmCr7A6n9zc1LTOxZfCOTgqfvZ1ORxTK9yYY94wXCr0 4qFKj0lT+qjM4mAmi8ANpzVlUzBbOALAjgJYTFFtfnFXoTt9bV+T+ef8mER14hq1tx vYEQP5Jg84d7mPL0ObzZv3WUud5IKCO3s6flzJp4= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Michael Hamburg In-Reply-To: Date: Fri, 17 Oct 2014 14:27:46 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <5218FD35-E00A-413F-ACCB-AA9B99DEF48B@shiftleft.org> References: <54400E9F.5020905@akr.io> To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/Pg8KgWgcZhK8jFggdNSnfH2pl3I Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] ECC reboot (Was: When's the decision?) X-BeenThere: cfrg@irtf.org 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, 17 Oct 2014 21:27:51 -0000 > On Oct 17, 2014, at 1:22 PM, Phillip Hallam-Baker = wrote: >=20 > On Thu, Oct 16, 2014 at 2:29 PM, Alyssa Rowan wrote: >=20 >> I put forth that 2^521-1 also falls within scope. It's not very far >> away, and it's a true Mersenne prime rather than a pseudo-Mersenne, >> and they do not grow on trees - no others fall near our criteria (the >> next lowest is 2^127-1 which is way too small, and the next biggest = is >> 2^607-1). They are very attractive - attractive enough for 4 (?) >> independent research groups to independently arrive on E-521, and >> SECG/NIST to have independently picked the same prime years ago for >> secp521r1. >=20 > It is a Mersenne but the performance advantage is compromised by it > being larger than 512 bits. That means every memory operation is going > to break stride. Which is a really bad tradeoff for the marginal > improvement in speed. Why is this a bad tradeoff? Will it lead to a more-than-marginal drop = in speed, or is breaking stride bad for some other reason? The best-performing implementations so far =E2=80=94 at least the ones = that use more than 4 machine words per element, and some that don't =E2=80= =94 have been those which store an n-bit number in more than n bits. = For example, Curve25519-Donna uses 320 bits to store a 255-bit number, = and Curve41417 or Goldilocks or Ridinghood use 512 bits to store a 414- = or 448- or 480-bit number. This is why their primes are strictly less = than 512 bits: so that they can fit in 512 bits with delayed carry = propagation. While doing a multiplication, of course, a vectorized 512-bit prime = implementation would store at least 1024 bits and probably more. But = reducing back to 512 bits (and not, say, 576 bits) would come at a = significant cost. >> [Previous discussion countering this point: Sean Parkinson @ RSA >> suggested stepping over a power of 2 is "only going to hurt >> performance in the future". Phillip Hallam-Baker also thought = anything >> that is not less than a clean multiple of a power of two "may cause >> severe performance hits on future architectures", mentioning 512-bit >> memory buses on graphics cards?! >=20 > There is a good reason for that. What we call 'graphics cards' are > really just what we used to call a vector unit. >=20 > Getting someone to build purpose built ECC accelerators is hard and > expensive. I can buy an nvida card that with a ridiculous number of > cores that I can pretty much program to do anything I like. >=20 >=20 > Its not just a question of speed, its a question of the amount of > microcode required to implement ECC math as a native function of the > GPU. Discrete graphics probably won=E2=80=99t be be a common crypto platform, = though I agree that AVX-512F will be in a few years. >> although I'm not convinced that's >> actually primarily relevant to an implementation of a high-strength >> curve. We will, of course, evaluate performance of contenders in = Phase >> II, future architectures can be more-or-less anything that works = well, >> and performance implications usually aren't anything like so = obvious=E2=80=A6 >> Aren't Mersennes actually particularly _good_ performance-wise?] >=20 > That depends on whether you are looking for a reason to include or = exclude. >=20 > At the ~512 level, what I am looking for is a curve that absolutely > nobody is going to be able to suggest is suspect as being bongoed. > 2^512 is a round number that needs no explanation. 2^521 isn=E2=80=99t. I=E2=80=99m not sure what you mean by =E2=80=9Cbongoed=E2=80=9D. I do = not believe that 2^521-1 has been struck rhythmically by hands, or has = been played as a melody on bongos. It is possible, if unlikely, that some mathematical property of Mersenne = primes would make elliptic curves mod them weaker than mod other primes. = But at least 4 groups thought 2^521-1 was an obvious choice, and at = least 3 of them came up with the same curve. That=E2=80=99s about as = unsuspicious as you=E2=80=99re going to get without some VPR performance = art. > The Web PKI will almost certainly be based exclusively on the ~512 > level curve. The roots certainly will. So the performance advantage of > issuing end entity ~256 certs would be very small. Just the way they use ~15kbit RSA keys now, eschewing ~3072-bit keys as = too weak, right? I looked at Mozilla=E2=80=99s included CAs. There are four ECC certs = there, all of them on the NIST secp384r1 curve. So they apparently do = not consider ~512 bits necessary, but if the only choices are 256 and = 512 I suppose they will go with 512. The RSA-based roots are mostly 2048 bits long, equivalent to about a = 224-bit ECC. If the CAs consider this an acceptable level of security = for hosts, I suspect that webmasters will be OK with ~256-bit curves. = That=E2=80=99s what Cloudflare uses for their universal SSL, for = example. > Where I think ~256 keys will be used is for ephemeral mix ins. So I > exchange a master session key M with the ~512 bit key, use an > ephemeral ~256 to create a second session key E and then derive my > encryption and authentication keys using a one way function on M and > E. That preserves the ~512 work factor for confidentiality and adds a > ~256 work factor for forward secrecy. >=20 >=20 > So I am willing to be more flexible on ~256 than ~512 because for my > applications the attacker always has to break the ~512. Maybe for your applications, but that=E2=80=99s not how TLS=E2=80=99s = ECDHE works. >> I put forth that 2^414-17 and 2^448-2^224-1 might fall outside = "wiggle >> room" there, although I do so very reluctantly as I think it's a = shame >> to exclude them on that basis if they have otherwise nice properties, >> and they do seem to have very good performance for their strength. >=20 > I agree. They are a little faster but we have to give up a lot of > security to get that speed. Its not 64 bits, its a 2^20 reduction in > work factor. I want them bits. I basically get this sentiment. But just so we can be clear: why do you = want them bits? Is it just an insatiable craving, or does a round 512 = sound better in product advertisements, or is there a foreseeable attack = that the extra bits will protect you from? If most CAs today are OK with security equivalent to 224-bit curves, but = they're hedging to 384 bits, why are you convinced that 384 or 414 or = 448 or 480 bits would not be enough? And if they aren=E2=80=99t enough, = why not go to 607 or 640 or 1024 bits? >>> 31/10/14 (2 weeks from now): we agree on whatever benchmarking >>> system we're going to use for performance measurements. (Right now, >>> supercop seems like the front runner to me.) >=20 > I think a significant performance difference is a tie breaker but not > the best determinant. What I see as being convincing are: >=20 > 1) Difficulty of screwing up the implementation (see Watson Ladd's = post). >=20 > 2) Legacy deployment. The only new bigger-than-256-bit curve which would ease legacy = transition is E-521. > Given the way that I think we are likely to use ~256 and given the > fact that DJB has established a large user base for the curve already. > I am willing to suggest we just let him win on that one unless there > is at least a 10%, maybe a 20% speed advantage he missed. >=20 > For ~512 I want the Platinum level security, whatever it takes. Platinum is heavy and very, very expensive. It resists corrosion = phenomenally well, but not cutting. Quite the metaphor. =E2=80=94 Mike From nobody Fri Oct 17 14:30:59 2014 Return-Path: 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 9B8411A7033 for ; Fri, 17 Oct 2014 14:30:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 lO5DOhbCYXLf for ; Fri, 17 Oct 2014 14:30:57 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id A5D7B1A702D for ; Fri, 17 Oct 2014 14:30:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 14775BE97; Fri, 17 Oct 2014 22:30:57 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NPAf-SVVCdea; Fri, 17 Oct 2014 22:30:56 +0100 (IST) Received: from [10.87.48.12] (unknown [86.42.18.172]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id EC7E5BE8A; Fri, 17 Oct 2014 22:30:55 +0100 (IST) Message-ID: <54418A8F.3090506@cs.tcd.ie> Date: Fri, 17 Oct 2014 22:30:55 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Michael Hamburg References: <543FF1A7.8030908@secunet.com> <544002AF.1020107@akr.io> <5440DFA7.80208@secunet.com> <20141017094755.GA29915@LK-Perkele-VII> <0FC829CD89DE224E98637A5D757BC1B81F02460A@GSBEEX01.int.gematik.de> <842BF4E0-8132-42F6-BDE6-65717E004006@shiftleft.org> In-Reply-To: <842BF4E0-8132-42F6-BDE6-65717E004006@shiftleft.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/XmXnGx7Ae4zmF2Whxphj1IhsytU Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] ECC reboot (Was: When's the decision?) X-BeenThere: cfrg@irtf.org 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, 17 Oct 2014 21:30:58 -0000 On 17/10/14 18:58, Michael Hamburg wrote: > So is the thrust of this whole argument “have your special curves, > but make Brainpool mandatory to implement”? If so, just say so, and > let the forum discuss it separately, and unblock the discussion of > new curves. If that were the case then CFRG would be the wrong forum. Which algs are MTI for which IETF protocols is an IETF issue. S. From nobody Fri Oct 17 14:45:31 2014 Return-Path: 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 4E2761A86EA for ; Fri, 17 Oct 2014 14:45:30 -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 FHwVO08SCf6X for ; Fri, 17 Oct 2014 14:45:26 -0700 (PDT) Received: from mail-yh0-x232.google.com (mail-yh0-x232.google.com [IPv6:2607:f8b0:4002:c01::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61E241A86DE for ; Fri, 17 Oct 2014 14:45:26 -0700 (PDT) Received: by mail-yh0-f50.google.com with SMTP id a41so758941yho.9 for ; Fri, 17 Oct 2014 14:45:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=pWs5PNxajsqStMFdft+ih6kJLwg6Sc9bG2KShv174+M=; b=HUCqdTaX9Yz+sIgtr4/b59sS+aKs+aso99ewYwJ9HYQI52t8y/i/x8VEbrRgWVyO/5 K5AaFz+IwpJApe1E/s9UecwwMe2zzlkkpBQMT1ByBCRbDYsLuco+wwpg1zPfsw594top Cnc96kNtvASy9iUA6SPfdDoGCOq3kUYJZwpzhWDeXT8TcTc/JPN2MSJ9CHEhY3T+TG7T VU1uy/3Z8/J5quyLfqRAOD698BafSdCFGzns5LQDJomrev6qtMCoz1l8QBESLdN45iUU eiM0ivcRETHsV9ZpebCk9fnOoiXOMYmNH+v7KAqrhGbauMfoGKXQeQYOeb07ehlAP5PL pExQ== MIME-Version: 1.0 X-Received: by 10.236.51.233 with SMTP id b69mr7871876yhc.147.1413582325526; Fri, 17 Oct 2014 14:45:25 -0700 (PDT) Received: by 10.170.195.149 with HTTP; Fri, 17 Oct 2014 14:45:25 -0700 (PDT) Received: by 10.170.195.149 with HTTP; Fri, 17 Oct 2014 14:45:25 -0700 (PDT) In-Reply-To: References: <54400E9F.5020905@akr.io> Date: Fri, 17 Oct 2014 14:45:25 -0700 Message-ID: From: Watson Ladd To: Phillip Hallam-Baker Content-Type: multipart/alternative; boundary=089e013a14085fb62d0505a54895 Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/VFs3BXXoYceg4ZtMt7xRmazYbOM Cc: cfrg@irtf.org Subject: Re: [Cfrg] ECC reboot (Was: When's the decision?) X-BeenThere: cfrg@irtf.org 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, 17 Oct 2014 21:45:30 -0000 --089e013a14085fb62d0505a54895 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Oct 17, 2014 1:22 PM, "Phillip Hallam-Baker" wrote: > > On Thu, Oct 16, 2014 at 2:29 PM, Alyssa Rowan wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA512 > > > > On 16/10/2014 17:08, Paterson, Kenny wrote: > > > >> Our first task should be to finalise the requirements that we will > >> use to guide the selection process. I think we are close, with a > >> couple of outstanding issues: > > > > Alright, so let's try to get things in high gear and argue those out=E2= =80=A6? > > > >> 1. Amount of "wiggle room" that should be permitted. > > > > Broadly: I think what we're aiming for is probably one faster/strong > > curve, and one stronger/fast curve. > > > > Given the strong preferences of some to minimise the number of curves, > > it looks to me like =C2=AD=E2=89=88384 is almost-definitely dropped, le= aving us > > with something near =E2=89=88256 and something near =E2=89=88512. > > > > We seem to be in agreement that wiggle room on =E2=89=88256 would inclu= de > > fields of 2^255-19 as well as 2^256-189 in scope. > > > > For the paranoid-strong, performance-second =E2=89=88512, 2^512-569 ver= y > > obviously falls within scope. > > Agree so far. > > > > I put forth that 2^521-1 also falls within scope. It's not very far > > away, and it's a true Mersenne prime rather than a pseudo-Mersenne, > > and they do not grow on trees - no others fall near our criteria (the > > next lowest is 2^127-1 which is way too small, and the next biggest is > > 2^607-1). They are very attractive - attractive enough for 4 (?) > > independent research groups to independently arrive on E-521, and > > SECG/NIST to have independently picked the same prime years ago for > > secp521r1. > > It is a Mersenne but the performance advantage is compromised by it > being larger than 512 bits. That means every memory operation is going > to break stride. Which is a really bad tradeoff for the marginal > improvement in speed. Shouldn't this show up in benchmarks? Or is this a performance issue that doesn't actually do anything with performance? > > > > [Previous discussion countering this point: Sean Parkinson @ RSA > > suggested stepping over a power of 2 is "only going to hurt > > performance in the future". Phillip Hallam-Baker also thought anything > > that is not less than a clean multiple of a power of two "may cause > > severe performance hits on future architectures", mentioning 512-bit > > memory buses on graphics cards?! > > There is a good reason for that. What we call 'graphics cards' are > really just what we used to call a vector unit. > > Getting someone to build purpose built ECC accelerators is hard and > expensive. I can buy an nvida card that with a ridiculous number of > cores that I can pretty much program to do anything I like. > Actually, there are major issues with offloading to graphics cards in latency. My guess is that CPU performance is fast enough that graphics cards don't win out. > > Its not just a question of speed, its a question of the amount of > microcode required to implement ECC math as a native function of the > GPU. Right: an extra load is so hard. > > > > although I'm not convinced that's > > actually primarily relevant to an implementation of a high-strength > > curve. We will, of course, evaluate performance of contenders in Phase > > II, future architectures can be more-or-less anything that works well, > > and performance implications usually aren't anything like so obvious=E2= =80=A6 > > Aren't Mersennes actually particularly _good_ performance-wise?] > > That depends on whether you are looking for a reason to include or exclude. > > At the ~512 level, what I am looking for is a curve that absolutely > nobody is going to be able to suggest is suspect as being bongoed. > 2^512 is a round number that needs no explanation. 2^521 isn't. > > The Web PKI will almost certainly be based exclusively on the ~512 > level curve. The roots certainly will. So the performance advantage of > issuing end entity ~256 certs would be very small. > > Where I think ~256 keys will be used is for ephemeral mix ins. So I > exchange a master session key M with the ~512 bit key, use an > ephemeral ~256 to create a second session key E and then derive my > encryption and authentication keys using a one way function on M and > E. That preserves the ~512 work factor for confidentiality and adds a > ~256 work factor for forward secrecy. > > > So I am willing to be more flexible on ~256 than ~512 because for my > applications the attacker always has to break the ~512. > > > > I put forth that 2^414-17 and 2^448-2^224-1 might fall outside "wiggle > > room" there, although I do so very reluctantly as I think it's a shame > > to exclude them on that basis if they have otherwise nice properties, > > and they do seem to have very good performance for their strength. > > I agree. They are a little faster but we have to give up a lot of > security to get that speed. Its not 64 bits, its a 2^20 reduction in > work factor. I want them bits. > As Mike Hamburg points out downthread, TLS doesn't work that way. Furthermore, P384 is in use now. I wish someone would toss it into eBATS, but I think both Curve 41417 and Goldilocks are faster by something, can't recall what. > > >> 31/10/14 (2 weeks from now): we agree on whatever benchmarking > >> system we're going to use for performance measurements. (Right now, > >> supercop seems like the front runner to me.) > > I think a significant performance difference is a tie breaker but not > the best determinant. What I see as being convincing are: > > 1) Difficulty of screwing up the implementation (see Watson Ladd's post). Which has little to nothing to do with curves. See DJB's curves coordinates and computations email. > > 2) Legacy deployment. See above. > > > Given the way that I think we are likely to use ~256 and given the > fact that DJB has established a large user base for the curve already. > I am willing to suggest we just let him win on that one unless there > is at least a 10%, maybe a 20% speed advantage he missed. > > For ~512 I want the Platinum level security, whatever it takes. > > _______________________________________________ > Cfrg mailing list >Cfrg@irtf.org >http://www.irtf.org/mailman/listinfo/ cfrg --089e013a14085fb62d0505a54895 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Oct 17, 2014 1:22 PM, "Phillip Hallam-Baker" <phill@hallambaker.com> wrote:
>
> On Thu, Oct 16, 2014 at 2:29 PM, Alyssa Rowan <akr@akr.io> wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA512
> >
> > On 16/10/2014 17:08, Paterson, Kenny wrote:
> >
> >> Our first task should be to finalise the requirements that we= will
> >> use to guide the selection process. I think we are close, wit= h a
> >> couple of outstanding issues:
> >
> > Alright, so let's try to get things in high gear and argue th= ose out=E2=80=A6?
> >
> >> 1. Amount of "wiggle room" that should be permitted= .
> >
> > Broadly: I think what we're aiming for is probably one faster= /strong
> > curve, and one stronger/fast curve.
> >
> > Given the strong preferences of some to minimise the number of cu= rves,
> > it looks to me like =C2=AD=E2=89=88384 is almost-definitely dropp= ed, leaving us
> > with something near =E2=89=88256 and something near =E2=89=88512.=
> >
> > We seem to be in agreement that wiggle room on =E2=89=88256 would= include
> > fields of 2^255-19 as well as 2^256-189 in scope.
> >
> > For the paranoid-strong, performance-second =E2=89=88512, 2^512-5= 69 very
> > obviously falls within scope.
>
> Agree so far.
>
>
> > I put forth that 2^521-1 also falls within scope. It's not ve= ry far
> > away, and it's a true Mersenne prime rather than a pseudo-Mer= senne,
> > and they do not grow on trees - no others fall near our criteria = (the
> > next lowest is 2^127-1 which is way too small, and the next bigge= st is
> > 2^607-1). They are very attractive - attractive enough for 4 (?)<= br> > > independent research groups to independently arrive on E-521, and=
> > SECG/NIST to have independently picked the same prime years ago f= or
> > secp521r1.
>
> It is a Mersenne but the performance advantage is compromised by it > being larger than 512 bits. That means every memory operation is going=
> to break stride. Which is a really bad tradeoff for the marginal
> improvement in speed.

Shouldn't this show up in benchmarks? Or is this a perfo= rmance issue that doesn't actually do anything with performance?

>
>
> > [Previous discussion countering this point: Sean Parkinson @ RSA<= br> > > suggested stepping over a power of 2 is "only going to hurt<= br> > > performance in the future". Phillip Hallam-Baker also though= t anything
> > that is not less than a clean multiple of a power of two "ma= y cause
> > severe performance hits on future architectures", mentioning= 512-bit
> > memory buses on graphics cards?!
>
> There is a good reason for that. What we call 'graphics cards'= are
> really just what we used to call a vector unit.
>
> Getting someone to build purpose built ECC accelerators is hard and > expensive. I can buy an nvida card that with a ridiculous number of > cores that I can pretty much program to do anything I like.
>

Actually,=C2=A0 there are major issues with offloading to gr= aphics cards in latency. My guess is that CPU performance is fast enough th= at graphics cards don't win out.

>
> Its not just a question of speed, its a question of the amount of
> microcode required to implement ECC math as a native function of the > GPU.

Right: an extra load is so hard.
>
>
> > although I'm not convinced that's
> > actually primarily relevant to an implementation of a high-streng= th
> > curve. We will, of course, evaluate performance of contenders in = Phase
> > II, future architectures can be more-or-less anything that works = well,
> > and performance implications usually aren't anything like so = obvious=E2=80=A6
> > Aren't Mersennes actually particularly _good_ performance-wis= e?]
>
> That depends on whether you are looking for a reason to include or exc= lude.
>
> At the ~512 level, what I am looking for is a curve that absolutely > nobody is going to be able to suggest is suspect as being bongoed.
> 2^512 is a round number that needs no explanation. 2^521 isn't. >
> The Web PKI will almost certainly be based exclusively on the ~512
> level curve. The roots certainly will. So the performance advantage of=
> issuing end entity ~256 certs would be very small.
>
> Where I think ~256 keys will be used is for ephemeral mix ins. So I > exchange a master session key M with the ~512 bit key, use an
> ephemeral ~256 to create a second session key E and then derive my
> encryption and authentication keys using a one way function on M and > E. That preserves the ~512 work factor for confidentiality and adds a<= br> > ~256 work factor for forward secrecy.
>
>
> So I am willing to be more flexible on ~256 than ~512 because for my > applications the attacker always has to break the ~512.
>
>
> > I put forth that 2^414-17 and 2^448-2^224-1 might fall outside &q= uot;wiggle
> > room" there, although I do so very reluctantly as I think it= 's a shame
> > to exclude them on that basis if they have otherwise nice propert= ies,
> > and they do seem to have very good performance for their strength= .
>
> I agree. They are a little faster but we have to give up a lot of
> security to get that speed. Its not 64 bits, its a 2^20 reduction in > work factor. I want them bits.
>

As Mike Hamburg points out downthread, TLS doesn't work = that way.

Furthermore, P384 is in use now. I wish someone would toss i= t into eBATS, but I think both Curve 41417 and Goldilocks are faster by som= ething, can't recall what.

>
> >> 31/10/14 (2 weeks from now): we agree on whatever benchmarkin= g
> >> system we're going to use for performance measurements. (= Right now,
> >> supercop seems like the front runner to me.)
>
> I think a significant performance difference is a tie breaker but not<= br> > the best determinant. What I see as being convincing are:
>
> 1) Difficulty of screwing up the implementation (see Watson Ladd's= post).

Which has little to nothing to do with curves. See DJB's= curves coordinates and computations email.

>
> 2) Legacy deployment.

See above.
>
>
> Given the way that I think we are likely to use ~256 and given the
> fact that DJB has established a large user base for the curve already.=
> I am willing to suggest we just let him win on that one unless there > is at least a 10%, maybe a 20% speed advantage he missed.
>
> For ~512 I want the Platinum level security, whatever it takes.
>
> _______________________________________________
> Cfrg mailing list
>Cfrg@irtf.org
>http://www.irtf.o= rg/mailman/listinfo/cfrg

--089e013a14085fb62d0505a54895-- From nobody Fri Oct 17 16:12:59 2014 Return-Path: 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 29B761A8775 for ; Fri, 17 Oct 2014 16:12:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 VbAla8eA-278 for ; Fri, 17 Oct 2014 16:12:55 -0700 (PDT) Received: from ore.jhcloos.com (ore.jhcloos.com [198.147.23.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48EC21A876F for ; Fri, 17 Oct 2014 16:12:55 -0700 (PDT) Received: by ore.jhcloos.com (Postfix, from userid 10) id 841841E0C4; Fri, 17 Oct 2014 23:12:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=ore14; t=1413587574; bh=gd7JRuTuuGbYOK4xQ25P7sSW5lRQKzkM8dv5MkSinew=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=Pd1qWZm1d5prHf1AIpuMNVwPJD2motbmpxpoHiV65FdesNGGC3eiw/IUdM5JWIyY+ O02IaHD4VTMPFan+KRIp6dgTdpfa1yJ24QEhAwmA73Ivq/yiPmDWPWSKrC785X73Kf 7zHqdV3lMxhoafmaY1YB5rhigamAnqPVdSjxfI5s= Received: by carbon.jhcloos.org (Postfix, from userid 500) id ADB7660023; Fri, 17 Oct 2014 23:11:23 +0000 (UTC) From: James Cloos To: Michael Hamburg In-Reply-To: <5218FD35-E00A-413F-ACCB-AA9B99DEF48B@shiftleft.org> (Michael Hamburg's message of "Fri, 17 Oct 2014 14:27:46 -0700") References: <54400E9F.5020905@akr.io> <5218FD35-E00A-413F-ACCB-AA9B99DEF48B@shiftleft.org> User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/24.4.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2014 James Cloos OpenPGP: 0x997A9F17ED7DAEA6; url=https://jhcloos.com/public_key/0x997A9F17ED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Fri, 17 Oct 2014 19:11:23 -0400 Message-ID: Lines: 15 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Hashcash: 1:28:141017:mike@shiftleft.org::2g6Wmg7IAnUGYe/W:00000000000000000000000000000000000000000042nH7 X-Hashcash: 1:28:141017:phill@hallambaker.com::dJkbYESqDU+3bSyt:0000000000000000000000000000000000000009m2kr X-Hashcash: 1:28:141017:"cfrg\@irtf.org"::7lrUOMWB8QfJH1oR:Ah99f X-Hashcash: 1:28:141017:cfrg@irtf.org::724VoFbszVdoopNg:00092nAc Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/6jvAQR7AW1xDPTBtYINwJL6eCOk Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] ECC reboot X-BeenThere: cfrg@irtf.org 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, 17 Oct 2014 23:12:57 -0000 >>>>> "MH" == Michael Hamburg writes: MH> I looked at Mozilla’s included CAs. There are four ECC certs there, MH> all of them on the NIST secp384r1 curve. So they apparently do not MH> consider ~512 bits necessary, but if the only choices are 256 and 512 MH> I suppose they will go with 512. The nist 2^521-1 curve probably wasn't available in enough software. Presumably for the same reason suite-B lost it. (Which, AIUI, was some ipr claim, yes?) -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6 From nobody Fri Oct 17 16:31:11 2014 Return-Path: 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 2BB6F1A1A03 for ; Fri, 17 Oct 2014 16:31:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no 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 JYC1gUD-ap_g for ; Fri, 17 Oct 2014 16:31:07 -0700 (PDT) Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AE251A1A02 for ; Fri, 17 Oct 2014 16:31:06 -0700 (PDT) Received: by mail-lb0-f180.google.com with SMTP id n15so1421010lbi.39 for ; Fri, 17 Oct 2014 16:31:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=/2KC+wgKPXnrUEcs3jd9BhZXqxvUzBmIHU2PcwaMFVc=; b=w+4lzgNxE9tXCT9OkDSOHhnEIlNuedSzObqaOYJfGu9Y4iy38kOYC0BHEjCUOA/6Xr X1XiB7TtLt8aFtCzd3XeqJCBnyiiR6GygRA5FdPcWzWDLJEc6vRjrNEl1Y7QWXqpUk2Z j+ba1dPJXN+3FHY/mUJC1/jeg+19J5+RFpt0k3YeZgWEoi/okxrEugak9mqdQnsFJbuY rxmNlRKyqygoNAD/KpsaQg3uDsVGQp6Agr/a1tLP60auwdj3GJLPZSwybznmztiYBn+4 Ad0DwQ3T8gq9RMJ6GfzoTbdeu9k72WC3JjRq9+cTknmIroXNlrrPC2k9UQfRFRm9SRWN +PDw== MIME-Version: 1.0 X-Received: by 10.153.7.170 with SMTP id dd10mr11934436lad.45.1413588665365; Fri, 17 Oct 2014 16:31:05 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.66.196 with HTTP; Fri, 17 Oct 2014 16:31:05 -0700 (PDT) In-Reply-To: <5218FD35-E00A-413F-ACCB-AA9B99DEF48B@shiftleft.org> References: <54400E9F.5020905@akr.io> <5218FD35-E00A-413F-ACCB-AA9B99DEF48B@shiftleft.org> Date: Fri, 17 Oct 2014 19:31:05 -0400 X-Google-Sender-Auth: n6YSxfpEFJljKFo0lRADHDmheWY Message-ID: From: Phillip Hallam-Baker To: Michael Hamburg Content-Type: multipart/alternative; boundary=001a113483ae41fb390505a6c23c Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/p8mHpYFXEtsj61HpPJxMTzl5xXA Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] ECC reboot (Was: When's the decision?) X-BeenThere: cfrg@irtf.org 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, 17 Oct 2014 23:31:10 -0000 --001a113483ae41fb390505a6c23c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Oct 17, 2014 at 5:27 PM, Michael Hamburg wrote= : > > > Its not just a question of speed, its a question of the amount of > > microcode required to implement ECC math as a native function of the > > GPU. > > Discrete graphics probably won=E2=80=99t be be a common crypto platform, = though I > agree that AVX-512F will be in a few years. I think that we will find the CPU choices will end up being limited to CPU cores and GPU cores long term because those are the areas where all the big R&D bucks are going. Its like when I try to buy motors for my robots. There are no motors made for the purpose of driving a dalek or an R2D2. There are motors made for scooters and wheelchairs because those are the markets with the big enough markets. AVX-512F looks tasty though. > > That depends on whether you are looking for a reason to include or > exclude. > > > > At the ~512 level, what I am looking for is a curve that absolutely > > nobody is going to be able to suggest is suspect as being bongoed. > > 2^512 is a round number that needs no explanation. 2^521 isn=E2=80=99t. > > I=E2=80=99m not sure what you mean by =E2=80=9Cbongoed=E2=80=9D. I do no= t believe that 2^521-1 > has been struck rhythmically by hands, or has been played as a melody on > bongos. > Got at by the NSA. > It is possible, if unlikely, that some mathematical property of Mersenne > primes would make elliptic curves mod them weaker than mod other primes. > But at least 4 groups thought 2^521-1 was an obvious choice, and at least= 3 > of them came up with the same curve. That=E2=80=99s about as unsuspiciou= s as > you=E2=80=99re going to get without some VPR performance art. > > > The Web PKI will almost certainly be based exclusively on the ~512 > > level curve. The roots certainly will. So the performance advantage of > > issuing end entity ~256 certs would be very small. > > Just the way they use ~15kbit RSA keys now, eschewing ~3072-bit keys as > too weak, right? > The only reason we are interested in ECC is that RSA stops giving meaningful increases in work factor at 2048 bits. 4096 bits is a lot more work for the defender for a rather modest improvement in work factor. I looked at Mozilla=E2=80=99s included CAs. There are four ECC certs there= , all of > them on the NIST secp384r1 curve. So they apparently do not consider ~51= 2 > bits necessary, but if the only choices are 256 and 512 I suppose they wi= ll > go with 512. > > The RSA-based roots are mostly 2048 bits long, equivalent to about a > 224-bit ECC. If the CAs consider this an acceptable level of security fo= r > hosts, I suspect that webmasters will be OK with ~256-bit curves. That= =E2=80=99s > what Cloudflare uses for their universal SSL, for example. The only reason to deploy ECC is if we are unsatisfied with RSA. It is not the case that RSA2048 is satisfactory. It is merely 'adequate'. > Where I think ~256 keys will be used is for ephemeral mix ins. So I > > exchange a master session key M with the ~512 bit key, use an > > ephemeral ~256 to create a second session key E and then derive my > > encryption and authentication keys using a one way function on M and > > E. That preserves the ~512 work factor for confidentiality and adds a > > ~256 work factor for forward secrecy. > > > > > > So I am willing to be more flexible on ~256 than ~512 because for my > > applications the attacker always has to break the ~512. > > Maybe for your applications, but that=E2=80=99s not how TLS=E2=80=99s ECD= HE works. Not relevant because we have to cut a new OID set anyhow. In fact there is quite a raft of changes likely to happen in parallel. > > I agree. They are a little faster but we have to give up a lot of > > security to get that speed. Its not 64 bits, its a 2^20 reduction in > > work factor. I want them bits. > > I basically get this sentiment. But just so we can be clear: why do you > want them bits? Is it just an insatiable craving, or does a round 512 > sound better in product advertisements, or is there a foreseeable attack > that the extra bits will protect you from? > If a competitor launches a 512 bit ECC cert then I will have to. > If most CAs today are OK with security equivalent to 224-bit curves, but > they're hedging to 384 bits, why are you convinced that 384 or 414 or 448 > or 480 bits would not be enough? And if they aren=E2=80=99t enough, why = not go to > 607 or 640 or 1024 bits? Same reason as 2048 and 1024 the next nearest power of 2 that gives close to the desired work factor. When we chose 1024 we were working with 2^80 as an acceptable work factor. Now we are generally looking for 128 and 256. So RSA2048 is showing its age= . Making the choice for TLS is perhaps not ideal as TLS is a transport protocol and so we are not that worried about long term security. For S/MIME we really do want 30 year security. > > >>> 31/10/14 (2 weeks from now): we agree on whatever benchmarking > >>> system we're going to use for performance measurements. (Right now, > >>> supercop seems like the front runner to me.) > > > > I think a significant performance difference is a tie breaker but not > > the best determinant. What I see as being convincing are: > > > > 1) Difficulty of screwing up the implementation (see Watson Ladd's post= ). > > > > 2) Legacy deployment. > > The only new bigger-than-256-bit curve which would ease legacy transition > is E-521. I think the legacy argument is a lot stronger for Curve 25519. Not in the TLS space but he has got a lot of mindshare elsewhere. > > > Given the way that I think we are likely to use ~256 and given the > > fact that DJB has established a large user base for the curve already. > > I am willing to suggest we just let him win on that one unless there > > is at least a 10%, maybe a 20% speed advantage he missed. > > > > For ~512 I want the Platinum level security, whatever it takes. > > > Platinum is heavy and very, very expensive. It resists corrosion > phenomenally well, but not cutting. Quite the metaphor. > I rejected diamond because its brittle. --001a113483ae41fb390505a6c23c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Oct 17, 2014 at 5:27 PM, Michael Hamburg <mike@shiftleft.org>= wrote:

> Its not just a question of speed, its a question of the amount of
> microcode required to implement ECC math as a native function of the > GPU.

Discrete graphics probably won=E2=80=99t be be a common crypto platf= orm, though I agree that AVX-512F will be in a few years.
=
I think that we will find the CPU choices will end up being = limited to CPU cores and GPU cores long term because those are the areas wh= ere all the big R&D bucks are going.

Its like = when I try to buy motors for my robots. There are no motors made for the pu= rpose of driving a dalek or an R2D2. There are motors made for scooters and= wheelchairs because those are the markets with the big enough markets.

AVX-512F looks tasty though.=C2=A0

=

=C2=A0
> That depends on whether you are looking for a reason to include or exc= lude.
>
> At the ~512 level, what I am looking for is a curve that absolutely > nobody is going to be able to suggest is suspect as being bongoed.
> 2^512 is a round number that needs no explanation. 2^521 isn=E2=80=99t= .

I=E2=80=99m not sure what you mean by =E2=80=9Cbongoed=E2=80=9D.=C2= =A0 I do not believe that 2^521-1 has been struck rhythmically by hands, or= has been played as a melody on bongos.

Got at by the NSA.
=C2=A0
It is possible, if unlikely, that some mathematical property of Mersenne pr= imes would make elliptic curves mod them weaker than mod other primes.=C2= =A0 But at least 4 groups thought 2^521-1 was an obvious choice, and at lea= st 3 of them came up with the same curve.=C2=A0 That=E2=80=99s about as uns= uspicious as you=E2=80=99re going to get without some VPR performance art.<= br>
> The Web PKI will almost certainly be based exclusively on the ~512
> level curve. The roots certainly will. So the performance advantage of=
> issuing end entity ~256 certs would be very small.

Just the way they use ~15kbit RSA keys now, eschewing ~3072-bit keys= as too weak, right?

The only reason we= are interested in ECC is that RSA stops giving meaningful increases in wor= k factor at 2048 bits. 4096 bits is a lot more work for the defender for a = rather modest improvement in work factor.


I looked at Mozilla=E2=80=99s included CAs.=C2=A0 There are four ECC certs = there, all of them on the NIST secp384r1 curve.=C2=A0 So they apparently do= not consider ~512 bits necessary, but if the only choices are 256 and 512 = I suppose they will go with 512.

The RSA-based roots are mostly 2048 bits long, equivalent to about a 224-bi= t ECC.=C2=A0 If the CAs consider this an acceptable level of security for h= osts, I suspect that webmasters will be OK with ~256-bit curves.=C2=A0 That= =E2=80=99s what Cloudflare uses for their universal SSL, for example.

The only reason to deploy ECC is if we are unsat= isfied with RSA. It is not the case that RSA2048 is satisfactory. It is mer= ely 'adequate'. =C2=A0


> Where I think ~256 keys will be used is for ephemeral mix ins. So I > exchange a master session key M with the ~512 bit key, use an
> ephemeral ~256 to create a second session key E and then derive my
> encryption and authentication keys using a one way function on M and > E. That preserves the ~512 work factor for confidentiality and adds a<= br> > ~256 work factor for forward secrecy.
>
>
> So I am willing to be more flexible on ~256 than ~512 because for my > applications the attacker always has to break the ~512.

Maybe for your applications, but that=E2=80=99s not how TLS=E2=80=99= s ECDHE works.

Not relevant because we have= to cut a new OID set anyhow. In fact there is quite a raft of changes like= ly to happen in parallel.

=C2=A0
> I agree. They are a little faster but we have to give up a lot of
> security to get that speed. Its not 64 bits, its a 2^20 reduction in > work factor. I want them bits.

I basically get this sentiment.=C2=A0 But just so we can be clear: w= hy do you want them bits?=C2=A0 Is it just an insatiable craving, or does a= round 512 sound better in product advertisements, or is there a foreseeabl= e attack that the extra bits will protect you from?
If a competitor launches a 512 bit ECC cert then I will have t= o.
=C2=A0
If most CAs today are OK with security equivalent to 224-bit curves, but th= ey're hedging to 384 bits, why are you convinced that 384 or 414 or 448= or 480 bits would not be enough?=C2=A0 And if they aren=E2=80=99t enough, = why not go to 607 or 640 or 1024 bits?

Same= reason as 2048 and 1024 the next nearest power of 2 that gives close to th= e desired work factor.

When we chose 1024 we were = working with 2^80 as an acceptable work factor. Now we are generally lookin= g for 128 and 256. So RSA2048 is showing its age.

= Making the choice for TLS is perhaps not ideal as TLS is a transport protoc= ol and so we are not that worried about long term security. For S/MIME we r= eally do want 30 year security.

=C2=A0

>>> 31/10/14 (2 weeks from now): we agree on whatever benchmarking=
>>> system we're going to use for performance measurements. (R= ight now,
>>> supercop seems like the front runner to me.)
>
> I think a significant performance difference is a tie breaker but not<= br> > the best determinant. What I see as being convincing are:
>
> 1) Difficulty of screwing up the implementation (see Watson Ladd's= post).
>
> 2) Legacy deployment.

The only new bigger-than-256-bit curve which would ease legacy trans= ition is E-521.

I think the legacy argument= is a lot stronger for Curve 25519. Not in the TLS space but he has got a l= ot of mindshare elsewhere.
=C2=A0

> Given the way that I think we are likely to use ~256 and given the
> fact that DJB has established a large user base for the curve already.=
> I am willing to suggest we just let him win on that one unless there > is at least a 10%, maybe a 20% speed advantage he missed.
>
> For ~512 I want the Platinum level security, whatever it takes.


Platinum is heavy and very, very expensive.=C2=A0 It resists corrosi= on phenomenally well, but not cutting.=C2=A0 Quite the metaphor.

I rejected diamond because its brittle.=C2=A0

--001a113483ae41fb390505a6c23c-- From nobody Fri Oct 17 16:48:14 2014 Return-Path: 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 F02471A87B2 for ; Fri, 17 Oct 2014 16:48:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 OGV18gDO7lrM for ; Fri, 17 Oct 2014 16:48:11 -0700 (PDT) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13DC11A87B1 for ; Fri, 17 Oct 2014 16:48:10 -0700 (PDT) Received: by mail-wg0-f50.google.com with SMTP id a1so1859260wgh.33 for ; Fri, 17 Oct 2014 16:48:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=y2QR7QVU5+RXGuDOoQA6BkVDrM862urwsUBmdI2WOn8=; b=WPRghDINX+tcqwnoDIbhqjSHv9UulA87qR2kXa1vePL4Ugh8bwXxZUPpELECOevL+b I0AH8axqzXb4GC+vDkoUUlhBzU8UiVGenHbRhjPiKxZbcEln0XhkZROHKUH1nLhSKNVO eRvQheqA83qaPYlCO2+b9HakJPwEttTghU9sUrE7LoFYMqtEu8B3ioAUy2kI4MGjFvij dAIcx6XkIUxq2j7z98Tn1Q71MgfqHql94Z5w9rZ0d8s2JI9YTAzB+YlhcHs0HbqJJ/J3 BfBs9jDiJ5ZSO39tht1LZKssN1nD7RDp6R3BRa++jVf+62b+Vy6pkLufBocmZECEf0tw pccA== X-Gm-Message-State: ALoCoQlS/gBAZuvypeBfw8ddI0QFRk4VWYm6u36hLEs5IjagCqOynyZBIa0EfQWNoxHSAkk6XZ5H X-Received: by 10.194.48.84 with SMTP id j20mr13969174wjn.35.1413589689136; Fri, 17 Oct 2014 16:48:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.217.14.70 with HTTP; Fri, 17 Oct 2014 16:47:48 -0700 (PDT) In-Reply-To: References: <54400E9F.5020905@akr.io> <5218FD35-E00A-413F-ACCB-AA9B99DEF48B@shiftleft.org> From: Benjamin Black Date: Fri, 17 Oct 2014 16:47:48 -0700 Message-ID: To: Phillip Hallam-Baker Content-Type: multipart/alternative; boundary=047d7b86c92447b0530505a6ffb4 Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/OIL3qZ9LXHWDT63Fqrc28fzf9y0 Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] ECC reboot (Was: When's the decision?) X-BeenThere: cfrg@irtf.org 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, 17 Oct 2014 23:48:13 -0000 --047d7b86c92447b0530505a6ffb4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Oct 17, 2014 at 4:31 PM, Phillip Hallam-Baker wrote: > > > > >> > That depends on whether you are looking for a reason to include or >> exclude. >> > >> > At the ~512 level, what I am looking for is a curve that absolutely >> > nobody is going to be able to suggest is suspect as being bongoed. >> > 2^512 is a round number that needs no explanation. 2^521 isn=E2=80=99t= . >> >> I=E2=80=99m not sure what you mean by =E2=80=9Cbongoed=E2=80=9D. I do n= ot believe that 2^521-1 >> has been struck rhythmically by hands, or has been played as a melody on >> bongos. >> > > Got at by the NSA. > If the NSA is capable of causing numbers to be Mersenne primes then we should all pack it in immediately. b --047d7b86c92447b0530505a6ffb4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Oct 17, 2014 at 4:31 PM, Phillip Hallam-Baker <phill@hallambaker.c= om> wrote:
=C2=A0
> That depends on whether you are looking for a reason to include or exc= lude.
>
> At the ~512 level, what I am looking for is a curve that absolutely > nobody is going to be able to suggest is suspect as being bongoed.
> 2^512 is a round number that needs no explanation. 2^521 isn=E2=80=99t= .

I=E2=80=99m not sure what you mean by =E2=80=9Cbongoed=E2=80=9D.=C2= =A0 I do not believe that 2^521-1 has been struck rhythmically by hands, or= has been played as a melody on bongos.

Got at by the NSA.

If the NSA is capable of causing numbers to be Mersenne primes then= we should all pack it in immediately.=C2=A0


<= /div>
b

--047d7b86c92447b0530505a6ffb4-- From nobody Fri Oct 17 16:55:10 2014 Return-Path: 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 B10601A87C9 for ; Fri, 17 Oct 2014 16:55:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.503 X-Spam-Level: X-Spam-Status: No, score=-1.503 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, BIGNUM_EMAILS=0.474, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no 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 p-zbbBjto7Ee for ; Fri, 17 Oct 2014 16:55:04 -0700 (PDT) Received: from mail-wg0-f51.google.com (mail-wg0-f51.google.com [74.125.82.51]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C26B91A87C7 for ; Fri, 17 Oct 2014 16:55:03 -0700 (PDT) Received: by mail-wg0-f51.google.com with SMTP id b13so1884815wgh.34 for ; Fri, 17 Oct 2014 16:55:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=nf3pgCtkOdDJclX797lNwv3pWUkMugXv7Yr5aSejY8g=; b=RF5chAfHwIqupfsyfFnInBH04ZSDDVNAWxTmHqh6PmBplmThuZ9P0gJxiV9XUWPTu3 4pJVx0ksrakU2+73yGndzCvba4CDtKoS7FbvWDpY/N17cy4qTIl4PG7EpbVdEEHxqDKU USatfxkmYyO7nM9H/1/9oXaviOqF/v70QOe8rMNxvz2WPOHrjgsuR34aWmeapV3r+AUm 2+uWQr/HsiWRUyNLfuvjpqiPYYDNGzO9a3BAe4U+jRt4W3+o8woFP7xKSqvuhBHeabR2 B4mnJkGpBbyN3cO9dNl0IWxxDnIWiVu3ABS41WvMP9oU/HZXV/TzBNRuKjhk49pxGU/r LWsA== X-Gm-Message-State: ALoCoQmOyu6Fc62pZP1Cme1LbdXQXKpKr53KXNncdUvDNpJ0ZlfRJU2SkW6ksCAHmf71sgtXyL7W X-Received: by 10.180.149.169 with SMTP id ub9mr2247214wib.73.1413590102334; Fri, 17 Oct 2014 16:55:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.217.14.70 with HTTP; Fri, 17 Oct 2014 16:54:42 -0700 (PDT) In-Reply-To: <253D0648-0DDE-497E-8BC1-4DD2805640E4@shiftleft.org> References: <075fdb98d04b42d08e39dbc706cc21fa@DM2PR03MB495.namprd03.prod.outlook.com> <253D0648-0DDE-497E-8BC1-4DD2805640E4@shiftleft.org> From: Benjamin Black Date: Fri, 17 Oct 2014 16:54:42 -0700 Message-ID: To: Michael Hamburg Content-Type: multipart/alternative; boundary=001a11c38aeae891560505a717d5 Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/RU8Q2gXkBcrXOZe2MKloirP-tIE Cc: "cfrg@ietf.org" , Craig Costello Subject: Re: [Cfrg] Complexity of the Microsoft curve proposal X-BeenThere: cfrg@irtf.org 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, 17 Oct 2014 23:55:06 -0000 --001a11c38aeae891560505a717d5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Oct 14, 2014 at 6:03 PM, Michael Hamburg wrote= : > I don=E2=80=99t think everyone on this list would agree with the above st= atement, > though. A pretty big part of Benjamin Black=E2=80=99s argument against \= w+25519 is > the idea that they are different curves, not just different coordinates f= or > the same curve, even though the curves are isomorphic and not just > isogenous. > > For the record, my argument was, and is, that _requiring_ implementation of multiple forms of the same curve is undesirable and unnecessary. At the time, the discussion was not \w+25519, but X25519 and Ed25519 (and apologies if I have made mistakes with the various 25519 names). As the discussion has moved on from there, I don't think it is terribly relevant. b --001a11c38aeae891560505a717d5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Oct 14, 2014 at 6:03 PM, Michael Hamburg <mike@shiftleft.org>= wrote:
I don=E2=80=99t think everyone on this list would agree= with the above statement, though.=C2=A0 A pretty big part of Benjamin Blac= k=E2=80=99s argument against \w+25519 is the idea that they are different c= urves, not just different coordinates for the same curve, even though the c= urves are isomorphic and not just isogenous.


For the record, my argument was, and is,= that _requiring_ implementation of multiple forms of the same curve is und= esirable and unnecessary. At the time, the discussion was not \w+25519, but= X25519 and Ed25519 (and apologies if I have made mistakes with the various= 25519 names). As the discussion has moved on from there, I don't think= it is terribly relevant.


b
=C2=A0
--001a11c38aeae891560505a717d5-- From nobody Fri Oct 17 17:11:36 2014 Return-Path: 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 3C6E51A87E1 for ; Fri, 17 Oct 2014 17:11:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 mRXqkbWOWRap for ; Fri, 17 Oct 2014 17:11:28 -0700 (PDT) Received: from mail-wi0-f171.google.com (mail-wi0-f171.google.com [209.85.212.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 189311A883B for ; Fri, 17 Oct 2014 17:10:21 -0700 (PDT) Received: by mail-wi0-f171.google.com with SMTP id em10so3257276wid.10 for ; Fri, 17 Oct 2014 17:10:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=z5PrwgqvAPfRKZmCsRI2RgU3PQfzCHenQhNGxJ0REOI=; b=F+yRsiQyy5c8ewVumnZf6VAHncr7BXxeN0DlGgTDSIb4qecXx9fAeDForExLSPIA2U dfqK4kTs76+D3L9q/nzTaz19mV4TypeiEADdQhnJzovC1pW3ZPPrGtDOkJURa0aB+2KY 4fodD+IllnzjU26/0dex52eQjQ2UHs/rZQZttnXDAGhjlTVZeMPgPR+d7+D+7WEz+y13 /mjhtx9Izjl6rVJ4ChmttLs/UZ8qyANBcEf+W5jjoK9vPK5CKQWqYYbrYA4anTlS7X38 CojTaST90AZiBLiCfhex9/RlfwAPNmnYV5g1+NSEmMsN+ST238ecppVbem/SEPNC5VdU 1W9g== X-Gm-Message-State: ALoCoQnJFPsbSDrDozi4+GxjZBH0xvk5GJoy4E9PJzzucHT5CGIuZtCjwF6unqC1x6t8b/J4KF46 X-Received: by 10.180.93.37 with SMTP id cr5mr2423855wib.76.1413591020656; Fri, 17 Oct 2014 17:10:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.217.14.70 with HTTP; Fri, 17 Oct 2014 17:10:00 -0700 (PDT) In-Reply-To: References: <54400E9F.5020905@akr.io> <5218FD35-E00A-413F-ACCB-AA9B99DEF48B@shiftleft.org> From: Benjamin Black Date: Fri, 17 Oct 2014 17:10:00 -0700 Message-ID: To: James Cloos Content-Type: multipart/alternative; boundary=f46d043c8050a50e500505a74edc Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/vsLDKZgNEtNouctgrpFGs0KOJzM Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] ECC reboot X-BeenThere: cfrg@irtf.org 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: Sat, 18 Oct 2014 00:11:31 -0000 --f46d043c8050a50e500505a74edc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Oct 17, 2014 at 4:11 PM, James Cloos wrote: > >>>>> "MH" =3D=3D Michael Hamburg writes: > > MH> I looked at Mozilla=E2=80=99s included CAs. There are four ECC certs= there, > MH> all of them on the NIST secp384r1 curve. So they apparently do not > MH> consider ~512 bits necessary, but if the only choices are 256 and 512 > MH> I suppose they will go with 512. > > The nist 2^521-1 curve probably wasn't available in enough software. > > Presumably for the same reason suite-B lost it. (Which, AIUI, was some > ipr claim, yes?) > > > Per an earlier thread, P521 was not intended to be in Suite B, but AES-192 was. Since AES-192 was not broadly implemented, P384 was paired with AES-256, instead. b --f46d043c8050a50e500505a74edc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
--f46d043c8050a50e500505a74edc-- From nobody Fri Oct 17 20:35:10 2014 Return-Path: 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 E6D2E1A0137 for ; Fri, 17 Oct 2014 20:35:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.555 X-Spam-Level: * X-Spam-Status: No, score=1.555 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.982, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no 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 cFi2Ar9Gh6pR for ; Fri, 17 Oct 2014 20:35:06 -0700 (PDT) Received: from aspartame.shiftleft.org (199-116-74-168-v301.PUBLIC.monkeybrains.net [199.116.74.168]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05FFE1A012D for ; Fri, 17 Oct 2014 20:35:05 -0700 (PDT) Received: from [192.168.1.129] (unknown [192.168.1.1]) by aspartame.shiftleft.org (Postfix) with ESMTPSA id 94F5C3AA49; Fri, 17 Oct 2014 20:33:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=shiftleft.org; s=sldo; t=1413603183; bh=yUUcnFbMoFgUmtMV3yiJzgU/svB3/F00PFP2GPWjZsQ=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=BFh01F391xyZMzzyL8b6x8taBsWZUcCXaXbCnFk2TyrXRzygs28BaiSLgnihP9zil oYu89wweBur1iVru5QbGKR+TYqITmjt50EnFHBlhC6W1aYkGs3AUqrR9txMwXNOdCn SPykmdBditZIdy+d+Ti09GOkQ8UlKOH7ExrL3kVc= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Michael Hamburg In-Reply-To: Date: Fri, 17 Oct 2014 20:35:03 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <004F71A2-35F7-41EE-B19C-2264C23785F2@shiftleft.org> References: <54400E9F.5020905@akr.io> <5218FD35-E00A-413F-ACCB-AA9B99DEF48B@shiftleft.org> To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/td221b5RFffE4cAaH9S7GlgZBhA Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] ECC reboot (Was: When's the decision?) X-BeenThere: cfrg@irtf.org 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: Sat, 18 Oct 2014 03:35:07 -0000 > On Oct 17, 2014, at 4:31 PM, Phillip Hallam-Baker = wrote: >=20 > On Fri, Oct 17, 2014 at 5:27 PM, Michael Hamburg = wrote: >=20 >> Phillip Hallam-Baker wrote: >>=20 >>> For ~512 I want the Platinum level security, whatever it takes. >>=20 >>=20 >> Platinum is heavy and very, very expensive. It resists corrosion = phenomenally well, but not cutting. Quite the metaphor. >=20 > I rejected diamond because its brittle.=20 Maybe I should expand on this. Sometimes precious metals or gemstones = are used for protection (platinum for corrosion, sapphire for abrasion, = =E2=80=A6) because they=E2=80=99re genuinely the best material to = survive a particular harsh environment. Sometimes they=E2=80=99re used = for marketing reasons. Sometimes it=E2=80=99s a combination. It=E2=80=99s clear from your email that you want this 512-bit = =E2=80=9CPlatinum level security" for marketing reasons. If your = competitor offers it, you=E2=80=99ll need to as well. 521 bits is not = so round, not so shiny. And 414 or 448 or 480, well, everyone knows = those are less than 512. You don=E2=80=99t know, and I don=E2=80=99t = know, what the possible threats are against curves like this, or whether = more bits (and how many) will help resist them. But you want 512 = anyway, whatever it takes. And you know what? I get that. Especially post-Snowden, marketability = is an important part of any new security standard. But that won=E2=80=99t= stop me from pushing a solution that gives similar security at half the = cost. =E2=80=94 Mike= From nobody Sat Oct 18 07:57:03 2014 Return-Path: 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 6BF851A888E for ; Sat, 18 Oct 2014 07:57:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 tdGKp9Mq5tQM for ; Sat, 18 Oct 2014 07:57:00 -0700 (PDT) Received: from mail-yh0-x234.google.com (mail-yh0-x234.google.com [IPv6:2607:f8b0:4002:c01::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D8F91A0381 for ; Sat, 18 Oct 2014 07:56:59 -0700 (PDT) Received: by mail-yh0-f52.google.com with SMTP id f10so1134833yha.11 for ; Sat, 18 Oct 2014 07:56:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=zSjH3USzmqgIiw5qH+xdgE/a7YI2wJOw4EsKyT47xqs=; b=pPWKziHmXVx+nkOL3/barkm09JVO/Bc/r6N0GaV/Bi0tQfqncCi8zfVadKhv3Du9z3 lftbWUS5wDjIByuxh4VmWc/sF8swKHZ8avNTRuPQdSSd/GVq+CJrfREYWhatviIHR30I T6CP90LE3MRymRhKghvwo5GveIPIBNH1vLlQrOFnIwUpS4NZlOTOYTEbitlkBiJCnBBo SFN9J8kgpMu4iRNqP9DA6416NEF8GDrK1hWg4/qg4PVda8mrcZIkrmM7NbBCx91EA2yX 2OnyETR73halp7+A3AyhLoal5M+JPhWNz5POiwpXw5EaWlx9ICLjdtWL5ECk3TdiBhW2 5HPA== MIME-Version: 1.0 X-Received: by 10.236.53.69 with SMTP id f45mr22490919yhc.65.1413644219247; Sat, 18 Oct 2014 07:56:59 -0700 (PDT) Received: by 10.170.195.149 with HTTP; Sat, 18 Oct 2014 07:56:59 -0700 (PDT) In-Reply-To: References: Date: Sat, 18 Oct 2014 07:56:59 -0700 Message-ID: From: Watson Ladd To: "Paterson, Kenny" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/Wzii2n-wZziWNpOftyOO3KJMYhk Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] ECC reboot (Was: When's the decision?) X-BeenThere: cfrg@irtf.org 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: Sat, 18 Oct 2014 14:57:02 -0000 On Thu, Oct 16, 2014 at 9:08 AM, Paterson, Kenny wrote: > Dear all, > > Watson rightly pointed out that we are far behind the originally > advertised schedule for our process for selection of curves to recommend > to the TLS WG. Other parties in and beyond IETF are waiting on our > recommendations too. > > The reasons for the delay are quite complex, and I won't go into reviewing > them here. Suffice to say we've had a lot of really informative technical > discussion about performance of the different options, benchmarking, etc, > so the slippage has not exactly been wasted. > > Our first task should be to finalise the requirements that we will use to > guide the selection process. I think we are close, with a couple of > outstanding issues: > > 1. Amount of "wiggle room" that should be permitted. > > 2. A more nuanced set of hardware requirements. > > > I suggest we use the next *week* to try to finalise the requirements, and > then November to evaluate the candidates that we currently have (along > with any new candidates that might emerge) against the final set of > requirements. > > With this schedule, we'd miss the IETF 91 meeting for our decision, but I > don't think having our answer by mid-Novmeber is really feasible. We > should certainly be able to deliver an early Christmas present to the TLS > WG. > > To make this work, we'd need the RG to focus on the requirements for a > short additional period of time. > > So here's a proposal for a new schedule which I believe to be feasible: > > 24/10/14 (1 week from now): we finalise requirements, including hardware > requirements. > 31/10/14 (2 weeks from now): we agree on whatever benchmarking system > we're going to use for performance measurements. (Right now, supercop > seems like the front runner to me.) > 30/11/14 (6 weeks from now): we deliver our recommendations to the TLS WG. > > Could people let me know if this looks workable, within the next 24-48 > hours? Meantime, I'll send a message indicating where things stand on the > requirements list. This looks workable, assuming the requirements doesn't become settling the issue of point formats. (This seems to have quieted down, but probably out of exhaustion rather than agreement) If we give ourselves the month to do that, I think this makes sense. (Waiting around for benchmark results can easily be done while doing other things) I second the recommendation for Supercop: it has very good diversity of systems, easy to develop for, and already contains many contenders. Sadly, my P256 entry clearly needs work: the reference implementation is outperforming it on many CPUs! (This is probably due to the lack of a precomputed table of points for basepoint multiplications, or having the wrong window size, or some other similar issue: I'll investigate further) A state of the art P256 implementation and P384 implementation would make comparing the benefits of the new curves easy. One feature I would like to see is an easy way to plot multiple different primitives on the same graph, across machines. Reading the numbers from the per machine charts and accumulating them manually gets tired fast, and the graphs with all primitives are very crowded, including primitives that while fast are not on the table (for odd reasons: we should be able to work out a way to put Kummer surfaces into TLS to reduce CPU costs) Sincerely, Watson Ladd > > Thanks > > Kenny > > > On 06/10/2014 16:26, "Watson Ladd" wrote: > >>Dear all, >>We were promised on July 27 a process running for 6 weeks. Doubling I >>get 12 weeks, which is three months, of which two (August, September) >>have already gone. Am I correct in supposing that we're on track for a >>decision by Halloween? >> >>If we aren't, what remaining issues need to be addressed/when can we >>expect a decision? >> >>Sincerely, >>Watson Ladd >> >>_______________________________________________ >>Cfrg mailing list >>Cfrg@irtf.org >>http://www.irtf.org/mailman/listinfo/cfrg > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Sat Oct 18 13:30:33 2014 Return-Path: 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 20D521A066C for ; Sat, 18 Oct 2014 13:30:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.101 X-Spam-Level: X-Spam-Status: No, score=0.101 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, UNPARSEABLE_RELAY=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 Km3Vkmeb4-bG for ; Sat, 18 Oct 2014 13:30:29 -0700 (PDT) Received: from mace.cs.uic.edu (mace.cs.uic.edu [131.193.32.224]) by ietfa.amsl.com (Postfix) with SMTP id E29441A036B for ; Sat, 18 Oct 2014 13:30:27 -0700 (PDT) Received: (qmail 818 invoked by uid 1011); 18 Oct 2014 20:30:24 -0000 Received: from unknown (unknown) by unknown with QMTP; 18 Oct 2014 20:30:24 -0000 Received: (qmail 23025 invoked by uid 1001); 18 Oct 2014 20:30:17 -0000 Date: 18 Oct 2014 20:30:17 -0000 Message-ID: <20141018203017.23023.qmail@cr.yp.to> From: "D. J. Bernstein" To: cfrg@irtf.org Mail-Followup-To: cfrg@irtf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/XcszWmrTsQZXCxEyCnAEsuA9P-w Subject: [Cfrg] ed448goldilocks vs. numsp384t1 and numsp512t1 X-BeenThere: cfrg@irtf.org 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: Sat, 18 Oct 2014 20:30:32 -0000 Michael Hamburg writes: > I didn’t do this last time, which is (part of?) why the numbers from > my own benchmarks do not match DJB’s numbers; see below. Numbers are now coming into eBATS (see http://bench.cr.yp.to) for Mike's fixed ed448goldilocks software, and confirm what Mike said about speed compared to Microsoft's claimed speed. Here's the updated comparison chart on Sandy Bridge, the microarchitecture selected by Microsoft for benchmarks in http://eprint.iacr.org/2014/130.pdf: 617000 cycles claimed: numsp384t1 (ed-384-mers), ~2^192 security. 666544 cycles measured on h6sandy: ed448goldilocks, ~2^224 security. 1293000 cycles claimed: numsp512t1 (ed-512-mers), ~2^256 security. These DH ratios don't _perfectly_ predict ratios for other operations--- the instruction mix changes, and speeds of other operations depend on choices of precomputed table size---but at this point it's unsurprising to see ed448goldilocks close to numsp384t1 for signature generation: 231000 cycles claimed: numsp384t1 (ed-384-mers), ~2^192 security. 234844 cycles measured on h6sandy: ed448goldilocks, ~2^224 security. 446000 cycles claimed: numsp512t1 (ed-512-mers), ~2^256 security. Also signature verification: 624000 cycles claimed: numsp384t1 (ed-384-mers), ~2^192 security. 729152 cycles measured on h6sandy: ed448goldilocks, ~2^224 security. 1320000 cycles claimed: numsp512t1 (ed-512-mers), ~2^256 security. Microsoft says that its goal is to justify "all choices" in NUMS with "undisputable efficiency arguments"; but the actual measurements show considerably better efficiency/security tradeoffs for other curves. There's a lot more wiggle room for achieving not-quite-the-best speeds than there is for achieving the best speeds. ---Dan From nobody Mon Oct 20 02:40:57 2014 Return-Path: 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 618FE1A7026 for ; Mon, 20 Oct 2014 02:40:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.609 X-Spam-Level: X-Spam-Status: No, score=0.609 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_MISMATCH_NET=0.611, SPF_PASS=-0.001] autolearn=no 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 Az7CV03WTU20 for ; Mon, 20 Oct 2014 02:40:52 -0700 (PDT) Received: from ian.brad.office.comodo.net (eth5.brad-fw.brad.office.ccanet.co.uk [178.255.87.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 092FC1A7020 for ; Mon, 20 Oct 2014 02:40:51 -0700 (PDT) Received: (qmail 21219 invoked by uid 1000); 20 Oct 2014 09:40:47 -0000 Received: from and0004.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (AES128-SHA encrypted) ESMTPSA; Mon, 20 Oct 2014 10:40:47 +0100 Message-ID: <5444D89F.5080407@comodo.com> Date: Mon, 20 Oct 2014 10:40:47 +0100 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: "cfrg@irtf.org" References: <54400E9F.5020905@akr.io><5218FD35-E00A-413F-ACCB-AA9B99DEF48B@shiftleft.org> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/H_RPRsqE2j2HI81__v39WGjGq60 Subject: Re: [Cfrg] ECC reboot X-BeenThere: cfrg@irtf.org 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: Mon, 20 Oct 2014 09:40:55 -0000 On 18/10/14 01:10, Benjamin Black wrote: > On Fri, Oct 17, 2014 at 4:11 PM, James Cloos > wrote: > > >>>>> "MH" == Michael Hamburg > writes: > > MH> I looked at Mozillas included CAs. There are four ECC certs there, > MH> all of them on the NIST secp384r1 curve. So they apparently do not > MH> consider ~512 bits necessary, but if the only choices are 256 and 512 > MH> I suppose they will go with 512. When we generated our ECC root CA keys in 2008, secp384r1 seemed like the best choice. secp521r1 wasn't in Suite B, and it seemed likely that Suite B compliance would be a requirement for some of our customers. BTW, I strongly suspect that secp521r1/SHA-512 certificate signatures are in practice unusable in WebPKI TLS. RSA/SHA-512 certificate signatures are definitely unusable. The problem isn't lack of support for any of the algorithms in the crypto libraries. Rather, the problem is that TLS clients commonly don't specify RSA/SHA-512 and ECDSA/SHA-512 in the TLS signature_algorithms extension. Some servers respond by refusing to serve certs with SHA-512 signatures. > The nist 2^521-1 curve probably wasn't available in enough software. > > Presumably for the same reason suite-B lost it. (Which, AIUI, was some > ipr claim, yes?) > > Per an earlier thread, P521 was not intended to be in Suite B, but > AES-192 was. Since AES-192 was not broadly implemented, P384 was paired > with AES-256, instead. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From nobody Mon Oct 20 06:05:30 2014 Return-Path: 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 E0C101A872F for ; Mon, 20 Oct 2014 06:05:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.798 X-Spam-Level: X-Spam-Status: No, score=0.798 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_HELO_PASS=-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 iV93IhZcKd2N for ; Mon, 20 Oct 2014 06:05:26 -0700 (PDT) Received: from entima.net (entima.net [78.129.143.175]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EBEC1A872A for ; Mon, 20 Oct 2014 06:05:24 -0700 (PDT) In-Reply-To: <5444D89F.5080407@comodo.com> References: <54400E9F.5020905@akr.io><5218FD35-E00A-413F-ACCB-AA9B99DEF48B@shiftleft.org> <5444D89F.5080407@comodo.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 From: Alyssa Rowan Date: Mon, 20 Oct 2014 14:05:13 +0100 To: "cfrg@irtf.org" Message-ID: <90C609A5-ECB2-4FDC-9669-5830F3463D2B@akr.io> Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/TmojEgEwKPHvrCQxHW_ZlqaNEns Subject: Re: [Cfrg] ECC reboot X-BeenThere: cfrg@irtf.org 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: Mon, 20 Oct 2014 13:05:29 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 20 October 2014 10:40:47 BST, Rob Stradling wrote: >When we generated our ECC root CA keys in 2008, secp384r1 seemed like the best choice. secp521r1 wasn't in Suite B, and it seemed likely that Suite B compliance would be a requirement for some of our customers. Why not secp256r1? (I'm guessing the big reason was because the TS profile required ≈WF192 and you wanted one root to be suitable for both profiles if you could?) It's a bit early to say, but (open question to all) if we picked one curve at ≈WF128, would you in principle be comfortable with having roots of that strength? What about if we picked two: one fast secure curve at 128 and one at some higher "paranoid" grade (be it 384, 448, 480, 512, 521, 607...)? Which would you perhaps consider using when? Would you have one root at each level, or a shared root at the paranoid level? What kinds of things would you need to be able to have such a root? I'm guessing, bringing it back home to the weekly topic, that 'high-assurance' crypto hardware of some form would be highly desirable for that. But what does that mean to *you*? I say this because I don't think the initial target market for these new curves necessarily includes those mandated to use Suite B (although never say never!), I don't think government approval will drive adoption this time, and also the assurances people ask of Web PKI CAs in particular seem to be strengthening considerably relative to where they were (cf: Certificate Transparency, et al). >TLS clients commonly don't specify RSA/SHA-512 and ECDSA/SHA-512 in the TLS signature_algorithms extension. Some servers respond by refusing to serve certs with SHA-512 signatures. Thanks for that note. The TLS WG and user-agent participants should probably bear this in mind, down the line, if whatever we come up with is to be accepted and used. - -- /akr -----BEGIN PGP SIGNATURE----- Version: APG v1.1.1 iQI3BAEBCgAhBQJURQiIGhxBbHlzc2EgUm93YW4gPGFrckBha3IuaW8+AAoJEOyE jtkWi2t6lFAP/04NXnjKWHI34cZ2OYIs+qCP4q35hKFvbtAX+7MECPmlF+4lrpbS /Hzu8bjjsLVphsTWbXo8bW7sXCLWzHGkcL4QuvZM56ArngvP17EK3tZIgkFiOjKY D+hlGskjcAgXDhRvyaEvimuUHQ9BVWmGft0XPnMSucBckq634Bbw3VSdzhq+0yAV 5awXzKeTkrI9sYrwSXZ/P9TN/ejVjfI0t3KU+RxdMPWTY8psbmXsuaMT8ny4EkOi PhskwFNb5rndfRBEq/rnenhXAgTnUJVf51vBhU8YOKZLy2NojcZ2Wjy5YOQuDepQ GE3phWRqxCA4hnhbnNHcguxnlh5B6y5OzEYd/9/Iaia/brj7H3eYvc84RnG1H9Fl VTkBrAZUUmtcmdnTlNnEBQQ/pmSlGWZsIhLYPueXD43yAggMvP8YffURKADFfm6J Om5BmI2JVWjFpDjQA7e9NKL6niTJUccqUkHNjm54wEwIuh0zcKJCBzZ4P4cUU+vk T5BDy3AoVLFT9uVOXV/vXkTA3xcOtlLaUgnTa3CzRR9IuoIewPncK1MurP6I37jA XzcupAFmTgiDcITjKAm2xzaVzJwWByBbtuvaMBKRFbA1UK++y9/YWnhalwsEmNYf lo5LnvTuJa/SvmPcpLHqtqeTIIV3rWVdn5GVbZOx5jxao5KK19b/7kMF =tB0e -----END PGP SIGNATURE----- From nobody Mon Oct 20 11:37:25 2014 Return-Path: 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 BA5091A6F53 for ; Mon, 20 Oct 2014 11:37:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 Hb-Cy8-MXZDI for ; Mon, 20 Oct 2014 11:37:21 -0700 (PDT) Received: from emvm-gh1-uea09.nsa.gov (emvm-gh1-uea09.nsa.gov [63.239.67.10]) by ietfa.amsl.com (Postfix) with ESMTP id 56DD61A1B92 for ; Mon, 20 Oct 2014 11:37:21 -0700 (PDT) X-TM-IMSS-Message-ID: <6f2db0180015b385@nsa.gov> Received: from MSHT-GH1-UEA01.corp.nsa.gov ([10.215.227.18]) by nsa.gov ([63.239.67.10]) with ESMTP (TREND IMSS SMTP Service 7.1; TLSv1/SSLv3 AES128-SHA (128/128)) id 6f2db0180015b385 ; Mon, 20 Oct 2014 14:41:56 -0400 Received: from MSMR-GH1-UEA05.corp.nsa.gov (10.215.228.28) by MSHT-GH1-UEA01.corp.nsa.gov (10.215.227.18) with Microsoft SMTP Server (TLS) id 14.2.347.0; Mon, 20 Oct 2014 14:37:20 -0400 Received: from MSMR-GH1-UEA03.corp.nsa.gov ([10.215.224.3]) by MSMR-GH1-UEA05.corp.nsa.gov ([10.215.228.28]) with mapi id 14.02.0347.000; Mon, 20 Oct 2014 14:37:20 -0400 From: "Igoe, Kevin M." To: "cfrg@irtf.org" Thread-Topic: When in doubt, err on the side of security Thread-Index: Ac/slOLKVUxRHjqnToG6XRIn8WzXyg== Date: Mon, 20 Oct 2014 18:37:19 +0000 Message-ID: <3C4AAD4B5304AB44A6BA85173B4675CABC705962@MSMR-GH1-UEA03.corp.nsa.gov> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.215.225.46] Content-Type: multipart/alternative; boundary="_000_3C4AAD4B5304AB44A6BA85173B4675CABC705962MSMRGH1UEA03cor_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/AEfz1ydv2t8wGMFaRSVqYYwIEcc Subject: [Cfrg] When in doubt, err on the side of security X-BeenThere: cfrg@irtf.org 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: Mon, 20 Oct 2014 18:37:23 -0000 --_000_3C4AAD4B5304AB44A6BA85173B4675CABC705962MSMRGH1UEA03cor_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Once a security primitive has been selected, Moore's law will naturally imp= rove its performance with the passage of time. But Moore's law and advances in cryptanalysis will only erode its security (measured in the money needed to= run the attack). Bottom line: err on the side of security. ----------------+-------------------------------------------------- Kevin M. Igoe | "We can't solve problems by using the same kind kmigoe@nsa.gov | of thinking we used when we created them." | - Albert Einstein - ----------------+-------------------------------------------------- --_000_3C4AAD4B5304AB44A6BA85173B4675CABC705962MSMRGH1UEA03cor_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Once a security primitive has been selected, Moore&#= 8217;s law will naturally improve its

performance with the passage of time.   Bu= t Moore’s law and advances in

cryptanalysis will only erode its security (measured= in the money needed to run

the attack).  Bottom line: err on the side of s= ecurity.

 

 

----------------+-----------= ---------------------------------------

Kevin M. Igoe   | &quo= t;We can't solve problems by using the same kind

kmigoe@nsa.gov  | of thinki= ng we used when we created them."

     &n= bsp;          | &nbs= p;            - Albe= rt Einstein -

----------------+-----------= ---------------------------------------

 

--_000_3C4AAD4B5304AB44A6BA85173B4675CABC705962MSMRGH1UEA03cor_-- From nobody Mon Oct 20 12:23:01 2014 Return-Path: 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 5CA9F1A9218 for ; Mon, 20 Oct 2014 12:22:55 -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 25GzkhcNufN6 for ; Mon, 20 Oct 2014 12:22:48 -0700 (PDT) Received: from mail-yh0-x22d.google.com (mail-yh0-x22d.google.com [IPv6:2607:f8b0:4002:c01::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBF581AC3C3 for ; Mon, 20 Oct 2014 12:22:47 -0700 (PDT) Received: by mail-yh0-f45.google.com with SMTP id b6so3770212yha.18 for ; Mon, 20 Oct 2014 12:22:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=XFNTj//lnhTAitfhL6gPEV4hrmYcYTFiSRU8kTvEhWg=; b=H2E2vzOWR8Rb36dbLGbSlH4Z9S25Nz5OsNKBNUt98EZ1SlhHRkgMd3b4fFCEm8hOpU WTCVdlK4CPykwAxXUVvAnfoCyCzPH0KSItiWXB4U7TiNbGrE94lDznkxTwLHSFCJ4QMa xFBLFeC4/GaN+1qdhHBV3LhvvhrQ55hlqtvF+2mPoTe5iYdgIn/1abWKEKO2i9IMH8JN +eAhH54f0sfYy+CqIQPMb8WZ0Fv9Uhoh74JYTYCromEe423ADxkGJECNk+XhHk/DfmSw 7QfIObNtv4lu6JqjHZLqXxj/kHKI1uiXc04UCQKnteU2tL3cT/WnB+Tx16cXZVbelRBq SByA== MIME-Version: 1.0 X-Received: by 10.236.22.37 with SMTP id s25mr6006575yhs.138.1413832966985; Mon, 20 Oct 2014 12:22:46 -0700 (PDT) Received: by 10.170.195.149 with HTTP; Mon, 20 Oct 2014 12:22:46 -0700 (PDT) Received: by 10.170.195.149 with HTTP; Mon, 20 Oct 2014 12:22:46 -0700 (PDT) In-Reply-To: <3C4AAD4B5304AB44A6BA85173B4675CABC705962@MSMR-GH1-UEA03.corp.nsa.gov> References: <3C4AAD4B5304AB44A6BA85173B4675CABC705962@MSMR-GH1-UEA03.corp.nsa.gov> Date: Mon, 20 Oct 2014 12:22:46 -0700 Message-ID: From: Watson Ladd To: "Kevin M. Igoe" Content-Type: multipart/alternative; boundary=e89a8f642b46c4e1640505dfa302 Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/BYCFtKSmna6MZKl0yPgWqGNVI9o Cc: cfrg@irtf.org Subject: Re: [Cfrg] When in doubt, err on the side of security X-BeenThere: cfrg@irtf.org 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: Mon, 20 Oct 2014 19:22:55 -0000 --e89a8f642b46c4e1640505dfa302 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Oct 20, 2014 11:37 AM, "Igoe, Kevin M." wrote: > > Once a security primitive has been selected, Moore=E2=80=99s law will nat= urally improve its > > performance with the passage of time. But Moore=E2=80=99s law and advan= ces in > > cryptanalysis will only erode its security (measured in the money needed to run > > the attack). Bottom line: err on the side of security. Truisms like that are rarely helpful, and this is no exception. First, Moores law amplifies, not erases, performance issuses: users want to do more with cheaper crypto. How much this matters is an economic question. Sadly we've already ruled out the fastest options for somewhat decent reasons, as a glance at eBATS will show. The second issue is that the choice between performance and security is made worse by the absence of intermediate options. An organization that strained and strained to get adequate performance out of ed448goldilocks isn't made more secure by a standard only offering a 521 bit and 256 bit curve, as they will reduce security to get adequate performance. The tradeoff doesn't need to be that extreme for this to happen. I haven't seen good arguments for approving two curves at the far ends of the performance scale, instead of picking inflection points where a small increase in time yields a large increase in security. What I've seen is arguments that ignore the revealed preferences of users. Thirdly, I recall more Z80 processors are produced today then in the days of the microcomputer. Moore's law can be used to increase performance or reduce price. Interestingly, the NSA is no stranger to this issue. Suite B did not use the highest security for everything, presumably for performance reasons. In some cases the US Army uses very breakable ciphers, because the alternative is no cipher and the material isn't that sensitive. (If the message is "Attack at dawn", decrypting at 9 am isn't terribly helpful to the enemy) In conclusion performance still matters. Sincerely, Watson Ladd > > > > > > ----------------+-------------------------------------------------- > > Kevin M. Igoe | "We can't solve problems by using the same kind > >kmigoe@nsa.gov | of thinking we used when we created them." > > | - Albert Einstein - > > ----------------+-------------------------------------------------- > > > > > _______________________________________________ > Cfrg mailing list >Cfrg@irtf.org >http://www.irtf.org/mailman/listinfo/cfrg > --e89a8f642b46c4e1640505dfa302 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Oct 20, 2014 11:37 AM, "Igoe, Kevin M." <kmigoe@nsa.gov> wrote:
>
> Once a security primitive has been selected, Moore=E2=80=99s law will = naturally improve its
>
> performance with the passage of time.=C2=A0 =C2=A0But Moore=E2=80=99s = law and advances in
>
> cryptanalysis will only erode its security (measured in the money need= ed to run
>
> the attack).=C2=A0 Bottom line: err on the side of security.

Truisms like that are rarely helpful, and this is no excepti= on. First, Moores law amplifies, not erases, performance issuses: users wan= t to do more with cheaper crypto. How much this matters is an economic ques= tion. Sadly we've already ruled out the fastest options for somewhat de= cent reasons, as a glance at eBATS will show.

The second issue is that the choice between performance and = security is made worse by the absence of intermediate options. An organizat= ion that strained and strained to get adequate performance out of ed448gold= ilocks isn't made more secure by a standard only offering a 521 bit and= 256 bit curve, as they will reduce security to get adequate performance. T= he tradeoff doesn't need to be that extreme for this to happen.

I haven't seen good arguments for approving two curves a= t the far ends of the performance scale, instead of picking inflection poin= ts where a small increase in time yields a large increase in security. What= I've seen is arguments that ignore the revealed preferences of users.<= /p>

Thirdly, I recall more Z80 processors are produced today the= n in the days of the microcomputer. Moore's law can be used to increase= performance or reduce price.

Interestingly, the NSA is no stranger to this issue. Suite B= did not use the highest security for everything, presumably for performanc= e reasons. In some cases the US Army uses very breakable ciphers, because t= he alternative is no cipher and the material isn't that sensitive.=C2= =A0 (If the message is "Attack at dawn", decrypting at 9 am isn&#= 39;t terribly helpful to the enemy)

In conclusion performance still matters.

Sincerely,
Watson Ladd
>
> =C2=A0
>
> =C2=A0
>
> ----------------+-------------------------------------------------- >
> Kevin M. Igoe=C2=A0=C2=A0 | "We can't solve problems by using= the same kind
>
>kmigoe@nsa.gov=C2=A0 | of thinkin= g we used when we created them."
>
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0|=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - Albert Einstein -
>
> ----------------+-------------------------------------------------- >
> =C2=A0
>
>
> _______________________________________________
> Cfrg mailing list
>Cfrg@irtf.org
>http://www.irtf.o= rg/mailman/listinfo/cfrg
>

--e89a8f642b46c4e1640505dfa302-- From nobody Mon Oct 20 12:50:07 2014 Return-Path: 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 80C521ACD45 for ; Mon, 20 Oct 2014 12:50:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.013 X-Spam-Level: X-Spam-Status: No, score=-5.013 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 bGN4Ic4v7YQc for ; Mon, 20 Oct 2014 12:50:03 -0700 (PDT) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18EF51ACD44 for ; Mon, 20 Oct 2014 12:50:03 -0700 (PDT) Received: from host91-242-static.240-95-b.business.telecomitalia.it ([95.240.242.91] helo=[192.168.1.105]) by jay.w3.org with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1XgIxt-0004bP-Kr for cfrg@irtf.org; Mon, 20 Oct 2014 15:50:01 -0400 Message-ID: <54456762.7090606@w3.org> Date: Mon, 20 Oct 2014 21:49:54 +0200 From: Harry Halpin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: cfrg@irtf.org References: In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/u9WEJ15bxZrv7jXMMm93TbNopT0 Subject: [Cfrg] W3C WebCrypto WG Liasioning [was Re: ECC reboot (Was: When's the decision?)] X-BeenThere: cfrg@irtf.org 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: Mon, 20 Oct 2014 19:50:05 -0000 Note that there has been a vigorous discussion over exposing whatever curves the CFRG recommends to the IETF TLS WG as part of the W3C WebCryto API. For those who are interested, see here: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25839 https://www.w3.org/Bugs/Public/show_bug.cgi?id=25618 In particular, there is debate over extensions for ECC curves for WebCrypto, which currently only the NIST curves. Developers have requested non-NIST curves during our public "Last Call" review. The opinions in the Working Group are wide-ranging. Microsoft has already provided a change request for the NUMS curve and Trevor Perrin has provided an extension spec for Curve 25519. With my W3C hat on, I'm just going to announce that due to this situation there's a possible dependency with WebCrypto on this decision. Since W3C has a rather strict process and timetable for Working Groups, knowing the precise schedule for the decision helps our process run smoother and allows us to co-ordinate our schedule. cheers, harry On 10/16/2014 06:08 PM, Paterson, Kenny wrote: > Dear all, > > Watson rightly pointed out that we are far behind the originally > advertised schedule for our process for selection of curves to recommend > to the TLS WG. Other parties in and beyond IETF are waiting on our > recommendations too. > > The reasons for the delay are quite complex, and I won't go into reviewing > them here. Suffice to say we've had a lot of really informative technical > discussion about performance of the different options, benchmarking, etc, > so the slippage has not exactly been wasted. > > Our first task should be to finalise the requirements that we will use to > guide the selection process. I think we are close, with a couple of > outstanding issues: > > 1. Amount of "wiggle room" that should be permitted. > > 2. A more nuanced set of hardware requirements. > > > I suggest we use the next *week* to try to finalise the requirements, and > then November to evaluate the candidates that we currently have (along > with any new candidates that might emerge) against the final set of > requirements. > > With this schedule, we'd miss the IETF 91 meeting for our decision, but I > don't think having our answer by mid-Novmeber is really feasible. We > should certainly be able to deliver an early Christmas present to the TLS > WG. > > To make this work, we'd need the RG to focus on the requirements for a > short additional period of time. > > So here's a proposal for a new schedule which I believe to be feasible: > > 24/10/14 (1 week from now): we finalise requirements, including hardware > requirements. > 31/10/14 (2 weeks from now): we agree on whatever benchmarking system > we're going to use for performance measurements. (Right now, supercop > seems like the front runner to me.) > 30/11/14 (6 weeks from now): we deliver our recommendations to the TLS WG. > > Could people let me know if this looks workable, within the next 24-48 > hours? Meantime, I'll send a message indicating where things stand on the > requirements list. > > Thanks > > Kenny > > > On 06/10/2014 16:26, "Watson Ladd" wrote: > >> Dear all, >> We were promised on July 27 a process running for 6 weeks. Doubling I >> get 12 weeks, which is three months, of which two (August, September) >> have already gone. Am I correct in supposing that we're on track for a >> decision by Halloween? >> >> If we aren't, what remaining issues need to be addressed/when can we >> expect a decision? >> >> Sincerely, >> Watson Ladd >> >> _______________________________________________ >> Cfrg mailing list >> Cfrg@irtf.org >> http://www.irtf.org/mailman/listinfo/cfrg > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg > From nobody Mon Oct 20 13:01:55 2014 Return-Path: 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 F28981ACDB0 for ; Mon, 20 Oct 2014 13:01:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no 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 iHkx8nLAZxUt for ; Mon, 20 Oct 2014 13:01:48 -0700 (PDT) Received: from mail-lb0-x232.google.com (mail-lb0-x232.google.com [IPv6:2a00:1450:4010:c04::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BE471ACDA9 for ; Mon, 20 Oct 2014 13:01:47 -0700 (PDT) Received: by mail-lb0-f178.google.com with SMTP id w7so4500233lbi.23 for ; Mon, 20 Oct 2014 13:01:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=h4ZU6YmVgYCbfrgLD22lNjlcD0ubDax6RjptSLM4/cI=; b=ZwYm31pbIH55H1IkIx+ORL/CXD8uXUesT9+xiwzBjvsCUgFLt3/DTqi1sD/tCIutsD iwZ/9dslgkvwO/biRyt/dL8Pv7OGng7y4V3LC26p7852/Cp0ghC81qARxx1KJ9d2NGBH DVgdejVbu6qXJkaMetobOZgOK9OfYQ0ddXuKL+70NfyyALhiHwglx2zbz01tNkeqgbyD HZCRNAkIK3Keg/R3lozXnIuxuXzOJ5n7SRB80JW/jzQGPH2uNuX+uw8afqt757QEDMFi z+l1K34ywfxxwq2ORg08nGD4OTyJyAokG8SXBzwc5jQUOXPBcDAWIwyZYwoXzA3sste0 D3oA== MIME-Version: 1.0 X-Received: by 10.112.221.226 with SMTP id qh2mr30004533lbc.5.1413835304556; Mon, 20 Oct 2014 13:01:44 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.66.196 with HTTP; Mon, 20 Oct 2014 13:01:44 -0700 (PDT) In-Reply-To: References: <3C4AAD4B5304AB44A6BA85173B4675CABC705962@MSMR-GH1-UEA03.corp.nsa.gov> Date: Mon, 20 Oct 2014 16:01:44 -0400 X-Google-Sender-Auth: P3Rs1PC7V0P9IxLGPs_tMTuzqaE Message-ID: From: Phillip Hallam-Baker To: Watson Ladd Content-Type: multipart/alternative; boundary=001a1135ecb81960330505e02ff6 Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/YJNDAyjdqGkPjcR2y24hJodCBaQ Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] When in doubt, err on the side of security X-BeenThere: cfrg@irtf.org 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: Mon, 20 Oct 2014 20:01:51 -0000 --001a1135ecb81960330505e02ff6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Oct 20, 2014 at 3:22 PM, Watson Ladd wrote: > > On Oct 20, 2014 11:37 AM, "Igoe, Kevin M." wrote: > > > > Once a security primitive has been selected, Moore=E2=80=99s law will n= aturally > improve its > > > > performance with the passage of time. But Moore=E2=80=99s law and adv= ances in > > > > cryptanalysis will only erode its security (measured in the money neede= d > to run > > > > the attack). Bottom line: err on the side of security. > > Truisms like that are rarely helpful, and this is no exception. First, > Moores law amplifies, not erases, performance issuses: users want to do > more with cheaper crypto. How much this matters is an economic question. > Sadly we've already ruled out the fastest options for somewhat decent > reasons, as a glance at eBATS will show. > > The second issue is that the choice between performance and security is > made worse by the absence of intermediate options. An organization that > strained and strained to get adequate performance out of ed448goldilocks > isn't made more secure by a standard only offering a 521 bit and 256 bit > curve, as they will reduce security to get adequate performance. The > tradeoff doesn't need to be that extreme for this to happen. > > I haven't seen good arguments for approving two curves at the far ends of > the performance scale, instead of picking inflection points where a small > increase in time yields a large increase in security. What I've seen is > arguments that ignore the revealed preferences of users. > We didn't. We picked one point that was comfortably above being broken using any current or future computer or network of computers built using conventional computing gates using known algorithms. Then we picked another point that gave roughly the square of the work factor of the first. There is no security/performance tradeoff above the ~256 bit level. The point of going for those extra bits is to put the question beyond any feasible doubt. So this argument would make sense if we were talking about something faster than Curve25519. But I don't think anyone is. --001a1135ecb81960330505e02ff6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Oct 20, 2014 at 3:22 PM, Watson Ladd <watsonbladd@gmail.co= m> wrote:
=


On Oct 20, 2014 11:37 AM, "Igoe, Kevin M." <kmigoe@nsa.gov> wrote:
>
> Once a security primitive has been selected, Moore=E2=80=99s law will = naturally improve its
>
> performance with the passage of time.=C2=A0 =C2=A0But Moore=E2=80=99s = law and advances in
>
> cryptanalysis will only erode its security (measured in the money need= ed to run
>
> the attack).=C2=A0 Bottom line: err on the side of security.

Truisms like that are rarely helpful, and this is no = exception. First, Moores law amplifies, not erases, performance issuses: us= ers want to do more with cheaper crypto. How much this matters is an econom= ic question. Sadly we've already ruled out the fastest options for some= what decent reasons, as a glance at eBATS will show.

The second issue is that the choice between performance and = security is made worse by the absence of intermediate options. An organizat= ion that strained and strained to get adequate performance out of ed448gold= ilocks isn't made more secure by a standard only offering a 521 bit and= 256 bit curve, as they will reduce security to get adequate performance. T= he tradeoff doesn't need to be that extreme for this to happen.

I haven't seen good arguments for approving two curves a= t the far ends of the performance scale, instead of picking inflection poin= ts where a small increase in time yields a large increase in security. What= I've seen is arguments that ignore the revealed preferences of users.<= /p>


We didn't. We picked one point that= was comfortably above being broken using any current or future computer or= network of computers built using conventional computing gates using known = algorithms. Then we picked another point that gave roughly the square of th= e work factor of the first.

There is no security/p= erformance tradeoff above the ~256 bit level. The point of going for those = extra bits is to put the question beyond any feasible doubt.

=
So this argument would make sense if we were talking about somet= hing faster than Curve25519. But I don't think anyone is.

--001a1135ecb81960330505e02ff6-- From nobody Mon Oct 20 13:33:22 2014 Return-Path: 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 4EFCC1ACE24 for ; Mon, 20 Oct 2014 13:33:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 4ABlGBM0kQqQ for ; Mon, 20 Oct 2014 13:33:19 -0700 (PDT) Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4C911ACE15 for ; Mon, 20 Oct 2014 13:33:18 -0700 (PDT) Received: by mail-la0-f54.google.com with SMTP id gm9so4592253lab.41 for ; Mon, 20 Oct 2014 13:33:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=/nrQtbdenln+ZNhFGuOun08U2p2KDApCjQD7UfhaUfs=; b=Hlop6lV8DzA60bw9QtiK/lCV7zyemlfDU4Q5Qnyi7uGpqFQAe63l6TjI+zfIVjFBoF vqw7GBYN6WmYkJ5YBsqzHP1bj88W467TO9mQxGOLt9xbcyo6G+KfxyLcZN+YUFFeIiG7 DjLSy9iqwc/4/rWQel2EcvDCNmUzp7zCCeF4/9RxMSBb2LAKuanJegAuYwuSvyu3Lb0c BnocMavuK5NpIv95XfikH/3nAoaxsFANoWBxMTzfkcxiLLNxAHYKR6hrCQfc21SfppPd oblIiYS8DK9wmQWZUrXjVEcSOZ2yOp6ksLt59cRtgK/XnMpDoeIpedbbWdoBpQ9NCaGf EjUA== X-Received: by 10.152.204.103 with SMTP id kx7mr30102988lac.7.1413837196706; Mon, 20 Oct 2014 13:33:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.218.145 with HTTP; Mon, 20 Oct 2014 13:32:56 -0700 (PDT) In-Reply-To: References: <3C4AAD4B5304AB44A6BA85173B4675CABC705962@MSMR-GH1-UEA03.corp.nsa.gov> From: David Leon Gil Date: Mon, 20 Oct 2014 16:32:56 -0400 Message-ID: To: Watson Ladd Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/POXprlmUnAypdeh3IVqJjFJAvGM Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] When in doubt, err on the side of security X-BeenThere: cfrg@irtf.org 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: Mon, 20 Oct 2014 20:33:20 -0000 On Mon, Oct 20, 2014 at 3:22 PM, Watson Ladd wrote: > The second issue is that the choice between performance and security is m= ade > worse by the absence of intermediate options. An organization that strain= ed > and strained to get adequate performance out of ed448goldilocks What organization has strained and strained to get more performance out of Ed448? Or Curve25519, for that matter? On Mon, Oct 20, 2014 at 2:37 PM, Igoe, Kevin M. wrote: > Once a security primitive has been selected, Moore=E2=80=99s law will nat= urally improve > its performance with the passage of time. But Moore=E2=80=99s law and a= dvances in > cryptanalysis will only erode its security [ . . . ] Proposal: Pick curve bit-length based on a fixed latency budget; say, 1 ms. Each semiconductor node, increase bit-length as much as necessary to keep latency the same. Security is asymptotically guaranteed. The CFRG could start by recommending a curve over Fq(2^4062-17), rather tha= n any of this nonsense about Fq(2^414-17) etc. From nobody Mon Oct 20 13:38:30 2014 Return-Path: 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 72D091ACE53 for ; Mon, 20 Oct 2014 13:38:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no 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 l5CWTHbKHmTW for ; Mon, 20 Oct 2014 13:38:17 -0700 (PDT) Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A0CE1ACE41 for ; Mon, 20 Oct 2014 13:38:16 -0700 (PDT) Received: by mail-lb0-f177.google.com with SMTP id w7so4598029lbi.36 for ; Mon, 20 Oct 2014 13:38:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=yQBD/f3c1J0fEIERxt911y1QLdRDyLGG64dWaKytM9I=; b=P8g8Zkpuv/tEgbYopY8gxpuzkdF8ip22huMhvKNAlp4aaclX6UNDPzYZzugbrMxb1h b1Oa9zFbJ5TUak9YXXrbjmns6vG3DvmWaWI/V6aUtfHVZAlOXCQZ4bau044zTP46gGn+ 25GQ/EgtUCUUl9kPbgBZ0UyOsVEpBgx3LKWcACy7/NLdBuvA1N5RJOzS8rFgZbxmNHMR ZcJ2rc+ut4cCwhA1+a3hmm6poDti7PESKRHol2hfAHgcZvSnxy3V7U2QkceqO6k/w5SH PPwizYsqnz4CUhsBfD+UsyT75uqenkxtZgiYIPsDLT5W3xyZClz680CLtkKuxEMQBOi2 rOZA== MIME-Version: 1.0 X-Received: by 10.112.134.39 with SMTP id ph7mr29963630lbb.45.1413837494740; Mon, 20 Oct 2014 13:38:14 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.66.196 with HTTP; Mon, 20 Oct 2014 13:38:14 -0700 (PDT) In-Reply-To: References: <3C4AAD4B5304AB44A6BA85173B4675CABC705962@MSMR-GH1-UEA03.corp.nsa.gov> Date: Mon, 20 Oct 2014 16:38:14 -0400 X-Google-Sender-Auth: DSOvaseijpFsEfL8FJc27_-zc88 Message-ID: From: Phillip Hallam-Baker To: David Leon Gil Content-Type: multipart/alternative; boundary=047d7b344184a4eec20505e0b161 Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/MO0KUVr1C9xjChao8MehHXNeEjQ Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] When in doubt, err on the side of security X-BeenThere: cfrg@irtf.org 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: Mon, 20 Oct 2014 20:38:18 -0000 --047d7b344184a4eec20505e0b161 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I don't understand the constraint suggested. In practice the performance of public key is not particularly critical. If you want really fast then use symmetric key. The only time that you ever need public key is to establish a trust relationship. Other than the Web, which is a far outlier, what synchronous protocol do we have where negotiating keys synchronously is a hard requirement? Certainly not email, nor chat. And if we get into money then we can solve problems by spending our way out. On Mon, Oct 20, 2014 at 4:32 PM, David Leon Gil wrote: > On Mon, Oct 20, 2014 at 3:22 PM, Watson Ladd > wrote: > > The second issue is that the choice between performance and security is > made > > worse by the absence of intermediate options. An organization that > strained > > and strained to get adequate performance out of ed448goldilocks > > What organization has strained and strained to get more performance out > of Ed448? Or Curve25519, for that matter? > > On Mon, Oct 20, 2014 at 2:37 PM, Igoe, Kevin M. wrote: > > Once a security primitive has been selected, Moore=E2=80=99s law will n= aturally > improve > > its performance with the passage of time. But Moore=E2=80=99s law and= advances > in > > cryptanalysis will only erode its security [ . . . ] > > Proposal: Pick curve bit-length based on a fixed latency budget; say, 1 m= s. > Each semiconductor node, increase bit-length as much as necessary to > keep latency the same. > > Security is asymptotically guaranteed. > > The CFRG could start by recommending a curve over Fq(2^4062-17), rather > than > any of this nonsense about Fq(2^414-17) etc. > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg > --047d7b344184a4eec20505e0b161 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I don't understand the constraint suggested.

<= /div>
In practice the performance of public key is not particularly cri= tical. If you want really fast then use symmetric key. The only time that y= ou ever need public key is to establish a trust relationship. Other than th= e Web, which is a far outlier, what synchronous protocol do we have where n= egotiating keys synchronously is a hard requirement?

Certainly not email, nor chat. And if we get into money then we can solv= e problems by spending our way out.
<= br>
On Mon, Oct 20, 2014 at 4:32 PM, David Leon G= il <coruus@gmail.com> wrote:
On Mon, Oct 20, 2014 at 3:22 PM, Watson Ladd <watsonbladd@gmail.com> wrote:
> The second issue is that the choice between pe= rformance and security is made
> worse by the absence of intermediate options. An organization that str= ained
> and strained to get adequate performance out of ed448goldilocks

What organization has strained and strained to get more performance = out
of Ed448? Or Curve25519, for that matter?

On Mon, Oct 20, 2014 at 2:37 PM, Igoe, Kevin M. <kmigoe@nsa.gov> wrote:
> Once a security primitive has been selected, Moore=E2=80=99s law will = naturally improve
> its performance with the passage of time.=C2=A0 =C2=A0But Moore=E2=80= =99s law and advances in
> cryptanalysis will only erode its security [ . . . ]

Proposal: Pick curve bit-length based on a fixed latency budget; say, 1 ms.=
Each semiconductor node, increase bit-length as much as necessary to
keep latency the same.

Security is asymptotically guaranteed.

The CFRG could start by recommending a curve over Fq(2^4062-17), rather tha= n
any of this nonsense about Fq(2^414-17) etc.

_______________________________________________
Cfrg mailing list
Cfrg@irtf.org
htt= p://www.irtf.org/mailman/listinfo/cfrg

--047d7b344184a4eec20505e0b161-- From nobody Mon Oct 20 14:24:52 2014 Return-Path: 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 1FD181ACEE5 for ; Mon, 20 Oct 2014 14:24:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.501 X-Spam-Level: X-Spam-Status: No, score=-0.501 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, 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 d43m5zV3Y_nw for ; Mon, 20 Oct 2014 14:24:46 -0700 (PDT) Received: from emh02.mail.saunalahti.fi (emh02.mail.saunalahti.fi [62.142.5.108]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B6621ACEE2 for ; Mon, 20 Oct 2014 14:24:45 -0700 (PDT) Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh02.mail.saunalahti.fi (Postfix) with ESMTP id 2285881A2C for ; Tue, 21 Oct 2014 00:24:42 +0300 (EEST) Date: Tue, 21 Oct 2014 00:24:41 +0300 From: Ilari Liusvaara To: cfrg@irtf.org Message-ID: <20141020212441.GA23673@LK-Perkele-VII> References: <20141018203017.23023.qmail@cr.yp.to> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20141018203017.23023.qmail@cr.yp.to> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/O_4GUOIi7UUKS5PqAgtHCU1mKp0 Subject: Re: [Cfrg] ed448goldilocks vs. numsp384t1 and numsp512t1 X-BeenThere: cfrg@irtf.org 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: Mon, 20 Oct 2014 21:24:50 -0000 On Sat, Oct 18, 2014 at 08:30:17PM -0000, D. J. Bernstein wrote: > Michael Hamburg writes: > > I didn’t do this last time, which is (part of?) why the numbers from > > my own benchmarks do not match DJB’s numbers; see below. > > Numbers are now coming into eBATS (see http://bench.cr.yp.to) for Mike's > fixed ed448goldilocks software, and confirm what Mike said about speed > compared to Microsoft's claimed speed. Here's the updated comparison > chart on Sandy Bridge, the microarchitecture selected by Microsoft for > benchmarks in http://eprint.iacr.org/2014/130.pdf: > > 617000 cycles claimed: numsp384t1 (ed-384-mers), ~2^192 security. > 666544 cycles measured on h6sandy: ed448goldilocks, ~2^224 security. > 1293000 cycles claimed: numsp512t1 (ed-512-mers), ~2^256 security. IIRC, Mike has said that Ed448 software is not quite optimized as far as it would go. Also, these all are apples-to-apples comparisions (either all uncompressed or all compressed), right? > These DH ratios don't _perfectly_ predict ratios for other operations--- > the instruction mix changes, and speeds of other operations depend on > choices of precomputed table size---but at this point it's unsurprising > to see ed448goldilocks close to numsp384t1 for signature generation: > > 231000 cycles claimed: numsp384t1 (ed-384-mers), ~2^192 security. > 234844 cycles measured on h6sandy: ed448goldilocks, ~2^224 security. > 446000 cycles claimed: numsp512t1 (ed-512-mers), ~2^256 security. > > Also signature verification: > > 624000 cycles claimed: numsp384t1 (ed-384-mers), ~2^192 security. > 729152 cycles measured on h6sandy: ed448goldilocks, ~2^224 security. > 1320000 cycles claimed: numsp512t1 (ed-512-mers), ~2^256 security. Here Ed448 seems to be slightly slow for some reason. I would have estimated (on very dubious grounds) ~680k. -Ilari From nobody Mon Oct 20 15:48:56 2014 Return-Path: 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 A011A1ACF93 for ; Mon, 20 Oct 2014 15:48:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.555 X-Spam-Level: * X-Spam-Status: No, score=1.555 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.982, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no 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 zb-sgG0b8ucJ for ; Mon, 20 Oct 2014 15:48:53 -0700 (PDT) Received: from aspartame.shiftleft.org (199-116-74-168-v301.PUBLIC.monkeybrains.net [199.116.74.168]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C0291ACF90 for ; Mon, 20 Oct 2014 15:48:52 -0700 (PDT) Received: from [10.184.148.249] (unknown [209.36.6.242]) by aspartame.shiftleft.org (Postfix) with ESMTPSA id 7E7B0F5EAE; Mon, 20 Oct 2014 15:46:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=shiftleft.org; s=sldo; t=1413845197; bh=/LGjfmzZLQssmcsjgPeYwJPUW32zAoo2P8g6TwAlRGk=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=guCaepM6569UJCl+v8k78TutC3k8zg/Yv1A0yS9Q8eYYimFLgYB7BhIe2pVwNvvqG lsbE/otIw6ZXTmkwi0wddp6eu9k8Q/9JJPIK83xikjwcSR2Ln3by8se7A4DOvILaFD NGl0IRF4faTmNAskCZzR4uNLmLzh/LGyUNe1312c= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Michael Hamburg In-Reply-To: <20141020212441.GA23673@LK-Perkele-VII> Date: Mon, 20 Oct 2014 15:48:48 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <45033A8A-0702-480B-86D7-78CB9A93359B@shiftleft.org> References: <20141018203017.23023.qmail@cr.yp.to> <20141020212441.GA23673@LK-Perkele-VII> To: Ilari Liusvaara X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/tkZLDwUQIOrJjEAiulQsJ5EFmKU Cc: cfrg@irtf.org Subject: Re: [Cfrg] ed448goldilocks vs. numsp384t1 and numsp512t1 X-BeenThere: cfrg@irtf.org 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: Mon, 20 Oct 2014 22:48:54 -0000 > On Oct 20, 2014, at 2:24 PM, Ilari Liusvaara = wrote: >=20 > On Sat, Oct 18, 2014 at 08:30:17PM -0000, D. J. Bernstein wrote: >> Michael Hamburg writes: >>> I didn=E2=80=99t do this last time, which is (part of?) why the = numbers from >>> my own benchmarks do not match DJB=E2=80=99s numbers; see below. >>=20 >> Numbers are now coming into eBATS (see http://bench.cr.yp.to) for = Mike's >> fixed ed448goldilocks software, and confirm what Mike said about = speed >> compared to Microsoft's claimed speed. Here's the updated comparison >> chart on Sandy Bridge, the microarchitecture selected by Microsoft = for >> benchmarks in http://eprint.iacr.org/2014/130.pdf: >>=20 >> 617000 cycles claimed: numsp384t1 (ed-384-mers), ~2^192 = security. >> 666544 cycles measured on h6sandy: ed448goldilocks, ~2^224 = security. >> 1293000 cycles claimed: numsp512t1 (ed-512-mers), ~2^256 = security. >=20 > IIRC, Mike has said that Ed448 software is not quite optimized as far > as it would go. Maybe not "as far as it would go=E2=80=9D, but those numbers are for = recent, optimized code, and fixes to the bug which was holding it back = in previous SUPERCOP benchmarks. > Also, these all are apples-to-apples comparisions (either all = uncompressed > or all compressed), right? No, Goldilocks is compressed and NUMS is uncompressed. I=E2=80=99ll see if I can get (possibly untwisted) NUMS curves working = in the Goldilocks source tree, which would make a slightly more = apples-to-apples comparison. >> These DH ratios don't _perfectly_ predict ratios for other = operations--- >> the instruction mix changes, and speeds of other operations depend on >> choices of precomputed table size---but at this point it's = unsurprising >> to see ed448goldilocks close to numsp384t1 for signature generation: >>=20 >> 231000 cycles claimed: numsp384t1 (ed-384-mers), ~2^192 = security. >> 234844 cycles measured on h6sandy: ed448goldilocks, ~2^224 = security. >> 446000 cycles claimed: numsp512t1 (ed-512-mers), ~2^256 = security. >>=20 >> Also signature verification: >>=20 >> 624000 cycles claimed: numsp384t1 (ed-384-mers), ~2^192 = security. >> 729152 cycles measured on h6sandy: ed448goldilocks, ~2^224 = security. >> 1320000 cycles claimed: numsp512t1 (ed-512-mers), ~2^256 = security. >=20 > Here Ed448 seems to be slightly slow for some reason. >=20 > I would have estimated (on very dubious grounds) ~680k. >=20 > -Ilari It=E2=80=99s due in large part to point decompression. Point = compression costs about the same as affine serialization. For signing, Goldilocks needs to compress points but not decompress = them, so it doesn=E2=80=99t take a speed penalty. Also, its precomputed = tables are slightly bigger than the ECCLib tables. On the other hand, = the signature is a bit slower than I=E2=80=99d have guessed; it might = just be that the constant-time selection is vectorized, and SBR = doesn=E2=80=99t have AVX2 and so uses SSE2 instead. For ECDH, Goldilocks uses the Montgomery ladder, which avoids = decompression at the cost of a slightly slower scalarmul. So it has a = small disadvantage vs ECCLib. For verification, Goldilocks has to decompress and ECCLib doesn=E2=80=99t,= which costs almost 10%. Cheers, =E2=80=94 Mike= From nobody Tue Oct 21 01:32:40 2014 Return-Path: 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 AFF861A03D0 for ; Tue, 21 Oct 2014 01:32:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.859 X-Spam-Level: X-Spam-Status: No, score=-3.859 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=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 QkUrdnxcz6TY for ; Tue, 21 Oct 2014 01:32:34 -0700 (PDT) Received: from m2-bln.bund.de (m2-bln.bund.de [77.87.224.106]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D4EB1A00D7 for ; Tue, 21 Oct 2014 01:27:28 -0700 (PDT) Received: from m2.mfw.bln.ivbb.bund.de (localhost.mfw.bln.ivbb.bund.de [127.0.0.1]) by m2-bln.bund.de (8.14.3/8.14.3) with ESMTP id s9L8RPuh005162 for ; Tue, 21 Oct 2014 10:27:26 +0200 (CEST) Received: (from localhost) by m2.mfw.bln.ivbb.bund.de (MSCAN) id 5/m2.mfw.bln.ivbb.bund.de/smtp-gw/mscan; Tue Oct 21 10:27:25 2014 X-P350-Id: 2230c75a3228f050 X-Virus-Scanned: by amavisd-new at bsi.bund.de From: "Lochter, Manfred" Organization: BSI Bonn To: cfrg@irtf.org Date: Tue, 21 Oct 2014 10:27:13 +0200 User-Agent: KMail/1.9.10 (enterprise35 20140205.23bb19c) References: <842BF4E0-8132-42F6-BDE6-65717E004006@shiftleft.org> <54418A8F.3090506@cs.tcd.ie> In-Reply-To: <54418A8F.3090506@cs.tcd.ie> X-KMail-QuotePrefix: > MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-ID: <201410211027.13608.manfred.lochter@bsi.bund.de> X-AntiVirus: checked by Avira MailGate (version: 3.2.1.26; AVE: 8.3.24.38; VDF: 7.11.180.32; host: sgasmtp2.bsi.de); id=15570-jXRvY6 Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/eGzjAoENL-2wPiTe-rEZCbXFhjQ Subject: Re: [Cfrg] ECC reboot (Was: When's the decision?) X-BeenThere: cfrg@irtf.org 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: Tue, 21 Oct 2014 08:32:37 -0000 __________ urspr=C3=BCngliche Nachricht __________ Von: Stephen Farrell Datum: Freitag, 17. Oktober 2014, 23:30:55 An: Michael Hamburg Kopie: "cfrg@irtf.org" Betr.: Re: [Cfrg] ECC reboot (Was: When's the decision?) > On 17/10/14 18:58, Michael Hamburg wrote: > > So is the thrust of this whole argument =E2=80=9Chave your special curv= es, > > but make Brainpool mandatory to implement=E2=80=9D? If so, just say so= , and > > let the forum discuss it separately, and unblock the discussion of > > new curves. > > If that were the case then CFRG would be the wrong forum. Which algs > are MTI for which IETF protocols is an IETF issue. > > S. > I can assure you that this is not the case. The Brainpool paper=20 eprint.iacr.org/2014/832 discusses selection criteria for secure elliptic=20 curves and their use. We basically look at different attack models and deri= ve=20 requirements on secure elliptic curves. (A very simplistic way of describin= g=20 the attack models is HW vs. SW). In my understandig that is exactly the topic of the cfrg discussion. =20 Actually, we do not even propose that the cfrg choose the Brainpool curves,= we=20 just propose to generate two sets of curves, one using special primes and o= ne=20 using special primes. Here we assume the generation process to be a trusted= =20 pocess. We also note that a flexible approach that allows an easy replaceme= nt=20 of curves is very desirable. As the cfrg also discusses parameter lengths I would like to add that it i= s=20 completely adequate to use 384 bit curves even for highest security demands= =2E=20 So, 384 bit curves must be included in any proposed set of curves. Manfred > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg =2D-=20 Lochter, Manfred =2D------------------------------------------- Bundesamt f=C3=BCr Sicherheit in der Informationstechnik (BSI) Referat K21 Godesberger Allee 185 -189 53175 Bonn Postfach 20 03 63 53133 Bonn Telefon: +49 (0)228 99 9582 5643 Telefax: +49 (0)228 99 10 9582 5643 E-Mail: manfred.lochter@bsi.bund.de Internet: www.bsi.bund.de www.bsi-fuer-buerger.de From nobody Tue Oct 21 02:05:36 2014 Return-Path: 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 782141A0149 for ; Tue, 21 Oct 2014 02:05:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 qhk1l-Yw8krW for ; Tue, 21 Oct 2014 02:05:33 -0700 (PDT) Received: from emh07.mail.saunalahti.fi (emh07.mail.saunalahti.fi [62.142.5.117]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 467651A017D for ; Tue, 21 Oct 2014 02:05:33 -0700 (PDT) Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh07.mail.saunalahti.fi (Postfix) with ESMTP id 51639407F; Tue, 21 Oct 2014 12:05:30 +0300 (EEST) Date: Tue, 21 Oct 2014 12:05:29 +0300 From: Ilari Liusvaara To: "Lochter, Manfred" Message-ID: <20141021090529.GA12154@LK-Perkele-VII> References: <842BF4E0-8132-42F6-BDE6-65717E004006@shiftleft.org> <54418A8F.3090506@cs.tcd.ie> <201410211027.13608.manfred.lochter@bsi.bund.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <201410211027.13608.manfred.lochter@bsi.bund.de> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/PdWB5DbiUAg90mnQsp3goL2sJew Cc: cfrg@irtf.org Subject: Re: [Cfrg] ECC reboot (Was: When's the decision?) X-BeenThere: cfrg@irtf.org 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: Tue, 21 Oct 2014 09:05:35 -0000 On Tue, Oct 21, 2014 at 10:27:13AM +0200, Lochter, Manfred wrote: > > Actually, we do not even propose that the cfrg choose the Brainpool curves, we > just propose to generate two sets of curves, one using special primes and one > using special primes. Here we assume the generation process to be a trusted > pocess. We also note that a flexible approach that allows an easy replacement > of curves is very desirable. You mean pseudorandom primes and special primes, right? And what would advantage of generating a new pseudorandom set be, compared to just using Brainpool if pseudorandom primes are needed? I don't see any advantage (at least based on properties you have claimed to be desirable and properties you have claimed for Brainpool to have). Nor do I see such curves would be used much in practice. > As the cfrg also discusses parameter lengths I would like to add that it is > completely adequate to use 384 bit curves even for highest security demands. > So, 384 bit curves must be included in any proposed set of curves. Not if you can get more security at less or equal cost. There are some above- 384bit primes with very good performance (there doesn't seem to be that good primes near 384bit). -Ilari From nobody Tue Oct 21 02:28:55 2014 Return-Path: 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 964D21A03D0 for ; Tue, 21 Oct 2014 02:28:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.559 X-Spam-Level: X-Spam-Status: No, score=-6.559 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=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 MSNmDI-u0gkE for ; Tue, 21 Oct 2014 02:28:50 -0700 (PDT) Received: from m2-bln.bund.de (m2-bln.bund.de [77.87.224.106]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEE6B1A03F9 for ; Tue, 21 Oct 2014 02:28:05 -0700 (PDT) Received: from m2.mfw.bln.ivbb.bund.de (localhost.mfw.bln.ivbb.bund.de [127.0.0.1]) by m2-bln.bund.de (8.14.3/8.14.3) with ESMTP id s9L9S3uL015534 for ; Tue, 21 Oct 2014 11:28:03 +0200 (CEST) Received: (from localhost) by m2.mfw.bln.ivbb.bund.de (MSCAN) id 5/m2.mfw.bln.ivbb.bund.de/smtp-gw/mscan; Tue Oct 21 11:28:03 2014 X-P350-Id: 223139023aa97c54 X-Virus-Scanned: by amavisd-new at bsi.bund.de From: "Lochter, Manfred" Organization: BSI Bonn To: Ilari Liusvaara Date: Tue, 21 Oct 2014 11:27:52 +0200 User-Agent: KMail/1.9.10 (enterprise35 20140205.23bb19c) References: <201410211027.13608.manfred.lochter@bsi.bund.de> <20141021090529.GA12154@LK-Perkele-VII> In-Reply-To: <20141021090529.GA12154@LK-Perkele-VII> X-KMail-QuotePrefix: > MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-ID: <201410211127.53008.manfred.lochter@bsi.bund.de> X-AntiVirus: checked by Avira MailGate (version: 3.2.1.26; AVE: 8.3.24.38; VDF: 7.11.180.32; host: sgasmtp2.bsi.de); id=16878-dlfAKh Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/0TVvQo4c42OYXmaREkXGRzhiFL8 Cc: cfrg@irtf.org Subject: Re: [Cfrg] ECC reboot (Was: When's the decision?) X-BeenThere: cfrg@irtf.org 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: Tue, 21 Oct 2014 09:28:52 -0000 __________ urspr=C3=BCngliche Nachricht __________ Von: Ilari Liusvaara Datum: Dienstag, 21. Oktober 2014, 11:05:29 An: "Lochter, Manfred" Kopie: cfrg@irtf.org Betr.: Re: [Cfrg] ECC reboot (Was: When's the decision?) > On Tue, Oct 21, 2014 at 10:27:13AM +0200, Lochter, Manfred wrote: > > Actually, we do not even propose that the cfrg choose the Brainpool > > curves, we just propose to generate two sets of curves, one using speci= al > > primes and one using special primes. Here we assume the generation > > process to be a trusted pocess. We also note that a flexible approach > > that allows an easy replacement of curves is very desirable. > > You mean pseudorandom primes and special primes, right? Yes. Thank you! > > And what would advantage of generating a new pseudorandom set be, compared > to just using Brainpool if pseudorandom primes are needed? I strongly believe that pseudorandom primes are needed. There is no immedia= te=20 advantage in generating new curves. The proposal to generate new curves has= =20 two main driving factors. a) We want to be open to an approach where an widely agreed generation meth= od=20 is used. b) The original Brainpool curves have falsely been discredited in the=20 BADA55-paper. > > I don't see any advantage (at least based on properties you have claimed = to > be desirable and properties you have claimed for Brainpool to have). Nor = do > I see such curves would be used much in practice. Is this opinion based on our papers or on the discussion within cfrg? > > > As the cfrg also discusses parameter lengths I would like to add that = it > > is completely adequate to use 384 bit curves even for highest security > > demands. So, 384 bit curves must be included in any proposed set of > > curves. > > Not if you can get more security at less or equal cost. There are some > above- 384bit primes with very good performance (there doesn't seem to be > that good primes near 384bit). Here 384 refers to random primes. The main point is that there has been the= =20 proposal to drop 384 (or similar) at all, and to just propose 256 and 512 b= it=20 curves. > > > -Ilari Manfred =2D-=20 Lochter, Manfred =2D------------------------------------------- Bundesamt f=C3=BCr Sicherheit in der Informationstechnik (BSI) Referat K21 Godesberger Allee 185 -189 53175 Bonn Postfach 20 03 63 53133 Bonn Telefon: +49 (0)228 99 9582 5643 Telefax: +49 (0)228 99 10 9582 5643 E-Mail: manfred.lochter@bsi.bund.de Internet: www.bsi.bund.de www.bsi-fuer-buerger.de From nobody Tue Oct 21 04:09:57 2014 Return-Path: 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 6F1BD1A0861 for ; Tue, 21 Oct 2014 04:09:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 J6UxbXav9Agn for ; Tue, 21 Oct 2014 04:09:51 -0700 (PDT) Received: from emh04.mail.saunalahti.fi (emh04.mail.saunalahti.fi [62.142.5.110]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A4CF1A1A6F for ; Tue, 21 Oct 2014 04:09:13 -0700 (PDT) Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh04.mail.saunalahti.fi (Postfix) with ESMTP id 4C3431A268D; Tue, 21 Oct 2014 14:09:11 +0300 (EEST) Date: Tue, 21 Oct 2014 14:09:10 +0300 From: Ilari Liusvaara To: Michael Hamburg Message-ID: <20141021110910.GA17139@LK-Perkele-VII> References: <20141018203017.23023.qmail@cr.yp.to> <20141020212441.GA23673@LK-Perkele-VII> <45033A8A-0702-480B-86D7-78CB9A93359B@shiftleft.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <45033A8A-0702-480B-86D7-78CB9A93359B@shiftleft.org> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/OKMFr6pKGGwrfN-ndV1l1ytxyMs Cc: cfrg@irtf.org Subject: Re: [Cfrg] ed448goldilocks vs. numsp384t1 and numsp512t1 X-BeenThere: cfrg@irtf.org 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: Tue, 21 Oct 2014 11:09:54 -0000 On Mon, Oct 20, 2014 at 03:48:48PM -0700, Michael Hamburg wrote: > > On Oct 20, 2014, at 2:24 PM, Ilari Liusvaara wrote: > > > > On Sat, Oct 18, 2014 at 08:30:17PM -0000, D. J. Bernstein wrote: > > >> Also signature verification: > >> > >> 624000 cycles claimed: numsp384t1 (ed-384-mers), ~2^192 security. > >> 729152 cycles measured on h6sandy: ed448goldilocks, ~2^224 security. > >> 1320000 cycles claimed: numsp512t1 (ed-512-mers), ~2^256 security. > > > > Here Ed448 seems to be slightly slow for some reason. > > > > I would have estimated (on very dubious grounds) ~680k. > > For verification, Goldilocks has to decompress and ECCLib doesn’t, > which costs almost 10%. Signature verification uses double-sclar multiply, right? Is your ds multiply constant-time? Because the one in ECClib apparently isn't (everything else should be). -Ilari From nobody Tue Oct 21 04:40:10 2014 Return-Path: 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 1E2971A1AE0 for ; Tue, 21 Oct 2014 04:40:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 Nu5Hjl91mWw5 for ; Tue, 21 Oct 2014 04:40:04 -0700 (PDT) Received: from mace.cs.uic.edu (mace.cs.uic.edu [131.193.32.224]) by ietfa.amsl.com (Postfix) with SMTP id F0F2E1A1ADF for ; Tue, 21 Oct 2014 04:40:03 -0700 (PDT) Received: (qmail 4604 invoked from network); 21 Oct 2014 11:39:59 -0000 Received: from pcdhz005.win.tue.nl (HELO hyperelliptic.org) (131.155.71.33) by mace.cs.uic.edu with SMTP; 21 Oct 2014 11:39:59 -0000 Received: (qmail 17138 invoked by uid 1000); 21 Oct 2014 11:40:03 -0000 Date: Tue, 21 Oct 2014 13:40:03 +0200 From: Tanja Lange To: "Lochter, Manfred" Message-ID: <20141021114003.GZ5502@cph.win.tue.nl> References: <201410211027.13608.manfred.lochter@bsi.bund.de> <20141021090529.GA12154@LK-Perkele-VII> <201410211127.53008.manfred.lochter@bsi.bund.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201410211127.53008.manfred.lochter@bsi.bund.de> User-Agent: Mutt/1.5.11 Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/LQaObHszAV0n2seaH5ddF5ol6t8 Cc: cfrg@irtf.org Subject: Re: [Cfrg] ECC reboot (Was: When's the decision?) X-BeenThere: cfrg@irtf.org 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: Tue, 21 Oct 2014 11:40:06 -0000 Dear Manfred, On Tue, Oct 21, 2014 at 11:27:52AM +0200, Lochter, Manfred wrote: > b) The original Brainpool curves have falsely been discredited in the > BADA55-paper. > What do you claim to be false in that paper? We show -- and as far as I know are the first to show -- that the approach to generate the BP curves allows the designer of that approach to hide a one-in-a-million weakness in the resulting curve, should he or she have found such a weakness. Regards Tanja From nobody Tue Oct 21 06:13:08 2014 Return-Path: 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 CB24E1A1B6D for ; Tue, 21 Oct 2014 06:13:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.003 X-Spam-Level: X-Spam-Status: No, score=-0.003 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, SPF_HELO_PASS=-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 G_onnEkR2DR4 for ; Tue, 21 Oct 2014 06:13:04 -0700 (PDT) Received: from entima.net (entima.net [78.129.143.175]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8E181A1B4B for ; Tue, 21 Oct 2014 06:13:03 -0700 (PDT) In-Reply-To: <201410211027.13608.manfred.lochter@bsi.bund.de> References: <842BF4E0-8132-42F6-BDE6-65717E004006@shiftleft.org> <54418A8F.3090506@cs.tcd.ie> <201410211027.13608.manfred.lochter@bsi.bund.de> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 From: Alyssa Rowan Date: Tue, 21 Oct 2014 14:12:46 +0100 To: cfrg@irtf.org Message-ID: Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/M4KKwscznuy3NHe1r2o4JS-pS7A Subject: Re: [Cfrg] ECC reboot (Was: When's the decision?) X-BeenThere: cfrg@irtf.org 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: Tue, 21 Oct 2014 13:13:07 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 21 October 2014 09:27:13 BST, "Lochter, Manfred" wrote: >>> [MH] So is the thrust of this whole argument “have your special curves, but make Brainpool mandatory to implement”? If so, just say so, and let the forum discuss it separately, and unblock the discussion of new curves. >> [SF] If that were the case then CFRG would be the wrong forum. Which algs are MTI for which IETF protocols is an IETF issue. > [ML] I can assure you that this is not the case. Actually, we do not even propose that the cfrg choose the Brainpool curves, we just propose to generate two sets of curves, one using special primes and one using [pseudorandom] primes. Here we assume the generation process to be a trusted process. Perhaps I'm confused, or perhaps there's a language barrier? The position paper you posted says that Brainpool wants pseudorandom prime curves, whose description *exactly* matches those of the existing Brainpool curves, but generated via some (unspecified, yet assumed trusted) new process; that you want these alongside special curves; and you want the PSR curves to be mandatory to implement. Um... Wasn't this what Brainpool was for? Don't you already have some? They've got codepoints assigned and everything, and not even all that long ago. The Brainpool hardware stakeholders were quite clear that what they wanted was, basically, Brainpool - which is why I assume they are in Brainpool. We have pointed out that they've already got that, and no change obviously unbeatably minimises the changes to deployed crypto hardware, which they were quite clear was one of their goals! If you wanted another Brainpool: why, and what is stopping Brainpool from doing it? You didn't need to do it here before. You seem to be worried the BADA55 paper discredits the Brainpool curves by showing a plausible way they could have been rigged. It doesn't prove that they actually were rigged (indeed, Brainpool is listed on Safecurves as "somewhat rigid" and still has a tick in that box). Where's the fire? And you aren't clear how you could avoid making enough choices in any new VPR process to address the BADA55 criticisms, because you haven't suggested any new VPR process, just assumed one will exist and be agreed within our timescales. A bold assumption. I'm relatively new, but my understanding is that Stephen is correctly pointing out that mandatory-to-implement anything is way out-of-scope here. We make suggestions, recommendations; downstream WGs in IETF decide whether they have rough consensus to adopt them, and then implementers decide whether they actually care to. I have expressed scepticism that pseudorandom Brainpool-style curves will meet the needs of the TLS WG bringing this request to us. They'll almost certainly come dead last in performance and complexity in most scenarios, and rigidity is, as the BADA55 paper points out, tricky to argue. You haven't refuted that. >As the cfrg also discusses parameter lengths I would like to add that it is completely adequate to use 384 bit curves even for highest security demands. I agree, although there aren't any convenient special primes around that area. (I also think 256 is fine.) >So, 384 bit curves must be included in any proposed set of curves. Um, how does that follow? Do you propose just 256 and 384, then? Or...? Why is 384-bit a must? What's so magical about it? Why not 417? 448? 512? 521? 607? 31337? I'm just not clear about what you want from us, and why you don't already have it. - -- /akr -----BEGIN PGP SIGNATURE----- Version: APG v1.1.1 iQI3BAEBCgAhBQJURlvOGhxBbHlzc2EgUm93YW4gPGFrckBha3IuaW8+AAoJEOyE jtkWi2t6q1wQAKAKuURzrcnzTsvORUS4H/PrBTH1wwFNU5cFAq0KTRsGK4UFj8Rs 8ntzyoJ0lhzQht2puN9BVekby3z9zd0eDUuMMuhsDCMNtrlm8fHS8isKXMhgKJfK tqRz8ps6PtTyKyxYu2oZH7jkplwzMbaGqraYvrgN72knFRv225Yr9fLsF2LCfsMY 86s6JMJremE5jXLkYTAFO3exksBdmSsvNOhUnPBfRYXxNQd/M6nWK3mLTJCZUTaj 7QNeRafcUUQMs6VU2bBvDwhxSMWAbXKsnKnfRM8UBk3v8pILu1xE7KablDRfetgg TeI2Pb8TORlZOO7sEkVRyouuRN4SYt+nwFAlTKwpLDvj7VLMcUfv5G+5Pe/s5P2t 6+IfUtDpbreL8SPNvaj75Hx4LrIBzN1ueCXNLElqJEAZvAJeMsEenGbDy14GAVqM KgGOpeD6qfA1G19tVAj+vuWRjGAnAOHU2Ze18wMJV2E5kfJOYFhY8qMgVFluYHfn i4zVvTZPXFR7WA/ZruSwEQ0TsWK20IHdPtt0cjlQvYIttxipbe9zwQikdaJ2tlg5 qiztfZ1P+CwLQ6aufSgBZ4DaDt5fSvGGmCzpaSatW9NS+GAjlXxSM51RREqKJclf u/LDIvRQ3QoGHSNAONDGW45wSfG0MlaqMo2xJ0ANxozxWcY9TmI5tU9a =cCZj -----END PGP SIGNATURE----- From nobody Tue Oct 21 07:55:12 2014 Return-Path: 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 B4C221A8700 for ; Tue, 21 Oct 2014 07:55:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 t10dZO6FF73q for ; Tue, 21 Oct 2014 07:55:07 -0700 (PDT) Received: from mail-qa0-x235.google.com (mail-qa0-x235.google.com [IPv6:2607:f8b0:400d:c00::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2AB41A86EC for ; Tue, 21 Oct 2014 07:55:07 -0700 (PDT) Received: by mail-qa0-f53.google.com with SMTP id v10so925154qac.26 for ; Tue, 21 Oct 2014 07:55:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=Q+Yrvrj2WlYkMd1G3ZOrulkFJHRbQB8L25Vu3WjMCsg=; b=MIrozX9Plko5HScfaPdqU3VUDkTY1Ow5yxB/NA8Z9MTrWig/EISuPb9IK2aMyWpdsE O0mp7NVgoHYYOZXgaXCN/isNFN+iX0olMgW6n9qemJdnjQjyjzCKEe5ZsP5A6i6YahGM 67xQbPG0rVo1TXjX+ZCtOjchZFenqDalFFlQd4hrzc417Y5P4LIAqP7zsVa8qByRFXFF e4M4JRxJ+xF1SDP7LdGkVaDjHSZZLf7cEgAFlPIAa9SxyjO+M7FAvT7Qw7BDlO8ApGVF vpqSfOUoC2NqrKu+PGryqnGy30Bag5BETm3f7vOTl9y7OQ+WWhXx8fKMggMWV1i4wasK 6/ZQ== MIME-Version: 1.0 X-Received: by 10.224.36.148 with SMTP id t20mr15738231qad.39.1413903303853; Tue, 21 Oct 2014 07:55:03 -0700 (PDT) Received: by 10.140.20.199 with HTTP; Tue, 21 Oct 2014 07:55:03 -0700 (PDT) Date: Tue, 21 Oct 2014 07:55:03 -0700 Message-ID: From: Watson Ladd To: "cfrg@irtf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/qYpTOQzfiy0l3b1CBtLJu0JTdxU Subject: [Cfrg] Impact of point compression on security, round 2 X-BeenThere: cfrg@irtf.org 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: Tue, 21 Oct 2014 14:55:09 -0000 Dear all, What is the result of accepting damaged points? For ECDH a catastrophe. But for signatures? The answer is it depends on the details of the signature mechanism. In particular, if signatures themselves do not contain points, than bad points can only be public keys, which ends up not violating the standard assumption on signatures (EUF-CMA). (The reason is only properly formed keys matter) Unfortunately, batchable signatures contain points, so there is the possibility of forgery when bad points are accepted. Ultimately, we need benchmarks of signature verification to see what the impact is. Note that verification uses only public data, and so can be as non-constant time for speed as desired. In particular, double-base mult doesn't usually need side channel protection. On the gripping hand, some protocols like MQV do need protected double-scalar addition, and need an honest group to work with. So compressed point formats do add security to some applications, enable more performant signatures, and at a fairly reasonable cost of 10% on receiving. I didn't realize this before, which is why I'm thinking about it now. I think this still supports compression as mandatory, but it's not nearly as strong a case as it used to be, and in particular for PKIX uses, probably not necessary. (We also have to decide: what are we doing about signatures? The best option in my mind is batchable Schnorr variants, but others might disagree) Sincerely, Watson Ladd From nobody Tue Oct 21 10:12:38 2014 Return-Path: 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 F13A81A1A27 for ; Tue, 21 Oct 2014 10:12:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.555 X-Spam-Level: * X-Spam-Status: No, score=1.555 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.982, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no 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 oWhCN5OnNRO8 for ; Tue, 21 Oct 2014 10:12:34 -0700 (PDT) Received: from aspartame.shiftleft.org (199-116-74-168-v301.PUBLIC.monkeybrains.net [199.116.74.168]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3ACD01A1A37 for ; Tue, 21 Oct 2014 10:11:59 -0700 (PDT) Received: from [192.168.1.129] (unknown [192.168.1.1]) by aspartame.shiftleft.org (Postfix) with ESMTPSA id 13E453AA49; Tue, 21 Oct 2014 10:09:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=shiftleft.org; s=sldo; t=1413911382; bh=RkhqXq2fNxI45BXPozqZUL5P+XHY/h7EWMMZ70GICak=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=Kan8YakIaH8vpfrba1IM9mVJVY+0BFzF1XkalV5HtxZyS/NKm9tAqHiRRtD9KtylL /AeLWpLSLsdEGKZiYG4mlLdGIgXMnF4c4v9NntfP9zYrfAGdRsC6Xth9oKzOqc8Y0C 2VFrIuFtuTht7VbPDFV8LKlYivBJOsmeYtlP2GSI= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Michael Hamburg In-Reply-To: <20141021110910.GA17139@LK-Perkele-VII> Date: Tue, 21 Oct 2014 10:11:55 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <5883529A-6CB0-4251-ADB6-9E47AA6C2507@shiftleft.org> References: <20141018203017.23023.qmail@cr.yp.to> <20141020212441.GA23673@LK-Perkele-VII> <45033A8A-0702-480B-86D7-78CB9A93359B@shiftleft.org> <20141021110910.GA17139@LK-Perkele-VII> To: Ilari Liusvaara X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/v9eNoKmEl_bMhz-HNgHX0_MZ5O0 Cc: cfrg@irtf.org Subject: Re: [Cfrg] ed448goldilocks vs. numsp384t1 and numsp512t1 X-BeenThere: cfrg@irtf.org 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: Tue, 21 Oct 2014 17:12:35 -0000 > On Oct 21, 2014, at 4:09 AM, Ilari Liusvaara = wrote: >=20 > On Mon, Oct 20, 2014 at 03:48:48PM -0700, Michael Hamburg wrote: >>=20 >> On Oct 20, 2014, at 2:24 PM, Ilari Liusvaara = wrote: >>>=20 >>> On Sat, Oct 18, 2014 at 08:30:17PM -0000, D. J. Bernstein wrote: >>=20 >>>> Also signature verification: >>>>=20 >>>> 624000 cycles claimed: numsp384t1 (ed-384-mers), ~2^192 = security. >>>> 729152 cycles measured on h6sandy: ed448goldilocks, ~2^224 = security. >>>> 1320000 cycles claimed: numsp512t1 (ed-512-mers), ~2^256 = security. >>>=20 >>> Here Ed448 seems to be slightly slow for some reason. >>>=20 >>> I would have estimated (on very dubious grounds) ~680k. >>=20 >> For verification, Goldilocks has to decompress and ECCLib doesn=E2=80=99= t, >> which costs almost 10%. >=20 > Signature verification uses double-sclar multiply, right? >=20 > Is your ds multiply constant-time? Because the one in ECClib > apparently isn't (everything else should be). >=20 >=20 > -Ilari Yeah, it uses pretty much the same WNAF algorithm ECCLib uses, but it = burns 60 or 70kcy first to decompress the public key. =E2=80=94 Mike= From nobody Tue Oct 21 11:22:08 2014 Return-Path: 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 C472E1A1BC7 for ; Tue, 21 Oct 2014 11:22:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 W62ksUKLhCpg for ; Tue, 21 Oct 2014 11:22:03 -0700 (PDT) Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94FF41A6F0D for ; Tue, 21 Oct 2014 11:22:02 -0700 (PDT) Received: by mail-lb0-f175.google.com with SMTP id u10so1484793lbd.6 for ; Tue, 21 Oct 2014 11:22:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=yzOUsTD01g9MEXLJUgTf8AtRU2O1fYnx3EXMhVr2rOE=; b=PZ03o2z2C2ON6E8EVhTwoexZx2+mEffBFi7JzDdNfnvzq062GUsu+emA0apsRGNoiQ U7gttvxpChKzBeiovQfRz8kL0hYMrS2F1CWDXZ/dGbFIH8diOE5s8Z9GVyBk7PBe2ImN S3j7n/9lWxTPtXf1YhV0HQ4fW0sE6D4mz013mB+yQZqJUbqqeGEZti+4fBtRip2z3+AV fA3reI0Aslowyz6SBEeQIv1fpS6WlguVOLJ+6Sb5t2CsX8OYUx9udCzyuIIrg5AyLcZw MJrGnOPkMlm/awpIOK0FfKuMgm/G72sJ3KPHm/2IDlu8bGtA/anrfKQjaOHpn2jj0GFr eB/A== X-Received: by 10.112.147.225 with SMTP id tn1mr36714828lbb.37.1413915720610; Tue, 21 Oct 2014 11:22:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.218.145 with HTTP; Tue, 21 Oct 2014 11:21:40 -0700 (PDT) From: David Leon Gil Date: Tue, 21 Oct 2014 14:21:40 -0400 Message-ID: To: Alyssa Rowan Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/VShlnSiVA5ZGAPBmW6GFayQjjco Cc: "cfrg@irtf.org" Subject: [Cfrg] Verifiably hard-to-find random curves (Was: ECC reboot) X-BeenThere: cfrg@irtf.org 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: Tue, 21 Oct 2014 18:22:06 -0000 On Tue, Oct 21, 2014 at 9:12 AM, Alyssa Rowan wrote: > > Perhaps I'm confused, or perhaps there's a language barrier? The position= paper you posted says that Brainpool wants pseudorandom prime curves, whos= e description *exactly* matches those of the existing Brainpool curves, but= generated via some (unspecified, yet assumed trusted) new process; that yo= u want these alongside special curves; and you want the PSR curves to be ma= ndatory to implement. There are some problems with the current Brainpool curves; in particular, brainpoolP256t1 has a very insecure twist. -- But I agree: It is hard to generate random numbers by consensus. 1. I tend to think that CFRG/Brainpool/someone should recommend -- for applications that *need* random curves -- a new process to generate verifiably random primes and curves starting from a seed that meet the SafeCurves+Brainpool conditions. 2. There is, however, another possibility; suggested by djb's BADA55 exercise (especially for special primes): a. Require, as in BADA55, that the high order bits of the curve parameter are equal to something simple and pseudorandom. E.g., Salsa20(k=3D0,n=3D0,0)[0:64]. b. Find a matching (safe) curve. (Starting from a public "verifiable" seed, if you like.) c. Suppose that fewer than 2^-32 of curves are weak; an adversary will require 2^96 trials to find a weak curve that satisfies this condition. This only requires agreement that prescribing a pseudo-random bitpattern is not likely to be correlated with curve weakness. (I still dislike this idea, as compared to a rigid choice, and see little point in doing it.[**] But it seems better than trying to specify a new seed/generation procedure, where there are many choices.) - dlg [*] Is the list of reasonable choices longer than, e.g.: - {Salsa,ChaCha}20(k=3D0*256, n=3D0*8) - SHAx-x('') - AES-x[k=3D0*x](0*128) - {BLAKE,blake2{b,s}}('') This is still << than 2^8 choices for the adversary. [**] In particular, it is a purely linear difficulty tradeoff. From nobody Wed Oct 22 05:05:15 2014 Return-Path: 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 ED3481A900A for ; Wed, 22 Oct 2014 05:05:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.859 X-Spam-Level: X-Spam-Status: No, score=-3.859 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=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 5AmQxIVJtXeb for ; Wed, 22 Oct 2014 05:05:05 -0700 (PDT) Received: from m1-bn.bund.de (m1-bn.bund.de [77.87.228.73]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E6141A90B3 for ; Wed, 22 Oct 2014 05:05:03 -0700 (PDT) Received: from m1.mfw.bn.ivbb.bund.de (localhost.mfw.bn.ivbb.bund.de [127.0.0.1]) by m1-bn.bund.de (8.14.5/8.14.5) with ESMTP id s9MC51wC031993 for ; Wed, 22 Oct 2014 14:05:01 +0200 (CEST) Received: (from localhost) by m1.mfw.bn.ivbb.bund.de (MSCAN) id 5/m1.mfw.bn.ivbb.bund.de/smtp-gw/mscan; Wed Oct 22 14:05:01 2014 X-P350-Id: 223ceb2a2e01730a X-Virus-Scanned: by amavisd-new at bsi.bund.de From: "Lochter, Manfred" Organization: BSI Bonn To: cfrg@irtf.org Date: Wed, 22 Oct 2014 14:04:36 +0200 User-Agent: KMail/1.9.10 (enterprise35 20140205.23bb19c) References: <201410211027.13608.manfred.lochter@bsi.bund.de> In-Reply-To: X-KMail-QuotePrefix: > MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-ID: <201410221404.36477.manfred.lochter@bsi.bund.de> X-AntiVirus: checked by Avira MailGate (version: 3.2.1.26; AVE: 8.3.24.38; VDF: 7.11.180.138; host: sgasmtp2.bsi.de); id=11769-gxS0gj Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/NPINi8mPLPhDOjxJkw5Z9Zc3gaI Subject: Re: [Cfrg] ECC reboot (Was: When's the decision?) X-BeenThere: cfrg@irtf.org 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: Wed, 22 Oct 2014 12:05:10 -0000 > > If you wanted another Brainpool: why, and what is stopping Brainpool from > doing it? You didn't need to do it here before. You seem to be worried the > BADA55 paper discredits the Brainpool curves by showing a plausible way > they could have been rigged. It doesn't prove that they actually were > rigged (indeed, Brainpool is listed on Safecurves as "somewhat rigid" and > still has a tick in that box). Where's the fire? =46or examle here: Andy Lutomirski wrote on 16.10.2014 20:06: > Are the Brainpool curves really VPR? They're certainly far better in > that regard than the NIST curves, but the BADA55 paper points out > correctly that the "verifiably" part is weak. And for me the reasoning from the BADA55 paper does not appear to be=20 plausible. > > I'm relatively new, but my understanding is that Stephen is correctly > pointing out that mandatory-to-implement anything is way out-of-scope her= e. > We make suggestions, recommendations; downstream WGs in IETF decide wheth= er > they have rough consensus to adopt them, and then implementers decide > whether they actually care to. Where did I suggest to make anything mandatory? I searched all my postings= =20 for "mandatory" without finding that source. > >As the cfrg also discusses parameter lengths I would like to add that it > > is completely adequate to use 384 bit curves even for highest security > > demands. > > I agree, although there aren't any convenient special primes around that > area. (I also think 256 is fine.) > > >So, 384 bit curves must be included in any proposed set of curves. > > Um, how does that follow? Do you propose just 256 and 384, then? Or...? > > Why is 384-bit a must? What's so magical about it? Why not 417? 448? 512? > 521? 607? 31337? You can see this statement as a direct answer to your own posting from=20 September 14, where you stated "If it's optional, I definitely say drop 192= =20 from requirement SE6". There you did not write about 31337, did you? To make it perfectly clear: If the group is going to only propose curves fo= r=20 two security-levels I'm opting for 128 and 192.=20 Manfred =2D-=20 Lochter, Manfred =2D------------------------------------------- Bundesamt f=C3=BCr Sicherheit in der Informationstechnik (BSI) Referat K21 Godesberger Allee 185 -189 53175 Bonn Postfach 20 03 63 53133 Bonn Telefon: +49 (0)228 99 9582 5643 Telefax: +49 (0)228 99 10 9582 5643 E-Mail: manfred.lochter@bsi.bund.de Internet: www.bsi.bund.de www.bsi-fuer-buerger.de From nobody Wed Oct 22 05:59:47 2014 Return-Path: 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 2B9781A90F9 for ; Wed, 22 Oct 2014 05:59:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-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 bHfLWK8YSgCR for ; Wed, 22 Oct 2014 05:59:44 -0700 (PDT) Received: from entima.net (entima.net [78.129.143.175]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC6461A90F8 for ; Wed, 22 Oct 2014 05:59:43 -0700 (PDT) In-Reply-To: <201410221404.36477.manfred.lochter@bsi.bund.de> References: <201410211027.13608.manfred.lochter@bsi.bund.de> <201410221404.36477.manfred.lochter@bsi.bund.de> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 From: Alyssa Rowan Date: Wed, 22 Oct 2014 13:59:36 +0100 To: "Lochter, Manfred" ,cfrg@irtf.org Message-ID: Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/4ciomgww5a_hjtz_XU2e7u5BqP4 Subject: Re: [Cfrg] ECC reboot (Was: When's the decision?) X-BeenThere: cfrg@irtf.org 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: Wed, 22 Oct 2014 12:59:46 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 22 October 2014 13:04:36 BST, "Lochter, Manfred" wrote: >And for me the reasoning from the BADA55 paper does not appear to be plausible. I understand your defending your position, but there does appear to be professional disagreement on that point. (I think myself they are indeed plausible but not too likely, as the approach taken by Brainpool would have likely been the most obvious one at the time. However, I have not investigated this in detail.) Like I've said, if you want new pseudorandom curves, nothing stopped you before and nothing's stopping you now - but: I don't think that's what the TLS WG asked us for; I don't think that's what anyone other than the Brainpool participants want; I don't think Brainpool needs our help to get the things it wants because it's already got them; I don't agree at all it's the best approach to take even in hardware, and; I don't think any further discussion on this point will bring our diametrically-opposed requirements into unison, it'll just delay matters and we don't want that. I propose therefore, simply, that no changes need to be made to the curve criteria to accommodate the request of the Brainpool group. Let's move on from this. >> …mandatory-to-implement anything is way out-of-scope here. >Where did I suggest to make anything mandatory? I searched all my postings for "mandatory" without finding that source. Um. It's… right there in the conclusions of the position paper you co-authored and linked here, Manfred. "Requirements for Standard Elliptic Curves: Position of the ECC Brainpool", Cryptology ePrint Archive: Report 2014/832 : >A potential compromise is the construction of new curves with similar properties as the Brainpool Curves, i.e., with verifiably pseudo-random primes, and make this set mandatory to implement. I hope that clears that up for you. And as before, any mandatory agreement is not really within our gift to give, so that's not a compromise we can really make. >To make it perfectly clear: If the group is going to only propose curves for two security-levels I'm opting for 128 and 192. If 192 is strong enough, surely bigger ones would be stronger and also fine? If 192 is not a good efficiency::security inflexion point, we'd probably rather choose another. If stronger ones are more efficient (and they are: Curve41417, Ed448-Goldilocks) we'd probably rather choose those, unless we can very clearly justify why 192, and not, say 256. Why would you pick 192, in particular, given there are really no very good special primes in that area and, for example, AES-192 is seldom used? (secp384r1 and SHA-384 is only used anywhere because NSA Suite B picked it; even they couldn't get anyone who actually used AES-192.) This is, after all, the kind of thing meant by "rigidity": clear, justifiable, obvious reasoning, without arbitrary unexplained choices. - -- /akr -----BEGIN PGP SIGNATURE----- Version: APG v1.1.1 iQI3BAEBCgAhBQJUR6o3GhxBbHlzc2EgUm93YW4gPGFrckBha3IuaW8+AAoJEOyE jtkWi2t6ALwP/27zMX92hZxM2YS8iCfwfr3ozz03buCWDrg1KKIyiS5oiV32r1zD nZLwlulnV8c7QkgTAFHqtrEODEsjVO5tb77mhYD0lDC2b/Ym6FHhSi+GyjX9kz8a htgckWDnFxJ5jVviAXnFoOCsRKv0cjSfTdHmXAtyWj3PNJEOPicaj790Fio+SZSw QK7oZvlqOSHCjPF0YP6Gpt00nLglnrjCFPg8zyAwJ++yNP4duDGcLAHLzEEBTgMB BBX6fY3h3aNXxt7QG5uAwNN2hzKzyZN91ckgM2luDBrc7NFJ0iQvL7AB8w36uP5n omgVn7V7ZeyDP9AdVg5+8JWSr8QERzkPHdVDGnQ95uJrJGLZQIXyiIarZn+BVtwM 8aQ3+7H7ZF9jURCwuAj93OyoZXZVBgjmx9RHmLmJXrdFW8FW0ftbDNAD6ENvWBXl 6ZfhF4Njv/VuV1V5CITikusDyt+sbplwVCq9H8luB6KU/RPcrozgu9o5bNwVCijF F0q4s3qkCJEOHpFsTSZBHZI6bEb9gIDSMbkkEYhlPpBmIBTvmrnRrG/24yfDwec1 /Y2mKuv6h0jQ1YKI2JIpzQuXL3bqj3toDGCX/mhN5ibDDfl9Eb+NtZqaEvJMMN41 o2PFOUg+LDAf+NbMr87lcLwyFC5xFTUFS8M4QP9WxpT7LwGrtUREKLPj =BUcz -----END PGP SIGNATURE----- From nobody Wed Oct 22 14:35:04 2014 Return-Path: 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 57F1F1A6F1D for ; Wed, 22 Oct 2014 14:35:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.61 X-Spam-Level: ** X-Spam-Status: No, score=2.61 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, TO_NO_BRKTS_PCNT=2.499, T_TVD_FUZZY_SECURITIES=0.01, UNPARSEABLE_RELAY=0.001] autolearn=no 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 upfq6mzPTGg2 for ; Wed, 22 Oct 2014 14:35:01 -0700 (PDT) Received: from mace.cs.uic.edu (mace.cs.uic.edu [131.193.32.224]) by ietfa.amsl.com (Postfix) with SMTP id 9EFE21A6F04 for ; Wed, 22 Oct 2014 14:35:01 -0700 (PDT) Received: (qmail 6121 invoked by uid 1011); 22 Oct 2014 21:34:55 -0000 Received: from unknown (unknown) by unknown with QMTP; 22 Oct 2014 21:34:55 -0000 Received: (qmail 20220 invoked by uid 1001); 22 Oct 2014 21:34:47 -0000 Date: 22 Oct 2014 21:34:47 -0000 Message-ID: <20141022213447.20218.qmail@cr.yp.to> From: "D. J. Bernstein" To: cfrg@irtf.org Mail-Followup-To: cfrg@irtf.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/D4U_v3K-KxYeybk6zAGwZ6ySatQ Subject: [Cfrg] E-521 vs. numsp512t1 X-BeenThere: cfrg@irtf.org 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: Wed, 22 Oct 2014 21:35:03 -0000 Rob Granger and Mike Scott have posted a new paper "Faster ECC over \F_{2^521-1}" (https://eprint.iacr.org/2014/852) reporting ECC speeds mod 2^521-1, and in particular the first (as far as I know) serious implementation of E-521. Granger and Scott haven't contributed the software to SUPERCOP yet, and they report only Haswell speeds, while Microsoft's paper reports only Sandy Bridge speeds, so comparison isn't easy. I downloaded the E-521 software and tried it on Sandy Bridge: * E-521: slightly under 1.12 million cycles. * numsp512t1 (ed-512-mers): 1.293 million cycles, according to the Microsoft paper. To summarize, on the microarchitecture selected by Microsoft for benchmarks, Microsoft's claimed numsp512t1 speeds are about 15% slower than these higher-security E-521 speeds. At a lower level, the new paper reports 155 Haswell cycles for field multiplication, a noticeable improvement over the 167 Haswell cycles mentioned in Mike Hamburg's message https://www.ietf.org/mail-archive/web/cfrg/current/msg04984.html (using a different technique). Mike had already estimated that his approach to E-521 would beat the Microsoft results for numsp512t1. For comparison, Microsoft claimed in July to "show that ... moving from 512 bits to 521 bits ... degrades performance by a factor 1.2". This is yet another example of the dangers of measuring _some_ implementation rather than measuring the _best_ implementation. There's clearly a big difference in performance between * a 2^521-1 implementation from someone who never had an incentive to use state-of-the-art techniques and * a 2^521-1 implementation from someone who wants it to run fast. The new E-521 code is also surprisingly short; we're not talking about some difficult tradeoff between simplicity and performance. The code actually works mod 2^(58*9)-c where c=2, and relies heavily on c being very small. This appears to add even more evidence for the idea that "make everything as fast as possible" creates rigidity: there are many primes that provide tolerable speeds but there are only a few primes that provide truly top speeds. (When I say "truly top" I mean something even better than Pareto-optimal; see my message https://www.ietf.org/mail-archive/web/cfrg/current/msg04894.html for details.) If further analysis continues to support the statement that 2^521-1 is exceptionally fast, how many people will argue that downgrading to 2^512-569---sacrificing security and sacrificing speed---is a good idea? I don't understand how the "512 is a power of 2" statement is supposed to be relevant. I also don't understand the "match 2^256" argument. As Adam Langley wrote: Above the 120ish bit level one is no longer fighting stronger attackers, but hedging against a breakthrough (but not too much of one). Matching 192 or 256 bit security levels is a *misunderstanding* in the wider community, and is thus of the lowest priority. I realize that the TLS WG requested "128-bit" and "256-bit" and maybe "192-bit" but all indications are that this was a knee-jerk list---not something CFRG should take seriously, and certainly not something that should override CFRG's security judgment. If there's doubt about this then surely the TLS WG can provide more clarification as to its needs. I don't mean to suggest that it's obvious that CFRG should pick _any_ curve at this stratospheric >500-bit size. I simply don't see the argument for picking 2^512-569 rather than 2^521-1. ---Dan From nobody Wed Oct 22 15:12:33 2014 Return-Path: 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 9D13B1A8741 for ; Wed, 22 Oct 2014 15:12:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.741 X-Spam-Level: X-Spam-Status: No, score=0.741 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_BR=0.955, HOST_EQ_BR=1.295, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 qk-yIuJnjD6c for ; Wed, 22 Oct 2014 15:12:25 -0700 (PDT) Received: from ephesus.correio.usp.br (ephesus.correio.usp.br [200.144.182.205]) by ietfa.amsl.com (Postfix) with ESMTP id 877B71A7031 for ; Wed, 22 Oct 2014 15:12:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ephesus.correio.usp.br (Postfix) with ESMTP id C83A41EC0D9 for ; Wed, 22 Oct 2014 20:12:21 -0200 (BRST) X-Virus-Scanned: amavisd-new at ephesus.correio.usp.br Received: from ephesus.correio.usp.br ([127.0.0.1]) by localhost (ephesus.correio.usp.br [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s3D9QWpJACvI for ; Wed, 22 Oct 2014 20:12:21 -0200 (BRST) Received: from cuzco.correio.usp.br (unknown [10.0.22.2]) by ephesus.correio.usp.br (Postfix) with ESMTP id 19E8A1EB002 for ; Wed, 22 Oct 2014 20:12:21 -0200 (BRST) Date: Wed, 22 Oct 2014 20:12:21 -0200 (BRST) From: Paulo Sergio Licciardi Messeder Barreto To: cfrg@irtf.org Message-ID: <612808849.9498237.1414015941064.JavaMail.root@larc.usp.br> In-Reply-To: <1027677370.9495894.1414015116140.JavaMail.root@larc.usp.br> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_9498236_1776083507.1414015941063" X-Originating-IP: [143.107.151.34] X-Mailer: Zimbra 7.2.0_GA_2681 (ZimbraWebClient - FF3.0 (Win)/7.2.0_GA_2681) Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/sAnRi4NbFTpZmiKWNfIuU7EMKYI Subject: [Cfrg] A case for E-521 X-BeenThere: cfrg@irtf.org 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: Wed, 22 Oct 2014 22:12:29 -0000 ------=_Part_9498236_1776083507.1414015941063 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Greetings. Sorry for my late entry in these discussions, I was only recently made aware of them. I would like to suggest that, for the top security level, the curve E-521 (or its equally secure quadratic twist) as defined in be considered. E-521 was discovered independently by at least three teams (1. M. Hamburg; 2. D. Bernstein and T. Lange; 3. The authors of , including myself). In fact, I see that this curve has appeared in the discussions already, and this is intended to be a complement to that. The substantial advantages of E-521 (not only in terms of speed on some particular platform, but in a portable manner as well) over other curves at the same security level, including P-521 and other curves reported in , were recently corroborated by a fourth, independent team . These results were obtained with the Miracl library, which is publicly available and hence makes reproducibility a straightforward matter. Unsurprisingly, E-521 will be quite hard to beat if at all. Further comparisons by other teams are under way. E-521 has been proposed to the Brazilian government (by the Special Committee on Security of the Brazilian Computer Society; a copy of that document, in Portuguese, can be found at ) for official use at the higher security level, both domestically and in passports, in replacement of NIST and Brainpool curves. Regards, Paulo Barreto. ------=_Part_9498236_1776083507.1414015941063 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
Greetings.

Sorry for my late entry in these discussions, I was only recently made aware of them.

I would like to suggest that, for the top security level, the curve E-521 (or its equally secure quadratic twist) as defined in <http://eprint.iacr.org/2013/647> be considered.

E-521 was discovered independently by at least three teams (1. M. Hamburg; 2. D. Bernstein and T. Lange; 3. The authors of <http://eprint.iacr.org/2013/647>, including myself). In fact, I see that this curve has appeared in the discussions already, and this is intended to be a complement to that.

The substantial advantages of E-521 (not only in terms of speed on some particular platform, but in a portable manner as well) over other curves at the same security level, including P-521 and other curves reported in <http://eprint.iacr.org/2014/130>, were recently corroborated by a fourth, independent team <http://eprint.iacr.org/2014/852>. These results were obtained with the Miracl library, which is publicly available and hence makes reproducibility a straightforward matter. Unsurprisingly, E-521 will be quite hard to beat if at all. Further comparisons by other teams are under way.

E-521 has been proposed to the Brazilian government (by the Special Committee on Security of the Brazilian Computer Society; a copy of that document, in Portuguese, can be found at <http://www.larc.usp.br/~pbarreto/manifesto-curvas.pdf>) for official use at the higher security level, both domestically and in passports, in replacement of NIST and Brainpool curves.

Regards,

Paulo Barreto.

------=_Part_9498236_1776083507.1414015941063-- From nobody Wed Oct 22 16:20:10 2014 Return-Path: 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 B06B11AD40F for ; Wed, 22 Oct 2014 16:20:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 Y4XodN362ndp for ; Wed, 22 Oct 2014 16:20:07 -0700 (PDT) Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A468E1A87C8 for ; Wed, 22 Oct 2014 16:20:06 -0700 (PDT) Received: by mail-lb0-f180.google.com with SMTP id n15so3712327lbi.11 for ; Wed, 22 Oct 2014 16:20:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=S4aEHlE6IlkZjvGPbYTbmw/TUQliSdHVSraJkoKg5Yc=; b=D1fKiWMxwi2P/FvHrkCQn6I5xyGbC0Q5Koeg24xx6RRUbL8VGH5SLp4nQDTk7kwai8 KX/e7/kOh2Q4GMjzAwaPa6RNcM/vFHFEfBl/jPq8ekLOmBPsSBxYkGzJzpEFtLPvHl6A 3I7T/qH3x803QHLBo27HSFENBXecHoSmoXbI5isiNSn7PGQ4FoHEJefPNPcDNuEuc2QP Gxbkf5WxRweuvIVFnkn9bau6w7q5Tk3KOvr5sxxmk+zsLqRq+b3v7hU/luQhCOWMWPQ0 pg8ffe4QknK/QIDV1WYsexp2BtzBkL/jTvmFPGbGkmN9jLI2Kg271Mq5Zpx4NBHW38gv 0qRQ== X-Received: by 10.112.28.75 with SMTP id z11mr1018082lbg.49.1414020004835; Wed, 22 Oct 2014 16:20:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.218.145 with HTTP; Wed, 22 Oct 2014 16:19:44 -0700 (PDT) In-Reply-To: <20141022213447.20218.qmail@cr.yp.to> References: <20141022213447.20218.qmail@cr.yp.to> From: David Leon Gil Date: Wed, 22 Oct 2014 19:19:44 -0400 Message-ID: To: "cfrg@irtf.org" , "D. J. Bernstein" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/Z7VEiPcOaRqw6MpjKLZN77vxKAw Subject: Re: [Cfrg] E-521 vs. numsp512t1 X-BeenThere: cfrg@irtf.org 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: Wed, 22 Oct 2014 23:20:09 -0000 On Wed, Oct 22, 2014 at 5:34 PM, D. J. Bernstein wrote: > Rob Granger and Mike Scott have posted a new paper "Faster ECC over > \F_{2^521-1}" (https://eprint.iacr.org/2014/852) reporting ECC speeds > mod 2^521-1, and in particular the first (as far as I know) serious > implementation of E-521. The implementation djb mentions is available on their website: http://indigo.ie/~mscott/{ed521,ws521}.cpp -- I've put this code in a GitHub repo, as it needed to be modified slightly to work with Clang++ HEAD:* https://github.com/coruus/E521 * This is the first time I've encountered a compiler taking advantage of the fact that undefined behavior ensues when a function not declared void doesn't return a value. Clang++ generates code that just continues to some other function...and eventually SIGSEGVs. From nobody Wed Oct 22 16:43:06 2014 Return-Path: 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 7D6581A87AF for ; Wed, 22 Oct 2014 16:43:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_71=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 LQOtwvourcbl for ; Wed, 22 Oct 2014 16:43:02 -0700 (PDT) Received: from emh06.mail.saunalahti.fi (emh06.mail.saunalahti.fi [62.142.5.116]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AE761A802D for ; Wed, 22 Oct 2014 16:43:02 -0700 (PDT) Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh06.mail.saunalahti.fi (Postfix) with ESMTP id 40224699DE; Thu, 23 Oct 2014 02:42:58 +0300 (EEST) Date: Thu, 23 Oct 2014 02:42:58 +0300 From: Ilari Liusvaara To: David Leon Gil Message-ID: <20141022234258.GA29823@LK-Perkele-VII> References: <20141022213447.20218.qmail@cr.yp.to> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/EPmidSzE0F-HRpRg3xP86Kocvxc Cc: "cfrg@irtf.org" , "D. J. Bernstein" Subject: Re: [Cfrg] E-521 vs. numsp512t1 X-BeenThere: cfrg@irtf.org 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: Wed, 22 Oct 2014 23:43:04 -0000 On Wed, Oct 22, 2014 at 07:19:44PM -0400, David Leon Gil wrote: > On Wed, Oct 22, 2014 at 5:34 PM, D. J. Bernstein wrote: > > Rob Granger and Mike Scott have posted a new paper "Faster ECC over > > \F_{2^521-1}" (https://eprint.iacr.org/2014/852) reporting ECC speeds > > mod 2^521-1, and in particular the first (as far as I know) serious > > implementation of E-521. > > The implementation djb mentions is available on their website: > > http://indigo.ie/~mscott/{ed521,ws521}.cpp > Watch out (from ed521.cpp): void mul(int *w,ECp *P) { ECp W[33],Q; precomp(P,W); copy(&W[w[86]],P); for (int i=85;i>=0;i--) { if (w[i]>=0) copy(&W[w[i]],&Q); else neg(&W[-w[i]],&Q); ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ window(&Q,P); } norm(P); } That does not look constant-time... -Ilari From nobody Thu Oct 23 02:47:13 2014 Return-Path: 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 3E9761A8A40 for ; Thu, 23 Oct 2014 02:47:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.69 X-Spam-Level: X-Spam-Status: No, score=0.69 tagged_above=-999 required=5 tests=[BAYES_50=0.8, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] 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 z7_Db6c1K6bS for ; Thu, 23 Oct 2014 02:47:06 -0700 (PDT) Received: from a.mx.secunet.com (a.mx.secunet.com [195.81.216.161]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A2141A8A42 for ; Thu, 23 Oct 2014 02:47:05 -0700 (PDT) Received: from localhost (alg1 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id 812B41A008B; Thu, 23 Oct 2014 11:46:57 +0200 (CEST) X-Virus-Scanned: by secunet Received: from a.mx.secunet.com ([127.0.0.1]) by localhost (a.mx.secunet.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id agrQjthHGxo6; Thu, 23 Oct 2014 11:46:53 +0200 (CEST) Received: from mail-essen-01.secunet.de (unknown [10.53.40.204]) by a.mx.secunet.com (Postfix) with ESMTP id 643981A0087; Thu, 23 Oct 2014 11:46:53 +0200 (CEST) Received: from [10.208.1.76] (10.208.1.76) by mail-essen-01.secunet.de (10.53.40.204) with Microsoft SMTP Server (TLS) id 14.3.210.2; Thu, 23 Oct 2014 11:46:58 +0200 Message-ID: <5448CE92.6080903@secunet.com> Date: Thu, 23 Oct 2014 11:46:58 +0200 From: Johannes Merkle User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Tanja Lange References: <201410211027.13608.manfred.lochter@bsi.bund.de> <20141021090529.GA12154@LK-Perkele-VII> <201410211127.53008.manfred.lochter@bsi.bund.de> <20141021114003.GZ5502@cph.win.tue.nl> In-Reply-To: <20141021114003.GZ5502@cph.win.tue.nl> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Originating-IP: [10.208.1.76] X-EXCLAIMER-MD-CONFIG: 2c86f778-e09b-4440-8b15-867914633a10 Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/yyZ8LiE8m_U243vzEcJVC7JQTmk Cc: cfrg@irtf.org Subject: Re: [Cfrg] ECC reboot (Was: When's the decision?) X-BeenThere: cfrg@irtf.org 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: Thu, 23 Oct 2014 09:47:10 -0000 Dear Tanja, please allow me to answer your question. I have repeatedly expressed my feeling that the discrediting of the Brainpool curves by the BAD55 paper is wrongful and unfair. First of all, I would like to emphasize that I was not involved in the generation of the Brainpool curves, as I started participating in the Brainpool group not before end of 2005. (I don't need to tell you that, as you had been a Brainpool member in that time but others on this list will not know.) In your paper, you explain, how you were able to create an elliptic curve with a BADA55 string in the coefficient a: As you put it, the basic idea was "to try all possible combinations of hash functions, seed length, initial seed constant, and so on, until he [Jerry] finds a curve that exhibits the desired vulnerability." Thus, you chose a general with design variations that result in almost 20 bits of freedom or, equivalently, almost 2^20 combinations. According to your paper, the following variations were used: - 73 natural constants - 10 different hash functions. - 6 block size configurations of the hash function - 2 endian-formats for the seed - 5 counter lengths for the seed update function - 2 orders for the concatenation of counter and seed - 2 methods of shortening the seed to the right length - 8 "different ways to update the counter between generation of a and b and to choose the order of generating a and b" While your approach is scientifically sound and ingenious, I object to the conclusion that it is comparable to the approach taken for the Brainpool curves. In this case, the number of plausible variations is much smaller: 1. Choice of the natural constants. Brainpool curves used Pi to generate the primes and e to generate the curve coefficients. Apart from 0, 1 and 2, or i, these are by far the most prominent mathematical constants. Period. It doesn't matter what constants are used in some hash or symmetric encryption functions (where mathematical theory is much less prevalent than in asymmetric crypto); when it comes to rigidity and trust, you have to choose the most natural looking, obvious seeds. If you ask a random mathematician about which constant is most prominent, you will get Pi as an answer with overwhelming probability, and on second place, there will almost certainly be e. For instance, http://en.wikipedia.org/wiki/Mathematical_constant lists these two as the first in the list of mathematical constants, and only two others (sqrt(2) and i) as "Common mathematical constants". Nobody would answer  zeta(3), zeta(5), sin(1), sin(2), cos(1), cos(2), tan(1), tan(2), sqrt(3), sqrt(5), sqrt(7), log(2), or any of their reciprocals, very few would respond with the EulerMascheroni gamma (or any other like listed in Wikipedia as "Constants in advanced mathematics"). The golden ratio phi = (1 + sqrt(5))/2 is certainly quite prominent, but without doubt, the numbers Pi and e are by far more "fundamental" in that they appear in so many important results. Leaves only sqrt(2) as an alternative choice; however, sqrt(2) is algebraic, and transcendental numbers are widely felt as being less comprehensible and structured. (Also, one could argue that deriving seeds from algebraic numbers may give it a "bad small" for the generation of algebraic curves, but this is a weak argument as the hash function should destroy any algebraic relation.) The conclusion is that even if you are willing to accept sqrt(2) and the golden ratio as comparably prominent and eligible as e, Pi is outstanding and, thus, I could only imagine Pi alone, Pi+e, Pi+phi, Pi+sqrt(2), as well as reversed orders of the combinations as being an acceptably obvious choice. This makes 7 choices, as compared to 73. 2. Choice of hash function. The Brainpool members used the approach of ANSI X9.62 to derive integers from the seeds. This was (and is) by far the most relevant standard for elliptic curves, and I can see no reason to deviate from that method; for a PRNG, SHA-1 was (and still is) sufficiently secure [1]. Thus, although SHA-2 was already standardized in that time, there was no reason to change the hash function. Beside from deviating from the existing standard, using SHA-2 would have implied additional options w.r.t the output length, which is undesirable for rigidity. IMHO, anything else than SHA-1 would have looked less plausible. Thus, I do not really see any freedom here. 3. Seed length. ANSI X9.62 requires the seeds to be at least 160 bits long. This requirement is implied by the output length of SHA-1. In fact, all seeds used for the NIST curves had exactly 160 bits. Again, there as no reason to deviate from this existing example, thus, using 160 bit was the most natural choice. In addition, where there is no maximum, the minimum is the only distinguished value. 4. Block size configurations of the hash function. This configuration option is not available for SHA-1 (and, BTW, not for SHA-2 either). 5. Endian-formats for the seed. The Brainpool group used the same integer representation as ANSI X9.62 and all other relevant standards for elliptic curves. IMO, any deviation would have looked suspicious. 6. Counter lengths for the seed update function. I don't know, if the option of a dedicated counter had been considered by the Brainpool group, but for me using a counter in addition to the seeds adds unnecessary flexibility and is, thus, undesirable. 7. Orders for the concatenation of counter and seed. No counter, no order. 8. Methods of shortening the seed to the right length. To me, the idea of rounding sounds quite unusual in the context of cryptographic derivation functions. But to be fair, I admit that the expansion of the constants by 1120 bits, e.g., setting Seed = 2^1120*Pi, and the subsequent truncation of one nibble at the right hand side gives a few options. They could have set Seed = 2^1118*Pi, which would have eliminated the need for truncation. Or they could have truncated on the left hand side. If we add the two options of ordering the seeds according to the individual bit lengths (Seed_160 on the left side and Seed_512 on the ride hand side, or vice-versa), we get 6 options. 9. Method to update the counter between generation of a and b and to choose the order of generating a and b. The natural order of a and b is given by the alphabet, and, IMO, reversing this in the generation method would look a bit artificial. For updating the seed after generation of b, the Brainpool method simply uses the seed update function. This is the simplest approach, which is generally preferable for rigidity. But lets assume that applying the hash function s -> h(s) was also an option, which makes 2 options. 10. There is an additional source of flexibility: It has been observed (initially in RFC 5639) that the derivation method differs from that in ANSI X9.62 in that both coefficients are derived directly from the seeds, whereas ANSI derives just r = a^3/b^2 mod p and leaves definition of a and b open. As explained in RFC 5639, the objective of the Brainpool members was to generate for each bit length two isomorphic curves, one with random a and one with a=-3. The motivation behind this was that random coefficients may facilitate avoiding patents in implementations. Since the ANSI method does not specify how to obtain a verifiably pseudo-random a, a deviation seems unavoidable to achieve this objective. And the most simple approach is to generate a and b using the same method as specified by ANSI for r. And by the way, the same method (with different seed) was also used to generate the prime p. When I multiply all the options, I get 7*6*2=84 options. Even if you don't agree with all my statements above and add some options at one aspect or the other, there is a big difference to the estimation of 1.4 million possibilities estimated in your paper. Furthermore, in all aspects where flexibility was possible, the choice of the Brainpool group was among the simplest and most plausible. Of course, any assessments of plausibility is subjective and can be controversially discussed - presumably without reaching consensus. On the other hand, the approach taken for the Curve25519, i.e. to choose minimal coefficients, is also not 100% rigid. In his Curve25519 paper, Dan writes: > I rejected A = 358990 because one of its primes is slightly smaller > than 2^252, raising the question of how standards and implementations should > handle the theoretical possibility of a user's secret key matching the prime; > discussing this question is more difficult than switching to another A. I rejected > 464586 for the same reason. So I ended up with A = 486662. These are valid arguments but, nevertheless, the conclusion is subjective. Furthermore, Bos, Costello, Longa, and Naehrig, took quite the same approach and arrived at different curves (the NUMS curves), even at different primes. As they write, "Full rigidity is virtually impossible in practice" [2]. I fully agree with that. The best approach to address this is to openly discuss (with open outcome) the generation method in a large audience of interested parties. This exactly was done in the ECC Brainpool, which is an open group which everybody (even private persons) can join without registration, feed, or restrictions, and which includes virtually all stakeholders of ECC standardization in Germany. In this open forum, the generation method was presented and discussed, and there was a consensus that it is eligible. Actually, you know that better than me, because you had been an active member at that time and you participated these discussions. All the more, I was surprised to find you among the authors of the BADA55 paper, which, IMHO, casts a damning light of suspicion on the Brainpool curves. And Dan's statement on this list is even more explicit in that: > However, the following recent analysis shows that the Brainpool curves, > which were advertised as "generated in a systematic and comprehensive > way" covering several different security levels, actually gave the curve > generator the flexibility to secretly choose from among more than > 1000000 curves for any particular prime: I have already met users (with limited knowledge in cryptology) telling me they have read that the Brainpool curves are not trustworthy. Considering the process that had been taken by the Brainpool group, this statement is unjustified and misleading, and considering that the curves are already rolled out in more than 50 million national ID cards and passports, this damage of reputation is very serious. I fully respect your scientific work in the area of elliptic curves and your contribution to the current standardization effort, but consider the impact of your paper to the reputation of the Brainpool curves as very unfortunate. Best regards, Johannes [1] NIST Special Publication 800-57. Recommendation for Key Management Part 1: General (Revision 3). 2012 [2] J. Bos, C. Costello, P. Longa, and M. Naehrig: Selecting Elliptic Curves for Cryptography - A presentation for the Crypto Forum Research Group (CFRG). http://patricklonga.webs.com/Presentation_CFRG_Selecting_Elliptic_Curves_for_Cryptography.pdf Tanja Lange wrote on 21.10.2014 13:40: > Dear Manfred, > > On Tue, Oct 21, 2014 at 11:27:52AM +0200, Lochter, Manfred wrote: >> b) The original Brainpool curves have falsely been discredited in the >> BADA55-paper. >> > > What do you claim to be false in that paper? > > We show -- and as far as I know are the first to show -- that the > approach to generate the BP curves allows the designer of that > approach to hide a one-in-a-million weakness in the resulting > curve, should he or she have found such a weakness. > > Regards > Tanja > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg > > -- Viele Gre, Johannes Merkle From nobody Thu Oct 23 03:44:12 2014 Return-Path: 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 1F4331A89AE for ; Thu, 23 Oct 2014 03:44:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.41 X-Spam-Level: * X-Spam-Status: No, score=1.41 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_MISMATCH_NET=0.611, SPF_PASS=-0.001] autolearn=no 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 TTqnfIGDdpEc for ; Thu, 23 Oct 2014 03:44:01 -0700 (PDT) Received: from ian.brad.office.comodo.net (eth5.brad-fw.brad.office.ccanet.co.uk [178.255.87.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5F291A8ABC for ; Thu, 23 Oct 2014 03:43:52 -0700 (PDT) Received: (qmail 29959 invoked by uid 1000); 23 Oct 2014 10:43:47 -0000 Received: from and0004.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (AES128-SHA encrypted) ESMTPSA; Thu, 23 Oct 2014 11:43:47 +0100 Message-ID: <5448DBE2.10107@comodo.com> Date: Thu, 23 Oct 2014 11:43:46 +0100 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Alyssa Rowan , "cfrg@irtf.org" References: <54400E9F.5020905@akr.io><5218FD35-E00A-413F-ACCB-AA9B99DEF48B@shiftleft.org><5444D89F.5080407@comodo.com> <90C609A5-ECB2-4FDC-9669-5830F3463D2B@akr.io> In-Reply-To: <90C609A5-ECB2-4FDC-9669-5830F3463D2B@akr.io> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/RdR9kWlwPvr8_cYnCNJztAz0fJA Subject: Re: [Cfrg] ECC reboot X-BeenThere: cfrg@irtf.org 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: Thu, 23 Oct 2014 10:44:05 -0000 On 20/10/14 14:05, Alyssa Rowan wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > On 20 October 2014 10:40:47 BST, Rob Stradling wrote: > >> When we generated our ECC root CA keys in 2008, secp384r1 seemed like the best choice. secp521r1 wasn't in Suite B, and it seemed likely that Suite B compliance would be a requirement for some of our customers. > > Why not secp256r1? (I'm guessing the big reason was because the TS profile required ≈WF192 and you wanted one root to be suitable for both profiles if you could?) That was certainly part of the reason. The other part was that a competitor had already chosen secp384r1, so it seemed safest to follow suit. :-) > It's a bit early to say, but (open question to all) if we picked one curve at ≈WF128, would you in principle be comfortable with having roots of that strength? In principle, yes, but... > What about if we picked two: one fast secure curve at 128 and one at some higher "paranoid" grade (be it 384, 448, 480, 512, 521, 607...)? Which would you perhaps consider using when? Would you have one root at each level, or a shared root at the paranoid level? I'm inclined to agree with my colleague PHB, who wrote recently: "The Web PKI will almost certainly be based exclusively on the ~512 level curve. The roots certainly will." The various browser root programs place limits on the total number of roots per CA. So whilst a ≈WF128 root could be useful, I think there's a very good chance that we won't have the option to embed both ≈WF128 and ≈WF roots. > What kinds of things would you need to be able to have such a root? I'm guessing, bringing it back home to the weekly topic, that 'high-assurance' crypto hardware of some form would be highly desirable for that. But what does that mean to *you*? Yes, we would need at least one HSM that can generate keys and signatures on the new curves. The speed of the implementation won't matter much. If the new curves are to be used with ECDSA (unlikely?) then I think it might even be possible to persuade existing HSMs to do the job. PKCS#11 supports ANSI x9.62 "EC domain parameters" as well as named curves, for example. > I say this because I don't think the initial target market for these new curves necessarily includes those mandated to use Suite B (although never say never!), I don't think government approval will drive adoption this time, and also the assurances people ask of Web PKI CAs in particular seem to be strengthening considerably relative to where they were (cf: Certificate Transparency, et al). Agreed. >> TLS clients commonly don't specify RSA/SHA-512 and ECDSA/SHA-512 in the TLS signature_algorithms extension. Some servers respond by refusing to serve certs with SHA-512 signatures. > > Thanks for that note. The TLS WG and user-agent participants should probably bear this in mind, down the line, if whatever we come up with is to be accepted and used. > > - -- > /akr > -----BEGIN PGP SIGNATURE----- > Version: APG v1.1.1 > > iQI3BAEBCgAhBQJURQiIGhxBbHlzc2EgUm93YW4gPGFrckBha3IuaW8+AAoJEOyE > jtkWi2t6lFAP/04NXnjKWHI34cZ2OYIs+qCP4q35hKFvbtAX+7MECPmlF+4lrpbS > /Hzu8bjjsLVphsTWbXo8bW7sXCLWzHGkcL4QuvZM56ArngvP17EK3tZIgkFiOjKY > D+hlGskjcAgXDhRvyaEvimuUHQ9BVWmGft0XPnMSucBckq634Bbw3VSdzhq+0yAV > 5awXzKeTkrI9sYrwSXZ/P9TN/ejVjfI0t3KU+RxdMPWTY8psbmXsuaMT8ny4EkOi > PhskwFNb5rndfRBEq/rnenhXAgTnUJVf51vBhU8YOKZLy2NojcZ2Wjy5YOQuDepQ > GE3phWRqxCA4hnhbnNHcguxnlh5B6y5OzEYd/9/Iaia/brj7H3eYvc84RnG1H9Fl > VTkBrAZUUmtcmdnTlNnEBQQ/pmSlGWZsIhLYPueXD43yAggMvP8YffURKADFfm6J > Om5BmI2JVWjFpDjQA7e9NKL6niTJUccqUkHNjm54wEwIuh0zcKJCBzZ4P4cUU+vk > T5BDy3AoVLFT9uVOXV/vXkTA3xcOtlLaUgnTa3CzRR9IuoIewPncK1MurP6I37jA > XzcupAFmTgiDcITjKAm2xzaVzJwWByBbtuvaMBKRFbA1UK++y9/YWnhalwsEmNYf > lo5LnvTuJa/SvmPcpLHqtqeTIIV3rWVdn5GVbZOx5jxao5KK19b/7kMF > =tB0e > -----END PGP SIGNATURE----- > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg > -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online Office Tel: +44.(0)1274.730505 Office Fax: +44.(0)1274.730909 www.comodo.com COMODO CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by COMODO for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. From nobody Thu Oct 23 05:01:48 2014 Return-Path: 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 0CC2B1A916A for ; Thu, 23 Oct 2014 05:01:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 wBlYdvQ9S0oA for ; Thu, 23 Oct 2014 05:01:44 -0700 (PDT) Received: from emh06.mail.saunalahti.fi (emh06.mail.saunalahti.fi [62.142.5.116]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95D351ACEA8 for ; Thu, 23 Oct 2014 05:01:43 -0700 (PDT) Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh06.mail.saunalahti.fi (Postfix) with ESMTP id 7962B69A15; Thu, 23 Oct 2014 15:01:40 +0300 (EEST) Date: Thu, 23 Oct 2014 15:01:40 +0300 From: Ilari Liusvaara To: "Paterson, Kenny" Message-ID: <20141023120139.GA14813@LK-Perkele-VII> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/CXPIzes1GaeS1B82hcbWXwZ6vcU Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] ECC reboot (Was: When's the decision?) X-BeenThere: cfrg@irtf.org 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: Thu, 23 Oct 2014 12:01:46 -0000 On Thu, Oct 16, 2014 at 04:08:18PM +0000, Paterson, Kenny wrote: > > Our first task should be to finalise the requirements that we will use to > guide the selection process. I think we are close, with a couple of > outstanding issues: > > 1. Amount of "wiggle room" that should be permitted. Barring unforseen new way to implement base field math, there will not be much wiggle room if performance is important consideration and curve parameters are choosen minimally. Heck, just see the amount of problems trying to find truly high- performance curve near 384 bits. > 2. A more nuanced set of hardware requirements. Quite blunt, but: Hardware implementations are no consideration. Why: - This is for IETF TLS, and vast majority of endpoints are software. - Software-optimized curves are not too bad for most hardware. - And if they are too bad for some specialized kind of hardware, there already are more suitable curves in TLS. - The kind of hardware needing such curves should not be contacting random peers, so making those peers capable of dealing with the necressary curves is feasible. -Ilari From nobody Thu Oct 23 07:27:12 2014 Return-Path: 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 ABB291A9139 for ; Thu, 23 Oct 2014 07:27:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 YwYP82BYew0j for ; Thu, 23 Oct 2014 07:27:09 -0700 (PDT) Received: from mail-yh0-x236.google.com (mail-yh0-x236.google.com [IPv6:2607:f8b0:4002:c01::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33F6F1A90DA for ; Thu, 23 Oct 2014 07:27:09 -0700 (PDT) Received: by mail-yh0-f54.google.com with SMTP id 29so1058237yhl.13 for ; Thu, 23 Oct 2014 07:27:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=ZPR078U2/Bd+GOxiblXFGz5jJ71KGUrGKJabyc/frLE=; b=NCFMzAMZPaYf/rbiIX/ew2Gbnqe1bnyyYAanRkKPTXBOGAiyTD3XWWJz2ZyXC1e9fr ly4BX2MX90C3VZ2tjVFz3Ek4Go2s+JbVJ0Hp9dhiT5TQFq1lxzpnVgPnIq30MnNecA0m ag/tLDOm6SWbm96TILzAz96tLOEyxMCXahEQvClg7Nnq3wHbJ6sKZrGheroX3OiYu2v1 dQJyCELATpcUZ/S+lmKm3APbUlECd32HFICtgfLvC36nDI/UJ6ZueEn55vj2KbasPaM2 FqRd75aju6QVd1nd8+M1CiFHHSQGs4sKuw5huSHvaUmjeQMEti58ayNw4JGKwENGiFce AQIw== MIME-Version: 1.0 X-Received: by 10.236.53.69 with SMTP id f45mr7771634yhc.65.1414074428531; Thu, 23 Oct 2014 07:27:08 -0700 (PDT) Received: by 10.170.195.149 with HTTP; Thu, 23 Oct 2014 07:27:08 -0700 (PDT) In-Reply-To: <5448DBE2.10107@comodo.com> References: <54400E9F.5020905@akr.io> <5218FD35-E00A-413F-ACCB-AA9B99DEF48B@shiftleft.org> <5444D89F.5080407@comodo.com> <90C609A5-ECB2-4FDC-9669-5830F3463D2B@akr.io> <5448DBE2.10107@comodo.com> Date: Thu, 23 Oct 2014 07:27:08 -0700 Message-ID: From: Watson Ladd To: Rob Stradling Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/bQ1-h8U-mEFGHmHWJlaSW2sez7g Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] ECC reboot X-BeenThere: cfrg@irtf.org 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: Thu, 23 Oct 2014 14:27:11 -0000 On Thu, Oct 23, 2014 at 3:43 AM, Rob Stradling w= rote: > On 20/10/14 14:05, Alyssa Rowan wrote: >> >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA512 >> >> On 20 October 2014 10:40:47 BST, Rob Stradling >> wrote: >> >>> When we generated our ECC root CA keys in 2008, secp384r1 seemed like t= he >>> best choice. secp521r1 wasn't in Suite B, and it seemed likely that Su= ite B >>> compliance would be a requirement for some of our customers. >> >> >> Why not secp256r1? (I'm guessing the big reason was because the TS profi= le >> required =E2=89=88WF192 and you wanted one root to be suitable for both = profiles if >> you could?) > > > That was certainly part of the reason. The other part was that a competi= tor > had already chosen secp384r1, so it seemed safest to follow suit. :-) > >> It's a bit early to say, but (open question to all) if we picked one cur= ve >> at =E2=89=88WF128, would you in principle be comfortable with having roo= ts of that >> strength? > > > In principle, yes, but... > >> What about if we picked two: one fast secure curve at 128 and one at som= e >> higher "paranoid" grade (be it 384, 448, 480, 512, 521, 607...)? Which w= ould >> you perhaps consider using when? Would you have one root at each level, = or a >> shared root at the paranoid level? > > > I'm inclined to agree with my colleague PHB, who wrote recently: > "The Web PKI will almost certainly be based exclusively on the ~512 > level curve. The roots certainly will." Previously, when given a choice of curves, the one with size 384 or thereabouts was picked. Now you are saying you want the biggest possible curve, regardless of the performance impact. I've heard complaints that P384 is already painfully slow to verify on mobile. It's a lot more sensible to pick Goldilocks: just as fast as what you have now, but a few hundred bits bigger. If you really needed 512, you would have already done it. So the fact that you haven't tells me that you don't actually need a 512 or 521 length root key and are perfectly fine with anything above 384 in length. The performance of verification is an issue for some clients already: we don't need to make it worse. > > The various browser root programs place limits on the total number of roo= ts > per CA. So whilst a =E2=89=88WF128 root could be useful, I think there's= a very > good chance that we won't have the option to embed both =E2=89=88WF128 an= d > =E2=89=88WF roots. > >> What kinds of things would you need to be able to have such a root? I'm >> guessing, bringing it back home to the weekly topic, that 'high-assuranc= e' >> crypto hardware of some form would be highly desirable for that. But wha= t >> does that mean to *you*? > > > Yes, we would need at least one HSM that can generate keys and signatures= on > the new curves. The speed of the implementation won't matter much. If t= he > new curves are to be used with ECDSA (unlikely?) then I think it might ev= en > be possible to persuade existing HSMs to do the job. PKCS#11 supports AN= SI > x9.62 "EC domain parameters" as well as named curves, for example. There is a technical issue here. While you could express the curve in Weierstrass form for signatures, that won't give the same results as using Edwards form. So if you wanted to reuse HSMs, that means that we would need to have Weierstrass form keys for signing, and would need to continue the use of a signature algorithm that isn't batchable and is painful because it requires arithmetic modulo the group order. How long do you think it would take to make an HSM that supports our choice? Is this a matter of grab an ARM chip, add some custom firmware, bypass caps, and epoxy (say ~ 6 months), or is it a more involved process? (I'm also unsure of how ECDSA handles cofactors. Will check this) > >> I say this because I don't think the initial target market for these new >> curves necessarily includes those mandated to use Suite B (although neve= r >> say never!), I don't think government approval will drive adoption this >> time, and also the assurances people ask of Web PKI CAs in particular se= em >> to be strengthening considerably relative to where they were (cf: >> Certificate Transparency, et al). > > > Agreed. > >>> TLS clients commonly don't specify RSA/SHA-512 and ECDSA/SHA-512 in th= e >>> TLS signature_algorithms extension. Some servers respond by refusing t= o >>> serve certs with SHA-512 signatures. >> >> >> Thanks for that note. The TLS WG and user-agent participants should >> probably bear this in mind, down the line, if whatever we come up with i= s to >> be accepted and used. >> >> - -- >> /akr >> -----BEGIN PGP SIGNATURE----- >> Version: APG v1.1.1 >> >> iQI3BAEBCgAhBQJURQiIGhxBbHlzc2EgUm93YW4gPGFrckBha3IuaW8+AAoJEOyE >> jtkWi2t6lFAP/04NXnjKWHI34cZ2OYIs+qCP4q35hKFvbtAX+7MECPmlF+4lrpbS >> /Hzu8bjjsLVphsTWbXo8bW7sXCLWzHGkcL4QuvZM56ArngvP17EK3tZIgkFiOjKY >> D+hlGskjcAgXDhRvyaEvimuUHQ9BVWmGft0XPnMSucBckq634Bbw3VSdzhq+0yAV >> 5awXzKeTkrI9sYrwSXZ/P9TN/ejVjfI0t3KU+RxdMPWTY8psbmXsuaMT8ny4EkOi >> PhskwFNb5rndfRBEq/rnenhXAgTnUJVf51vBhU8YOKZLy2NojcZ2Wjy5YOQuDepQ >> GE3phWRqxCA4hnhbnNHcguxnlh5B6y5OzEYd/9/Iaia/brj7H3eYvc84RnG1H9Fl >> VTkBrAZUUmtcmdnTlNnEBQQ/pmSlGWZsIhLYPueXD43yAggMvP8YffURKADFfm6J >> Om5BmI2JVWjFpDjQA7e9NKL6niTJUccqUkHNjm54wEwIuh0zcKJCBzZ4P4cUU+vk >> T5BDy3AoVLFT9uVOXV/vXkTA3xcOtlLaUgnTa3CzRR9IuoIewPncK1MurP6I37jA >> XzcupAFmTgiDcITjKAm2xzaVzJwWByBbtuvaMBKRFbA1UK++y9/YWnhalwsEmNYf >> lo5LnvTuJa/SvmPcpLHqtqeTIIV3rWVdn5GVbZOx5jxao5KK19b/7kMF >> =3DtB0e >> -----END PGP SIGNATURE----- >> >> _______________________________________________ >> Cfrg mailing list >> Cfrg@irtf.org >> http://www.irtf.org/mailman/listinfo/cfrg >> > > -- > Rob Stradling > Senior Research & Development Scientist > COMODO - Creating Trust Online > Office Tel: +44.(0)1274.730505 > Office Fax: +44.(0)1274.730909 > www.comodo.com > > COMODO CA Limited, Registered in England No. 04058690 > Registered Office: > 3rd Floor, 26 Office Village, Exchange Quay, > Trafford Road, Salford, Manchester M5 3EQ > > This e-mail and any files transmitted with it are confidential and intend= ed > solely for the use of the individual or entity to whom they are addressed= . > If you have received this email in error please notify the sender by > replying to the e-mail containing this attachment. Replies to this email = may > be monitored by COMODO for operational or business reasons. Whilst every > endeavour is taken to ensure that e-mails are free from viruses, no > liability can be accepted and the recipient is requested to use their own > virus checking software. > > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg --=20 "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Thu Oct 23 07:43:27 2014 Return-Path: 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 CE6201A9134 for ; Thu, 23 Oct 2014 07:43:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no 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 JEfw8CI6QcF5 for ; Thu, 23 Oct 2014 07:43:23 -0700 (PDT) Received: from mail-lb0-x22d.google.com (mail-lb0-x22d.google.com [IPv6:2a00:1450:4010:c04::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 417E41A90F5 for ; Thu, 23 Oct 2014 07:43:23 -0700 (PDT) Received: by mail-lb0-f173.google.com with SMTP id 10so959795lbg.32 for ; Thu, 23 Oct 2014 07:43:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=81ubOhXcNyMjxnj0+Gnn/mlj6U8Ib/DmKYS7+4PMShs=; b=UPjc6aoi7knAAjWJozhAyIN6Sk8LiBkDT6954fdtwS5IC5GZ86+VX/K1yWGgew+uYq VfSpUMP7YwA0fKdWAY/OXvlECrizryFipy+QAznVpPGxmr4jkAGSQs+yeCV8uXU7pRiE UcLa4CwCcss9wZjHfTkznQmEl/XhL2tccxrBj79b3ZYpb9ZnZXmXhPE0AF8Pu3OhSksm 7YCgCMb9Z/5JYswrjChsTr9R+KqGYPZEKpAxpvi9yn+Wp5N9rmMSFo1DK0CrPyqmBsV0 UEZZd6BlRs2fTF7+cS0vxd7z+g8xBHHOjNQvDLafiFqoSot9yWlDooGq7RzkBTj00xlC 64qg== MIME-Version: 1.0 X-Received: by 10.112.125.33 with SMTP id mn1mr3528491lbb.99.1414075401370; Thu, 23 Oct 2014 07:43:21 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.66.196 with HTTP; Thu, 23 Oct 2014 07:43:21 -0700 (PDT) In-Reply-To: <5448DBE2.10107@comodo.com> References: <54400E9F.5020905@akr.io> <5218FD35-E00A-413F-ACCB-AA9B99DEF48B@shiftleft.org> <5444D89F.5080407@comodo.com> <90C609A5-ECB2-4FDC-9669-5830F3463D2B@akr.io> <5448DBE2.10107@comodo.com> Date: Thu, 23 Oct 2014 10:43:21 -0400 X-Google-Sender-Auth: GBzReJ1X96JKI5xdAU47GNZA5Ls Message-ID: From: Phillip Hallam-Baker To: Rob Stradling Content-Type: multipart/alternative; boundary=089e0116136afc05d705061815f6 Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/KmLmzg_5-s__7NpZwfCqUZAtlls Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] ECC reboot X-BeenThere: cfrg@irtf.org 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: Thu, 23 Oct 2014 14:43:26 -0000 --089e0116136afc05d705061815f6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Oct 23, 2014 at 6:43 AM, Rob Stradling wrote: > On 20/10/14 14:05, Alyssa Rowan wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA512 >> >> On 20 October 2014 10:40:47 BST, Rob Stradling >> wrote: >> >> When we generated our ECC root CA keys in 2008, secp384r1 seemed like >>> the best choice. secp521r1 wasn't in Suite B, and it seemed likely tha= t >>> Suite B compliance would be a requirement for some of our customers. >>> >> >> Why not secp256r1? (I'm guessing the big reason was because the TS >> profile required =E2=89=88WF192 and you wanted one root to be suitable f= or both >> profiles if you could?) >> > > That was certainly part of the reason. The other part was that a > competitor had already chosen secp384r1, so it seemed safest to follow > suit. :-) > > It's a bit early to say, but (open question to all) if we picked one >> curve at =E2=89=88WF128, would you in principle be comfortable with havi= ng roots of >> that strength? >> > > In principle, yes, but... > > What about if we picked two: one fast secure curve at 128 and one at som= e >> higher "paranoid" grade (be it 384, 448, 480, 512, 521, 607...)? Which >> would you perhaps consider using when? Would you have one root at each >> level, or a shared root at the paranoid level? >> > > I'm inclined to agree with my colleague PHB, who wrote recently: > "The Web PKI will almost certainly be based exclusively on the ~512 > level curve. The roots certainly will." > > The various browser root programs place limits on the total number of > roots per CA. So whilst a =E2=89=88WF128 root could be useful, I think t= here's a > very good chance that we won't have the option to embed both =E2=89=88WF1= 28 and > =E2=89=88WF roots. Just to clarify here since the nomenclature tends to switch between WF and bits. I think we will end up at 512 bits which is actually rather more than =E2=89=88WF256 but is considered =E2=89=88WF256 because the rule of thumb = is to halve. Perhaps if we call it P512? Marketing might seem a trivial issue but what we are talking about here is how do we make the ECC story an easy one to explain to the non technical and how do we come to one choice for the industry that has a good chance of sticking. I can form a really good argument for P512 and either P256 or P255 that won't get any objections from the non-technical and the only complaints from technical folk will be on performance grounds: * WF 128 is generally considered to be sufficient unless the algorithm itself is compromised by a new attack * WF 256 is the largest work factor currently supported by industry standard algorithms. * P256 is a very round number * P255 is almost P256 and can be considered an established algorithm * The field has generally favored bit sizes that are a power of 2. Using powers of 2 provides maximum compatibility with general purpose hardware which has progressed from 8 to 16 to 32 to 64 bits for general arithmetic operations with some architectures supporting 128 bit floats and 512 bit integers. Data paths are up to 512 bits. * Going just above a power of 2 means a more complicated implementation. In particular code optimizations are now different depending on whether we are on a 32 or 64 bit machine. If we get into discussion of performance then we are on a slippery slope. We have admitted that we are accepting a tradeoff for a start. And we have to explain that it is the work factor ratio that is important and all sorts of things. The objective here is to arrive at a set of curves that everyone is confident are secure and do not appear to be odd in any way. Curve 255 is being widely used because the implementation is so short, the speed is probably secondary. To implement P512 fast I would write a 512 bit fixed size bignum library. To implement P521 fast I would have to write a 544 or 576 bit bignum library depending on the architecture. Those 9 extra bits are actually a heap of extra complexity. --089e0116136afc05d705061815f6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Oct 23, 2014 at 6:43 AM, Rob Stradling <rob.stradling@c= omodo.com> wrote:
On 20= /10/14 14:05, Alyssa Rowan wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 20 October 2014 10:40:47 BST, Rob Stradling <rob.stradling@comodo.com> wrot= e:

When we generated our ECC root CA keys in 2008, secp384r1 seemed like the b= est choice.=C2=A0 secp521r1 wasn't in Suite B, and it seemed likely tha= t Suite B compliance would be a requirement for some of our customers.

Why not secp256r1? (I'm guessing the big reason was because the TS prof= ile required =E2=89=88WF192 and you wanted one root to be suitable for both= profiles if you could?)

 That was certainly part of the reason.=C2=A0 The other part was that a comp= etitor had already chosen secp384r1, so it seemed safest to follow suit.=C2= =A0 :-)

It's a bit early to say, but (open question to all) if we picked one cu= rve at =E2=89=88WF128, would you in principle be comfortable with having ro= ots of that strength?

 In principle, yes, but...

What about if we picked two: one fast secure curve at 128 and one at some h= igher "paranoid" grade (be it 384, 448, 480, 512, 521, 607...)? W= hich would you perhaps consider using when? Would you have one root at each= level, or a shared root at the paranoid level?

 I'm inclined to agree with my colleague PHB, who wrote recently:
"The Web PKI will almost certainly be based exclusively on the ~512 level curve. The roots certainly will."

The various browser root programs place limits on the total number of roots= per CA.=C2=A0 So whilst a =E2=89=88WF128 root could be useful, I think the= re's a very good chance that we won't have the option to embed both= =E2=89=88WF128 and =E2=89=88WF<paranoid> roots.
Just to clarify here since the nomenclature tends to switch bet= ween WF and bits.

I think we will end up at 512 bi= ts which is actually rather more than =C2=A0=E2=89=88WF256 but is considere= d =E2=89=88WF256 because the rule of thumb is to halve.

Perhaps if we call it P512?

Marketing might = seem a trivial issue but what we are talking about here is how do we make t= he ECC story an easy one to explain to the non technical and how do we come= to one choice for the industry that has a good chance of sticking.


I can form a really good argument for P512= and either P256 or P255 that won't get any objections from the non-tec= hnical and the only complaints from technical folk will be on performance g= rounds:


* WF 128 is generally consi= dered to be sufficient unless the algorithm itself is compromised by a new = attack

* WF 256 is the largest work factor current= ly supported by industry standard algorithms.

* P2= 56 is a very round number
* P255 is almost P256 and can be consid= ered an established algorithm

* The field has= generally favored bit sizes that are a power of 2. Using powers of 2 provi= des maximum compatibility with general purpose hardware which has progresse= d from 8 to 16 to 32 to 64 bits for general arithmetic operations with some= architectures supporting 128 bit floats and 512 bit integers. Data paths a= re up to 512 bits.

* Going just above a powe= r of 2 means a more complicated implementation. In particular code optimiza= tions are now different depending on whether we are on a 32 or 64 bit machi= ne.


If we get into discussion of pe= rformance then we are on a slippery slope. We have admitted that we are acc= epting a tradeoff for a start. And we have to explain that it is the work f= actor ratio that is important and all sorts of things.

=
The objective here is to arrive at a set of curves that everyone is co= nfident are secure and do not appear to be odd in any way.

Curve 255 is being widely used because the implementation is so sh= ort, the speed is probably secondary.

To implement= P512 fast I would write a 512 bit fixed size bignum library.=C2=A0

To implement P521 fast I would have to write a 544 or 576= bit bignum library depending on the architecture.

Those 9 extra bits are actually a heap of extra complexity.=C2=A0
--089e0116136afc05d705061815f6-- From nobody Thu Oct 23 08:10:18 2014 Return-Path: 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 C5BC41AC3A2 for ; Thu, 23 Oct 2014 08:10:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no 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 c2ZojD7YcfrN for ; Thu, 23 Oct 2014 08:10:13 -0700 (PDT) Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com [IPv6:2a00:1450:4010:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D8241A8F49 for ; Thu, 23 Oct 2014 08:09:17 -0700 (PDT) Received: by mail-la0-f47.google.com with SMTP id pv20so1012560lab.20 for ; Thu, 23 Oct 2014 08:09:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=lPLJGUGiJyYUCzco7TtJd1qBHxSVWs6dCDC0VyBfbmc=; b=Rqk/KQjE02eoRus7CWyFDNv5mR7tKhyl36O4IUC3x97GtkU+kEl8J16cr1/90UhZoR rqD1Fx2sgGQme9uxwJ81Lb95KXIL6jeTsdcMqnwkr9otYNry6kd444Zx9cjIe103cjFP yIaywMW6gJAp2c71B4Me0GRgnrmGvlRevoFmIY+5mnMxiI6XRY4fVhgJfq0LXmYV0DCS Kkl4zx5JDoKUsOV3PX0XUeQp1VZfAgUMA5icYiptL6INcfSNEfLUJ5bAE045LVLNihUN 5U7aodx7azB1IHcnINrKYRoRllwRPlDTJrq0Akz39N/04YK97nm5zg13Loz1xWddknZ/ jFhA== MIME-Version: 1.0 X-Received: by 10.152.1.42 with SMTP id 10mr5987387laj.4.1414076956293; Thu, 23 Oct 2014 08:09:16 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.66.196 with HTTP; Thu, 23 Oct 2014 08:09:16 -0700 (PDT) In-Reply-To: References: <54400E9F.5020905@akr.io> <5218FD35-E00A-413F-ACCB-AA9B99DEF48B@shiftleft.org> <5444D89F.5080407@comodo.com> <90C609A5-ECB2-4FDC-9669-5830F3463D2B@akr.io> <5448DBE2.10107@comodo.com> Date: Thu, 23 Oct 2014 11:09:16 -0400 X-Google-Sender-Auth: XNCAmOPzHj4RsCPGSUJRDYa1DP4 Message-ID: From: Phillip Hallam-Baker To: Watson Ladd Content-Type: multipart/alternative; boundary=089e013c65bcaa438405061872f2 Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/O6Fb-XV5KKFpMYdXlyJq4pEf3tw Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] ECC reboot X-BeenThere: cfrg@irtf.org 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: Thu, 23 Oct 2014 15:10:15 -0000 --089e013c65bcaa438405061872f2 Content-Type: text/plain; charset=UTF-8 On Thu, Oct 23, 2014 at 10:27 AM, Watson Ladd wrote: > > > In principle, yes, but... > > > >> What about if we picked two: one fast secure curve at 128 and one at > some > >> higher "paranoid" grade (be it 384, 448, 480, 512, 521, 607...)? Which > would > >> you perhaps consider using when? Would you have one root at each level, > or a > >> shared root at the paranoid level? > > > > > > I'm inclined to agree with my colleague PHB, who wrote recently: > > "The Web PKI will almost certainly be based exclusively on the ~512 > > level curve. The roots certainly will." > > Previously, when given a choice of curves, the one with size 384 or > thereabouts was picked. Now you are saying you want the biggest > possible curve, regardless of the performance impact. I've heard > complaints that P384 is already painfully slow to verify on mobile. > It's a lot more sensible to pick Goldilocks: just as fast as what you > have now, but a few hundred bits bigger. > That really depends on your mobile. Whatever numbers are picked there will always be a significant number of devices being made that are not suited to doing repeated public key operations. There are more 8 bit devices being made today than at any time in the past. But equally important, nobody is looking at ECC as a fast alternative to RSA2048 in consumer oriented devices any more. Commodity processors are cheap enough and low power enough to do RSA2048 without breaking sweat. > If you really needed 512, you would have already done it. So the fact > that you haven't tells me that you don't actually need a 512 or 521 > length root key and are perfectly fine with anything above 384 in > length. The performance of verification is an issue for some clients > already: we don't need to make it worse. We don't really 'need' ECC at all. Unless something happens to RSA2048 that is unexpected, TLS is almost certainly fine for quite a few years yet. Given the mess the NSA has created here, we have to put clear water between our new curves and the old. It is not enough for me to be satisfied that the system is secure. Its the general Internet population that has to be confident that they are safe from having their crypto cracked. How long do you think it would take to make an HSM that supports our > choice? Is this a matter of grab an ARM chip, add some custom > firmware, bypass caps, and epoxy (say ~ 6 months), or is it a more > involved process? > Vastly more involved and producing the hardware and software for the HSM is at most 25% of the effort required. The requirement is for a certified HSM, not just something that we are confident is secure. This is an area where we are likely to require assistance from NIST because they have the only widely used certification program. As a practical matter it is much easier for the NIST people to add a new 512 bit curve to their stable than to add in an additional 384 curve whose advantage over the previous curves is being demonstrably free of perfidy by NIST. --089e013c65bcaa438405061872f2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Oct 23, 2014 at 10:27 AM, Watson Ladd <watsonbladd@gmail.com&g= t; wrote:
> In principle, yes, but...
>
>> What about if we picked two: one fast secure curve at 128 and one = at some
>> higher "paranoid" grade (be it 384, 448, 480, 512, 521, = 607...)? Which would
>> you perhaps consider using when? Would you have one root at each l= evel, or a
>> shared root at the paranoid level?
>
>
> I'm inclined to agree with my colleague PHB, who wrote recently: > "The Web PKI will almost certainly be based exclusively on the ~5= 12
> level curve. The roots certainly will."

Previously, when given a choice of curves, the one with size 38= 4 or
thereabouts was picked. Now you are saying you want the biggest
possible curve, regardless of the performance impact. I've heard
complaints that P384 is already painfully slow to verify on mobile.
It's a lot more sensible to pick Goldilocks: just as fast as what you have now, but a few hundred bits bigger.

That really depends on your mobile. Whatever numbers are picked there wil= l always be a significant number of devices being made that are not suited = to doing repeated public key operations. There are more 8 bit devices being= made today than at any time in the past.

But equa= lly important, nobody is looking at ECC as a fast alternative to RSA2048 in= consumer oriented devices any more. Commodity processors are cheap enough = and low power enough to do RSA2048 without breaking sweat.

=C2=A0
If you really needed 512, you would have already done it. So the fact
that you haven't tells me that you don't actually need a 512 or 521=
length root key and are perfectly fine with anything above 384 in
length. The performance of verification is an issue for some clients
already: we don't need to make it worse.

We don't really 'need' ECC at all. Unless something happens t= o RSA2048 that is unexpected, TLS is almost certainly fine for quite a few = years yet.

Given the mess the NSA has created here= , we have to put clear water between our new curves and the old. It is not = enough for me to be satisfied that the system is secure. Its the general In= ternet population that has to be confident that they are safe from having t= heir crypto cracked.


How long do you think it would take to make an HSM that suppo= rts our
choice? Is this a matter of grab an ARM chip, add some custom
firmware, bypass caps, and epoxy (say ~ 6 months), or is it a more
involved process?

Vastly more involved = and producing the hardware and software for the HSM is at most 25% of the e= ffort required.

The requirement is for a certified= HSM, not just something that we are confident is secure. This is an area w= here we are likely to require assistance from NIST because they have the on= ly widely used certification program.


As a practical matter it is much easier for the NIST people to add a new= 512 bit curve to their stable than to add in an additional 384 curve whose= advantage over the previous curves is being demonstrably free of perfidy b= y NIST.

=C2=A0
--089e013c65bcaa438405061872f2-- From nobody Thu Oct 23 10:06:44 2014 Return-Path: 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 06E3E1ACE12 for ; Thu, 23 Oct 2014 10:06:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.855 X-Spam-Level: **** X-Spam-Status: No, score=4.855 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_71=0.6, RDNS_DYNAMIC=0.982, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no 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 KujXLr51IGbY for ; Thu, 23 Oct 2014 10:06:39 -0700 (PDT) Received: from aspartame.shiftleft.org (199-116-74-168-v301.PUBLIC.monkeybrains.net [199.116.74.168]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1F0A1ACE01 for ; Thu, 23 Oct 2014 10:06:39 -0700 (PDT) Received: from [192.168.1.124] (unknown [192.168.1.1]) by aspartame.shiftleft.org (Postfix) with ESMTPSA id E125D3AA13; Thu, 23 Oct 2014 10:04:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=shiftleft.org; s=sldo; t=1414083854; bh=fVlvXnL4VnrE84ZdiSgRPlHxo6e3KOxBq3Ct1/BUqpE=; h=Date:From:To:CC:Subject:References:In-Reply-To:From; b=MAmpY7wHbPRm3PCmNTuGU8n0h7I+pN3QLbJ6PfgIz8wxo4et9MFrsVOSYRKqk/cwU /c//1EhJZn4E+D4Gc7Gyyj03NhRdywLGTpeeLgUvZZB3wyteodjbBVxPwpdyFfOK8/ H9W5dYtgnBm4KauWtaFhWJ4sC0GbR21c474n9kwA= Message-ID: <5449359C.10105@shiftleft.org> Date: Thu, 23 Oct 2014 10:06:36 -0700 From: Mike Hamburg User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Ilari Liusvaara , David Leon Gil References: <20141022213447.20218.qmail@cr.yp.to> <20141022234258.GA29823@LK-Perkele-VII> In-Reply-To: <20141022234258.GA29823@LK-Perkele-VII> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/Xgb2ra2bDtkkxXu3TcSIRyHWKXs Cc: "cfrg@irtf.org" , "D. J. Bernstein" Subject: Re: [Cfrg] E-521 vs. numsp512t1 X-BeenThere: cfrg@irtf.org 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: Thu, 23 Oct 2014 17:06:41 -0000 On 10/22/2014 04:42 PM, Ilari Liusvaara wrote: > On Wed, Oct 22, 2014 at 07:19:44PM -0400, David Leon Gil wrote: >> On Wed, Oct 22, 2014 at 5:34 PM, D. J. Bernstein wrote: >>> Rob Granger and Mike Scott have posted a new paper "Faster ECC over >>> \F_{2^521-1}" (https://eprint.iacr.org/2014/852) reporting ECC speeds >>> mod 2^521-1, and in particular the first (as far as I know) serious >>> implementation of E-521. >> The implementation djb mentions is available on their website: >> >> http://indigo.ie/~mscott/{ed521,ws521}.cpp >> > > Watch out (from ed521.cpp): > > > void mul(int *w,ECp *P) > { > ECp W[33],Q; > precomp(P,W); > > copy(&W[w[86]],P); > for (int i=85;i>=0;i--) > { > if (w[i]>=0) copy(&W[w[i]],&Q); > else neg(&W[-w[i]],&Q); > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > window(&Q,P); > } > norm(P); > } > > > That does not look constant-time... > > > -Ilari > Also, on curves at moderncrypto dot org, Samuel Neves is reporting (and I can confirm) that the performance numbers do not account for TurboBoost. He measured a slower but still impressive ~884kcy. That said, the Granger-Scott implementation does not take advantage of vectorization or assembly optimizations, even to the degree that Goldilocks does (asm wide multiply and accumulate, mostly there to constrain the scheduler and register allocator). It would be interesting to check its performance with more optimization. On a related note, one of the numbers I reported for Goldilocks (~480k Haswell cycles) also did not account for TurboBoost. DJB's Titan0 SUPERCOP measurement of 529kcy on Haswell is accurate. It turns out that on Ubuntu at least (Linux 3.13.0-29), disabling HyperThreading re-enables TurboBoost, so be careful what order you do it in. Cheers, -- Mike From nobody Thu Oct 23 10:41:10 2014 Return-Path: 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 D94D41A8AA9 for ; Thu, 23 Oct 2014 10:41:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-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 dK0RJKnjxaEl for ; Thu, 23 Oct 2014 10:41:05 -0700 (PDT) Received: from entima.net (entima.net [78.129.143.175]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 265591A8AD2 for ; Thu, 23 Oct 2014 10:41:05 -0700 (PDT) Message-ID: <54493DB1.5070204@akr.io> Date: Thu, 23 Oct 2014 18:41:05 +0100 From: Alyssa Rowan MIME-Version: 1.0 To: "cfrg@irtf.org" References: <54400E9F.5020905@akr.io> <5218FD35-E00A-413F-ACCB-AA9B99DEF48B@shiftleft.org> <5444D89F.5080407@comodo.com> <90C609A5-ECB2-4FDC-9669-5830F3463D2B@akr.io> <5448DBE2.10107@comodo.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/gBdBnCKTFSHmH42MimDk-aSs5uk Subject: Re: [Cfrg] ECC reboot X-BeenThere: cfrg@irtf.org 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: Thu, 23 Oct 2014 17:41:09 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 23/10/2014 15:27, Watson Ladd wrote: >> I'm inclined to agree with my colleague PHB, who wrote recently: >> "The Web PKI will almost certainly be based exclusively on the >> ~512 level curve. The roots certainly will." > Previously, when given a choice of curves, the one with size 384 or > thereabouts was picked. Now you are saying you want the biggest > possible curve, regardless of the performance impact. Not wishing to speak for Rob, but what I _think_ he means here is simply that if there was one curve picked, he'd use it in principle; but given the choice between two curves (a strong fast curve, and a paranoid curve), he'd probably be tempted to go for the paranoid one for the roots? Seems sensible to me: they're the Web PKI roots, after all. They're much longer-lived signing keys than servers, and they will in practice be under sustained, well-funded attack from nation state adversaries. Under those circumstances, the more paranoid level may seem appropriate, but a server key would probably far rather plump for the strong fast curve. I echo your concerns about verification performance and secp384r1, but that _is_ a particularly ugly baby. We can do better than that, even if we pick a curve which is more secure, which is indeed the selling point of Curve41417 and/or Ed448-Goldilocks. (I actually wonder how a well-optimised E-521 would do, even. I guess we'll find out.) Future reference note: May be useful to have state-of-the-art implementations of NIST secp256r1, NIST secp384r1, NIST secp521r1 in the performance shootout as anchors? The way the sign/verify workload is on ECDSA works out well for many servers (where sign's the bottleneck) but it's a little unfortunate for roots (where verify is). > How long do you think it would take to make an HSM that supports > our choice? Depends: from what I've seen a few HSMs are flexible enough to run whatever we choose. (I'll refrain from discussion of specific vendors: it is for them to speak up if they wish.) By the way, as a matter of practicality, would we perhaps be looking at some kind of hybrid transition period where existing ECDSA-P384-SHA384 roots sign (purely by way of example) EdDSA-Curve25519-SHA512 end-entity certificates? How would the choice of end-entity algorithms be restrained by the signing algorithms and curves used on the roots, or not? (I appreciate that may not really be a question for here, but for upstream in TLS or PKIX.) > Is this a matter of grab an ARM chip, add some custom firmware, > bypass caps, and epoxy (say ~ 6 months), or is it a more involved > process? Yes, you _could_ indeed do that. It depends what you want out of it; whether that's a _good_ approach is another question entirely. (Epoxy doesn't really do a lot of good, by the way! ) But it's _certifying_ one that's the ridiculously involved process, as Philip raises. The big challenge in making a commodity security device today is not cryptography, but bureaucracy! However, I have an inkling that those who mistrust the NIST curves may not entirely trust the NIST certifications for _exactly_ the same reasons - so in practice, I wonder about its actual relevance, or the relevance of other certifications. (Besides, we're not picking NIST-approved curves here.) Transparency and open verifiability will probably be way more important in practice to what we're doing here than any government/other existing certifications. An openly-verifiable HSM would be highly desirable. > (I'm also unsure of how ECDSA handles cofactors. Will check this) I think djb posted about that one? Picking a new curve but using an old, relatively-fragile signature scheme when we know we could do better and safer now that the Schnorr patent expired seems a little silly to me, too. That's a discussion for a future date, however. - -- /akr -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJUST2xAAoJEOyEjtkWi2t6NeUQAKjXFfzlgMXOCeNBBSHoD7BI 7nrTiMTM+iGqj+5F0xwQ4KRJTmd9hf6y+MbLAv7HZGDNdVcrNOJPomnj8bQu35dd cK+C7R/Jr/JDdAC5/TOychR8IEpkfwsI5fLYwkoYHL4vwNSQ8ENAt2oGst3D3Tm3 bRKjve0vw9TzGLcn8sdEo83dkfvxW8WJjJrZ44U5gP9MElVio7yqmk4XZrw4ZIoV fAgmWXgpTciIP7yaoHkHo19JMbFkRnpmcraIcqaScf4XOUEMvF0LwyYGxkh8QiQD Cp3cPvatef+mWUoDuhvFNIVwBGJJYD/8RGlXVqWdbC/NidgUpCsHg4DYbBhLlTLT i0DTr9u1QsRGkuRa9CZuXFxAyN9jFiorYqz+F4CnCgrhWm4VYPjPT3XxZYtLshkP txVNKsrxv6N6GCa3yEjkOIdnjdZxY2p7aoa8hqz6irvWNgOORw8nVn/ZTPz3NDVj 2jDixxj1QfBWHp0VAaYv6/xt2kZTXYXcY7/vHFHoMF43O/C5n6qWgYiTmdyg3GZJ /W/Q+lYXYVgSZYSRGYFB2HfltzxJkZc0ZXFX7A2bqRcvMrnwoqn+YjI2uC1jYZXv rlTK+VZN90VtbmuFy2i+gFLpysNIHz5C1SEL9xEtYq4kOoeles14uKtVWLhwsmQ5 61tjNSHkFEAdCn17o2mL =PGsM -----END PGP SIGNATURE----- From nobody Thu Oct 23 10:49:49 2014 Return-Path: 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 9CEA11A0262 for ; Thu, 23 Oct 2014 10:49:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, 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 RN1XPYrqBb7S for ; Thu, 23 Oct 2014 10:49:46 -0700 (PDT) Received: from mail-la0-f48.google.com (mail-la0-f48.google.com [209.85.215.48]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B59F11A90DF for ; Thu, 23 Oct 2014 10:49:39 -0700 (PDT) Received: by mail-la0-f48.google.com with SMTP id gi9so1280262lab.7 for ; Thu, 23 Oct 2014 10:49:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=Tnqh46lD9M9zixrU138JC6ZG1NP6Ii+Eso9fY67h7Wo=; b=a7BzNQTd05Dng4O8jexZRrBk2uhqKIN3Ms+GWTi0R1J3ecQKAZJ2wT89Jhdpnm4ndU uighOS+/RqiPOL7eLsORikvwKDUlZb0JWZZUMleTcxvenNBkIMqKuGfRVmZcLOV9WSf/ vVRGYAXhXlJ8x/SDBWRJncASJCX4jkSolg6YV7lwzDWKC+qSaKubXmw4BOXF0aYCL4Ia 64+cEuWccG6DgM6jPZH1j9tCLo4auAREKdk8ZoHQ7rXHrsUzo/g05aRhCanjGtZCBazg NEvfnI42VXHB08rdghvzfQv5W1HQcNW+ePalcmM7lVr5qVhya3PxxJIi+DdSG9DprzAG IGIw== X-Gm-Message-State: ALoCoQleU1RMMvKOTGmxKjsQ8WunKgz77CXyyiHf4h2ChVxpwYV6xHabETpm4x77XDnZoGckzh0L X-Received: by 10.112.254.162 with SMTP id aj2mr6902284lbd.70.1414086577557; Thu, 23 Oct 2014 10:49:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.4.71 with HTTP; Thu, 23 Oct 2014 10:49:17 -0700 (PDT) In-Reply-To: <54493DB1.5070204@akr.io> References: <54400E9F.5020905@akr.io> <5218FD35-E00A-413F-ACCB-AA9B99DEF48B@shiftleft.org> <5444D89F.5080407@comodo.com> <90C609A5-ECB2-4FDC-9669-5830F3463D2B@akr.io> <5448DBE2.10107@comodo.com> <54493DB1.5070204@akr.io> From: Andy Lutomirski Date: Thu, 23 Oct 2014 10:49:17 -0700 Message-ID: To: Alyssa Rowan Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/jAEcB9J99wdLQ_ktfdVBhA-cguw Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] ECC reboot X-BeenThere: cfrg@irtf.org 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: Thu, 23 Oct 2014 17:49:47 -0000 On Thu, Oct 23, 2014 at 10:41 AM, Alyssa Rowan wrote: >> How long do you think it would take to make an HSM that supports >> our choice? > > Depends: from what I've seen a few HSMs are flexible enough to run > whatever we choose. (I'll refrain from discussion of specific vendors: > it is for them to speak up if they wish.) This seems like a good time to point out that Intel SGX is coming soon. With SGX, some performance-critical HSM applications could be replaced with hardware-assisted secure *software* enclaves on supported Intel chips. For this application, the relevant factors will be software speed (because it's just x86 software), freedom from timing attacks, and freedom from secrets being leaked in memory access patterns. Some users might require certification, but there will be no additional hardware development effort whatsoever to add new curves. --Andy From nobody Thu Oct 23 10:53:31 2014 Return-Path: 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 41B851ACE3B for ; Thu, 23 Oct 2014 10:53:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.52 X-Spam-Level: X-Spam-Status: No, score=0.52 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_71=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no 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 4N3Y8CNETy0Z for ; Thu, 23 Oct 2014 10:53:21 -0700 (PDT) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EE181ACE41 for ; Thu, 23 Oct 2014 10:51:53 -0700 (PDT) Received: by mail-lb0-f182.google.com with SMTP id z11so1235755lbi.41 for ; Thu, 23 Oct 2014 10:51:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=T8EzhJx5+OY0uRlZi6rBik9JUeqCm3rJPj09EmF5gw0=; b=PyOCyBoxyQ+drsc7GJXxHMpqXyW8RYCrglzGxP/xCoaaS1eBl0kZF8GJNozZv+Z+Fx aFkhvwB9WlCDgSHO9tG+8stMod0CyQ5/98a2Nawjs/r0psL780Wg1o8OxGLkp1tJIt+F GL4GT+/2D7pIzQKXni//N5/gNK6Vwjoo5CcTORQiloZZABLeu5XdWx1HRplt+g1hdbXw bSrgYcK8htWdN6Aby4O9G4A143+1ZvQeVnGfrx2bWvIHR19Kf7xjaOr5qLmMyFzY3KDs lQJjDiA9BTLdaqd7hqbnTw4T7tOXEvSbpz/Y2ZGDiFbf2kJnDT01cx9wiRKvtDUxpPPn f/Jg== X-Gm-Message-State: ALoCoQkfzEaGLLqvAgfcDjwwgjiH1UlptVnkNBFfbGQYhRlVbO70P5dunIEoxthitMMY6yBTXCzR X-Received: by 10.152.27.67 with SMTP id r3mr6754844lag.19.1414086711141; Thu, 23 Oct 2014 10:51:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.4.71 with HTTP; Thu, 23 Oct 2014 10:51:30 -0700 (PDT) In-Reply-To: <5449359C.10105@shiftleft.org> References: <20141022213447.20218.qmail@cr.yp.to> <20141022234258.GA29823@LK-Perkele-VII> <5449359C.10105@shiftleft.org> From: Andy Lutomirski Date: Thu, 23 Oct 2014 10:51:30 -0700 Message-ID: To: Mike Hamburg Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/qBulmmKVmS31f8SZnXF2IvS7f6s Cc: "cfrg@irtf.org" , "D. J. Bernstein" Subject: Re: [Cfrg] E-521 vs. numsp512t1 X-BeenThere: cfrg@irtf.org 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: Thu, 23 Oct 2014 17:53:22 -0000 On Thu, Oct 23, 2014 at 10:06 AM, Mike Hamburg wrote: > > > On 10/22/2014 04:42 PM, Ilari Liusvaara wrote: >> >> On Wed, Oct 22, 2014 at 07:19:44PM -0400, David Leon Gil wrote: >>> >>> On Wed, Oct 22, 2014 at 5:34 PM, D. J. Bernstein wrote: >>>> >>>> Rob Granger and Mike Scott have posted a new paper "Faster ECC over >>>> \F_{2^521-1}" (https://eprint.iacr.org/2014/852) reporting ECC speeds >>>> mod 2^521-1, and in particular the first (as far as I know) serious >>>> implementation of E-521. >>> >>> The implementation djb mentions is available on their website: >>> >>> http://indigo.ie/~mscott/{ed521,ws521}.cpp >>> >> >> Watch out (from ed521.cpp): >> >> >> void mul(int *w,ECp *P) >> { >> ECp W[33],Q; >> precomp(P,W); >> >> copy(&W[w[86]],P); >> for (int i=85;i>=0;i--) >> { >> if (w[i]>=0) copy(&W[w[i]],&Q); >> else neg(&W[-w[i]],&Q); >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> window(&Q,P); >> } >> norm(P); >> } >> >> >> That does not look constant-time... >> >> >> -Ilari >> > Also, on curves at moderncrypto dot org, Samuel Neves is reporting (and I > can confirm) that the performance numbers do not account for TurboBoost. He > measured a slower but still impressive ~884kcy. > > That said, the Granger-Scott implementation does not take advantage of > vectorization or assembly optimizations, even to the degree that Goldilocks > does (asm wide multiply and accumulate, mostly there to constrain the > scheduler and register allocator). It would be interesting to check its > performance with more optimization. > > On a related note, one of the numbers I reported for Goldilocks (~480k > Haswell cycles) also did not account for TurboBoost. DJB's Titan0 SUPERCOP > measurement of 529kcy on Haswell is accurate. It turns out that on Ubuntu > at least (Linux 3.13.0-29), disabling HyperThreading re-enables TurboBoost, > so be careful what order you do it in. > I haven't tried it for these types of tests, but something like: $ perf stat ./whatever_benchmark will count cycles directly. As long as the benchmark isn't too memory-heavy and as long as it runs enough loops to wash out the startup time, it might be a much simpler way to do this kind of benchmarking. --Andy From nobody Thu Oct 23 11:17:50 2014 Return-Path: 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 3C7051A9100 for ; Thu, 23 Oct 2014 11:17:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no 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 6hkq2k4wymoy for ; Thu, 23 Oct 2014 11:17:38 -0700 (PDT) Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A02B71A8ACC for ; Thu, 23 Oct 2014 11:17:37 -0700 (PDT) Received: by mail-la0-f52.google.com with SMTP id hz20so1321513lab.25 for ; Thu, 23 Oct 2014 11:17:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=lME3CFMPDvciV1IoJWSzEQK4NrgFOHJiNqHaVfof62I=; b=FIvyNNHlN4nhmjTuEa8ObT5an+Q9bdkswYK55woaqoIhqUJuGkcOja4TtsVaSye42G HOnmUn/049RFP0BSmmZigbmt+7EJNzs872RlHhiFSzIHh5s/4gPXtwgSDyKJtRZjwMuf YG+oT05K5Bkud/v9dD8uXLneUdGplV7yVU3tHrbm14pZEjy6Tp5bLa8LfowDoEwbKrEv XdkDiSlv6BlshtzdvTOVdGDdQtNGWY6GqNGvio4MOBihYbFFlw6o4gPjeeSHNtlpDDYt 5Hhsag2LY9I1TnqjSePHzEI4v0OLM28Vyrx3VZt8e4orqKfA5PFmqEAQ8oDADVg1zUH/ Az1Q== MIME-Version: 1.0 X-Received: by 10.112.28.75 with SMTP id z11mr6785341lbg.49.1414088255507; Thu, 23 Oct 2014 11:17:35 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.66.196 with HTTP; Thu, 23 Oct 2014 11:17:35 -0700 (PDT) In-Reply-To: References: <54400E9F.5020905@akr.io> <5218FD35-E00A-413F-ACCB-AA9B99DEF48B@shiftleft.org> <5444D89F.5080407@comodo.com> <90C609A5-ECB2-4FDC-9669-5830F3463D2B@akr.io> <5448DBE2.10107@comodo.com> <54493DB1.5070204@akr.io> Date: Thu, 23 Oct 2014 14:17:35 -0400 X-Google-Sender-Auth: u4q9R-gc28QRKhaKjooRXM1tXOs Message-ID: From: Phillip Hallam-Baker To: Andy Lutomirski Content-Type: multipart/alternative; boundary=001a1133eca626964a05061b14e6 Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/40zPv5UXLEzq9U4PYiA0ieI-QH4 Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] ECC reboot X-BeenThere: cfrg@irtf.org 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: Thu, 23 Oct 2014 18:17:39 -0000 --001a1133eca626964a05061b14e6 Content-Type: text/plain; charset=UTF-8 On Thu, Oct 23, 2014 at 1:49 PM, Andy Lutomirski wrote: > On Thu, Oct 23, 2014 at 10:41 AM, Alyssa Rowan wrote: > >> How long do you think it would take to make an HSM that supports > >> our choice? > > > > Depends: from what I've seen a few HSMs are flexible enough to run > > whatever we choose. (I'll refrain from discussion of specific vendors: > > it is for them to speak up if they wish.) > > This seems like a good time to point out that Intel SGX is coming > soon. With SGX, some performance-critical HSM applications could be > replaced with hardware-assisted secure *software* enclaves on > supported Intel chips. > > For this application, the relevant factors will be software speed > (because it's just x86 software), freedom from timing attacks, and > freedom from secrets being leaked in memory access patterns. > > Some users might require certification, but there will be no > additional hardware development effort whatsoever to add new curves. > And the AVX-512 extensions provide 512 bit native registers. I don't think it very likely we can persuade any chip vendor to lay down extra signal lines for 521 bits and if they did a 1024 bit data path we would be looking at using all of it, not just 9 extra bits. 256 and 512 bit wide paths are already starting to appear of their own accord as a multipurpose feature. --001a1133eca626964a05061b14e6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Oct 23, 2014 at 1:49 PM, Andy Lutomirski <= luto@amacapital.ne= t> wrote:
= On Thu, Oct 23, 2014 at 10:41 AM, Alyssa Rowan <akr@akr.io> wrote:
>> How long do you think it would take to make an HSM that supports >> our choice?
>
> Depends: from what I've seen a few HSMs are flexible enough to run=
> whatever we choose. (I'll refrain from discussion of specific vend= ors:
> it is for them to speak up if they wish.)

This seems like a good time to point out that Intel SGX is coming soon.=C2=A0 With SGX, some performance-critical HSM applications could be replaced with hardware-assisted secure *software* enclaves on
supported Intel chips.

For this application, the relevant factors will be software speed
(because it's just x86 software), freedom from timing attacks, and
freedom from secrets being leaked in memory access patterns.

Some users might require certification, but there will be no
additional hardware development effort whatsoever to add new curves.

And the AVX-512 extensions provide 512 bit na= tive registers.

I don't think it very likely w= e can persuade any chip vendor to lay down extra signal lines for 521 bits = and if they did a 1024 bit data path we would be looking at using all of it= , not just 9 extra bits.

256 and 512 bit wide path= s are already starting to appear of their own accord as a multipurpose feat= ure.


=C2=A0
--001a1133eca626964a05061b14e6-- From nobody Thu Oct 23 11:29:58 2014 Return-Path: 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 CA9931A0262 for ; Thu, 23 Oct 2014 11:29:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, 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 Asklf_gRsa2i for ; Thu, 23 Oct 2014 11:29:55 -0700 (PDT) Received: from mail-la0-f50.google.com (mail-la0-f50.google.com [209.85.215.50]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D11D1A1ABA for ; Thu, 23 Oct 2014 11:29:55 -0700 (PDT) Received: by mail-la0-f50.google.com with SMTP id s18so1369387lam.37 for ; Thu, 23 Oct 2014 11:29:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=OrUXnV/Ee+XsBJEpMHwE8W2WwVNvF0HhdS02OHQ5THs=; b=Xmb14QPGSMOOgeHiSZqIMBPNJ03cRuuyGdT9gsuiHthpmowlOqp6/J3vDHbUdqrlWU daz0SGxbit68l1Xho1sW1P7qnbRN8yW4vy/yeuHRAuMjo2HfHhtfLUMOpUN0zJ0YKUdI KNGVWggVs+/nhJAnlIVfDfth9s+qkCTz0RYMPCfAO0cE1sDhUZstWqo3//0kgV3X+L3Y tmzm8GZfpjuUi3b6FruWOqOhy5oWrAQo7xRQbq8xm1eHp1sYwBNWFJ0x/HQp11qIL1RA TC6blEvVCsb068ah1jpoBygE38gTXrm4FVW/Oo9eXOEhcawNuxZBMlCyrTjevrGl/dZS bNRA== X-Gm-Message-State: ALoCoQmTF1TOvSJWeiT3d6rbu3sMnaMnqXrxBYR3DUKjAAKojXj3X89Osmnd7Dhy/gA37EzIQaMX X-Received: by 10.152.30.33 with SMTP id p1mr6879269lah.78.1414088542899; Thu, 23 Oct 2014 11:22:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.4.71 with HTTP; Thu, 23 Oct 2014 11:22:02 -0700 (PDT) In-Reply-To: References: <54400E9F.5020905@akr.io> <5218FD35-E00A-413F-ACCB-AA9B99DEF48B@shiftleft.org> <5444D89F.5080407@comodo.com> <90C609A5-ECB2-4FDC-9669-5830F3463D2B@akr.io> <5448DBE2.10107@comodo.com> <54493DB1.5070204@akr.io> From: Andy Lutomirski Date: Thu, 23 Oct 2014 11:22:02 -0700 Message-ID: To: Phillip Hallam-Baker Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/of7yG8qjIAlVEFkQcZBrUXFz9bg Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] ECC reboot X-BeenThere: cfrg@irtf.org 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: Thu, 23 Oct 2014 18:29:57 -0000 On Thu, Oct 23, 2014 at 11:17 AM, Phillip Hallam-Baker wrote: > > > On Thu, Oct 23, 2014 at 1:49 PM, Andy Lutomirski > wrote: >> >> On Thu, Oct 23, 2014 at 10:41 AM, Alyssa Rowan wrote: >> >> How long do you think it would take to make an HSM that supports >> >> our choice? >> > >> > Depends: from what I've seen a few HSMs are flexible enough to run >> > whatever we choose. (I'll refrain from discussion of specific vendors: >> > it is for them to speak up if they wish.) >> >> This seems like a good time to point out that Intel SGX is coming >> soon. With SGX, some performance-critical HSM applications could be >> replaced with hardware-assisted secure *software* enclaves on >> supported Intel chips. >> >> For this application, the relevant factors will be software speed >> (because it's just x86 software), freedom from timing attacks, and >> freedom from secrets being leaked in memory access patterns. >> >> Some users might require certification, but there will be no >> additional hardware development effort whatsoever to add new curves. > > > And the AVX-512 extensions provide 512 bit native registers. > I feel like you're arguing against a straw man here. Unless I misunderstand, the fastest implementations of 512-bit curves don't fit in 512-bit registers either. Ed448-goldilocks, on the other hand, might. Mike? > I don't think it very likely we can persuade any chip vendor to lay down > extra signal lines for 521 bits and if they did a 1024 bit data path we > would be looking at using all of it, not just 9 extra bits. Wait, what? Are you suggesting using primes closer to 1024 bits? That seems even more excessive that 512 or 521 bits. --Andy From nobody Thu Oct 23 12:28:07 2014 Return-Path: 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 E8C401A19EC for ; Thu, 23 Oct 2014 12:28:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 k1VQBFejMR-g for ; Thu, 23 Oct 2014 12:28:04 -0700 (PDT) Received: from emh06.mail.saunalahti.fi (emh06.mail.saunalahti.fi [62.142.5.116]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 098A81A064C for ; Thu, 23 Oct 2014 12:28:04 -0700 (PDT) Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh06.mail.saunalahti.fi (Postfix) with ESMTP id B8165699AF; Thu, 23 Oct 2014 22:28:01 +0300 (EEST) Date: Thu, 23 Oct 2014 22:28:01 +0300 From: Ilari Liusvaara To: Phillip Hallam-Baker Message-ID: <20141023192801.GA30191@LK-Perkele-VII> References: <5218FD35-E00A-413F-ACCB-AA9B99DEF48B@shiftleft.org> <5444D89F.5080407@comodo.com> <90C609A5-ECB2-4FDC-9669-5830F3463D2B@akr.io> <5448DBE2.10107@comodo.com> <54493DB1.5070204@akr.io> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/dnOpiU_N_AGgtpoowJ6OLbAQhrw Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] ECC reboot X-BeenThere: cfrg@irtf.org 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: Thu, 23 Oct 2014 19:28:06 -0000 On Thu, Oct 23, 2014 at 02:17:35PM -0400, Phillip Hallam-Baker wrote: > > And the AVX-512 extensions provide 512 bit native registers. Those are vectored registers. The widest multiply appears to be 64x64->128. Even if 2^512-569 seems like it fits into 8x64 bits, unless you have good carry handling (you don't for SIMD on Intel CPUs), you need 9x64 bits for optimal speed. Now, the 9x64 bits could also store 2^521-1 (or 2^522-2), which have faster reductions due to constant being small and power of two (or 1). This explains why 2^521-1 is faster than 2^512-567, despite having to do 9 extra bits and seemingly break word boundary. Similarly, current fastest implementations for Curve25519 use 5x64 bits, not 4x64 bits. -Ilari From nobody Thu Oct 23 13:14:11 2014 Return-Path: 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 09D431ACFEF for ; Thu, 23 Oct 2014 13:14:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.555 X-Spam-Level: * X-Spam-Status: No, score=1.555 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.982, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no 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 Q9JJTppK12U5 for ; Thu, 23 Oct 2014 13:14:06 -0700 (PDT) Received: from aspartame.shiftleft.org (199-116-74-168-v301.PUBLIC.monkeybrains.net [199.116.74.168]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A6741A0861 for ; Thu, 23 Oct 2014 13:14:06 -0700 (PDT) Received: from [10.184.148.249] (unknown [209.36.6.242]) by aspartame.shiftleft.org (Postfix) with ESMTPSA id 60BA63AA13; Thu, 23 Oct 2014 13:11:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=shiftleft.org; s=sldo; t=1414095101; bh=NWLP00PAinYZLYKhiJCLdvHvN5QR5lgKEdigrLDin+E=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=b51NpydGAoxHJsaL24Y3LM9DDRrjMJhduCZCyfBo9d+IrvpVS7QQ1bnJpsW1iYSAQ zvgPyZuTCRLaeLywuD/+AYzWeh2GVihtTsnbVBmF3e8Hp91jD8Oh+sDwbjnCvErw/7 05IpEGv3HR3kK5p8CtBntzrF5cI7Xh/YjzJjZ64Q= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Michael Hamburg In-Reply-To: Date: Thu, 23 Oct 2014 13:14:05 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <0317470A-AA6A-44FA-A831-81CB93204C78@shiftleft.org> References: <54400E9F.5020905@akr.io> <5218FD35-E00A-413F-ACCB-AA9B99DEF48B@shiftleft.org> <5444D89F.5080407@comodo.com> <90C609A5-ECB2-4FDC-9669-5830F3463D2B@akr.io> <5448DBE2.10107@comodo.com> <54493DB1.5070204@akr.io> To: Andy Lutomirski X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/C0CtQXFPdt7oyiGDBJfR7m6-m0A Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] ECC reboot X-BeenThere: cfrg@irtf.org 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: Thu, 23 Oct 2014 20:14:09 -0000 > On Oct 23, 2014, at 11:22 AM, Andy Lutomirski = wrote: >=20 > On Thu, Oct 23, 2014 at 11:17 AM, Phillip Hallam-Baker > wrote: >>=20 >>=20 >> On Thu, Oct 23, 2014 at 1:49 PM, Andy Lutomirski = >> wrote: >>>=20 >>> On Thu, Oct 23, 2014 at 10:41 AM, Alyssa Rowan wrote: >>>>> How long do you think it would take to make an HSM that supports >>>>> our choice? >>>>=20 >>>> Depends: from what I've seen a few HSMs are flexible enough to run >>>> whatever we choose. (I'll refrain from discussion of specific = vendors: >>>> it is for them to speak up if they wish.) >>>=20 >>> This seems like a good time to point out that Intel SGX is coming >>> soon. With SGX, some performance-critical HSM applications could be >>> replaced with hardware-assisted secure *software* enclaves on >>> supported Intel chips. >>>=20 >>> For this application, the relevant factors will be software speed >>> (because it's just x86 software), freedom from timing attacks, and >>> freedom from secrets being leaked in memory access patterns. >>>=20 >>> Some users might require certification, but there will be no >>> additional hardware development effort whatsoever to add new curves. >>=20 >>=20 >> And the AVX-512 extensions provide 512 bit native registers. >>=20 >=20 > I feel like you're arguing against a straw man here. Unless I > misunderstand, the fastest implementations of 512-bit curves don't fit > in 512-bit registers either. >=20 > Ed448-goldilocks, on the other hand, might. Mike? We don=E2=80=99t actually have alternative implementation of NUMS p512, = so it=E2=80=99s hard to conclusively say that a 9x57 implementation will = be faster, but it seems reasonably likely. Goldilocks should work well in 512-bit registers. If Intel has = single-cycle PMUL[U]DQ on 512 bits, that will become the largest = multiplier on the chip: 8x32x32 -> 8x64 compared to the 64x64->128 = scalar multiplier. The ARM NEON Karatsuba implementation should = translate pretty well to that primitive, but the devil is in the = details. On the other hand, Broadwell is slated to introduce ADCX/ADOX scalar = carry-handling primitives which should mitigate some of the carry = handling issues for packed NUMSp512 math. It probably won=E2=80=99t be = as big a difference as AVX-512, but it=E2=80=99s something. @PHB: How much experience do you have actually implementing elliptic = curves or similar primitives? You have an awful lot to say about why = 512 will be fast in the long run, and I=E2=80=99m curious where that = comes from. Is it =E2=80=9Cjust common sense=E2=80=9D, or have you done = experiments? =E2=80=94 Mike >> I don't think it very likely we can persuade any chip vendor to lay = down >> extra signal lines for 521 bits and if they did a 1024 bit data path = we >> would be looking at using all of it, not just 9 extra bits. >=20 > Wait, what? Are you suggesting using primes closer to 1024 bits? > That seems even more excessive that 512 or 521 bits. >=20 > --Andy >=20 > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg From nobody Thu Oct 23 13:43:59 2014 Return-Path: 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 1A6D21AD3D2 for ; Thu, 23 Oct 2014 13:43:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.29 X-Spam-Level: X-Spam-Status: No, score=-1.29 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_NET=0.611, SPF_PASS=-0.001] autolearn=no 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 W0vUI4r4oHJ2 for ; Thu, 23 Oct 2014 13:43:55 -0700 (PDT) Received: from ian.brad.office.comodo.net (eth5.brad-fw.brad.office.ccanet.co.uk [178.255.87.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22A391AD3E2 for ; Thu, 23 Oct 2014 13:43:54 -0700 (PDT) Received: (qmail 1794 invoked by uid 1000); 23 Oct 2014 20:43:51 -0000 Received: from and0004.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (AES128-SHA encrypted) ESMTPSA; Thu, 23 Oct 2014 21:43:51 +0100 Message-ID: <54496886.2040807@comodo.com> Date: Thu, 23 Oct 2014 21:43:50 +0100 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Alyssa Rowan , "cfrg@irtf.org" References: <54400E9F.5020905@akr.io> <5218FD35-E00A-413F-ACCB-AA9B99DEF48B@shiftleft.org> <5444D89F.5080407@comodo.com> <90C609A5-ECB2-4FDC-9669-5830F3463D2B@akr.io> <5448DBE2.10107@comodo.com> <54493DB1.5070204@akr.io> In-Reply-To: <54493DB1.5070204@akr.io> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/xY7uy5pFjNdFILtvF3bGIc6hfhY Subject: Re: [Cfrg] ECC reboot X-BeenThere: cfrg@irtf.org 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: Thu, 23 Oct 2014 20:43:58 -0000 On 23/10/14 18:41, Alyssa Rowan wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > On 23/10/2014 15:27, Watson Ladd wrote: > >>> I'm inclined to agree with my colleague PHB, who wrote recently: >>> "The Web PKI will almost certainly be based exclusively on the >>> ~512 level curve. The roots certainly will." >> Previously, when given a choice of curves, the one with size 384 or >> thereabouts was picked. Now you are saying you want the biggest >> possible curve, regardless of the performance impact. > > Not wishing to speak for Rob, but what I _think_ he means here is simply > that if there was one curve picked, he'd use it in principle; but given > the choice between two curves (a strong fast curve, and a paranoid > curve), he'd probably be tempted to go for the paranoid one for the roots? Yes. > By the way, as a matter of practicality, would we perhaps be looking at > some kind of hybrid transition period where existing ECDSA-P384-SHA384 > roots sign (purely by way of example) EdDSA-Curve25519-SHA512 end-entity > certificates? Either that or existing RSA roots cross-certifying next generation ECC roots. > How would the choice of end-entity algorithms be > restrained by the signing algorithms and curves used on the roots, or > not? (I appreciate that may not really be a question for here, but for > upstream in TLS or PKIX.) Not. BTW, we're in a hybrid transition period at the moment: our ECDSA-P384-SHA384 roots are cross-certified by our old RSA roots. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From nobody Thu Oct 23 13:52:19 2014 Return-Path: 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 2AB3D1AD430 for ; Thu, 23 Oct 2014 13:52:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no 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 m13xAxwFgdYA for ; Thu, 23 Oct 2014 13:52:16 -0700 (PDT) Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F103C1AD3E2 for ; Thu, 23 Oct 2014 13:52:15 -0700 (PDT) Received: by mail-lb0-f180.google.com with SMTP id n15so1493053lbi.25 for ; Thu, 23 Oct 2014 13:52:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=cwrgnw5g6LSWL1f+zq89BGxK2MPm7Tq/NykBP3H1I9s=; b=bSfCe5ysul6x8aKU5qFfFZzapxMKdY4UwnsqXDJVGP6sxJN1byZNc1qhGSvY4axPaR HXkDgTpN+r3FMGWzFmdvz5biMTjYdP1zw5x/Io9yRXIaoXkhLyDsWuID2vwaZDi3JhEZ luo+nAYJGs74SeJnLVgVgUGTc/fcJNFiow6p11ig/uqS7jjG4TDuzS0cJjrWzv8JcWoo jEVIEPb513KMrtd+HK4Xm/qEC/Fc1fvWEriQ35MKSLAoVXpbtCnksWDOjLO82O86m6oT 0VRfd3V2Xvty24ciYs6x2x9sf5q1H7nt5NNbquwyon+t2hILW9KK33VN93YZ0NR9664t p8dg== MIME-Version: 1.0 X-Received: by 10.112.221.226 with SMTP id qh2mr80640lbc.5.1414097533634; Thu, 23 Oct 2014 13:52:13 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.66.196 with HTTP; Thu, 23 Oct 2014 13:52:13 -0700 (PDT) In-Reply-To: <0317470A-AA6A-44FA-A831-81CB93204C78@shiftleft.org> References: <54400E9F.5020905@akr.io> <5218FD35-E00A-413F-ACCB-AA9B99DEF48B@shiftleft.org> <5444D89F.5080407@comodo.com> <90C609A5-ECB2-4FDC-9669-5830F3463D2B@akr.io> <5448DBE2.10107@comodo.com> <54493DB1.5070204@akr.io> <0317470A-AA6A-44FA-A831-81CB93204C78@shiftleft.org> Date: Thu, 23 Oct 2014 16:52:13 -0400 X-Google-Sender-Auth: fvfxUxfeaam8UylqLpWSlxK8LsY Message-ID: From: Phillip Hallam-Baker To: Michael Hamburg Content-Type: multipart/alternative; boundary=001a1135ecb82b8fe505061d3dba Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/iC4Ja1_1M90Q7-j7GwuNDYEDaL8 Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] ECC reboot X-BeenThere: cfrg@irtf.org 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: Thu, 23 Oct 2014 20:52:18 -0000 --001a1135ecb82b8fe505061d3dba Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Oct 23, 2014 at 4:14 PM, Michael Hamburg wrote= : > > > On Oct 23, 2014, at 11:22 AM, Andy Lutomirski > wrote: > > Goldilocks should work well in 512-bit registers. If Intel has > single-cycle PMUL[U]DQ on 512 bits, that will become the largest multipli= er > on the chip: 8x32x32 -> 8x64 compared to the 64x64->128 scalar multiplier= . > The ARM NEON Karatsuba implementation should translate pretty well to tha= t > primitive, but the devil is in the details. > OK so that is an important data point. What I am trying to get to here is to get people to explain those details in terms more abstract than 'I ran X on Y and got time Z'. On the other hand, Broadwell is slated to introduce ADCX/ADOX scalar > carry-handling primitives which should mitigate some of the carry handlin= g > issues for packed NUMSp512 math. It probably won=E2=80=99t be as big a d= ifference > as AVX-512, but it=E2=80=99s something. > Thats the point, if there is a 512 bit wide register and there is an application that can be accelerated if 512 wide instructions are available there is a reasonable expectation that we can get them implemented. Adding in a Manchester carry chain isn't a big cost, nor is providing a primitive for a fast 512 bit multiply. 512 bit multiply > @PHB: How much experience do you have actually implementing elliptic > curves or similar primitives? You have an awful lot to say about why 512 > will be fast in the long run, and I=E2=80=99m curious where that comes fr= om. Is it > =E2=80=9Cjust common sense=E2=80=9D, or have you done experiments? > Having built large parallel machines and used them for very large tasks, I am going by a little more than common sense. 512 bit arithmetic operations are certainly going to be faster than 521. Now what that implies for implementing Knotted Weierstrass curves with a double Irish Dutch sandwich or whatever is what I am looking for an explanation of in terms that I can explain to the general security community. What I began arguing is that 521 is going to break stride on a 512 bit architecture and should be taken off the table unless the speed advantage is enormous. I don't think we need to implement the algorithm to see that. Now if you are arguing that 512 will also break stride on a 512 bit architecture then that is an important data point that by the same logic argues for looking at a curve that does fit and maybe Golilocks is actually the one. But before conceding that point I would like to see more of an explanation of the optimization being used and how much it delivers. --001a1135ecb82b8fe505061d3dba Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Oct 23, 2014 at 4:14 PM, Michael Hamburg <= mike@shiftleft.org<= /a>> wrote:

> On Oct 23, 2014, at 11:22 AM, Andy Lutomirski <luto@amacapital.net> wrote:

Goldilocks should work well in 512-bit registers.=C2=A0 If Intel has single= -cycle PMUL[U]DQ on 512 bits, that will become the largest multiplier on th= e chip: 8x32x32 -> 8x64 compared to the 64x64->128 scalar multiplier.= =C2=A0 The ARM NEON Karatsuba implementation should translate pretty well t= o that primitive, but the devil is in the details.
OK so that is an important data point.

What I am trying to get to here is to get people to explain those details = in terms more abstract than 'I ran X on Y and got time Z'.


On the other hand, Broadwell is slated to introduce ADCX/ADOX scalar carry-= handling primitives which should mitigate some of the carry handling issues= for packed NUMSp512 math.=C2=A0 It probably won=E2=80=99t be as big a diff= erence as AVX-512, but it=E2=80=99s something.

Thats the point, if there is a 512 bit wide register and there is a= n application that can be accelerated if 512 wide instructions are availabl= e there is a reasonable expectation that we can get them implemented.
=

Adding in a Manchester carry chain isn't a big cost= , nor is providing a primitive for a fast 512 bit multiply. 512 bit multipl= y=C2=A0

=C2=A0
@PHB: How much experience do you have actually implementing elliptic curves= or similar primitives?=C2=A0 You have an awful lot to say about why 512 wi= ll be fast in the long run, and I=E2=80=99m curious where that comes from.= =C2=A0 Is it =E2=80=9Cjust common sense=E2=80=9D, or have you done experime= nts?

Having built large parallel machin= es and used them for very large tasks, I am going by a little more than com= mon sense. 512 bit arithmetic operations are certainly going to be faster t= han 521. Now what that implies for implementing
Knotted Weierstrass cur= ves with a double Irish Dutch sandwich or whatever is what I am looking for= an explanation of in terms that I can explain to the general security comm= unity.


What I began arguing is that= 521 is going to break stride on a 512 bit architecture and should be taken= off the table unless the speed advantage is enormous. I don't think we= need to implement the algorithm to see that.

Now = if you are arguing that 512 will also break stride on a 512 bit architectur= e then that is an important data point that by the same logic argues for lo= oking at a curve that does fit and maybe Golilocks is actually the one.=C2= =A0

But before conceding that point I would like t= o see more of an explanation of the optimization being used and how much it= delivers.=C2=A0
=C2=A0
--001a1135ecb82b8fe505061d3dba-- From nobody Thu Oct 23 13:59:07 2014 Return-Path: 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 AD1881A6ED8 for ; Thu, 23 Oct 2014 13:59:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, 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 vJtBqTC_W3Xz for ; Thu, 23 Oct 2014 13:59:02 -0700 (PDT) Received: from mail-lb0-f175.google.com (mail-lb0-f175.google.com [209.85.217.175]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73EAF1A1B2D for ; Thu, 23 Oct 2014 13:59:02 -0700 (PDT) Received: by mail-lb0-f175.google.com with SMTP id u10so1556321lbd.34 for ; Thu, 23 Oct 2014 13:59:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=xU1vALOUB4BKxOEEFbfM9N9Eypxsa9B9BBWb13/CSig=; b=eU/wZI24eBtxRpBK14dqb0P8Dcd7HxeJUkbNWpT3DrETz33GkYt1hm6YaELNC73eDT 0ag3ivNuTuYjFT2piUuGpZxbTr86v4rXJxJJ2g6oISICvL5gQcjXc4JwJd3JhdBGRvfv LpfZV/zFsk8BQYGAqGb/slbdmBOt4RiolTE8xmrhdVQFnpHK/sX7VCaqdWaNhSWtKUQD qbIHXhkpUeuBhEjLZgs+Zl97OBp1/JA2aHLRC58APCejSnvCFec+MwtbHNE+l19YJt/l 4CkUYXErE4PWyBR5S8XacIcl4Xl13u35jGkw7Kl2ulf9EWq1ukcJ2qfffr7TQX1EP4ES DZmg== X-Gm-Message-State: ALoCoQnYhsqHBw2uUXibbXwb7sv/JLeTnGHM87lDa2zsudovu5fkF1yrxx398gY2HlTs9Xrw7WVr X-Received: by 10.152.27.67 with SMTP id r3mr93276lag.19.1414097940690; Thu, 23 Oct 2014 13:59:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.4.71 with HTTP; Thu, 23 Oct 2014 13:58:40 -0700 (PDT) In-Reply-To: References: <54400E9F.5020905@akr.io> <5218FD35-E00A-413F-ACCB-AA9B99DEF48B@shiftleft.org> <5444D89F.5080407@comodo.com> <90C609A5-ECB2-4FDC-9669-5830F3463D2B@akr.io> <5448DBE2.10107@comodo.com> <54493DB1.5070204@akr.io> <0317470A-AA6A-44FA-A831-81CB93204C78@shiftleft.org> From: Andy Lutomirski Date: Thu, 23 Oct 2014 13:58:40 -0700 Message-ID: To: Phillip Hallam-Baker Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/2YPRXcdwK3SxjanYqb0hfzjLtc0 Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] ECC reboot X-BeenThere: cfrg@irtf.org 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: Thu, 23 Oct 2014 20:59:04 -0000 On Thu, Oct 23, 2014 at 1:52 PM, Phillip Hallam-Baker wrote: > Having built large parallel machines and used them for very large tasks, I > am going by a little more than common sense. 512 bit arithmetic operations > are certainly going to be faster than 521. Now what that implies for > implementing > Knotted Weierstrass curves with a double Irish Dutch sandwich or whatever is > what I am looking for an explanation of in terms that I can explain to the > general security community. > > > What I began arguing is that 521 is going to break stride on a 512 bit > architecture and should be taken off the table unless the speed advantage is > enormous. I don't think we need to implement the algorithm to see that. > > Now if you are arguing that 512 will also break stride on a 512 bit > architecture then that is an important data point that by the same logic > argues for looking at a curve that does fit and maybe Golilocks is actually > the one. I'm really having trouble understanding what you mean by "break stride". I doubt that any implementation of any of these algorithms is even close to fast enough that the time it takes to shove data across the bus is relevant. If someone really builds special-purpose ASICs for this, they they can presumably back a 521-bit register (or any other size register) by a far smaller bus and get excellent performance. --Andy From nobody Thu Oct 23 14:43:51 2014 Return-Path: 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 D70B81A1AD5 for ; Thu, 23 Oct 2014 14:43:47 -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 vd0HFeeTyfeh for ; Thu, 23 Oct 2014 14:43:45 -0700 (PDT) Received: from mail-qc0-x22c.google.com (mail-qc0-x22c.google.com [IPv6:2607:f8b0:400d:c01::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AEFB1A0861 for ; Thu, 23 Oct 2014 14:43:40 -0700 (PDT) Received: by mail-qc0-f172.google.com with SMTP id o8so1297000qcw.31 for ; Thu, 23 Oct 2014 14:43:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=wGfOhPuYKp7AAzU9xLt7eU8vFD+8tb99c+7XLXvIGpA=; b=nuRuLcH43E+NgtMnDN0EpUBeT/MvO43KKqkwGPU/s2Z2Osqow1UXNB78umAxQi4WQn EenKnbJcTUVHpdbJB8CDgqs7ZpMhhyMtiSuxp/atBsL0Lh4wPrcqBYMq0qoOYOacNwq5 vOwMJ8r8Ltjhz5MbCB7K/mvL8UajIygPbY8tNFFM7xUaeG9AjFmmpx181ipTMF0nMXbj LUt9Kl/s1bpOOKcLaxRjZjXc7zfbah2r+pzqlGyqEbreywvKRtspwopanXjRwiyG/7XG 0e2OUghH6pbHEnG9fJtgC/mItqkdOml4SzXFaG0W6jIDQSmx/AkHPotvWLfC9T4e+isv zJEA== MIME-Version: 1.0 X-Received: by 10.170.207.20 with SMTP id y20mr301516yke.28.1414100619179; Thu, 23 Oct 2014 14:43:39 -0700 (PDT) Received: by 10.170.195.149 with HTTP; Thu, 23 Oct 2014 14:43:38 -0700 (PDT) Received: by 10.170.195.149 with HTTP; Thu, 23 Oct 2014 14:43:38 -0700 (PDT) In-Reply-To: References: <54400E9F.5020905@akr.io> <5218FD35-E00A-413F-ACCB-AA9B99DEF48B@shiftleft.org> <5444D89F.5080407@comodo.com> <90C609A5-ECB2-4FDC-9669-5830F3463D2B@akr.io> <5448DBE2.10107@comodo.com> <54493DB1.5070204@akr.io> <0317470A-AA6A-44FA-A831-81CB93204C78@shiftleft.org> Date: Thu, 23 Oct 2014 14:43:38 -0700 Message-ID: From: Watson Ladd To: Phillip Hallam-Baker Content-Type: multipart/alternative; boundary=001a1139e83e1559eb05061df50f Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/6w_38z1u3Eu6-r5Mgr5-waJttrU Cc: cfrg@irtf.org Subject: Re: [Cfrg] ECC reboot X-BeenThere: cfrg@irtf.org 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: Thu, 23 Oct 2014 21:43:48 -0000 --001a1139e83e1559eb05061df50f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Oct 23, 2014 1:52 PM, "Phillip Hallam-Baker" wrote: > > > > On Thu, Oct 23, 2014 at 4:14 PM, Michael Hamburg wrote: >> >> >> > On Oct 23, 2014, at 11:22 AM, Andy Lutomirski wrote: >> >> Goldilocks should work well in 512-bit registers. If Intel has single-cycle PMUL[U]DQ on 512 bits, that will become the largest multiplier on the chip: 8x32x32 -> 8x64 compared to the 64x64->128 scalar multiplier. The ARM NEON Karatsuba implementation should translate pretty well to that primitive, but the devil is in the details. > > > OK so that is an important data point. > > What I am trying to get to here is to get people to explain those details in terms more abstract than 'I ran X on Y and got time Z'. > > >> On the other hand, Broadwell is slated to introduce ADCX/ADOX scalar carry-handling primitives which should mitigate some of the carry handling issues for packed NUMSp512 math. It probably won=E2=80=99t be as big a dif= ference as AVX-512, but it=E2=80=99s something. > > > Thats the point, if there is a 512 bit wide register and there is an application that can be accelerated if 512 wide instructions are available there is a reasonable expectation that we can get them implemented. This is wrong. Many vector units operate on two independent halves internally, introducing an extra delay for any operation that crosses the halves. Furthermore, maximal gate delay times force strict limits on circuit depth. ADOX, ADCX, and MULX are nothing special in comparison. They use existing hardware in slightly nicer ways. The carryless multiply and AES instructions are much more similar to what you propose, and took a long time to get into silicon. Even then the multiply instruction was a sixteenth of the size of what you propose. > > Adding in a Manchester carry chain isn't a big cost, nor is providing a primitive for a fast 512 bit multiply. 512 bit multiply > > >> >> @PHB: How much experience do you have actually implementing elliptic curves or similar primitives? You have an awful lot to say about why 512 will be fast in the long run, and I=E2=80=99m curious where that comes from= . Is it =E2=80=9Cjust common sense=E2=80=9D, or have you done experiments? > > > Having built large parallel machines and used them for very large tasks, I am going by a little more than common sense. 512 bit arithmetic operations are certainly going to be faster than 521. Now what that implies for implementing > Knotted Weierstrass curves with a double Irish Dutch sandwich or whatever is what I am looking for an explanation of in terms that I can explain to the general security community. But it impacts performance in ways that don't show up in benchmarks. If you think 512 can go faster, roll up your sleeves and send it to SUPERCOP. If what you want is hardware support, you will have to explain why it hasn't already happened. If you want to say performance doesn't matter, and the prime picking we use isn't rigid enough, make that argument. But don't say "this is faster" when the benchmarks say otherwise. Sincerely, Watson Ladd > > > What I began arguing is that 521 is going to break stride on a 512 bit architecture and should be taken off the table unless the speed advantage is enormous. I don't think we need to implement the algorithm to see that. > > Now if you are arguing that 512 will also break stride on a 512 bit architecture then that is an important data point that by the same logic argues for looking at a curve that does fit and maybe Golilocks is actually the one. > > But before conceding that point I would like to see more of an explanation of the optimization being used and how much it delivers. > > > _______________________________________________ > Cfrg mailing list >Cfrg@irtf.org >http://www.irtf.org/mailman/listinfo/cfrg > --001a1139e83e1559eb05061df50f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Oct 23, 2014 1:52 PM, "Phillip Hallam-Baker" <phill@hallambaker.com> wrote:
>
>
>
> On Thu, Oct 23, 2014 at 4:14 PM, Michael Hamburg <mike@shiftleft.org> wrote:
>>
>>
>> > On Oct 23, 2014, at 11:22 AM, Andy Lutomirski <luto@amacapital.net> wrote:
>>
>> Goldilocks should work well in 512-bit registers.=C2=A0 If Intel h= as single-cycle PMUL[U]DQ on 512 bits, that will become the largest multipl= ier on the chip: 8x32x32 -> 8x64 compared to the 64x64->128 scalar mu= ltiplier.=C2=A0 The ARM NEON Karatsuba implementation should translate pret= ty well to that primitive, but the devil is in the details.
>
>
> OK so that is an important data point.
>
> What I am trying to get to here is to get people to explain those deta= ils in terms more abstract than 'I ran X on Y and got time Z'.
>
>
>> On the other hand, Broadwell is slated to introduce ADCX/ADOX scal= ar carry-handling primitives which should mitigate some of the carry handli= ng issues for packed NUMSp512 math.=C2=A0 It probably won=E2=80=99t be as b= ig a difference as AVX-512, but it=E2=80=99s something.
>
>
> Thats the point, if there is a 512 bit wide register and there is an a= pplication that can be accelerated if 512 wide instructions are available t= here is a reasonable expectation that we can get them implemented.

This is wrong. Many vector units operate on two independent = halves internally, introducing an extra delay for any operation that crosse= s the halves. Furthermore, maximal gate delay times force strict limits on = circuit depth.

ADOX, ADCX, and MULX are nothing special in comparison.=C2= =A0 They use existing hardware in slightly nicer ways. The carryless multip= ly and AES instructions are much more similar to what you propose, and took= a long time to get into silicon. Even then the multiply instruction was a = sixteenth of the size of what you propose.

>
> Adding in a Manchester carry chain isn't a big cost, nor is provid= ing a primitive for a fast 512 bit multiply. 512 bit multiply=C2=A0
>
> =C2=A0
>>
>> @PHB: How much experience do you have actually implementing ellipt= ic curves or similar primitives?=C2=A0 You have an awful lot to say about w= hy 512 will be fast in the long run, and I=E2=80=99m curious where that com= es from.=C2=A0 Is it =E2=80=9Cjust common sense=E2=80=9D, or have you done = experiments?
>
>
> Having built large parallel machines and used them for very large task= s, I am going by a little more than common sense. 512 bit arithmetic operat= ions are certainly going to be faster than 521. Now what that implies for i= mplementing
> Knotted Weierstrass curves with a double Irish Dutch sandwich or whate= ver is what I am looking for an explanation of in terms that I can explain = to the general security community.

But it impacts performance in ways that don't show up in= benchmarks. If you think 512 can go faster, roll up your sleeves and send = it to SUPERCOP. If what you want is hardware support, you will have to expl= ain why it hasn't already happened.

If you want to say performance doesn't matter, and the p= rime picking we use isn't rigid enough, make that argument.=C2=A0 But d= on't say "this is faster" when the benchmarks say otherwise.<= /p>

Sincerely,
Watson Ladd
>
>
> What I began arguing is that 521 is going to break stride on a 512 bit= architecture and should be taken off the table unless the speed advantage = is enormous. I don't think we need to implement the algorithm to see th= at.
>
> Now if you are arguing that 512 will also break stride on a 512 bit ar= chitecture then that is an important data point that by the same logic argu= es for looking at a curve that does fit and maybe Golilocks is actually the= one.=C2=A0
>
> But before conceding that point I would like to see more of an explana= tion of the optimization being used and how much it delivers.=C2=A0
> =C2=A0
>
> _______________________________________________
> Cfrg mailing list
>Cfrg@irtf.org
>http://www.irtf.o= rg/mailman/listinfo/cfrg
>

--001a1139e83e1559eb05061df50f-- From nobody Thu Oct 23 15:22:50 2014 Return-Path: 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 DBCA91A1B26 for ; Thu, 23 Oct 2014 15:22:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.19 X-Spam-Level: X-Spam-Status: No, score=-3.19 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 90v3i1OCKVa3 for ; Thu, 23 Oct 2014 15:22:35 -0700 (PDT) Received: from smtp.dei.uc.pt (smtp.dei.uc.pt [193.137.203.253]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C50D1A1BDD for ; Thu, 23 Oct 2014 15:22:34 -0700 (PDT) Received: from [192.168.1.71] (bl21-71-239.dsl.telepac.pt [2.82.71.239]) (authenticated bits=0) by smtp.dei.uc.pt (8.14.4/8.14.4) with ESMTP id s9NMM19Y005286 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 23 Oct 2014 23:22:07 +0100 Message-ID: <54497F87.1070801@dei.uc.pt> Date: Thu, 23 Oct 2014 23:21:59 +0100 From: Samuel Neves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 CC: "cfrg@irtf.org" References: <54400E9F.5020905@akr.io> <5218FD35-E00A-413F-ACCB-AA9B99DEF48B@shiftleft.org> <5444D89F.5080407@comodo.com> <90C609A5-ECB2-4FDC-9669-5830F3463D2B@akr.io> <5448DBE2.10107@comodo.com> <54493DB1.5070204@akr.io> <0317470A-AA6A-44FA-A831-81CB93204C78@shiftleft.org> In-Reply-To: <0317470A-AA6A-44FA-A831-81CB93204C78@shiftleft.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (smtp.dei.uc.pt [193.137.203.253]); Thu, 23 Oct 2014 23:22:07 +0100 (WEST) X-FCTUC-DEI-SIC-MailScanner-Information: Please contact helpdesk@dei.uc.pt for more information X-FCTUC-DEI-SIC-MailScanner-ID: s9NMM19Y005286 X-FCTUC-DEI-SIC-MailScanner: Found to be clean X-FCTUC-DEI-SIC-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-59.229, required 3.252, autolearn=not spam, ALL_TRUSTED -10.00, BAYES_00 -0.25, L_SMTP_AUTH -50.00, MISSING_HEADERS 1.02) X-FCTUC-DEI-SIC-MailScanner-From: sneves@dei.uc.pt Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/Z_-77RImCOyQPkzBKsKKI4YavQM Subject: Re: [Cfrg] ECC reboot X-BeenThere: cfrg@irtf.org 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: Thu, 23 Oct 2014 22:22:38 -0000 On 23-10-2014 21:14, Michael Hamburg wrote: > Goldilocks should work well in 512-bit registers. If Intel has single-= cycle PMUL[U]DQ on 512 bits, that will become the largest multiplier on t= he chip: 8x32x32 -> 8x64 compared to the 64x64->128 scalar multiplier. T= he ARM NEON Karatsuba implementation should translate pretty well to that= primitive, but the devil is in the details. AVX-512 has better than VPMUL[U]DQ. Not only does AVX-512* have VPMULLQ (= 64x64->64), which is useful on its own, but also VPMADD52{L,H}UQ, which does a 52-bit multiply followed by a 64-bit a= ddition of either the lower or upper 52 bits of the product. This latter instruction seems to expose the floating-point c= ircuitry to the user. * The fancy version of AVX-512, expected to be in Skylake; Knight's Corne= r only has a limited subset named AVX-512F. From nobody Thu Oct 23 16:14:41 2014 Return-Path: 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 D853F1A1B0D for ; Thu, 23 Oct 2014 16:14:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.555 X-Spam-Level: * X-Spam-Status: No, score=1.555 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.982, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no 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 EGRPs4LYfmxm for ; Thu, 23 Oct 2014 16:14:38 -0700 (PDT) Received: from aspartame.shiftleft.org (199-116-74-168-v301.PUBLIC.monkeybrains.net [199.116.74.168]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2B291A6EFB for ; Thu, 23 Oct 2014 16:14:38 -0700 (PDT) Received: from [10.184.148.249] (unknown [209.36.6.242]) by aspartame.shiftleft.org (Postfix) with ESMTPSA id 1327D3AA13; Thu, 23 Oct 2014 16:12:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=shiftleft.org; s=sldo; t=1414105932; bh=FdtUKXJLRDWW7+rY8YVeghDb/0g6EeI3+GqAbj97dWc=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=S9G7ziqkCA/kkvfhoSO0TndVdaKz/yOD61m0MarRTY6HqRUhRvuCgzk7f6C7qkS2v s74DjqP2bL0ItWNzPeTQ7JlsNoVOk9GscWFx1l5ymtkQDJyOrjX3/34sF1wWWoZf2U cfWwqbL8CICfwJG9o6JadUeLc+1dN1wRuhmwgahE= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Michael Hamburg In-Reply-To: <54497F87.1070801@dei.uc.pt> Date: Thu, 23 Oct 2014 16:14:35 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <54400E9F.5020905@akr.io> <5218FD35-E00A-413F-ACCB-AA9B99DEF48B@shiftleft.org> <5444D89F.5080407@comodo.com> <90C609A5-ECB2-4FDC-9669-5830F3463D2B@akr.io> <5448DBE2.10107@comodo.com> <54493DB1.5070204@akr.io> <0317470A-AA6A-44FA-A831-81CB93204C78@shiftleft.org> <54497F87.1070801@dei.uc.pt> To: Samuel Neves X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/iypS29tVeEjYF9JZZksBYhUax6s Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] ECC reboot X-BeenThere: cfrg@irtf.org 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: Thu, 23 Oct 2014 23:14:40 -0000 > On Oct 23, 2014, at 3:21 PM, Samuel Neves wrote: >=20 > On 23-10-2014 21:14, Michael Hamburg wrote: >> Goldilocks should work well in 512-bit registers. If Intel has = single-cycle PMUL[U]DQ on 512 bits, that will become the largest = multiplier on the chip: 8x32x32 -> 8x64 compared to the 64x64->128 = scalar multiplier. The ARM NEON Karatsuba implementation should = translate pretty well to that primitive, but the devil is in the = details. >=20 > AVX-512 has better than VPMUL[U]DQ. Not only does AVX-512* have = VPMULLQ (64x64->64), which is useful on its own, but > also VPMADD52{L,H}UQ, which does a 52-bit multiply followed by a = 64-bit addition of either the lower or upper 52 bits of > the product. This latter instruction seems to expose the = floating-point circuitry to the user. >=20 > * The fancy version of AVX-512, expected to be in Skylake; Knight's = Corner only has a limited subset named AVX-512F. Oh, huh, that=E2=80=99s pretty neat. At first glance, it looks like = it=E2=80=99d be most useful for an implementation of a 384-bit prime = with radix 2^48. Curve41417 or a curve over 2^416-2^208-1 would also work with radix 2^52 = (since 8*52 =3D 416), but you=E2=80=99d have to reduce almost completely = before multiplying which would offset the gains. A final possibility is that since the register file of AVX512 is = gi-freaking-normous, you could try to do 2-4 multiplies at a time using = the extended addition formula. Then you wouldn=E2=80=99t have to worry = as much about the 416-bit input size of this operation, and it would be = easier to apply to other primes. =E2=80=94 Mike= From nobody Thu Oct 23 20:27:11 2014 Return-Path: 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 5C7DC1A87D0 for ; Thu, 23 Oct 2014 20:27:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.555 X-Spam-Level: * X-Spam-Status: No, score=1.555 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.982, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no 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 cuMTPl7x7AXq for ; Thu, 23 Oct 2014 20:27:06 -0700 (PDT) Received: from aspartame.shiftleft.org (199-116-74-168-v301.PUBLIC.monkeybrains.net [199.116.74.168]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 799B21A1AF1 for ; Thu, 23 Oct 2014 20:27:06 -0700 (PDT) Received: from [10.184.148.249] (unknown [209.36.6.242]) by aspartame.shiftleft.org (Postfix) with ESMTPSA id 3D2273AA13; Thu, 23 Oct 2014 20:24:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=shiftleft.org; s=sldo; t=1414121080; bh=uYHfN7z7eGGnAGyt9iTlt4pb/kNVq32b1+dg+AEC6r8=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=cJIbgSNy6nUwOu0JXurfC++oIDD9qXwy+wKlNZVe4Qk26h3ePPibSrs1gOWV5EbgT OaOocUqaRqmwD/iJ/T80I8dLPpaCAH2jaLgr+ihWL8uJeGeZ2dHgXsULNxSpL/JrkX 5aECmErINiwkH0FtDsEUR8JoQT0tkk2G3Eglsct4= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Michael Hamburg In-Reply-To: Date: Thu, 23 Oct 2014 20:27:03 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <54400E9F.5020905@akr.io> <5218FD35-E00A-413F-ACCB-AA9B99DEF48B@shiftleft.org> <5444D89F.5080407@comodo.com> <90C609A5-ECB2-4FDC-9669-5830F3463D2B@akr.io> <5448DBE2.10107@comodo.com> <54493DB1.5070204@akr.io> <0317470A-AA6A-44FA-A831-81CB93204C78@shiftleft.org> To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/fcGNV3RwDAyexNQ_Ymrugsbkm74 Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] ECC reboot X-BeenThere: cfrg@irtf.org 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, 24 Oct 2014 03:27:08 -0000 > On Oct 23, 2014, at 1:52 PM, Phillip Hallam-Baker = wrote: >=20 > Now if you are arguing that 512 will also break stride on a 512 bit = architecture then that is an important data point that by the same logic = argues for looking at a curve that does fit and maybe Golilocks is = actually the one.=20 >=20 > But before conceding that point I would like to see more of an = explanation of the optimization being used and how much it delivers.=20 >=20 I really ought to write this up in a proper paper. But here=E2=80=99s a = sketch. First of all, many modern implementations use reduced-radix arithmetic. = So curve25519-donna uses 5x51-bit words, and ed448-goldilocks uses = 8x56-bit words, or 16x28-bit words on 32-bit platforms. Let=E2=80=99s = consider Goldilocks on 64-bit. The multiply routine can accumulate several 112-bit products in a = 128-bit register pair without carrying. This is important because carry = handling slows you down even on x86-64 and arm-scalar. It=E2=80=99s = even more important with vector units such as NEON, because carry = handling is much slower when you have to exchange elements between = vectors. The 448-bit size is chosen so that the whole multiply routine = can run on a 32-bit platform (like NEON) without propagating any carries = until the end. For a 64-bit platform, there=E2=80=99s more headroom and = fewer multiplies in that routine, so the next prime up in the family = (2^480 - 2^240 - 1, =E2=80=9CEd480-Ridinghood=E2=80=9D) could be used = instead. But I wanted to ensure that NEON would be fast, so I went with = 448. Conveniently, at this size the working state for a multiply fits = exactly in the NEON register file. Reduced radix also speeds up addition and subtraction, which can now be = vectorized. With too many additions or subtractions, you=E2=80=99ll = need to reduce to avoid overflow (conservatively, of course, since you = can=E2=80=99t usually check in constant-time software). But in the = =E2=80=9Chot=E2=80=9D routines like point additions, most numbers only = go through at most one addition or subtraction before being multiplied. = So they don=E2=80=99t need to be reduced if the multiply routine has a = little extra slack. For Goldilocks, this is true on 64 bit. On 32-bit, = there=E2=80=99s enough slack for an addition in each multiplicand, but = not for two subtractions unless the implementation uses signed numbers = (which it currently doesn=E2=80=99t). So it=E2=80=99s on the edge with = a small performance penalty for reductions, and could probably be tuned = a bit more. OK, so that=E2=80=99s one reason that the prime is less than 512 bits: = it=E2=80=99s designed to be represented internally in 512 bits, but some = of those bits are headroom for carries. It=E2=80=99s probably the = biggest prime that can do this on a 32-bit machine. (The biggest such = =E2=80=9CCrandall=E2=80=9D prime is DJB's 2^414-17.) The other main design point is the =E2=80=9Cgolden Solinas=E2=80=9D form = p =3D t^2 - t - 1, where t =3D 2^224. I=E2=80=99m calling it = =E2=80=9Cgolden=E2=80=9D (and Goldilocks) because t is the golden ratio = mod p. This is a Solinas trinomial, the sparsest kind of prime except = for Mersenne primes like 2^521-1. The NIST curves taught us a lesson = about Solinas primes: they can be fast, but the coefficients are = constraining. Since most of the NIST primes have lots of 32-bit aligned = coefficients, they suck on 64-bit machines and prevent you from reducing = the radix to eg 28 bits. The Goldilocks prime mitigates that problem by having only one = coefficient, right in the middle. So if you are representing your = numbers in an even number of words, reduction is really simple. This = makes any word size favorable if it is equal to (full radix) or slightly = less than (reduced radix) a divisor of 448/2: [1, 2, 4, 7, 8, 14, 16, = 28, 32, 56, 112, 224]. So while it doesn=E2=80=99t work perfectly on = every word size, it should work well on full-radix 16, full- or = reduced-radix 32, or full-radix 64-bit machines. Many of the options = involve 2^n limbs in reduced-radix mode, which vectorizes really well. In short, because it=E2=80=99s a Solinas trinomial, p has the second = most efficient reduction algorithm after Mersenne primes. You don=E2=80=99= t get quite as many choices of efficient word layout as with a Crandall = prime 2^big - small (which has no internal coefficient), but the = golden-ratio structure is pretty much the best you can get on a Solinas = prime. There are only a few options for bit lengths of primes of this shape. = The crypto-sized ones are 216, 322, 416, 448, 450 and 480. Note also = that 2^448 - p ~ sqrt(p). So security issues such as biases from not = being really close to a power of 2 are always less than 1/sqrt(p), which = is your security target anyway. Likewise, the curve=E2=80=99s order = will look basically the same as for a Crandall prime. There=E2=80=99s one more advantage to the golden-ratio structure. The = Goldilocks prime works very well with Karatsuba multiplication. Recall = that Karatsuba computes (a + bt) (c + dt) =3D ac + bdt^2 + = ((a+b)(c+d)-ac-bd)t, where t is either a polynomial term or a multiple = of the word size. So it saves one multiplication at the cost of several = additions. This is usually combined with reduced-radix math so that you = don=E2=80=99t have to handle carries in (a+b) and (c+d). Let t =3D 2^224, so that t^2 =3D t+1 mod the Goldilocks prime. Reducing = the above, (a+bt)(c+dt) =3D=3D ac + bd + ((a+b)(c+d)-ac)t. That is, = reduction mod p makes the Karatsuba formula slightly simpler instead of = more complex. The products above =E2=80=94 ac etc. =E2=80=94 will be wider than t, and = so will also need to be reduced. So it=E2=80=99s also important that = this formula multiplied by t is also simple: (a+bt)(c+dt)t =3D (a+b)(c+d)(1+t) + bdt - ac. The actual math code uses variants of these formulas depending on the = platform, for better locality or pipelining or whatever, but the basic = idea is the same. Since a and b are 4x56-bit numbers, they can be added = with a single 4-lane vectorized add; likewise for c and d. All in all, = this Karatsuba technique may or may not be profitable on AVX-512, but it = is definitely profitable on x86-64 and NEON. So for example, on a 64-bit machine, the Goldilocks field multiply uses = approximately: * 2x4x64-bit vector adds * 5 widening multiplies and 43 multiply-accumulates * 5 128-bit additions and 4 128-bit subtractions * Two final 64-bit for a total of about 54 ADD/SUB and 52 ADC/SBB. = I=E2=80=99m not looking at asm though, so I probably missed some. * 10 radix adjustments (mask and shift a 128-bit variable). The multiplies are easy to interleave at different place values, because = carries don=E2=80=99t propagate. This improves performance noticeably = on some platforms. Without Karatsuba, you=E2=80=99d need at least 64 multiply-accumulates. = Or with packed math at this size, you=E2=80=99d need 49 multiplies (48 = accumulates), but the accumulates would be wider, 192 bits, and thus = much slower. A Goldilocks add takes: * 2x4x64-bit vector adds It should be done in a few cycles, maybe less if it=E2=80=99s inline. By comparison, a 512-bit packed multiply (Comba like in MS NUMS) uses: * 1 widening multiply * 3 64x64->128-bit multiply-accumulates * 60 64x64->192-bit multiply-accumulates, if I=E2=80=99ve calculated = right=20 * 8 small multiply-accumulates (64x64->128 bits) for reduction * at least one, maybe two rounds of carry propagation after the = reduction This comes out to order of 80 ADD and 140 ADC instructions. Remember = that MUL isn=E2=80=99t that much more expensive than ADC on recent Intel = cores, and even on AMD it=E2=80=99s only twice as expensive. It=E2=80=99s= still possible to interleave the multiplications, but it=E2=80=99s = trickier because of carry propagation. Some platforms have faster carry propagation, including ARM scalar = (UMAAL) and the upcoming Intel Broadwell (MULX/ADCX/ADOX). But usually = vector units don=E2=80=99t have this, and ARM's NEON vector unit is a = huge win =E2=80=94 like triple the performance =E2=80=94 if you can use = it efficiently. A packed NUMSp512 add takes: * one add * 7 adds with carry in a chain * a multplication for the reduction * probably two rounds of carry propagation This sort of carry propagation is most of why NUMSp512 takes about twice = as long as Goldilocks. Overall, these optimizations give a curve which is 64 bits longer than = NUMS p384 with <10% worse performance, and 64 bits shorter than NUMS = p512 with about double the performance. So if you mock up an = =E2=80=9Cefficiency=E2=80=9D metric which trades off bit length for = speed, Goldilocks scores very well. Its main competitors in this region = would be its 480-bit cousin (but not on 32-bit), or 2^521-1, which I = still think is pretty good despite your criticism. There are other families of fast primes, as outlined in my email on = prime performance, but at a size of =E2=80=9Cbetween about 384 bits and = about 512 bits=E2=80=9D, Goldilocks is one of only a few really good = ones. Cheers, =E2=80=94 Mike From nobody Fri Oct 24 04:37:28 2014 Return-Path: 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 707881A8AB5 for ; Fri, 24 Oct 2014 04:37:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 5cX_tSSgMLG2 for ; Fri, 24 Oct 2014 04:37:23 -0700 (PDT) Received: from emh04.mail.saunalahti.fi (emh04.mail.saunalahti.fi [62.142.5.110]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6FD51A8993 for ; Fri, 24 Oct 2014 04:37:21 -0700 (PDT) Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh04.mail.saunalahti.fi (Postfix) with ESMTP id 92CCF1A2648; Fri, 24 Oct 2014 14:37:18 +0300 (EEST) Date: Fri, 24 Oct 2014 14:37:18 +0300 From: Ilari Liusvaara To: Alyssa Rowan Message-ID: <20141024113718.GA21089@LK-Perkele-VII> References: <54400E9F.5020905@akr.io> <5218FD35-E00A-413F-ACCB-AA9B99DEF48B@shiftleft.org> <5444D89F.5080407@comodo.com> <90C609A5-ECB2-4FDC-9669-5830F3463D2B@akr.io> <5448DBE2.10107@comodo.com> <54493DB1.5070204@akr.io> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <54493DB1.5070204@akr.io> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/4sTxHiA9xu9SAw3--ozheX6m-xo Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] ECC reboot X-BeenThere: cfrg@irtf.org 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, 24 Oct 2014 11:37:26 -0000 On Thu, Oct 23, 2014 at 06:41:05PM +0100, Alyssa Rowan wrote: > > On 23/10/2014 15:27, Watson Ladd wrote: > > I echo your concerns about verification performance and secp384r1, but > that _is_ a particularly ugly baby. We can do better than that, even if > we pick a curve which is more secure, which is indeed the selling point > of Curve41417 and/or Ed448-Goldilocks. (I actually wonder how a > well-optimised E-521 would do, even. I guess we'll find out.) There's also 416-bit prime equally fast to Ed448 prime (-> ~7% faster scalarmult for 16 less bits of security). > Future reference note: May be useful to have state-of-the-art > implementations of NIST secp256r1, NIST secp384r1, NIST secp521r1 in the > performance shootout as anchors? I think definitely so. I would set CPU budget for high curve at secp384r1. This should give at least ~190 bits of security, possibly >200. > The way the sign/verify workload is on ECDSA works out well for many > servers (where sign's the bottleneck) but it's a little unfortunate for > roots (where verify is). Simple idea: One could cache CA certificate validations (and also sites using exceptionally long keys). There shouldn't be THAT many CA certificates out there in open internet for that to be a serious storage challenge. And while there are undoubtedly more in private, one typically does not see very much of those. > > How long do you think it would take to make an HSM that supports > > our choice? > > Depends: from what I've seen a few HSMs are flexible enough to run > whatever we choose. (I'll refrain from discussion of specific vendors: > it is for them to speak up if they wish.) > > By the way, as a matter of practicality, would we perhaps be looking at > some kind of hybrid transition period where existing ECDSA-P384-SHA384 > roots sign (purely by way of example) EdDSA-Curve25519-SHA512 end-entity > certificates? How would the choice of end-entity algorithms be > restrained by the signing algorithms and curves used on the roots, or > not? (I appreciate that may not really be a question for here, but for > upstream in TLS or PKIX.) I think this is technically possible (dunno if it is a good idea). > > Is this a matter of grab an ARM chip, add some custom firmware, > > bypass caps, and epoxy (say ~ 6 months), or is it a more involved > > process? > > Yes, you _could_ indeed do that. It depends what you want out of it; > whether that's a _good_ approach is another question entirely. (Epoxy > doesn't really do a lot of good, by the way! ) E.g. doesn't stop EM attacks. And apparently even if software is hardened against software attacks, it tends to be rather vulernable to EM attacks. I would imagine such software would be written to apply heavy blinding, at great cost for signing time. But such signing doesn't occur that often. > > (I'm also unsure of how ECDSA handles cofactors. Will check this) > > I think djb posted about that one? > > Picking a new curve but using an old, relatively-fragile signature > scheme when we know we could do better and safer now that the Schnorr > patent expired seems a little silly to me, too. That's a discussion for > a future date, however. Heck, there are even older signature schemes that are easier (no need for private inversion when signing). -Ilari From nobody Sun Oct 26 22:35:02 2014 Return-Path: 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 1A4721A8998 for ; Sun, 26 Oct 2014 22:35:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_LOW=-0.7, UNPARSEABLE_RELAY=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 sYavT14IPblh for ; Sun, 26 Oct 2014 22:34:59 -0700 (PDT) Received: from mace.cs.uic.edu (mace.cs.uic.edu [131.193.32.224]) by ietfa.amsl.com (Postfix) with SMTP id B8F2B1A8996 for ; Sun, 26 Oct 2014 22:34:58 -0700 (PDT) Received: (qmail 15743 invoked by uid 1011); 27 Oct 2014 05:34:53 -0000 Received: from unknown (unknown) by unknown with QMTP; 27 Oct 2014 05:34:53 -0000 Received: (qmail 13078 invoked by uid 1001); 27 Oct 2014 05:34:52 -0000 Date: 27 Oct 2014 05:34:52 -0000 Message-ID: <20141027053452.13077.qmail@cr.yp.to> From: "D. J. Bernstein" To: cfrg@irtf.org Mail-Followup-To: cfrg@irtf.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/QvI6X1yZz85YY8v8AzCYWhLl8sA Subject: [Cfrg] Actual security levels for IETF crypto X-BeenThere: cfrg@irtf.org 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: Mon, 27 Oct 2014 05:35:00 -0000 CFRG's stated goal in the curve-selection process is to "provide real value" not just to TLS but "the IETF more widely". As an illustration of how crypto is in fact used in other IETF protocols, here are the three most common security levels chosen by top-level domains that use DNSSEC: ~80-bit security (1024-bit RSA): 286 TLDs. ~90-bit security (1280-bit RSA): 192 TLDs. ~110-bit security (2048-bit RSA): 22 TLDs. The fastest-growing category is ~90-bit security (1280-bit RSA). I don't see how this fits the "marketing department needs powers of 2" theory. I do see how it fits the "users are choosing weak crypto for performance reasons" theory. ---Dan From nobody Mon Oct 27 06:27:32 2014 Return-Path: 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 2082B1AC416 for ; Mon, 27 Oct 2014 06:27:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 tkev1CsKDLKi for ; Mon, 27 Oct 2014 06:27:17 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id B72AD1A923E for ; Mon, 27 Oct 2014 06:27:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id B6DE8BE14 for ; Mon, 27 Oct 2014 13:27:16 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S4L6dmzMYaN9 for ; Mon, 27 Oct 2014 13:27:15 +0000 (GMT) Received: from [10.87.48.12] (unknown [86.42.26.211]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 170C1BE12 for ; Mon, 27 Oct 2014 13:27:15 +0000 (GMT) Message-ID: <544E4832.8030600@cs.tcd.ie> Date: Mon, 27 Oct 2014 13:27:14 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: cfrg@irtf.org References: <20141027053452.13077.qmail@cr.yp.to> In-Reply-To: <20141027053452.13077.qmail@cr.yp.to> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/luiCBPaGQ0zXvXqhPUIe5UROOgI Subject: Re: [Cfrg] Actual security levels for IETF crypto X-BeenThere: cfrg@irtf.org 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: Mon, 27 Oct 2014 13:27:20 -0000 On 27/10/14 05:34, D. J. Bernstein wrote: > CFRG's stated goal in the curve-selection process is to "provide real > value" not just to TLS but "the IETF more widely". As an illustration of > how crypto is in fact used in other IETF protocols, here are the three > most common security levels chosen by top-level domains that use DNSSEC: > > ~80-bit security (1024-bit RSA): 286 TLDs. > ~90-bit security (1280-bit RSA): 192 TLDs. > ~110-bit security (2048-bit RSA): 22 TLDs. > > The fastest-growing category is ~90-bit security (1280-bit RSA). I don't > see how this fits the "marketing department needs powers of 2" theory. I > do see how it fits the "users are choosing weak crypto for performance > reasons" theory. I don't think you can safely extrapolate from DNSSEC deployment to "actual...IETF crypto." TLS is far far more widely deployed. (Its fair to say that DNSSEC deployment is a bit sad, and to try to make that better, but that's a different point.) S. > > ---Dan > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg > > From nobody Mon Oct 27 08:35:38 2014 Return-Path: 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 CB6D21A8AA6 for ; Mon, 27 Oct 2014 08:35:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 2aR7S0qN1MAf for ; Mon, 27 Oct 2014 08:35:33 -0700 (PDT) Received: from mail-yk0-x229.google.com (mail-yk0-x229.google.com [IPv6:2607:f8b0:4002:c07::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5E891A88C0 for ; Mon, 27 Oct 2014 08:35:21 -0700 (PDT) Received: by mail-yk0-f169.google.com with SMTP id 142so440661ykq.28 for ; Mon, 27 Oct 2014 08:35:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Kk4Ngee7bB57ttcDZ4tvAuZN4iWzFiLXvwtvzt22neM=; b=vlGKqknXbQ9ytHyz6IcE8KPTU3sC+Y9FfzwEFARY0g/ggz7FNYSm7a/ul2miwKLwLE Odl4eh48AkQeD2sSoua9aT+EbwMiLX6bWmT5Z6YV22RAdNJPsuU+m8zlIoodg4SJrECi MORHmE9KEDirHjHChU1OaGt7UFxm3TPbpRHyzsy1Bx1iLpieAjj0Lh21AC7QwKou13+c AI2BQHXh94GSK074+Vp2bqm42Sp/cq1WRxTj/yd8mD7tF9KkHkKvKIYVXfi0KvjhaHBo kr01xTlA0gvt1awQ4cFWQH4naTGSzon4ldW3rjiWnGsks4VnlxKYWNyC2af5trcwwn5k I/sg== MIME-Version: 1.0 X-Received: by 10.236.30.197 with SMTP id k45mr9188825yha.163.1414424121078; Mon, 27 Oct 2014 08:35:21 -0700 (PDT) Received: by 10.170.195.149 with HTTP; Mon, 27 Oct 2014 08:35:21 -0700 (PDT) In-Reply-To: <544E4832.8030600@cs.tcd.ie> References: <20141027053452.13077.qmail@cr.yp.to> <544E4832.8030600@cs.tcd.ie> Date: Mon, 27 Oct 2014 08:35:21 -0700 Message-ID: From: Watson Ladd To: Stephen Farrell Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/l7VLkT8YFvWUrxdi8KopXAAivoM Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] Actual security levels for IETF crypto X-BeenThere: cfrg@irtf.org 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: Mon, 27 Oct 2014 15:35:36 -0000 On Mon, Oct 27, 2014 at 6:27 AM, Stephen Farrell wrote: > > > > On 27/10/14 05:34, D. J. Bernstein wrote: > > CFRG's stated goal in the curve-selection process is to "provide real > > value" not just to TLS but "the IETF more widely". As an illustration of > > how crypto is in fact used in other IETF protocols, here are the three > > most common security levels chosen by top-level domains that use DNSSEC: > > > > ~80-bit security (1024-bit RSA): 286 TLDs. > > ~90-bit security (1280-bit RSA): 192 TLDs. > > ~110-bit security (2048-bit RSA): 22 TLDs. > > > > The fastest-growing category is ~90-bit security (1280-bit RSA). I don't > > see how this fits the "marketing department needs powers of 2" theory. I > > do see how it fits the "users are choosing weak crypto for performance > > reasons" theory. > > I don't think you can safely extrapolate from DNSSEC deployment > to "actual...IETF crypto." TLS is far far more widely deployed. > (Its fair to say that DNSSEC deployment is a bit sad, and to try > to make that better, but that's a different point.) Are you saying that DNSSEC isn't an IETF protocol? Or that we should only look at widely deployed protocols when determining how choices about what to deploy are made? Or that DNSSEC doesn't have the same "marketing issue" as TLS? Even if we look at TLS, performance matters a lot: it's the number 1 cited reason for not deploying TLS, and the stated reason we had this Curve25519 in TLS draft in the first place. Furthermore, I'm sure if we crawled server certificates, we would see close to no E521 usage, either at the roots or intermediates, or leaves. The EFF SSL Observatory has the data: I would need to analyze it to see exactly what is going on. We could easily achieve higher levels of security by expanding RSA keys, or using larger Diffie Hellman moduli. The only reason we don't is that performance matters, and bandwidth matters. And when you ignore these factors, you get DNSSEC, which has massive amplification issues and is nowhere near as secure as it could be if elliptic curve signatures had been used instead of RSA. Sincerely, Watson Ladd > > > S. > > > > > ---Dan > > > > _______________________________________________ > > Cfrg mailing list > > Cfrg@irtf.org > > http://www.irtf.org/mailman/listinfo/cfrg > > > > > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Mon Oct 27 09:04:23 2014 Return-Path: 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 0E79E1A88F4 for ; Mon, 27 Oct 2014 09:04:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 1YWksYjA6lgd for ; Mon, 27 Oct 2014 09:04:16 -0700 (PDT) Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C4221A0029 for ; Mon, 27 Oct 2014 09:03:24 -0700 (PDT) Received: by mail-la0-f54.google.com with SMTP id gm9so6157989lab.27 for ; Mon, 27 Oct 2014 09:03:23 -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 :content-transfer-encoding:message-id:references:to; bh=QHLd/wtiEQlpCRJKZOEVszTbwlXf6BCUQxU+k3+58RQ=; b=PtDmKoG5UjD3YTqhfO/OOw49nplBXD48qdWkP5WBw0qVHv3t9x8lHhHEwDI+7Tgirg DGCnlW4OaXbv5b5fr8rz2F/rgfxTP42IZBiI5/o1a9Xv6mYDftPPNrcut2YmMFn4d7UM pVY7hsIe8KcBurpDW0sHZNA0soac4t2SLLohR60G/ow6eZHCESK1hlzQ+0JbApKVkz9L I2YuyYIYpkC8OI8vZDFYqrtYppDqzotqTmyYRHdLoUc9pQVl/OoCpcHto8yE2swV6Ri3 TQkaxJn9YHp8nuz66kapkbZau89/G3SMmWsCPPhlwt0ShX9NjD/APKsP7+qzbhAdYUDo 937Q== X-Received: by 10.112.41.168 with SMTP id g8mr24309729lbl.59.1414425802956; Mon, 27 Oct 2014 09:03:22 -0700 (PDT) Received: from [172.24.249.90] (dyn32-131.checkpoint.com. [194.29.32.131]) by mx.google.com with ESMTPSA id x1sm5119751laa.20.2014.10.27.09.03.21 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 27 Oct 2014 09:03:22 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Yoav Nir In-Reply-To: Date: Mon, 27 Oct 2014 18:03:19 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <810FD859-5CE9-4163-9749-973ED4F810CA@gmail.com> References: <20141027053452.13077.qmail@cr.yp.to> <544E4832.8030600@cs.tcd.ie> To: Watson Ladd X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/5NQe-nnB3nr-GFRfsG0lNzl3leg Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] Actual security levels for IETF crypto X-BeenThere: cfrg@irtf.org 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: Mon, 27 Oct 2014 16:04:19 -0000 > On Oct 27, 2014, at 5:35 PM, Watson Ladd = wrote: >=20 > On Mon, Oct 27, 2014 at 6:27 AM, Stephen Farrell > wrote: >>=20 >>=20 >>=20 >> On 27/10/14 05:34, D. J. Bernstein wrote: >>> CFRG's stated goal in the curve-selection process is to "provide = real >>> value" not just to TLS but "the IETF more widely". As an = illustration of >>> how crypto is in fact used in other IETF protocols, here are the = three >>> most common security levels chosen by top-level domains that use = DNSSEC: >>>=20 >>> ~80-bit security (1024-bit RSA): 286 TLDs. >>> ~90-bit security (1280-bit RSA): 192 TLDs. >>> ~110-bit security (2048-bit RSA): 22 TLDs. >>>=20 >>> The fastest-growing category is ~90-bit security (1280-bit RSA). I = don't >>> see how this fits the "marketing department needs powers of 2" = theory. I >>> do see how it fits the "users are choosing weak crypto for = performance >>> reasons" theory. >>=20 >> I don't think you can safely extrapolate from DNSSEC deployment >> to "actual...IETF crypto." TLS is far far more widely deployed. >> (Its fair to say that DNSSEC deployment is a bit sad, and to try >> to make that better, but that's a different point.) >=20 > Are you saying that DNSSEC isn't an IETF protocol? Or that we should > only look at widely deployed protocols when determining how choices > about what to deploy are made? As the IETF or the IRTF all we can ever do is publish RFCs recommending = this or that. What is deployed is not up to us. We=E2=80=99ve had three = newer version of TLS since 1999, and there=E2=80=99s still a = depressingly large amount of SSLv3 going on. We can recommend that = people stop using 1024-bit RSA, but it=E2=80=99s only when auditors = start failing audits when such certificates are present, and when CAs = refuse to sign such certificates that they actually go away. The = auditors and the CAs have some power. We don=E2=80=99t. So no, we = don=E2=80=99t recommend 90-bit security for DNSSEC, but people deploy = what they deploy. And since auditors and reporters don=E2=80=99t care = about DNSSEC, using 90-bit security doesn=E2=80=99t get you any bad = points anywhere. And we have no control of that. > Or that DNSSEC doesn't have the same > "marketing issue" as TLS? Even if we look at TLS, performance matters > a lot: it's the number 1 cited reason for not deploying TLS, and the > stated reason we had this Curve25519 in TLS draft in the first place. Performance matters. That is why AES-GCM is gaining popularity fast. But = ECDHE is also becoming much more common, even with RSA certificates, and = that is a net loss for a server over RSA keying. > Furthermore, I'm sure if we crawled server certificates, we would see > close to no E521 usage, either at the roots or intermediates, or > leaves. The EFF SSL Observatory has the data: I would need to analyze > it to see exactly what is going on. Or you can see Mozilla=E2=80=99s telemetry: = http://telemetry.mozilla.org/#filter=3Drelease%2F32%2FSSL_AUTH_ECDSA_CURVE= _FULL&aggregates=3Dmultiselect-all!Submissions&evoOver=3DBuilds&locked=3Dt= rue&sanitize=3Dtrue&renderhistogram=3DGraph 5.12 G observations of P-256 8.48 K observations of P-384 135 observations of P-521 > We could easily achieve higher levels of security by expanding RSA > keys, or using larger Diffie Hellman moduli. The only reason we don't > is that performance matters, and bandwidth matters. And when you > ignore these factors, you get DNSSEC, which has massive amplification > issues and is nowhere near as secure as it could be if elliptic curve > signatures had been used instead of RSA. >=20 > Sincerely, > Watson Ladd From nobody Mon Oct 27 17:36:08 2014 Return-Path: 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 73ADD1A0363 for ; Mon, 27 Oct 2014 17:36:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 YGS4XFIWbA03 for ; Mon, 27 Oct 2014 17:36:04 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 380651A0360 for ; Mon, 27 Oct 2014 17:36:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 1109EBE1D; Tue, 28 Oct 2014 00:36:03 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AMuCRr0dSN2y; Tue, 28 Oct 2014 00:36:02 +0000 (GMT) Received: from [10.87.48.12] (unknown [86.46.26.9]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id EDFA4BE0A; Tue, 28 Oct 2014 00:36:01 +0000 (GMT) Message-ID: <544EE4F1.2070201@cs.tcd.ie> Date: Tue, 28 Oct 2014 00:36:01 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Watson Ladd References: <20141027053452.13077.qmail@cr.yp.to> <544E4832.8030600@cs.tcd.ie> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/9K_7-mrYk1DF-yabatv4YZB6CFc Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] Actual security levels for IETF crypto X-BeenThere: cfrg@irtf.org 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: Tue, 28 Oct 2014 00:36:05 -0000 On 27/10/14 15:35, Watson Ladd wrote: > Are you saying that DNSSEC isn't an IETF protocol? Or that we should > only look at widely deployed protocols when determining how choices > about what to deploy are made? Or that DNSSEC doesn't have the same > "marketing issue" as TLS? None of the above. I was saying (only) that that extrapolation is dodgy. If I measured a bunch of Dutch folks' heights, and assumed that the average of those told me something about the average height of a human I'd be making the same extrapolation mistake. S. From nobody Mon Oct 27 18:24:54 2014 Return-Path: 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 140321A8826 for ; Mon, 27 Oct 2014 18:24:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 d9vjWoqu28rH for ; Mon, 27 Oct 2014 18:24:50 -0700 (PDT) Received: from mail-yk0-x22b.google.com (mail-yk0-x22b.google.com [IPv6:2607:f8b0:4002:c07::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD4641A882B for ; Mon, 27 Oct 2014 18:24:50 -0700 (PDT) Received: by mail-yk0-f171.google.com with SMTP id 20so887626yks.30 for ; Mon, 27 Oct 2014 18:24:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7FYWzixZoXsyCB/faDjYXtzl6yK+2PXiwxzla3E8ASc=; b=G7H70OVpGZMotf7El057lT/3dc480WAa9alEsqAPrEL0a67vznPQkoZQ2yd09WXj1z 7G0Mq9deZKM/CipiMVUt2h1wN68fkmUMW3WW3umHijCwY7f5fzWCydn6xEXwHrvghci6 piunyY+f7HPLuQ5v87TovF2dD4xJtceT3Dr1hoz9/+xqoMCHIaEKEeV36Ppvi/pNnWg0 ccOIMByJdZcVRHFPEa/l6AODdrQir/PupmV8i6nfXMY9QRoIT2GGHFBRXLrQmxsaEuID kDWtwjai65MwuVGBpnStscomxcglmLITiHKXYbZG0Kzc2IT8iGCku9R6R2zT5MoHr5df KwYw== MIME-Version: 1.0 X-Received: by 10.170.214.6 with SMTP id g6mr181269ykf.34.1414459490086; Mon, 27 Oct 2014 18:24:50 -0700 (PDT) Received: by 10.170.195.149 with HTTP; Mon, 27 Oct 2014 18:24:50 -0700 (PDT) In-Reply-To: <544EE4F1.2070201@cs.tcd.ie> References: <20141027053452.13077.qmail@cr.yp.to> <544E4832.8030600@cs.tcd.ie> <544EE4F1.2070201@cs.tcd.ie> Date: Mon, 27 Oct 2014 18:24:50 -0700 Message-ID: From: Watson Ladd To: Stephen Farrell Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/PQiIANt2T7Fb4pDiOL3fd1kSfEQ Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] Actual security levels for IETF crypto X-BeenThere: cfrg@irtf.org 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: Tue, 28 Oct 2014 01:24:53 -0000 On Mon, Oct 27, 2014 at 5:36 PM, Stephen Farrell wrote: > > > On 27/10/14 15:35, Watson Ladd wrote: >> Are you saying that DNSSEC isn't an IETF protocol? Or that we should >> only look at widely deployed protocols when determining how choices >> about what to deploy are made? Or that DNSSEC doesn't have the same >> "marketing issue" as TLS? > > None of the above. I was saying (only) that that extrapolation > is dodgy. Huh? The point DJB and I are trying to make is that deployment of crypto is frequently performance constrained, and that the marketing benefits of the NUMS curves are completely overstated, as shown by the fact that people don't deploy crypto because it has nice round numbers, but because it meets the performance demands they have. In particular, it's clear that people prefer P384 to P521 in TLS, because of performance issues (or maybe compatibility). It's also clear that RSA deployments in DNSSEC with very low security remain popular, in part because of specific issues with DNSSEC that essentially require RSA+SHA1 to be used for backwards compatibility, and that end up capping the maximum security at that of RSA: these reasons don't apply as strongly to TLS. (Furthermore, OAEP was introduced a full 6 years before RFC 3110 was written. Guess what RFC 3110 uses?) If you think DNSSEC and the data we have on TLS certificates are both wrong, go ahead and find a crypto deployment that you think actually is representative, or explain that factors that make these irrelevant. Just as if Microsoft thinks the numbers we are getting for their curves are wrong, they should submit them to SUPERCOP. (hint hint). But don't say that the real world, observed, behavior and choices of users, are irrelevant to deciding what their preferences are. Sincerely, Watson Ladd > > If I measured a bunch of Dutch folks' heights, and assumed that > the average of those told me something about the average height > of a human I'd be making the same extrapolation mistake. > > S. -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Mon Oct 27 21:43:51 2014 Return-Path: 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 C63821A049A for ; Mon, 27 Oct 2014 21:43:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 0Cxqby4kGfGY for ; Mon, 27 Oct 2014 21:43:47 -0700 (PDT) Received: from resqmta-ch2-10v.sys.comcast.net (resqmta-ch2-10v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:42]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EC741A0469 for ; Mon, 27 Oct 2014 21:43:47 -0700 (PDT) Received: from resomta-ch2-19v.sys.comcast.net ([69.252.207.115]) by resqmta-ch2-10v.sys.comcast.net with comcast id 8Ujm1p0042VvR6D01UjmXM; Tue, 28 Oct 2014 04:43:46 +0000 Received: from [192.168.1.2] ([71.202.164.227]) by resomta-ch2-19v.sys.comcast.net with comcast id 8Ujj1p0024uhcbK01UjlRs; Tue, 28 Oct 2014 04:43:46 +0000 Message-ID: <544F1EFE.2000109@brainhub.org> Date: Mon, 27 Oct 2014 21:43:42 -0700 From: Andrey Jivsov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: cfrg@irtf.org References: <20141027053452.13077.qmail@cr.yp.to> <544E4832.8030600@cs.tcd.ie> <544EE4F1.2070201@cs.tcd.ie> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1414471426; bh=39Hczh2Fv+m3B1P41VT6j2QNHlUuUMQJMR8RJT1b7Bw=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=DIMrNw1KuqJ48kWqpxCWc6F5snFO5EMq5P4W64NVH1VhDHD1XpJDQvl5fjgx87Ug7 LRJwdA1CLPeV54kSuTGTXdbMYaQcXb9gmlwrMN8EsyAUzihWB9EY5mKQ4G8r5zAVX4 jvU/v7nPiWQ81ydDW1iy5wqGsArJFvuR+9LtupwRDi+4WPIkMxTk6ZxjDjr0VLtD4+ n+HLO4RROweiSL6N53PbOuizmUhyrMBj/86z2gOo/+O28yEWcktQcTWVU0CVoQZ7X3 bM6fcagz/PMKKcj6uW9zpvwoNTMJK2cdggtzNqY6z5LU1Cx53vzrxkG0oD/zjgsarb SfVL5CCvh6kLg== Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/y9z0t9RDpWTRM1WqcRaQv64L_s4 Subject: Re: [Cfrg] Actual security levels for IETF crypto X-BeenThere: cfrg@irtf.org 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: Tue, 28 Oct 2014 04:43:49 -0000 On 10/27/2014 06:24 PM, Watson Ladd wrote: > On Mon, Oct 27, 2014 at 5:36 PM, Stephen Farrell > wrote: >> >> >> On 27/10/14 15:35, Watson Ladd wrote: >>> Are you saying that DNSSEC isn't an IETF protocol? Or that we should >>> only look at widely deployed protocols when determining how choices >>> about what to deploy are made? Or that DNSSEC doesn't have the same >>> "marketing issue" as TLS? >> >> None of the above. I was saying (only) that that extrapolation >> is dodgy. > > Huh? The point DJB and I are trying to make is that deployment of > crypto is frequently performance constrained, and that the marketing > benefits of the NUMS curves are completely overstated, as shown by the > fact that people don't deploy crypto because it has nice round > numbers, but because it meets the performance demands they have. > > In particular, it's clear that people prefer P384 to P521 in TLS, > because of performance issues (or maybe compatibility). Among these two, I think this is more due to Suite B and patents. > It's also > clear that RSA deployments in DNSSEC with very low security remain > popular, in part because of specific issues with DNSSEC that > essentially require RSA+SHA1 to be used for backwards compatibility, > and that end up capping the maximum security at that of RSA: these > reasons don't apply as strongly to TLS. > > (Furthermore, OAEP was introduced a full 6 years before RFC 3110 was > written. Guess what RFC 3110 uses?) > > If you think DNSSEC and the data we have on TLS certificates are both > wrong, go ahead and find a crypto deployment that you think actually > is representative, or explain that factors that make these irrelevant. > Just as if Microsoft thinks the numbers we are getting for their > curves are wrong, they should submit them to SUPERCOP. (hint hint). > But don't say that the real world, observed, behavior and choices of > users, are irrelevant to deciding what their preferences are. > > Sincerely, > Watson Ladd > >> >> If I measured a bunch of Dutch folks' heights, and assumed that >> the average of those told me something about the average height >> of a human I'd be making the same extrapolation mistake. >> >> S. > > > From nobody Mon Oct 27 22:28:56 2014 Return-Path: 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 8DD551A0358 for ; Mon, 27 Oct 2014 22:28:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no 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 lJ5pyjalomlL for ; Mon, 27 Oct 2014 22:28:54 -0700 (PDT) Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 191611A0277 for ; Mon, 27 Oct 2014 22:28:53 -0700 (PDT) Received: by mail-lb0-f180.google.com with SMTP id z12so3416129lbi.25 for ; Mon, 27 Oct 2014 22:28:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=VB5iN9ZcAdfo2G0C9niI1oUp3oCWT0b3gTE7dB5vluU=; b=Sl7FUIGSNPMIHju4TqGqPDS2YqyuWjuiKrd+iijQcLKLjMZEyBoBnqZz9l5qvw+CQC +qxuXPT9aRqjfJa/Qh4rAMOeYzYExP2ejEHzpc2Mtmd3fbCMDfS2mU16lIWafjelE2i8 3ENKDoZ6oFn24Ed9gmR6Mo3VDlUMKkGuxq/KdDw+Y0Gmltxn6RIEmqk0j0r+oRz/VZWu 5N2OcZMcC8g2RU96TxAdKPaz52KrJe2OFqTTzhu9mLSYg8nIJGgd5a5GEd8VlO8xWc7D wB0A7Xp772I4KurOMvau7pm22KBOFFUYI36zNFW0PrHgOgg3fqPMDjU+wq9fz3XJ1nAr ZHvg== MIME-Version: 1.0 X-Received: by 10.152.234.136 with SMTP id ue8mr1052658lac.21.1414474132278; Mon, 27 Oct 2014 22:28:52 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.214.163 with HTTP; Mon, 27 Oct 2014 22:28:52 -0700 (PDT) In-Reply-To: <544EE4F1.2070201@cs.tcd.ie> References: <20141027053452.13077.qmail@cr.yp.to> <544E4832.8030600@cs.tcd.ie> <544EE4F1.2070201@cs.tcd.ie> Date: Tue, 28 Oct 2014 01:28:52 -0400 X-Google-Sender-Auth: HEZD3oZUZNlLYzMuiE2550tXyCI Message-ID: From: Phillip Hallam-Baker To: Stephen Farrell Content-Type: multipart/alternative; boundary=001a11349c4c32d310050674eccf Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/YZkRynrzNb9WSBNpZrjJ6Yd2cf0 Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] Actual security levels for IETF crypto X-BeenThere: cfrg@irtf.org 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: Tue, 28 Oct 2014 05:28:55 -0000 --001a11349c4c32d310050674eccf Content-Type: text/plain; charset=UTF-8 On Mon, Oct 27, 2014 at 8:36 PM, Stephen Farrell wrote: > > > On 27/10/14 15:35, Watson Ladd wrote: > > Are you saying that DNSSEC isn't an IETF protocol? Or that we should > > only look at widely deployed protocols when determining how choices > > about what to deploy are made? Or that DNSSEC doesn't have the same > > "marketing issue" as TLS? > > None of the above. I was saying (only) that that extrapolation > is dodgy. > > If I measured a bunch of Dutch folks' heights, and assumed that > the average of those told me something about the average height > of a human I'd be making the same extrapolation mistake. > A more apt comparison might be to try to measure average human height from a sample of Formula One drivers. There is a good reason folk choose a small key for DNS related work, the original protocol was limited to 500 bytes and quite a few bits of the Internet are still limited by the ancient ethernet MTU which isn't much bigger. Funny that someone would present this particular argument then accuse others of 'marketing' as if it was a bad thing. My actual argument was that the market is subject to a one-upmanship effect that tends to drive key sizes upwards. So if there is 384 and 512 on offer with the new curves, don't expect anyone to use 384. --001a11349c4c32d310050674eccf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Mon, Oct 27, 2014 at 8:36 PM, Stephen Farrell <stephen.farrell@= cs.tcd.ie> wrote:


On 27/10/14 15:35, Watson Ladd wrote:
> Are you saying that DNSSEC isn't an IETF protocol? Or that we shou= ld
> only look at widely deployed protocols when determining how choices > about what to deploy are made? Or that DNSSEC doesn't have the sam= e
> "marketing issue" as TLS?

None of the above. I was saying (only) that that extrapolation
is dodgy.

If I measured a bunch of Dutch folks' heights, and assumed that
the average of those told me something about the average height
of a human I'd be making the same extrapolation mistake.

A more apt comparison might be to try to measure aver= age human height from a sample of Formula One drivers.

There is a good reason folk choose a small key for DNS related wor= k, the original protocol was limited to 500 bytes and quite a few bits of t= he Internet are still limited by the ancient ethernet MTU which isn't m= uch bigger.


Funny that someone woul= d present this particular argument then accuse others of 'marketing'= ; as if it was a bad thing.

My actual argument was= that the market is subject to a one-upmanship effect that tends to drive k= ey sizes upwards. So if there is 384 and 512 on offer with the new curves, = don't expect anyone to use 384.
--001a11349c4c32d310050674eccf-- From nobody Mon Oct 27 23:29:49 2014 Return-Path: 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 B592F1A00FC for ; Mon, 27 Oct 2014 23:29:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 EmvsP6krowBs for ; Mon, 27 Oct 2014 23:29:45 -0700 (PDT) Received: from mail-yk0-x22d.google.com (mail-yk0-x22d.google.com [IPv6:2607:f8b0:4002:c07::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74E621A00FE for ; Mon, 27 Oct 2014 23:29:45 -0700 (PDT) Received: by mail-yk0-f173.google.com with SMTP id 131so3709ykp.32 for ; Mon, 27 Oct 2014 23:29:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=rg2Zp8aUzqkJjztyjAHjN/Wu2n9xPXnitTT5E3SLpN0=; b=ub52TsvunN1V79mmj7wSQ8Z5UUTwz5L+57vHUHBf7Rf9h/RtxcvRVhTGF2Z8FGwGVg NN+bTQR8ecPyYvfdGqqb2CdlIdiUK1LNpcvO3GJIU8kDNIhldLjyJAyu2pdhgsVe5gRl asRyyq4QXHOEkhyNk6F7t8oAhRltrecx0cjrR6ZruhtHn0iJAXhvNjIh2oAPUoEtAy2u 6joj72ltgCcO357LaG+Zxj+8jNJk6mUNLiihVT9PQx2qyzi3Vr6MMrWiACzP7LtRpxhc JjaHPK20LgCytRsXKg0EnWJjIyLTKCb783wrc3NST5EftUj3R1qBITvsqwFTte9MFqAt ty4g== MIME-Version: 1.0 X-Received: by 10.170.209.206 with SMTP id a197mr1261646ykf.24.1414477784709; Mon, 27 Oct 2014 23:29:44 -0700 (PDT) Received: by 10.170.195.149 with HTTP; Mon, 27 Oct 2014 23:29:44 -0700 (PDT) In-Reply-To: References: <20141027053452.13077.qmail@cr.yp.to> <544E4832.8030600@cs.tcd.ie> <544EE4F1.2070201@cs.tcd.ie> Date: Mon, 27 Oct 2014 23:29:44 -0700 Message-ID: From: Watson Ladd To: Phillip Hallam-Baker Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/MGcUVPmclQ3gUqzog9gZLrPg3t4 Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] Actual security levels for IETF crypto X-BeenThere: cfrg@irtf.org 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: Tue, 28 Oct 2014 06:29:47 -0000 On Mon, Oct 27, 2014 at 10:28 PM, Phillip Hallam-Baker wrote: > > On Mon, Oct 27, 2014 at 8:36 PM, Stephen Farrell > wrote: >> >> >> >> On 27/10/14 15:35, Watson Ladd wrote: >> > Are you saying that DNSSEC isn't an IETF protocol? Or that we should >> > only look at widely deployed protocols when determining how choices >> > about what to deploy are made? Or that DNSSEC doesn't have the same >> > "marketing issue" as TLS? >> >> None of the above. I was saying (only) that that extrapolation >> is dodgy. >> >> If I measured a bunch of Dutch folks' heights, and assumed that >> the average of those told me something about the average height >> of a human I'd be making the same extrapolation mistake. > > > A more apt comparison might be to try to measure average human height from a > sample of Formula One drivers. > > There is a good reason folk choose a small key for DNS related work, the > original protocol was limited to 500 bytes and quite a few bits of the > Internet are still limited by the ancient ethernet MTU which isn't much > bigger. NIST P-256 is in the DNSSEC spec, and does fit in 500 bytes. (64 bytes in fact). DNSSEC failed to select small keys with adequate security, and instead selected medium size keys with poor security, for reasons that are now irrelevant, and were probably bogus even then. But even in the range of keys that do fit, people are not going to the maximum possible security. > > > Funny that someone would present this particular argument then accuse others > of 'marketing' as if it was a bad thing. > > My actual argument was that the market is subject to a one-upmanship effect > that tends to drive key sizes upwards. So if there is 384 and 512 on offer > with the new curves, don't expect anyone to use 384. But this didn't happen to 256 bit curves, which are still widely used to protect TLS. It also didn't happen to 384 bit curves in PKIX: no one is moving to 521 bit curves, in part because of compatibility issues, but also because of lack of demand. It also hasn't happened to RSA key sizes: the most popular key size on the web from Mozilla telemetry is 2048 bits, with 4096 the next most popular, and the ludicrously oversized 16384 virtually unseen in comparison. It also hasn't happened to root certificates: Based on a cursory look (because clicking through every CA preloaded on my Mac was too much) I would say there are between 30-35 RSA 4096 certificates, compared to a vast number of 2048 and 1024 bit certificates. (My favorite is the MD2, 1024 bit RSA, root certificate) Looking at Mozilla's list of included CAs tells a similar story: the spreadsheet is avalible at https://docs.google.com/spreadsheet/pub?key=0Ah-tHXMAwqU3dGx0cGFObG9QM192NFM4UWNBMlBaekE&single=true&gid=1&output=html, and shows limited effect of one-upmanship. In fact, the removal of 1024 bit root keys broke a fair number of websites, and was only completed in 2013. We also have data from Internet-wide scans of servers. http://cryptome.org/2013/11/ecc-practice.pdf for ECC. The most common key size is 256, followed by 384, and lastly is 521. Sadly similar breakdowns by keysize for a similar scan aimed at RSA and DSA host keys does not appear to exist. I would be surprised if it actually supported the hypothesis. What evidence do you have that this one-upsmanship actually happens in selecting key sizes? Furthermore, even if a 384 bit options sees limited use, there is little harm in including it. However, given that there are 480 bit options offering better performance, why not pick those instead? Similarly, if 512 bits would make you happy, why not an even faster 521 bit option? And why deny users who want a 384 bit option for performance reasons the option to have a more satisfactory for them balance between paranoia and practicality? Sincerely, Watson Ladd From nobody Tue Oct 28 00:03:02 2014 Return-Path: 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 312541A037C for ; Tue, 28 Oct 2014 00:03:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 yf2TCzGe6s0G for ; Tue, 28 Oct 2014 00:02:59 -0700 (PDT) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4644C1A0066 for ; Tue, 28 Oct 2014 00:02:59 -0700 (PDT) Received: by mail-wi0-f176.google.com with SMTP id n3so8330506wiv.3 for ; Tue, 28 Oct 2014 00:02:58 -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 :content-transfer-encoding:message-id:references:to; bh=WmNIlgwFItAnuQTJYsk1utimGzvAdfOkmW/422bu9iU=; b=tTxiPfBrP9dA48TQq4XMJd/7FeedEyrsgF+1G6AOeaHecOpo46Vljnhz/JGCuVxsBo tfjqBpMwqitmXhmioa3pYyaQT1MQzRb4gB2zMebLd/6z0Mr7j0QabURKuGzwgbQmF2L7 FM18RI8FFssQgsfQcxefOVqz2AfYYL57y11k2dVB/4fwypLY5x/FCDs4aOPS38IxiJ4L qpEWZL2e6N2Ctn1SFKZThpSeIqClA8fhDU2wxNMXSTrrzSUYnh6mrRuYkWjOtU5urJjI q128HqiU0dLiQr9E3E9wt0IIgurAMaHAsKGuu4WOzRFYmV3mbfCc2EMksW/O0mfTvcga 2PBQ== X-Received: by 10.194.110.4 with SMTP id hw4mr1701260wjb.102.1414479777909; Tue, 28 Oct 2014 00:02:57 -0700 (PDT) Received: from yoavs-mbp.mshome.net ([95.35.50.47]) by mx.google.com with ESMTPSA id dc8sm1098924wib.7.2014.10.28.00.02.56 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 28 Oct 2014 00:02:57 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Yoav Nir In-Reply-To: Date: Tue, 28 Oct 2014 09:02:55 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <33C74092-514B-4316-B3E1-0FFE7241D08A@gmail.com> References: <20141027053452.13077.qmail@cr.yp.to> <544E4832.8030600@cs.tcd.ie> <544EE4F1.2070201@cs.tcd.ie> To: "cfrg@irtf.org" X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/Y86Y1slMuTUSGGNSRKqOjDwc7kM Subject: Re: [Cfrg] Actual security levels for IETF crypto X-BeenThere: cfrg@irtf.org 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: Tue, 28 Oct 2014 07:03:01 -0000 I tend to agree with Watson. We=E2=80=99ve been trying to do this in a = =E2=80=9Cwaterfall=E2=80=9D way, where first we define requirements, and = then choose from among the proposals those that fit the requirements = best. But in fact the we don=E2=80=99t have firm requirements. We=E2=80=99re = pretty much in agreement that we want two =E2=80=9Cstrength=E2=80=9D = level of curves. But it=E2=80=99s not clear how strong. For the =E2=80=9Cweaker=E2=80=9D curve, we=E2=80=99re pretty much in = agreement that we want 128-ish work factor. This is both because of = security (NIST and cryptographers tell us that we need this much) and = because at the start of this process we had a good candidate. I put the = =E2=80=9Cweaker=E2=80=9D in quotes because if we actually get 128 or = even 112 bit work factor, then breaking this is beyond the power of any = actor for the next 30 years. The weaker curve already has quite a bit of = margin. We=E2=80=99ve had a 64-bit work factor collision attack on SHA-1 = for several years now, and yet nobody has produced a pair of colliding = buffers.[1] For a 128-bit work factor, please insert platitude here = about the size of the universe, silicon atoms, billions of years and the = heat death of the universe. But because the weaker curve is so strong, there=E2=80=99s no rational = way to write requirements for the =E2=80=9Cstronger=E2=80=9D curve. = Again, the =E2=80=9Cstronger=E2=80=9D is in quotes, because if something = is impossible, talking about something being a billion times more = impossible or a trillion times more impossible is silly. Attacks get = better, but there=E2=80=99s little information about yet-undiscovered = attacks, so we don=E2=80=99t know if the attacks we=E2=80=99ll have in = 20 or 30 years will drop the work factor for the weaker curve from 128 = to 112, or all the way down to 64. Similarly, there is no way to know if = an attack that will make a 384-bit curve vulnerable will leave a 512-bit = curve still secure enough. IMO what we should be worried about is usability. We should assume that = both the strong and weak curve will be implemented, but the weak curve = will be overwhelmingly more common in use. In case the weak curve that = we pick turns out to have a flaw, it should be possible for = implementations to switch by mere configuration. And it should not mean = that all hardware has to be replaced. So unlike PHB, I believe that we = should be worried about performance or the stronger curve, because = it=E2=80=99s going to serve as a backup. So yes, we do want a margin = above ~128. ~192 or higher is a good choice. But I don=E2=80=99t believe = that Goldilocks is =E2=80=9Cnot high enough=E2=80=9D. I think it is. And = if we get an attack that brings that ~224 bit work factor down to = something breakable, we probably need to re-think our use of ECC anyway. Yoav [1] I=E2=80=99m sure there are quite a few actors who can perform a = 64-bit attack. It=E2=80=99s been 19 years since a university = brute-forced a 56-bit DES key. I=E2=80=99m sure we have computers that = can do 256 as much work. Point is, it=E2=80=99s not so easy.= From nobody Tue Oct 28 01:57:03 2014 Return-Path: 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 1270D1A1AA8 for ; Tue, 28 Oct 2014 01:56:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 GM0mykgoym5v for ; Tue, 28 Oct 2014 01:56:19 -0700 (PDT) Received: from smtp93.iad3a.emailsrvr.com (smtp93.iad3a.emailsrvr.com [173.203.187.93]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E1161A1A84 for ; Tue, 28 Oct 2014 01:56:19 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp28.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id DFAA13802EC; Tue, 28 Oct 2014 04:56:17 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp28.relay.iad3a.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id 322473802EE; Tue, 28 Oct 2014 04:56:15 -0400 (EDT) X-Sender-Id: ogud@ogud.com Received: from [192.168.100.134] ([UNAVAILABLE]. [77.76.110.18]) (using TLSv1 with cipher AES128-SHA) by 0.0.0.0:465 (trex/5.3.2); Tue, 28 Oct 2014 08:56:17 GMT Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Olafur Gudmundsson In-Reply-To: Date: Tue, 28 Oct 2014 08:56:13 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <1C7EEFB3-9C24-4739-9696-7939E75EBC8B@ogud.com> References: <20141027053452.13077.qmail@cr.yp.to> <544E4832.8030600@cs.tcd.ie> <544EE4F1.2070201@cs.tcd.ie> To: Watson Ladd X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/OCEWzTVKJzSl5zgXCVWmJaZs3Uk Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] Actual security levels for IETF crypto X-BeenThere: cfrg@irtf.org 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: Tue, 28 Oct 2014 08:56:21 -0000 On Oct 28, 2014, at 1:24 AM, Watson Ladd wrote: > On Mon, Oct 27, 2014 at 5:36 PM, Stephen Farrell > wrote: >>=20 >>=20 >> On 27/10/14 15:35, Watson Ladd wrote: >>> Are you saying that DNSSEC isn't an IETF protocol? Or that we should >>> only look at widely deployed protocols when determining how choices >>> about what to deploy are made? Or that DNSSEC doesn't have the same >>> "marketing issue" as TLS? >>=20 >> None of the above. I was saying (only) that that extrapolation >> is dodgy. >=20 > Huh? The point DJB and I are trying to make is that deployment of > crypto is frequently performance constrained, and that the marketing > benefits of the NUMS curves are completely overstated, as shown by the > fact that people don't deploy crypto because it has nice round > numbers, but because it meets the performance demands they have. >=20 > In particular, it's clear that people prefer P384 to P521 in TLS, > because of performance issues (or maybe compatibility). It's also > clear that RSA deployments in DNSSEC with very low security remain > popular, in part because of specific issues with DNSSEC that > essentially require RSA+SHA1 to be used for backwards compatibility, > and that end up capping the maximum security at that of RSA: these > reasons don't apply as strongly to TLS. I would like to offer that DNSSEC key size decisions are more based on = herd mentality i.e. "X does this way so I will copy=94=20 Secondly DNSSEC records are popular as DNS amplification attack vector = thus some people have keep their RSA key sizes small. Thirdly there is also a rational process going on here, does my vanity = domain need the=20 same security level as say PayPal ?=20 Of course once the world starts using ECC for DNSSEC peoples choices = become more restricted, right=20 now we see frequently that Key Signing Key is 2048 bits but the key that = signs the zone data is 1024=20 this is because updating KSK is hard but changing ZSK is easy. As an = example this is what the root does,=20 in that case the ZSK is changed every 3 months, limiting the time window = it can be cracked.=20 One of the worst possible inputs into deciding how to use keys in DNSSEC = is the advice from NIST,=20 there is nothing wrong with using short lived RSA 1024 bit key (3 to 12 = months) and using SHA1 in short lived signatures (less than 2 weeks).=20= The NIST advice covers documents that need to be verified in 30-50 years = which is totally different domain.=20 Olafur PS: I=92m working on rolling out DNSSEC for a large third party DNS = Operator and we will use ECDSA P256 for the 1M+ domains we operate,=20 and the reason has more to do with size of signatures than anything = else.=20 From nobody Tue Oct 28 02:13:18 2014 Return-Path: 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 B586C1A1A84 for ; Tue, 28 Oct 2014 02:12:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.859 X-Spam-Level: X-Spam-Status: No, score=-3.859 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 qhWWgWRYKMEY for ; Tue, 28 Oct 2014 02:12:44 -0700 (PDT) Received: from mx-out-2.rwth-aachen.de (mx-out-2.rwth-aachen.de [134.130.5.187]) by ietfa.amsl.com (Postfix) with ESMTP id 0BBBE1A1A83 for ; Tue, 28 Oct 2014 02:12:43 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.04,801,1406584800"; d="scan'208,217";a="267821732" Received: from hub2.rwth-ad.de (HELO mail.rwth-aachen.de) ([134.130.26.143]) by mx-2.rz.rwth-aachen.de with ESMTP; 28 Oct 2014 10:12:43 +0100 Received: from [192.168.1.2] (78.48.112.28) by mail.rwth-aachen.de (134.130.26.143) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 28 Oct 2014 10:12:42 +0100 Message-ID: <544F5E0A.1090308@rwth-aachen.de> Date: Tue, 28 Oct 2014 10:12:42 +0100 From: Jakob Breier User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: References: <20141027053452.13077.qmail@cr.yp.to> <544E4832.8030600@cs.tcd.ie> <544EE4F1.2070201@cs.tcd.ie> In-Reply-To: Content-Type: multipart/alternative; boundary="------------090909000907090809030707" X-PMWin-Version: 3.1.3.0 Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/TZ-_McYeyqb8hX1V9cLiaNkFRaU Subject: Re: [Cfrg] Actual security levels for IETF crypto X-BeenThere: cfrg@irtf.org 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: Tue, 28 Oct 2014 09:12:46 -0000 --------------090909000907090809030707 Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit On 28.10.2014 02:24, Watson Ladd wrote: > (Furthermore, OAEP was introduced a full 6 years before RFC 3110 was > written. Guess what RFC 3110 uses?) You were probably thinking of the Probabilistic Signature Scheme? While I'm not sure it is a bad idea, a quick Google search did not come up with anyone using OAEP for signatures. Also, both papers were written by Bellare and Rogaway, so I guess they would have reused OAEP for signatures, if the proofs were feasible. You can still make the same point by arguing that the PSS paper was published a full 5 years before RFC 3310 came out. On the other hand, adoption of PSS in cryptographic standards wasn't as fast as OAEP. The - then current - RFC 2313 (PKCS #1 v2.0) only takes note of its existence: > Editor's note. RSA Laboratories is investigating the possibility of > including a scheme based on the PSS encoding methods specified in > [3 ], which would be recommended for new applications. And PKCS #1 v2.1 only came along in 2002 [1], a year after the publication of RFC 3110. Regards, Jakob [1] ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-1/pkcs-1v2-1.pdf --------------090909000907090809030707 Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: 7bit
On 28.10.2014 02:24, Watson Ladd wrote:
(Furthermore, OAEP was introduced a full 6 years before RFC 3110 was
written. Guess what RFC 3110 uses?)


You were probably thinking of the Probabilistic Signature Scheme? While I'm not sure it is a bad idea, a quick Google search did not come up with anyone using OAEP for signatures. Also, both papers were written by Bellare and Rogaway, so I guess they would have reused OAEP for signatures, if the proofs were feasible.

You can still make the same point by arguing that the PSS paper was published a full 5 years before RFC 3310 came out. On the other hand, adoption of PSS in cryptographic standards wasn't as fast as OAEP. The - then current - RFC 2313 (PKCS #1 v2.0) only takes note of its existence: 

   Editor's note. RSA Laboratories is investigating the possibility of
   including a scheme based on the PSS encoding methods specified in
   [3], which would be recommended for new applications.

And PKCS #1 v2.1 only came along in 2002 [1], a year after the publication of RFC 3110.

Regards,
Jakob

[1] ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-1/pkcs-1v2-1.pdf
--------------090909000907090809030707-- From nobody Tue Oct 28 03:29:18 2014 Return-Path: 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 8D7561A1AF2 for ; Tue, 28 Oct 2014 03:28:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 4Z_mkN0E_UUG for ; Tue, 28 Oct 2014 03:28:29 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 0EFAE1A1AF4 for ; Tue, 28 Oct 2014 03:28:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 75A82BE15; Tue, 28 Oct 2014 10:28:20 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CzMr-qDDrJ-z; Tue, 28 Oct 2014 10:28:19 +0000 (GMT) Received: from [10.87.48.12] (unknown [86.46.26.9]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 20CC8BE14; Tue, 28 Oct 2014 10:28:19 +0000 (GMT) Message-ID: <544F6FC1.9030603@cs.tcd.ie> Date: Tue, 28 Oct 2014 10:28:17 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Watson Ladd References: <20141027053452.13077.qmail@cr.yp.to> <544E4832.8030600@cs.tcd.ie> <544EE4F1.2070201@cs.tcd.ie> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/eGUOiUvbFJeYSFg6TTLJ0_ZS8yE Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] Actual security levels for IETF crypto X-BeenThere: cfrg@irtf.org 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: Tue, 28 Oct 2014 10:28:34 -0000 Hiya, On 28/10/14 01:24, Watson Ladd wrote: > On Mon, Oct 27, 2014 at 5:36 PM, Stephen Farrell > wrote: >> >> >> On 27/10/14 15:35, Watson Ladd wrote: >>> Are you saying that DNSSEC isn't an IETF protocol? Or that we should >>> only look at widely deployed protocols when determining how choices >>> about what to deploy are made? Or that DNSSEC doesn't have the same >>> "marketing issue" as TLS? >> >> None of the above. I was saying (only) that that extrapolation >> is dodgy. > > Huh? The point DJB and I are trying to make is that deployment of > crypto is frequently performance constrained, and that the marketing > benefits of the NUMS curves are completely overstated, as shown by the > fact that people don't deploy crypto because it has nice round > numbers, but because it meets the performance demands they have. Yes, and I'm neither agreeing with nor disagreeing with that point. I am simply saying that it's fallacious to argue about all "IETF crypto" solely based on a few hundred key pairs of any sort. So while I don't have a dog in the "which curves" hunt, I would not like to see even the correct conclusion reached based on bad argument. S. > > In particular, it's clear that people prefer P384 to P521 in TLS, > because of performance issues (or maybe compatibility). It's also > clear that RSA deployments in DNSSEC with very low security remain > popular, in part because of specific issues with DNSSEC that > essentially require RSA+SHA1 to be used for backwards compatibility, > and that end up capping the maximum security at that of RSA: these > reasons don't apply as strongly to TLS. > > (Furthermore, OAEP was introduced a full 6 years before RFC 3110 was > written. Guess what RFC 3110 uses?) > > If you think DNSSEC and the data we have on TLS certificates are both > wrong, go ahead and find a crypto deployment that you think actually > is representative, or explain that factors that make these irrelevant. > Just as if Microsoft thinks the numbers we are getting for their > curves are wrong, they should submit them to SUPERCOP. (hint hint). > But don't say that the real world, observed, behavior and choices of > users, are irrelevant to deciding what their preferences are. > > Sincerely, > Watson Ladd > >> >> If I measured a bunch of Dutch folks' heights, and assumed that >> the average of those told me something about the average height >> of a human I'd be making the same extrapolation mistake. >> >> S. > > > From nobody Tue Oct 28 05:38:01 2014 Return-Path: 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 354801A8822 for ; Tue, 28 Oct 2014 05:37:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.622 X-Spam-Level: X-Spam-Status: No, score=0.622 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no 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 Vd8kXLs0qqeU for ; Tue, 28 Oct 2014 05:37:31 -0700 (PDT) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDA7C1A87EF for ; Tue, 28 Oct 2014 05:32:22 -0700 (PDT) Received: by mail-lb0-f169.google.com with SMTP id l4so503615lbv.0 for ; Tue, 28 Oct 2014 05:32:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=3yEb5DWYfgXmzGuKUXwhFvN5oknXbiSUYnEzVNPftpY=; b=YxkgSmY7o6nYlmhCqrjUkUaTCsLFB+n6IsO6MpZo+Ng/NAVSkWSX7Cp5eGZZ1wGPcG nIFoBdPt4ZFKCfDR0FdhKilDx3CnvJiDg2sYmj5RbU99WoJI/IxBhXrHpXAiY0mVHgWg bhulLZIoUya7M00LsTIka9S3ObJbZK3bBycFvO63o4DzCC+Y4JZUHvpKhRxkvcK5xzeQ 5jCTXM1zs+Hv1KsaqAS/2UKU188RyZe8lFtMCfXW1IuvjNrf5weHTinb011i2ijpag9Y VE/yLS6gtiJ7rbcV0uWVGcSnSAjALVbnStVW6OGBjBskBCuPu7SqzqolZAYFmK8I2ByC wYyA== MIME-Version: 1.0 X-Received: by 10.112.221.226 with SMTP id qh2mr3689528lbc.5.1414499540986; Tue, 28 Oct 2014 05:32:20 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.214.163 with HTTP; Tue, 28 Oct 2014 05:32:20 -0700 (PDT) In-Reply-To: References: <20141027053452.13077.qmail@cr.yp.to> <544E4832.8030600@cs.tcd.ie> <544EE4F1.2070201@cs.tcd.ie> Date: Tue, 28 Oct 2014 08:32:20 -0400 X-Google-Sender-Auth: UCq16rPK1zPAbBl_d9K3wIxBEjg Message-ID: From: Phillip Hallam-Baker To: Watson Ladd Content-Type: multipart/alternative; boundary=001a1135ecb8acf40305067ad6ab Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/kFe7VvmCbyyFDEIZWc98468I01c Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] Actual security levels for IETF crypto X-BeenThere: cfrg@irtf.org 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: Tue, 28 Oct 2014 12:37:33 -0000 --001a1135ecb8acf40305067ad6ab Content-Type: text/plain; charset=UTF-8 On Tue, Oct 28, 2014 at 2:29 AM, Watson Ladd wrote: > On Mon, Oct 27, 2014 at 10:28 PM, Phillip Hallam-Baker > wrote: > > > > > There is a good reason folk choose a small key for DNS related work, the > > original protocol was limited to 500 bytes and quite a few bits of the > > Internet are still limited by the ancient ethernet MTU which isn't much > > bigger. > > NIST P-256 is in the DNSSEC spec, and does fit in 500 bytes. (64 bytes > in fact). DNSSEC failed to select small keys with adequate security, > and instead selected medium size keys with poor security, for reasons > that are now irrelevant, and were probably bogus even then. But even > in the range of keys that do fit, people are not going to the maximum > possible security. Until some of the patents expired a few months ago, most people didn't have any interest in ECC at all. The risk of a lawsuit was large, the benefit of ECC over RSA, questionable. The market is split between two concerns. One is to have the absolute best industry standard crypto, the other is to support 100% of the browsers in use. What the certificate holders are interested in is converting shopping carts into orders. > Funny that someone would present this particular argument then accuse > others > > of 'marketing' as if it was a bad thing. > > > > My actual argument was that the market is subject to a one-upmanship > effect > > that tends to drive key sizes upwards. So if there is 384 and 512 on > offer > > with the new curves, don't expect anyone to use 384. > > But this didn't happen to 256 bit curves, which are still widely used > to protect TLS. They are? I hadn't noticed. I guess you are referring to ephemeral use, which isn't really the same as signing static data like certs or a zone. Adoption is much easier. It also didn't happen to 384 bit curves in PKIX: no > one is moving to 521 bit curves, in part because of compatibility > issues, but also because of lack of demand. It also hasn't happened > to RSA key sizes: the most popular key size on the web from Mozilla > telemetry is 2048 bits, with 4096 the next most popular, and the > ludicrously oversized 16384 virtually unseen in comparison. > RSA imposes serious costs as the key size increases. Not least lack of browser support. I forget which browser is holding up 4096, I suspect its another Windows XP thing. But the problem with RSA over 2048 is that the extra bits buy almost nothing. > What evidence do you have that this one-upsmanship actually happens in > selecting key sizes? > Customer surveys and A/B testing on marketing. > Furthermore, even if a 384 bit options sees limited use, there is > little harm in including it. No, there is a lot of harm. The real reason for going through this process is not because the existing curves are bad, its because the deployment of ECC has stalled due to the IPR FUD. Adopting a shiny new set of curves that everyone can agree on is the way to restart the process. CAs who were laggards in the process get a chance to catch up. Which means they don't need to continue to play boat anchor. Put two options on the table and there is a story that can sell ECC and we can converge on one approach that has a pretty decent chance of getting comprehensive support so that it is ready when 2048 starts to look soft and we really need it. Having 30+ curve choices harms deployment because that is a choice most folk don't feel qualified to make. So they stick with RSA2048 till the market decides. Which means the market doesn't make any choice at all. Back when the Web was only one of 30 odd network hypertext systems, I went after the Clinton Whitehouse to deploy the Web because I knew that was the way to win the standards battle. The early microcomputer market had seen dozens of machines appear then get replaced by newer, better models. Until IBM appeared and legitimized the microcomputer with the IBM PC. > However, given that there are 480 bit > options offering better performance, why not pick those instead? > Similarly, if 512 bits would make you happy, why not an even faster > 521 bit option? And why deny users who want a 384 bit option for > performance reasons the option to have a more satisfactory for them > balance between paranoia and practicality? > The idea we can balance security and performance is nonsense. They are incommensurate. Consider the following cases: 1) Curve 25519 is too much overhead. 2) Curve 25519 is acceptable but ~512 is not. 3) ~512 is acceptable. For reasons discussed earlier, there will always be constrained devices for which case 1 applies, but any device currently doing RSA2048 can do ~512 without any difficulty. So the only area where a 'tradeoff' is even arguably an issue is case 2 which is a very small slice to start with and going to get thinner over time because the growth in devices is at the ends of the performance curve, 8 bit devices and 64 bits. We can't balance performance and security, so we give a binary choice. If you can do ~512 then do it, otherwise there is the ~256 option. --001a1135ecb8acf40305067ad6ab Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Oct 28, 2014 at 2:29 AM, Watson Ladd <watsonbladd@gmail.co= m> wrote:
= On Mon, Oct 27, 2014 at 10:28 PM, Phillip Hallam-Baker
<phill@hallambaker.com> = wrote:
>

> There is a good reason folk choose a small key for DNS related work, t= he
> original protocol was limited to 500 bytes and quite a few bits of the=
> Internet are still limited by the ancient ethernet MTU which isn't= much
> bigger.

NIST P-256 is in the DNSSEC spec, and does fit in 500 bytes. (64 byt= es
in fact). DNSSEC failed to select small keys with adequate security,
and instead selected medium size keys with poor security, for reasons
that are now irrelevant, and were probably bogus even then. But even
in the range of keys that do fit, people are not going to the maximum
possible security.

Until some of the patent= s expired a few months ago, most people didn't
have any inter= est in ECC at all. The risk of a lawsuit was large, the benefit
o= f ECC over RSA, questionable.

The market is split = between two concerns. One is to have the absolute best industry standard cr= ypto, the other is to support 100% of the browsers in use. What the certifi= cate holders are interested in is converting shopping carts into orders.

> Funn= y that someone would present this particular argument then accuse others > of 'marketing' as if it was a bad thing.
>
> My actual argument was that the market is subject to a one-upmanship e= ffect
> that tends to drive key sizes upwards. So if there is 384 and 512 on o= ffer
> with the new curves, don't expect anyone to use 384.

But this didn't happen to 256 bit curves, which are still widely= used
to protect TLS.

They are? I hadn't not= iced. I guess you are referring to ephemeral use, which isn't really th= e same as signing static data like certs or a zone. Adoption is much easier= .


It also= didn't happen to 384 bit curves in PKIX: no
one is moving to 521 bit curves, in part because of compatibility
issues,=C2=A0 but also because of lack of demand.=C2=A0 It also hasn't = happened
to RSA key sizes: the most popular key size on the web from Mozilla
telemetry is 2048 bits, with 4096 the next most popular, and the
ludicrously oversized 16384 virtually unseen in comparison.

RSA imposes serious costs as the key size increases. N= ot least lack of browser support.

I forget which b= rowser is holding up 4096, I suspect its another Windows XP thing. But the = problem with RSA over 2048 is that the extra bits buy almost nothing.=C2=A0=
=C2=A0
What evidence do you have that this one-upsmanship actually happens in
selecting key sizes?

Customer surveys a= nd A/B testing on marketing.
=C2=A0
Furthermore, even if a 384 bit options sees limited use, there is
little harm in including it.

No, there is = a lot of harm.

The real reason for going through t= his process is not because the existing curves are bad, its because the dep= loyment of ECC has stalled due to the IPR FUD. Adopting a shiny new set of = curves that everyone can agree on is the way to restart the process. CAs wh= o were laggards in the process get a chance to catch up. Which means they d= on't need to continue to play boat anchor.

Put= two options on the table and there is a story that can sell ECC and we can= converge on one approach that has a pretty decent chance of getting compre= hensive support so that it is ready when 2048 starts to look soft and we re= ally need it.=C2=A0

Having 30+ curve choices harms= deployment because that is a choice most folk don't feel qualified to = make. So they stick with RSA2048 till the market decides. Which means the m= arket doesn't make any choice at all.


Back when the Web was only one of 30 odd network hypertext systems, = I went after the Clinton Whitehouse to deploy the Web because I knew that w= as the way to win the standards battle. The early microcomputer market had = seen dozens of machines appear then get replaced by newer, better models. U= ntil IBM appeared and legitimized the microcomputer with the IBM PC.
<= div>
=C2=A0
However, give= n that there are 480 bit
options offering better performance, why not pick those instead?
Similarly, if 512 bits would make you happy, why not an even faster
521 bit option? And why deny users who want a 384 bit option for
performance reasons the option to have a more satisfactory for them
balance between paranoia and practicality?
=C2=A0
The idea we can balance security and performance is nonsense. They a= re incommensurate. Consider the following cases:

1) Curve 25519 is too much overh= ead.
2) Curve 25519 is acceptable but ~512 = is not.
3) ~512 is acceptable.

For reasons discus= sed earlier, there will always be constrained devices for which case 1 appl= ies, but any device currently doing RSA2048 can do ~512 without any difficu= lty.

S= o the only area where a 'tradeoff' is even arguably an issue is cas= e 2 which is a very small slice to start with and going to get thinner over= time because the growth in devices is at the ends of the performance curve= , 8 bit devices and 64 bits.=C2=A0

We can't balance performance and security,= so we give a binary choice. If you can do ~512 then do it, otherwise there= is the ~256 option.

--001a1135ecb8acf40305067ad6ab-- From nobody Tue Oct 28 06:05:04 2014 Return-Path: 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 BD91E1A6F11 for ; Tue, 28 Oct 2014 06:04:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 Fs1qfp4WkSiZ for ; Tue, 28 Oct 2014 06:04:25 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A93181A6F60 for ; Tue, 28 Oct 2014 06:04:21 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1Xj6Rf-0003H3-Mr; Tue, 28 Oct 2014 13:04:20 +0000 Date: Tue, 28 Oct 2014 22:04:18 +0900 Message-ID: From: Randy Bush To: Phillip Hallam-Baker In-Reply-To: References: <20141027053452.13077.qmail@cr.yp.to> <544E4832.8030600@cs.tcd.ie> <544EE4F1.2070201@cs.tcd.ie> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/ndAhWyJ9PhdnteEl81TgeA5RdJA Cc: IRTF CFRG Subject: Re: [Cfrg] Actual security levels for IETF crypto X-BeenThere: cfrg@irtf.org 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: Tue, 28 Oct 2014 13:04:29 -0000 > There is a good reason folk choose a small key for DNS related work, > the original protocol was limited to 500 bytes and quite a few bits of > the Internet are still limited by the ancient ethernet MTU which isn't > much bigger. s/500/512/ and i thought dnssec required edns0 long size. randy From nobody Tue Oct 28 06:22:59 2014 Return-Path: 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 A6BC71A87BF for ; Tue, 28 Oct 2014 06:22:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no 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 B5p7lLD_2p7O for ; Tue, 28 Oct 2014 06:22:53 -0700 (PDT) Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FB871A878B for ; Tue, 28 Oct 2014 06:22:52 -0700 (PDT) Received: by mail-la0-f43.google.com with SMTP id ge10so604483lab.16 for ; Tue, 28 Oct 2014 06:22:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=J2Syz54/VbqRvRGHKs84RS4GTU2XkDyDn8z3Tm9QIqA=; b=z4yjmIr3Bi3L36eDg/IDBaJtWkwYLPcjj7YGRKTkisC/AznWxWTVIQ5oWNHV/R2dqc pBsJx4X8iJrpaN/Xgk7P4/qcfYuRXGjPLg1K2pKcq3LaWcMOBvprHTxB0LkuRGAEYm6J FqdofstVqUIAjoNuzdukJin6Fpb9W01JsiKAhWt08h8NVUPunnm+t0Hj22SZPziB2m6c 1EHq/jZMbV46+TpiFSOw4AbZB6G8tF9f6aipJFlRT97LuCm276B0RCOfjoA5SqmpwQz+ 5EPqtU75xmTSCkUrs6i4eLDpKtrd84g51UbD0D+UTJSrohPiPgY6gNu6if8PMuMzLIKj g8QA== MIME-Version: 1.0 X-Received: by 10.152.203.231 with SMTP id kt7mr4008552lac.84.1414502571209; Tue, 28 Oct 2014 06:22:51 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.214.163 with HTTP; Tue, 28 Oct 2014 06:22:51 -0700 (PDT) In-Reply-To: References: <20141027053452.13077.qmail@cr.yp.to> <544E4832.8030600@cs.tcd.ie> <544EE4F1.2070201@cs.tcd.ie> Date: Tue, 28 Oct 2014 09:22:51 -0400 X-Google-Sender-Auth: Sozl-d65J9wuMLvD77Mb68rbiFg Message-ID: From: Phillip Hallam-Baker To: Randy Bush Content-Type: multipart/alternative; boundary=001a11346ac64a7b0c05067b8b83 Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/8s5OvXq_7DyK_Wt-4UbPvfoutaA Cc: IRTF CFRG Subject: Re: [Cfrg] Actual security levels for IETF crypto X-BeenThere: cfrg@irtf.org 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: Tue, 28 Oct 2014 13:22:54 -0000 --001a11346ac64a7b0c05067b8b83 Content-Type: text/plain; charset=UTF-8 On Tue, Oct 28, 2014 at 9:04 AM, Randy Bush wrote: > > There is a good reason folk choose a small key for DNS related work, > > the original protocol was limited to 500 bytes and quite a few bits of > > the Internet are still limited by the ancient ethernet MTU which isn't > > much bigger. > > s/500/512/ and i thought dnssec required edns0 long size. > > randy > DNSSEC requires EDNS0 but the 1500 byte Ethernet MTU still bites. If you are trying to get messages through a broken middlebox, you are likely to find messages truncated at 512 (or sometimes 500) bytes. So I can understand why people might try to make DNSSEC work with RSA1024 even though I don't think they have much chance of success. --001a11346ac64a7b0c05067b8b83 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Oct 28, 2014 at 9:04 AM, Randy Bush <randy@psg.com> wrote:
> There is a good reas= on folk choose a small key for DNS related work,
> the original protocol was limited to 500 bytes and quite a few bits of=
> the Internet are still limited by the ancient ethernet MTU which isn&#= 39;t
> much bigger.

s/500/512/=C2=A0 and i thought dnssec required edns0 long size.

randy

DNSSE= C requires EDNS0 but the 1500 byte Ethernet MTU still bites.

If you are trying to= get messages through a broken middlebox, you are likely to find messages t= runcated at 512 (or sometimes 500) bytes.
<= br>
So I can understand why people might tr= y to make DNSSEC work with RSA1024 even though I don't think they have = much chance of success.


--001a11346ac64a7b0c05067b8b83-- From nobody Tue Oct 28 06:26:12 2014 Return-Path: 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 A87BF1A882C for ; Tue, 28 Oct 2014 06:26:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 5rh1ZHRUuiql for ; Tue, 28 Oct 2014 06:26:06 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 158181A87CB for ; Tue, 28 Oct 2014 06:26:05 -0700 (PDT) Received: by mail-wi0-f173.google.com with SMTP id ex7so9304723wid.12 for ; Tue, 28 Oct 2014 06:26:04 -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 :content-transfer-encoding:message-id:references:to; bh=tz4xRnsed6MqNErNPF8JOlQhNu8PzB34wKS7W2IbHJM=; b=qskRBaUk26Fqw9geQjy83chB50SvXGbYGnJbXNCsOdvLXBuXBMWQ5GFtwKZPeWs2nu +c2/2mVIklg1M5ejWhsd8VHWUCdGqbJnh+5u/3PRLjMYErrJB4s6SJEJaNI/Cygcjhui ouege9a+SiKOBzjssjEQ98EYZif9nCIc3RCtUFvWgSaiA0LXELBcFmCw939GF1plBbjy nKB2LKDdCu5NBLIDWGfg7peiugA/LNxgTPOPqble/Py1L97VgEmZdq0xBQkHVikdTTLM nzarMCudpVR6vBeDEjy9rd9RvMh/LGx0fEBu95ox0oHi1Lc5whrbG24zWkYm+j6mX8a7 LrMg== X-Received: by 10.181.11.131 with SMTP id ei3mr4760375wid.24.1414502764290; Tue, 28 Oct 2014 06:26:04 -0700 (PDT) Received: from yoavs-mbp.mshome.net ([95.35.50.226]) by mx.google.com with ESMTPSA id bi7sm2210718wib.17.2014.10.28.06.26.03 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 28 Oct 2014 06:26:03 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Yoav Nir In-Reply-To: Date: Tue, 28 Oct 2014 15:26:01 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20141027053452.13077.qmail@cr.yp.to> <544E4832.8030600@cs.tcd.ie> <544EE4F1.2070201@cs.tcd.ie> To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/jv0VRahFKHc4OWm9138JURVXXPQ Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] Actual security levels for IETF crypto X-BeenThere: cfrg@irtf.org 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: Tue, 28 Oct 2014 13:26:08 -0000 > On Oct 28, 2014, at 2:32 PM, Phillip Hallam-Baker = wrote: >=20 > The market is split between two concerns. One is to have the absolute = best industry standard crypto, the other is to support 100% of the = browsers in use. What the certificate holders are interested in is = converting shopping carts into orders. There=E2=80=99s also the concern that I don=E2=80=99t want to buy any = more servers/bandwidth/accelerators than I have to. > =20 > The idea we can balance security and performance is nonsense. They are = incommensurate. Consider the following cases: Totally disagree. > 1) Curve 25519 is too much overhead. > 2) Curve 25519 is acceptable but ~512 is not. > 3) ~512 is acceptable. >=20 > For reasons discussed earlier, there will always be constrained = devices for which case 1 applies, but any device currently doing RSA2048 = can do ~512 without any difficulty. It=E2=80=99s not a question of what they can or cannot do. According to = the Mozilla telemetry, 95% of HTTP connections (unfortunately this = statistic is not split by SSL/non-SSL) transfer less than 200 KB of = data. Pretty much regardless of which PK and symmetric algorithms you = use, PK operations will dominate. So if you have a lot of connections = like this (think web services and simple sites), the number of machines = you need to buy, power and maintain is inversely proportional to the = speed of the PK operation.=20 > So the only area where a 'tradeoff' is even arguably an issue is case = 2 which is a very small slice to start with and going to get thinner = over time because the growth in devices is at the ends of the = performance curve, 8 bit devices and 64 bits.=20 Going from 25519 to P-521 has some costs. If (as you claim) it has some = advantages, then there is a trade-off. You might say it=E2=80=99s not = important because other costs dominate this one. But there is always a = trade-off. > We can't balance performance and security, so we give a binary choice. = If you can do ~512 then do it, otherwise there is the ~256 option. Why should I? Are you claiming that P-256 or X25519 are insecure? =20 Yoav From nobody Tue Oct 28 06:41:03 2014 Return-Path: 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 733471A88B0 for ; Tue, 28 Oct 2014 06:41:02 -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 9l8EDTeYD3Ig for ; Tue, 28 Oct 2014 06:40:54 -0700 (PDT) Received: from mail-yh0-x22a.google.com (mail-yh0-x22a.google.com [IPv6:2607:f8b0:4002:c01::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 167861A886C for ; Tue, 28 Oct 2014 06:40:54 -0700 (PDT) Received: by mail-yh0-f42.google.com with SMTP id 29so344995yhl.1 for ; Tue, 28 Oct 2014 06:40:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=NAZTq8VgMlLBDkVCDyI0mSGqCPAoBCWzQuz+D2RgAjQ=; b=i/a06rEnuk9DbFpZE7pvPPQmWe/BTU3RZpphu6tKvUWCMELsHHQqX3YGhsYwi3D72B xr10eKhZyxRDrksWa7RSg3Dvn/pIa2MQh5sEi8/1y4lajsFHTL52sRzGvKi38RZ/qMuT ON0dC/M/n69NyG1qv//1VwMQ//pd3feQI3nwtYGfBS65WsiKDWb3DegmH+oeNvRx+iQ3 KRsVRKXkqnsqhIcV37Cnoub8jH3wlO7axsc2c8WA3/W8lhUlfAm+HSWOHqXYw9yOKDdP 23chpfTaZYU7+fnL//ksEmXiFoJheMv+nrgd9QmhaRPVFUWnH0O0L2mrhYwoZeQWGBQm k9EA== MIME-Version: 1.0 X-Received: by 10.236.53.69 with SMTP id f45mr2983706yhc.65.1414503653277; Tue, 28 Oct 2014 06:40:53 -0700 (PDT) Received: by 10.170.195.149 with HTTP; Tue, 28 Oct 2014 06:40:53 -0700 (PDT) In-Reply-To: <544F5E0A.1090308@rwth-aachen.de> References: <20141027053452.13077.qmail@cr.yp.to> <544E4832.8030600@cs.tcd.ie> <544EE4F1.2070201@cs.tcd.ie> <544F5E0A.1090308@rwth-aachen.de> Date: Tue, 28 Oct 2014 06:40:53 -0700 Message-ID: From: Watson Ladd To: Jakob Breier Content-Type: multipart/alternative; boundary=089e0122971cc9861605067bcb5b Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/AQ1ybeMlilPRreOhh4vyDhlNIRY Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] Actual security levels for IETF crypto X-BeenThere: cfrg@irtf.org 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: Tue, 28 Oct 2014 13:41:02 -0000 --089e0122971cc9861605067bcb5b Content-Type: text/plain; charset=UTF-8 On Oct 28, 2014 2:13 AM, "Jakob Breier" wrote: > > On 28.10.2014 02:24, Watson Ladd wrote: >> >> (Furthermore, OAEP was introduced a full 6 years before RFC 3110 was >> written. Guess what RFC 3110 uses?) > > > > You were probably thinking of the Probabilistic Signature Scheme? While I'm not sure it is a bad idea, a quick Google search did not come up with anyone using OAEP for signatures. Also, both papers were written by Bellare and Rogaway, so I guess they would have reused OAEP for signatures, if the proofs were feasible. I did indeed mean PSS. Do not use OAEP for signatures. Thanks for fixing that. > > You can still make the same point by arguing that the PSS paper was published a full 5 years before RFC 3310 came out. On the other hand, adoption of PSS in cryptographic standards wasn't as fast as OAEP. The - then current - RFC 2313 (PKCS #1 v2.0) only takes note of its existence: Well, that's the problem: standardization lags behind knowledge significantly. Of course, the actual state of PKCS 1.5 signatures is nowhere near as bad as PKCS 1.5 encryption, so it's much less urgent. > >> Editor's note. RSA Laboratories is investigating the possibility of >> including a scheme based on the PSS encoding methods specified in >> [3], which would be recommended for new applications. > > > And PKCS #1 v2.1 only came along in 2002 [1], a year after the publication of RFC 3110. > > Regards, > Jakob > > [1] ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-1/pkcs-1v2-1.pdf > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg > --089e0122971cc9861605067bcb5b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Oct 28, 2014 2:13 AM, "Jakob Breier" <Jakob.Breier@rwth-aachen.de= > wrote:
>
> On 28.10.2014 02:24, Watson Ladd wrote:
>>
>> (Furthermore, OAEP was introduced a full 6 years before RFC 3110 w= as
>> written. Guess what RFC 3110 uses?)
>
>
>
> You were probably thinking of the Probabilistic Signature Scheme? Whil= e I'm not sure it is a bad idea, a quick Google search did not come up = with anyone using OAEP for signatures. Also, both papers were written by Be= llare and Rogaway, so I guess they would have reused OAEP for signatures, i= f the proofs were feasible.

I did indeed mean PSS. Do not use OAEP for signatures. Thank= s for fixing that.

>
> You can still make the same point by arguing that the PSS paper was pu= blished a full 5 years before RFC 3310 came out. On the other hand, adoptio= n of PSS in cryptographic standards wasn't as fast as OAEP. The - then = current - RFC 2313 (PKCS #1 v2.0) only takes note of its existence:

Well, that's the problem: standardization lags behind kn= owledge significantly. Of course, the actual state of PKCS 1.5 signatures i= s nowhere near as bad as PKCS 1.5 encryption, so it's much less urgent.= =C2=A0
>
>>=C2=A0=C2=A0=C2=A0 Editor's note. RSA Laboratories is investiga= ting the possibility of
>>=C2=A0=C2=A0=C2=A0 including a scheme based on the PSS encoding met= hods specified in
>>=C2=A0=C2=A0=C2=A0 [3], which would be recommended for new applicat= ions.
>
>
> And PKCS #1 v2.1 only came along in 2002 [1], a year after the publica= tion of RFC 3110.
>
> Regards,
> Jakob
>
> [1] ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-1/pkcs-1v2-1.p= df
>
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg
>

--089e0122971cc9861605067bcb5b-- From nobody Tue Oct 28 06:41:29 2014 Return-Path: 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 8B8851A886C for ; Tue, 28 Oct 2014 06:41:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no 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 BTxnYEEMoDiY for ; Tue, 28 Oct 2014 06:41:22 -0700 (PDT) Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A47B81A88B4 for ; Tue, 28 Oct 2014 06:41:21 -0700 (PDT) Received: by mail-la0-f45.google.com with SMTP id gm9so626460lab.32 for ; Tue, 28 Oct 2014 06:41:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=JkQ/0nWhmBi+k8ikOtOXymG48A2fUX9BGmNYzpU/DSI=; b=NW/7SGdhEraoqbhR6IhS6ZvASPJ6q//0URDUKq48qXRgD12ZX0SWC61SkI7D8LsmJo mimGqnNVMFi0ZXA3AwJuIUSG7BXX2ufZId7fF6vhYaY7TBSK62XH1DQidH+fKvv4FUtX wQtmhHeSGlL9tflyK0QUUvN6jByx4jm4OIXvDlXFTvSh+ixag9se+nAax4hxupAD2vKA yLCmQV8LV2f97w/FcXjPsee2rCLRDZJWr/5Uoi1wf2TxpTQEnScyk3zVdax+i4smqayW pUNcW8rL5l96JeJfrJOB2EhL+xln8jGEF+xY6hCspvvifCUiaDpLEECnji1UQpQfV72h DOzQ== MIME-Version: 1.0 X-Received: by 10.112.200.34 with SMTP id jp2mr4140683lbc.1.1414503679320; Tue, 28 Oct 2014 06:41:19 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.214.163 with HTTP; Tue, 28 Oct 2014 06:41:19 -0700 (PDT) In-Reply-To: References: <20141027053452.13077.qmail@cr.yp.to> <544E4832.8030600@cs.tcd.ie> <544EE4F1.2070201@cs.tcd.ie> Date: Tue, 28 Oct 2014 09:41:19 -0400 X-Google-Sender-Auth: HpE16qENW8GsTgJ6uhBkwB6NHVA Message-ID: From: Phillip Hallam-Baker To: Yoav Nir Content-Type: multipart/alternative; boundary=001a11c3749e56ecc605067bcd5b Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/PTzTQt5oLdOOWg8Jqsiamml7vMk Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] Actual security levels for IETF crypto X-BeenThere: cfrg@irtf.org 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: Tue, 28 Oct 2014 13:41:28 -0000 --001a11c3749e56ecc605067bcd5b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Oct 28, 2014 at 9:26 AM, Yoav Nir wrote: > > > On Oct 28, 2014, at 2:32 PM, Phillip Hallam-Baker > wrote: > > > > The market is split between two concerns. One is to have the absolute > best industry standard crypto, the other is to support 100% of the browse= rs > in use. What the certificate holders are interested in is converting > shopping carts into orders. > > There=E2=80=99s also the concern that I don=E2=80=99t want to buy any mor= e > servers/bandwidth/accelerators than I have to. > > > > > The idea we can balance security and performance is nonsense. They are > incommensurate. Consider the following cases: > > Totally disagree. I don't think you did actually. I am arguing that there is no nuanced tradeoff because people will either take the performance pick or the security pick. If we are going to make the security pick we are going to consider these cases: > > 1) Curve 25519 is too much overhead. > > 2) Curve 25519 is acceptable but ~512 is not. > > 3) ~512 is acceptable. If we are going to take the performance pick then we are going to ask the question you do: > Why should I? Are you claiming that P-256 or X25519 are insecure? Either performance is an issue or it isn't. This isn't a smooth yield curve with a series of tradeoffs. We have two picks: 1) ~256: High Security and High Performance 2) ~512: Beyond all reasonable doubt security at modest performance penalty --001a11c3749e56ecc605067bcd5b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Oct 28, 2014 at 9:26 AM, Yoav Nir <ynir.ietf@gmail.com&g= t; wrote:

> On Oct 28, 2014, at 2:32 PM, Phillip Hallam-Baker <phill@hallambaker.com> wrote:
>
> The market is split between two concerns. One is to have the absolute = best industry standard crypto, the other is to support 100% of the browsers= in use. What the certificate holders are interested in is converting shopp= ing carts into orders.

There=E2=80=99s also the concern that I don=E2=80=99t want to buy an= y more servers/bandwidth/accelerators than I have to.

>
> The idea we can balance security and performance is nonsense. They are= incommensurate. Consider the following cases:

Totally disagree.

I don't think = you did actually. I am arguing that there is no nuanced tradeoff because pe= ople will either take the performance pick or the security pick.
=
If we are going to make the security pick we are going to co= nsider these cases:
=C2=A0
> 1) Curve 25519 is too much overhead.
> 2) Curve 25519 is acceptable but ~512 is not.
> 3) ~512 is acceptable.


If we are going to take the performance pick then we are going to as= k the question you do:
=C2=A0
Why should I?= =C2=A0 Are you claiming that P-256 or X25519 are insecure?


Either performance is an issue or it isn'= ;t. This isn't a smooth yield curve with a series of tradeoffs. We have= two picks:

1) ~256: High Security and High Perfor= mance
2) ~512: Beyond all reasonable doubt security at modest pe= rformance penalty


--001a11c3749e56ecc605067bcd5b-- From nobody Tue Oct 28 07:28:36 2014 Return-Path: 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 CC9971A896F for ; Tue, 28 Oct 2014 07:28:30 -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 Z67cfFomJZZQ for ; Tue, 28 Oct 2014 07:28:28 -0700 (PDT) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CF1C1A8976 for ; Tue, 28 Oct 2014 07:27:02 -0700 (PDT) Received: by mail-wg0-f52.google.com with SMTP id y10so977856wgg.23 for ; Tue, 28 Oct 2014 07:27:01 -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=1LTWw+TNmvyRlkac5/w4AATyPNkvO5xMojm+GSO+vzs=; b=jPgRD40xDVpCqbxOg9VuDH4/jkMdgWvj4Q3vNz/rYZrrzHCcUBT8xnaflbIvNfYkpD luHIHvJ9EUyAVuzpI0C4vP0f+7DXTnqIt/L80l4slQx2YCcmf5Hcv2PHI5nBHpIggBej yPg3qi4m4yizv04kiBWxFu/dSqyx0oQw7ShB+7i25m2FXYxNKi0Po4aEszCf1hNhVBJ7 vRZwCh7KOK1yKQkrHeEeOcbDg3NbO6GXSvMZo4/XAjX9BKrkCiOmMB3kB5ig2ps3ziTX MJaGB0zIYkZLOZ0Cv5qAgajj+RibGo6q2+oHEK5CSsHvTFtXTR4dLOpZTDjB9fawNofG r/Sw== X-Received: by 10.194.192.73 with SMTP id he9mr3727565wjc.125.1414506421136; Tue, 28 Oct 2014 07:27:01 -0700 (PDT) Received: from yoavs-mbp.mshome.net ([95.35.50.226]) by mx.google.com with ESMTPSA id p1sm2027673wjy.22.2014.10.28.07.26.59 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 28 Oct 2014 07:27:00 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_5B4EA963-1F08-4975-A28A-DAFE172F022A" Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Yoav Nir In-Reply-To: Date: Tue, 28 Oct 2014 16:26:58 +0200 Message-Id: <731C763F-D7B9-4FC2-90CE-11217AE82698@gmail.com> References: <20141027053452.13077.qmail@cr.yp.to> <544E4832.8030600@cs.tcd.ie> <544EE4F1.2070201@cs.tcd.ie> To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/ND-s8_CyhXn6NlO3h1xeAfiUOMA Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] Actual security levels for IETF crypto X-BeenThere: cfrg@irtf.org 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: Tue, 28 Oct 2014 14:28:31 -0000 --Apple-Mail=_5B4EA963-1F08-4975-A28A-DAFE172F022A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Oct 28, 2014, at 3:41 PM, Phillip Hallam-Baker = wrote: >=20 >=20 >=20 > On Tue, Oct 28, 2014 at 9:26 AM, Yoav Nir > wrote: >=20 > > On Oct 28, 2014, at 2:32 PM, Phillip Hallam-Baker = > wrote: > > > > The market is split between two concerns. One is to have the = absolute best industry standard crypto, the other is to support 100% of = the browsers in use. What the certificate holders are interested in is = converting shopping carts into orders. >=20 > There=E2=80=99s also the concern that I don=E2=80=99t want to buy any = more servers/bandwidth/accelerators than I have to. >=20 > > > > The idea we can balance security and performance is nonsense. They = are incommensurate. Consider the following cases: >=20 > Totally disagree. >=20 > I don't think you did actually. I am arguing that there is no nuanced = tradeoff because people will either take the performance pick or the = security pick. And I am arguing that it is nuanced. > If we are going to make the security pick we are going to consider = these cases: > =20 > > 1) Curve 25519 is too much overhead. > > 2) Curve 25519 is acceptable but ~512 is not. > > 3) ~512 is acceptable. >=20 >=20 > If we are going to take the performance pick then we are going to ask = the question you do: > =20 > Why should I? Are you claiming that P-256 or X25519 are insecure? I don=E2=80=99t think these are two separate cases. Performance is = always an issue, but if picking Curve25519 means that traffic recorded = today will be decrypted in 10 years, then I will take the performance = hit associated with using P-521 as part of the cost of doing business. = If you tell me that breaking one is impossible, while breaking the other = is a billion times more difficult than impossible, then I have to ask, = =E2=80=9Cwhy should I?" > Either performance is an issue or it isn't. This isn't a smooth yield = curve with a series of tradeoffs. We have two picks: >=20 > 1) ~256: High Security and High Performance > 2) ~512: Beyond all reasonable doubt security at modest performance = penalty Is it really modest? P-256 is 4 times as fast as P-521. We don=E2=80=99t = have numbers for a 512-bit curve, but Goldilocks is just over 3 times = slower than Curve25519, whereas P-521 is 23 times slower. So is there an argument to use #2 that is strong enough to overcome the = performance penalty argument? Yoav --Apple-Mail=_5B4EA963-1F08-4975-A28A-DAFE172F022A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Oct 28, 2014, at 3:41 PM, Phillip Hallam-Baker <phill@hallambaker.com> wrote:



On Tue, Oct 28, 2014 at 9:26 AM, Yoav Nir <ynir.ietf@gmail.com> = wrote:

> On Oct 28, 2014, at 2:32 PM, Phillip Hallam-Baker <phill@hallambaker.com> wrote:
>
> The market is split between two concerns. One is to have the = absolute best industry standard crypto, the other is to support 100% of = the browsers in use. What the certificate holders are interested in is = converting shopping carts into orders.

There=E2=80=99s also the concern that I don=E2=80=99t want to buy = any more servers/bandwidth/accelerators than I have to.

>
> The idea we can balance security and performance is nonsense. They = are incommensurate. Consider the following cases:

Totally disagree.

I don't think you did actually. I am = arguing that there is no nuanced tradeoff because people will either = take the performance pick or the security = pick.

And I am arguing that it is nuanced.

If we are going to make the = security pick we are going to consider these cases:
 
> 1) Curve 25519 is too much overhead.
> 2) Curve 25519 is acceptable but ~512 is not.
> 3) ~512 is acceptable.


If = we are going to take the performance pick then we are going to ask the = question you do:
 
Why should I?  Are you claiming that = P-256 or X25519 are = insecure?

I don=E2=80=99t think these are two separate = cases. Performance is always an issue, but if picking Curve25519 means = that traffic recorded today will be decrypted in 10 years, then I will = take the performance hit associated with using P-521 as part of the cost = of doing business. If you tell me that breaking one is impossible, while = breaking the other is a billion times more difficult than impossible, = then I have to ask, =E2=80=9Cwhy should I?"


Either performance is an issue or = it isn't. This isn't a smooth yield curve with a series of tradeoffs. We = have two picks:

1) ~256: High Security and High Performance
2) = ~512: Beyond all reasonable doubt security at modest performance = penalty

Is it = really modest?  P-256 is 4 times as fast as P-521. We don=E2=80=99t = have numbers for a 512-bit curve, but Goldilocks is just over 3 times = slower than Curve25519, whereas P-521 is 23 times slower.

So is there an argument to use #2 that is strong = enough to overcome the performance penalty argument?

Yoav

= --Apple-Mail=_5B4EA963-1F08-4975-A28A-DAFE172F022A-- From nobody Tue Oct 28 08:24:44 2014 Return-Path: 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 D5E0B1A8AD7 for ; Tue, 28 Oct 2014 08:24:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 vGHdfM6ryiUG for ; Tue, 28 Oct 2014 08:24:25 -0700 (PDT) Received: from mail-yk0-x233.google.com (mail-yk0-x233.google.com [IPv6:2607:f8b0:4002:c07::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74FAA1A8A9C for ; Tue, 28 Oct 2014 08:24:17 -0700 (PDT) Received: by mail-yk0-f179.google.com with SMTP id 131so402541ykp.24 for ; Tue, 28 Oct 2014 08:24:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=04FyCWL/7tdDRtcMqjkHj91srAcGQQg69K2gIneECMQ=; b=rzGVcdWSiIjeRPsO4p9AEouOBrXvNtUg151k8YDo0+b8p5ERk4BXFVXPP2wqFDdp+P CHAEMhVUnquNJs473x4+eWlARCWCMGFcRQ6B86selPPp/hgI9JezanBpKyMHRVkaVvdv 2GyH4zEFHqldxzcFlwJ0rbTDvzb8+3JJdKofx5ia6hQuqyy1wHzv66ICqgjw+h2j6G// a4/ZU7FlH3NeAgxE2TcwnDrD6ABpu9GS1XFw1O311HLjZpxdZ2zDvnsX3NxRGWDEVVGH 5IAcXD9lB7/Sb6kBBOlXRKL6QApv7mxFzIBU2LKRS33FgmqE37R6ZLrAwODcTUhTaOIs c51Q== MIME-Version: 1.0 X-Received: by 10.236.230.5 with SMTP id i5mr3700563yhq.174.1414509856671; Tue, 28 Oct 2014 08:24:16 -0700 (PDT) Received: by 10.170.195.149 with HTTP; Tue, 28 Oct 2014 08:24:16 -0700 (PDT) Date: Tue, 28 Oct 2014 08:24:16 -0700 Message-ID: From: Watson Ladd To: "cfrg@irtf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/lSdc8ylSkgwfSjRGseIUM5L0akg Subject: [Cfrg] Requirements, part II X-BeenThere: cfrg@irtf.org 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: Tue, 28 Oct 2014 15:24:38 -0000 Dear all, Benchmarks are only going to help decide which curves offer high security at reasonable price, and leave plenty of other things open. With that in mind I'm hoping to summarize the various decisions that need to get made. The first decision: what point format? Don't say "we can leave it up to WGs" because before you know it there will be six different ones, all of which implementers have to deal with. Weierstrass form is backwards compatible. This is both a blessing and a curse. It's a blessing because no one has to write new code. It's a curse because no one will, unless they need the performance gains, so the security gains won't happen as quickly. It does mean that it's easier to adopt the new curves. (How bad is the cofactor issue? Unclear) Representing points on a curve in a coordinate system with complete addition law for all possible primes requires Edwards form. Twisted Edwards with a=-1 is not necessary complete, and sadly 2^521-1 is a prime where it isn't. Montgomery form is extremely simple to add to an implementation, and in ECDH only scenarios very nice. Yes, there are protocols that only need encryption, and so can do this. Compressed codepoints mitigate a security issue, at the cost of a 10% or so decompression PITA on verification in signatures and ECDH. The endianness issue needs to get settled one way or the other. I wish one side had won a complete victory, but sadly this is not the case. The second decision: what to do about signatures? ECDSA seems like it can handle cofactors, but the official standard is not free, so I couldn't verify this. It does require Weierstrass form, and does have a painful inversion both for signers and verifiers. The Schnorr signature scheme is much faster, has batchable variants (less of a win then you might think), and is finally unpatented. The absence of an inversion makes implementing simple and increases performance. These decisions need to get made no matter what curves we choose. Sincerely, Watson Ladd From nobody Tue Oct 28 08:27:16 2014 Return-Path: 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 860F61A8AC8 for ; Tue, 28 Oct 2014 08:27:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.701 X-Spam-Level: X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, LOTS_OF_MONEY=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 Q_Uujc-ZyWMx for ; Tue, 28 Oct 2014 08:27:11 -0700 (PDT) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F70F1A8ACA for ; Tue, 28 Oct 2014 08:27:11 -0700 (PDT) Received: by mail-lb0-f179.google.com with SMTP id w7so810353lbi.38 for ; Tue, 28 Oct 2014 08:27:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=khYfZbIVhh8XGqt+/ZI+nvuc1T0k6CX4EfMQT3azg+0=; b=S+XVLt2NWPr22ogsnZqOz7M39FG386SmUvKo9OmRgTZi3Hu8UmYd3amZbRCyhn9DbU nduObHm60fXgnI/WXibJedvQUFmMjnU0gkXZbORV9YT6FnumJl78lX/mXa+it9aDwGKD CnZoLiELWX1x5QeRlcq4UARiAktexH6Ob6T9XySVfP+9CVDe2zXNDIppaohu7aCOnfsO KESUQNCNUMwlIpZcvz03K3E+15c0TNJZp/P0M2yJd1e46GclrUZ+asos4vgFnV2hB00a 3+GvVRWA8xXHuSUtEO7Ri5daDBjqhM0RDSEb+usvi31ONjYQlouvTJbhVciE8iaczPeM WcyQ== X-Received: by 10.152.45.2 with SMTP id i2mr4822123lam.7.1414510029519; Tue, 28 Oct 2014 08:27:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.218.145 with HTTP; Tue, 28 Oct 2014 08:26:49 -0700 (PDT) From: David Leon Gil Date: Tue, 28 Oct 2014 11:26:49 -0400 Message-ID: To: Yoav Nir Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/2NHWmdYUMJmQdHsqYnWmc15Qrmg Cc: "cfrg@irtf.org" Subject: [Cfrg] Estimating the adversary's computational power (was Re: [CFRG] Actual security levels) X-BeenThere: cfrg@irtf.org 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: Tue, 28 Oct 2014 15:27:13 -0000 Some numbers. On Tue, Oct 28, 2014 at 3:02 AM, Yoav Nir wrote: > The weaker curve already has quite a bit of margin. We=E2=80=99ve had a 6= 4-bit > work factor collision attack on SHA-1 for several years now, and yet > nobody has produced a pair of colliding buffers.[1] > I=E2=80=99m sure we have computers that can do 256 as much work. Point is= , > it=E2=80=99s not so easy. The main difficulty is that there isn't funding for this work. E.g.: Marc Stevens's attack's claimed complexity is ~ 2^61 SHA-1 evals. One GK110 can do ~ 2^31 SHA-1 evals per second. DOE's Titan supercomputer has ~ 18800 GK110s. Stevens's attack would take about *1 day* of its time. 18800 * 3600 * 24 ~=3D 2^31 GK110-seconds per day ~=3D 2^61 hash evals per day How many GK110s does djb's Saber have? 48. The same attack would take about a year. (I'm not accounting for Saber's 192 Opteron cores, or Titan's 300,000.) -- [reordered slightly] > [1] I=E2=80=99m sure there are quite a few actors who can perform a 64-bi= t attack. > It=E2=80=99s been 19 years since a university brute-forced a 56-bit DES k= ey. It was actually the EFF; Cryptography Research built the machine. It cost about $361k, adjusted for inflation. Saber: http://blog.cr.yp.to/20140602-saber.html Titan: https://www.olcf.ornl.gov/titan/ But anyways, how much do these supercomputers cost? DES: $0.361m Saber: $0.065m Titan: $97m The adversary has: > $3,100m / year (Sum of data processing and data analysis categories from NSA budget at http://www.washingtonpost.com/wp-srv/special/national/black-budget/) I am rather sick of the nonsense that large computations are infeasible. -dlg From nobody Tue Oct 28 09:12:45 2014 Return-Path: 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 D3E1F1A90A5 for ; Tue, 28 Oct 2014 09:12:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 OmaZLJGLCJhg for ; Tue, 28 Oct 2014 09:12:39 -0700 (PDT) Received: from emh06.mail.saunalahti.fi (emh06.mail.saunalahti.fi [62.142.5.116]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FB281A901F for ; Tue, 28 Oct 2014 09:06:22 -0700 (PDT) Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh06.mail.saunalahti.fi (Postfix) with ESMTP id 919C06997D; Tue, 28 Oct 2014 18:06:19 +0200 (EET) Date: Tue, 28 Oct 2014 18:06:19 +0200 From: Ilari Liusvaara To: Phillip Hallam-Baker Message-ID: <20141028160619.GA12772@LK-Perkele-VII> References: <20141027053452.13077.qmail@cr.yp.to> <544E4832.8030600@cs.tcd.ie> <544EE4F1.2070201@cs.tcd.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/R-Fy-5_qQRGMUUIjB3_8nd-Ip-8 Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] Actual security levels for IETF crypto X-BeenThere: cfrg@irtf.org 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: Tue, 28 Oct 2014 16:12:42 -0000 On Tue, Oct 28, 2014 at 09:41:19AM -0400, Phillip Hallam-Baker wrote: > On Tue, Oct 28, 2014 at 9:26 AM, Yoav Nir wrote: > > > Either performance is an issue or it isn't. This isn't a smooth yield curve > with a series of tradeoffs. We have two picks: > > 1) ~256: High Security and High Performance > 2) ~512: Beyond all reasonable doubt security at modest performance penalty The problem is, the performance goes like: "Orange level" (~200 bits[1]) is about 3x the cost of "Yellow level" (~128 bits). "Red level" (~256 bits) is about 6x the cost of "Yellow level" and 2x the cost of "orange level". Those aren't trivial cost differences. I think that unless we have curve that beats NIST P-384 in speed (and is at least ~192 bits[2]) NIST P-384 will retain most of its (not very widespread) use. Also, with certificates, there is difference in value. CA certificates are much much more valuable for attacker than just about any end-site certificate (and exceptionally high-value end-site certificates are rare too). So very few certificates would even need "red level" security. Sucky performance doesn't matter very much if signing is rare and verification can be cached. [1] One can get some extra bits above 192 with very small cost due to lack of good primes near 2^384 but some a good bit above. [2] Due to pracical factors, it seems one can get a good bit above 192-bit level for it. -Ilari From nobody Tue Oct 28 09:41:59 2014 Return-Path: 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 5EDFC1A908E for ; Tue, 28 Oct 2014 09:41:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, 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 CAGPA1Q1cRj1 for ; Tue, 28 Oct 2014 09:41:53 -0700 (PDT) Received: from mail-lb0-f173.google.com (mail-lb0-f173.google.com [209.85.217.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C06E1A9231 for ; Tue, 28 Oct 2014 09:37:57 -0700 (PDT) Received: by mail-lb0-f173.google.com with SMTP id l4so951737lbv.4 for ; Tue, 28 Oct 2014 09:37:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=p2TJbguyQDEc3rlfHEZICkpgE5gTUT1wXzq37wjwXJg=; b=JLWhx+bfBH209SswfvM7sgAMrvORWIkTkg1ZPqIv4BUi3vB2vvYRvDwSE27J3kJ8Eb /Wn/jtkrvNCG3yGNWsrI3j+tNUnSlk4MEGPjLKqhz8hHuHzcuI9maWlbOt0prDpC9XLS RvIjKofxRBLN/NfyEFmtR7yjdK3UlgyLpoQJQ6kZYoSQA4xsv39QMCoYHjlJ4KzYc6Y7 XnHli4rA9pcjIsovZ5blK+BPq0PbxfphtHAlLWs2TrOGtDKxkUvMX7Ea1/iPMz0XzmLj qOPjc3Vq0b/lVUwf7ruD50aBY1KOrrt9J9Nq0suPCLqXdqywmoj28g+A4O/+CvZH0cuV 4BGw== X-Gm-Message-State: ALoCoQk+OuJCTfTZZQ4MPGqu1Vj0Buiz4lfzBL11vqX+pMo7COWsn1nDvR6Sh7P+Lp1OI2SLNQTd X-Received: by 10.152.30.33 with SMTP id p1mr5189121lah.78.1414514271342; Tue, 28 Oct 2014 09:37:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.4.71 with HTTP; Tue, 28 Oct 2014 09:37:31 -0700 (PDT) In-Reply-To: References: From: Andy Lutomirski Date: Tue, 28 Oct 2014 09:37:31 -0700 Message-ID: To: Watson Ladd Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/nWwB97ptva_rpAnNEe9YDtuVZP4 Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] Requirements, part II X-BeenThere: cfrg@irtf.org 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: Tue, 28 Oct 2014 16:41:56 -0000 On Tue, Oct 28, 2014 at 8:24 AM, Watson Ladd wrote: > The second decision: what to do about signatures? ECDSA seems like it > can handle cofactors, but the official standard is not free, so I > couldn't verify this. It does require Weierstrass form, and does have > a painful inversion both for signers and verifiers. > > The Schnorr signature scheme is much faster, has batchable variants > (less of a win then you might think), and is finally unpatented. The > absence of an inversion makes implementing simple and increases > performance. > To the extent that performance matters for certain parts of certain protocols, CFRG could suggest that, where practical, new ECDH-using protocols that need authentication should avoid using signatures at all. For example, I see no reason that a TLS server, even one offering Channel ID or some similar mechanism, should need to sign anything or verify a signature for each new connection. There are any number of very simple protocols that can prove knowledge of an EC private key with a single scalar multiplication. --Andy From nobody Tue Oct 28 09:50:23 2014 Return-Path: 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 BDC6F1A8AE4 for ; Tue, 28 Oct 2014 09:50:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.244 X-Spam-Level: X-Spam-Status: No, score=-0.244 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, LOTS_OF_MONEY=0.001, SPF_PASS=-0.001, US_DOLLARS_3=1.754] autolearn=no 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 O_BIQXdGD80c for ; Tue, 28 Oct 2014 09:50:19 -0700 (PDT) Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1E181A90CC for ; Tue, 28 Oct 2014 09:45:04 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id y10so1325754wgg.15 for ; Tue, 28 Oct 2014 09:45:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=gEKNKBAYDKGKKbmSPhreY8W77uDDO3pi3l0IY9grvPQ=; b=eOAEQsJ38IpPK5w0SnOAQSEptDUYetuzJPwLp+bSODafi3BW588HfTgC/pAba/OwLD xV+lWLvDlDOk+cGgD/3lh9g5in8pX32oE1BHJrOYDBb6LyrnpIbTDmkXmLuU8Rqkz3f0 Q2aBCQLkx1Lylq6x68TbKku+Dg8w5lC27I/j/1b+oAdav/k+B3+KSdwUYLo+8iFvb2dK imZteKLhSQ+RI+eKB9ArzaoOQw7jWhvu6KycevBPTiQnZxZghWZxQRkzZXFMruSnF0/d pHKrlgAR5sQwf4ZYZidAFhGweFnVj+6TRxaXNuzEGUsOvMWPMLKZp3s+pqYrp/sKvsF/ GIHA== MIME-Version: 1.0 X-Received: by 10.194.134.200 with SMTP id pm8mr4434518wjb.136.1414514703046; Tue, 28 Oct 2014 09:45:03 -0700 (PDT) Received: by 10.194.220.104 with HTTP; Tue, 28 Oct 2014 09:45:02 -0700 (PDT) In-Reply-To: References: Date: Tue, 28 Oct 2014 18:45:03 +0200 Message-ID: From: Yoav Nir To: David Leon Gil Content-Type: multipart/alternative; boundary=089e0112cea067a09605067e5e6d Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/JPu5O9al-ILCQ9CY3y8VnGV8KrE Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] Estimating the adversary's computational power (was Re: [CFRG] Actual security levels) X-BeenThere: cfrg@irtf.org 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: Tue, 28 Oct 2014 16:50:21 -0000 --089e0112cea067a09605067e5e6d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I think your message proves my point rather than disprove it. There's a 61-bit work factor task that is infeasible for a 20 year old machine, infeasible for DJB's Saber, and the DOE's $97,000,000 machine can do it once a day. A 96-bit work factor is over 30 billion times more difficult, making it infeasible for even a million NSAs. 126-bit work factor is a billion times again more difficult I'm not saying that we should aim for 96-bit security. We need some margin. What I am objecting to is looking at Curve25519 that to the best of our knowledge is billions of billions of times harder to crack than anything that's ever been done, and saying "well, this is the option for those who can't afford super-good security because of performance issues. Those who really need security need quadrillions of quadrillions or times more. Merely getting quadrillions more is not enough." (sorry for the poor paraphrase, Phil) Yoav On Tue, Oct 28, 2014 at 5:26 PM, David Leon Gil wrote: > Some numbers. > > On Tue, Oct 28, 2014 at 3:02 AM, Yoav Nir wrote: > > The weaker curve already has quite a bit of margin. We=E2=80=99ve had a= 64-bit > > work factor collision attack on SHA-1 for several years now, and yet > > nobody has produced a pair of colliding buffers.[1] > > > I=E2=80=99m sure we have computers that can do 256 as much work. Point = is, > > it=E2=80=99s not so easy. > > The main difficulty is that there isn't funding for this work. > > E.g.: Marc Stevens's attack's claimed complexity is ~ 2^61 SHA-1 evals. > > One GK110 can do ~ 2^31 SHA-1 evals per second. DOE's Titan > supercomputer has ~ 18800 GK110s. Stevens's attack would take > about *1 day* of its time. > > 18800 * 3600 * 24 > ~=3D 2^31 GK110-seconds per day > ~=3D 2^61 hash evals per day > > How many GK110s does djb's Saber have? 48. The same attack would take > about a year. > > (I'm not accounting for Saber's 192 Opteron cores, or Titan's 300,000.) > > -- > > [reordered slightly] > > [1] I=E2=80=99m sure there are quite a few actors who can perform a 64-= bit > attack. > > It=E2=80=99s been 19 years since a university brute-forced a 56-bit DES= key. > > It was actually the EFF; Cryptography Research built the machine. It cost > about $361k, adjusted for inflation. > > Saber: http://blog.cr.yp.to/20140602-saber.html > Titan: https://www.olcf.ornl.gov/titan/ > > But anyways, how much do these supercomputers cost? > > DES: $0.361m > Saber: $0.065m > Titan: $97m > > The adversary has: > $3,100m / year > > (Sum of data processing and data analysis categories from NSA budget > at http://www.washingtonpost.com/wp-srv/special/national/black-budget/) > > I am rather sick of the nonsense that large computations are infeasible. > > -dlg > --089e0112cea067a09605067e5e6d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I think your message proves my point rather than disprove = it. There's a 61-bit work factor task that is infeasible for a 20 year = old machine, infeasible for DJB's Saber, and the DOE's $97,000,000 = machine can do it once a day.=C2=A0

A 96-bit work factor= is over 30 billion times more difficult, making it infeasible for even a m= illion NSAs. 126-bit work factor is a billion times again more difficult

I'm not saying that we should aim for 96-bit sec= urity. We need some margin. What I am objecting to is looking at Curve25519= that to the best of our knowledge is billions of billions of times harder = to crack than anything that's ever been done, and saying "well, th= is is the option for those who can't afford super-good security because= of performance issues. Those who really need security need quadrillions of= quadrillions or times more. Merely getting quadrillions more is not enough= ."

(sorry for the poor paraphrase, Phil)

Yoav

On Tue, Oct 28, 2014 at 5:26 PM, David Leon Gil <coruus= @gmail.com> wrote:
Some num= bers.

On Tue, Oct 28, 2014 at 3:02 AM, Yoav Nir <ynir.ietf@gmail.com> wrote:
> The weaker curve already has quite a bit of margin. We=E2=80=99ve had = a 64-bit
> work factor collision attack on SHA-1 for several years now, and yet > nobody has produced a pair of colliding buffers.[1]

> I=E2=80=99m sure we have computers that can do 256 as much work. Point= is,
> it=E2=80=99s not so easy.

The main difficulty is that there isn't funding for this work.

E.g.: Marc Stevens's attack's claimed complexity is ~ 2^61 SHA-1 ev= als.

One GK110 can do ~ 2^31 SHA-1 evals per second. DOE's Titan
supercomputer has ~ 18800 GK110s. Stevens's attack would take
about *1 day* of its time.

18800 * 3600 * 24
~=3D 2^31 GK110-seconds per day
~=3D 2^61 hash evals per day

How many GK110s does djb's Saber have? 48. The same attack would take about a year.

(I'm not accounting for Saber's 192 Opteron cores, or Titan's 3= 00,000.)

--

[reordered slightly]
> [1] I=E2=80=99m sure there are quite a few actors who can perform a 64= -bit attack.
> It=E2=80=99s been 19 years since a university brute-forced a 56-bit DE= S key.

It was actually the EFF; Cryptography Research built the machine. It cost about $361k, adjusted for inflation.

Saber: http://blog.cr.yp.to/20140602-saber.html
Titan: https= ://www.olcf.ornl.gov/titan/

But anyways, how much do these supercomputers cost?

DES:=C2=A0 =C2=A0$0.361m
Saber: $0.065m
Titan:=C2=A0 =C2=A0$97m

The adversary has: > $3,100m / year

(Sum of data processing and data analysis categories from NSA budget
at http://www.washingtonpost.com/wp-srv/special/nati= onal/black-budget/)

I am rather sick of the nonsense that large computations are infeasible.
-dlg

--089e0112cea067a09605067e5e6d-- From nobody Tue Oct 28 10:18:20 2014 Return-Path: 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 3C24B1A9074 for ; Tue, 28 Oct 2014 10:18:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.255 X-Spam-Level: **** X-Spam-Status: No, score=4.255 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.982, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no 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 g79EbKb6nqgb for ; Tue, 28 Oct 2014 10:18:15 -0700 (PDT) Received: from aspartame.shiftleft.org (199-116-74-168-v301.PUBLIC.monkeybrains.net [199.116.74.168]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADD901A909A for ; Tue, 28 Oct 2014 10:18:15 -0700 (PDT) Received: from [192.168.1.124] (unknown [192.168.1.1]) by aspartame.shiftleft.org (Postfix) with ESMTPSA id 0DF643ABAF; Tue, 28 Oct 2014 10:15:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=shiftleft.org; s=sldo; t=1414516532; bh=65F+KO1ibN/B2wfPZC9b7fWOajZl1eCVZvoPOgZlLbM=; h=Date:From:To:CC:Subject:References:In-Reply-To:From; b=B4y+pmY40/s/2E3Oaxa4ZN/2Yygds/weV3jNtdzX8c9ZOiKeNG1+JuNfKraUSdrKL 1/ZpG+SZEKOYpyR/Zva0BDTddelKCBzypLKf1dlkVtrLryePBBc7dJrcPvwGdRfbWq gmaxfVCK3K/+RLvIZP2e3c1XP5fYpOyX/ZxD3VvE= Message-ID: <544FCFD6.2040501@shiftleft.org> Date: Tue, 28 Oct 2014 10:18:14 -0700 From: Mike Hamburg User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Yoav Nir , Phillip Hallam-Baker References: <20141027053452.13077.qmail@cr.yp.to> <544E4832.8030600@cs.tcd.ie> <544EE4F1.2070201@cs.tcd.ie> <731C763F-D7B9-4FC2-90CE-11217AE82698@gmail.com> In-Reply-To: <731C763F-D7B9-4FC2-90CE-11217AE82698@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/JBc5o77P8R08XUGxptAaweF6RB8 Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] Actual security levels for IETF crypto X-BeenThere: cfrg@irtf.org 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: Tue, 28 Oct 2014 17:18:17 -0000 > Is it really modest? P-256 is 4 times as fast as P-521. We dont have > numbers for a 512-bit curve, but Goldilocks is just over 3 times > slower than Curve25519, whereas P-521 is 23 times slower. > > So is there an argument to use #2 that is strong enough to overcome > the performance penalty argument? > > Yoav > Actually, we do have numbers. They aren't quite apples-to-apples because of point formats, point compression, hashing and different benchmarking suites, but they're close. And of course, keep in mind that these aren't benchmarks of curves, but of implementations. Curve25519 takes 194kcy for an ECDH on Sandy Bridge (SUPERCOP). I'm using Sandy Bridge and ECDH because we have the most benchmarks on that combination. Point compression built-in. Microsoft's ed-256-mers takes 234kcy (Bos et al, published). P256 takes 374kcy for an ECDH on Sandy Bridge (Gueron and Krasnov, published). ed-384-mers takes 617kcy (Bos et al, published). Ed448-Goldilocks takes 667kcy (SUPERCOP), just under 3.5x Curve25519. Point compression built-in. ed-512-mers takes 1293kcy (Bos et al, published). Granger and Scott posted an E-521 implementation and claimed much better performance than this, but their implementation is not constant-time and their numbers didn't account for TurboBoost. Samuel Neves measured it with TurboBoost disabled and got 1030kcy on Sandy Bridge. I wrote an experimental constant-time implementation of E-521 using Goldilocks as a framework, and measured it at 803kcy on Haswell. This would probably be in the same neighborhood as that 1030kcy on Sandy Bridge (~15% IPC difference and no AVX2). Point compression built-in. Trevor Perrin clocked OpenSSL 1.0.2's NIST P-521 at 1714kcy on Haswell, which would probably be just under 2MCy on Sandy Bridge. OpenSSL's NIST-P-384 implementation isn't optimized yet, so it's even slower than P-521 at 2.2M Haswell cycles (Trevor again). Cheers, -- Mike From nobody Tue Oct 28 10:59:44 2014 Return-Path: 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 C95811A8941 for ; Tue, 28 Oct 2014 10:59:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.423 X-Spam-Level: * X-Spam-Status: No, score=1.423 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no 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 R2PdUkGHDBCW for ; Tue, 28 Oct 2014 10:59:38 -0700 (PDT) Received: from mail-la0-x229.google.com (mail-la0-x229.google.com [IPv6:2a00:1450:4010:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03FC01A9048 for ; Tue, 28 Oct 2014 10:56:16 -0700 (PDT) Received: by mail-la0-f41.google.com with SMTP id pn19so1130249lab.0 for ; Tue, 28 Oct 2014 10:56:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=FV+BIkDmRBa4ShHkOAl81TBUvzrDSRBC25dEx1rz2sA=; b=Kc+Yc9O00jBY9bBK/yX16gHMpfQfh00HpO/McSY5eShjSSARkgp7ZTFeEXCol+RqJP a59zwX9Xz7CIrtB3yX8NewQL88cy7kRzv5fisCx28BAQrulaZ5S02FH+bwDQumIp/KS9 mc1DQ14WGKZhFRYP4IFUD+MTM6I5E7wyfY0/TYvL2OXvIwRY+N7Rw/RGl28VgCjOreYO hpMpFuSq5ijc65lY4EErRmZ50tBi01jwvJeFWIU+o6quQ8Btuvsxc23h6J1CXmdiGyVc mUcttBOPLksGHKU/3nZJBq1pVvbO9xb4GMJoArnRIg4SsI2kzdiG7mxr91LB/vH4jsN7 s0Ig== MIME-Version: 1.0 X-Received: by 10.112.200.34 with SMTP id jp2mr5770416lbc.1.1414518974971; Tue, 28 Oct 2014 10:56:14 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.214.163 with HTTP; Tue, 28 Oct 2014 10:56:14 -0700 (PDT) In-Reply-To: <544FCFD6.2040501@shiftleft.org> References: <20141027053452.13077.qmail@cr.yp.to> <544E4832.8030600@cs.tcd.ie> <544EE4F1.2070201@cs.tcd.ie> <731C763F-D7B9-4FC2-90CE-11217AE82698@gmail.com> <544FCFD6.2040501@shiftleft.org> Date: Tue, 28 Oct 2014 13:56:14 -0400 X-Google-Sender-Auth: Np68SGFP87Qqqbe3UWeJr6CHPi0 Message-ID: From: Phillip Hallam-Baker To: Mike Hamburg Content-Type: multipart/alternative; boundary=001a11c3749e08038705067f5d22 Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/pfVtkWeP9G4t6l5DY1mGR6eevDY Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] Actual security levels for IETF crypto X-BeenThere: cfrg@irtf.org 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: Tue, 28 Oct 2014 17:59:40 -0000 --001a11c3749e08038705067f5d22 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Oct 28, 2014 at 1:18 PM, Mike Hamburg wrote: > > Is it really modest? P-256 is 4 times as fast as P-521. We don=E2=80=99= t have >> numbers for a 512-bit curve, but Goldilocks is just over 3 times slower >> than Curve25519, whereas P-521 is 23 times slower. >> >> So is there an argument to use #2 that is strong enough to overcome the >> performance penalty argument? >> >> Yoav >> >> Actually, we do have numbers. They aren't quite apples-to-apples > because of point formats, point compression, hashing and different > benchmarking suites, but they're close. And of course, keep in mind that > these aren't benchmarks of curves, but of implementations. > > Curve25519 takes 194kcy for an ECDH on Sandy Bridge (SUPERCOP). I'm usin= g > Sandy Bridge and ECDH because we have the most benchmarks on that > combination. Point compression built-in. > > Microsoft's ed-256-mers takes 234kcy (Bos et al, published). > > P256 takes 374kcy for an ECDH on Sandy Bridge (Gueron and Krasnov, > published). > > ed-384-mers takes 617kcy (Bos et al, published). > > Ed448-Goldilocks takes 667kcy (SUPERCOP), just under 3.5x Curve25519. > Point compression built-in. > > ed-512-mers takes 1293kcy (Bos et al, published). > > Granger and Scott posted an E-521 implementation and claimed much better > performance than this, but their implementation is not constant-time and > their numbers didn't account for TurboBoost. Samuel Neves measured it wit= h > TurboBoost disabled and got 1030kcy on Sandy Bridge. > > I wrote an experimental constant-time implementation of E-521 using > Goldilocks as a framework, and measured it at 803kcy on Haswell. This wou= ld > probably be in the same neighborhood as that 1030kcy on Sandy Bridge (~15= % > IPC difference and no AVX2). Point compression built-in. > > Trevor Perrin clocked OpenSSL 1.0.2's NIST P-521 at 1714kcy on Haswell, > which would probably be just under 2MCy on Sandy Bridge. > > OpenSSL's NIST-P-384 implementation isn't optimized yet, so it's even > slower than P-521 at 2.2M Haswell cycles (Trevor again). > For the sake of comparison, where do RSA1024 and RSA2048 fit in? [Accepting that the public/private key advantage flips] And lets not forget that the performance issues are different for client and server. First, lets take the constrained devices off the table. Anything that is struggling with X25519 is not going to look at anything stronger. So that leaves non constrained clients and high volume servers. As far as the client goes, the baseline is the RSA2048 public key operation. Anything that takes that number of cycles or less is going to be OK. Its moot anyway as the client does not make the choice. On the server side things are a little more complex. But either it is crypto limited or limited by something else. All the curves are going to be faster than RSA2048 because we get the asymmetric advantage for private key operations but in the sort term at least, we might lose the crypto accelerator board advantage. So I can see a strong argument for ~256 on the server and something much higher (i.e. ~512). I don't see a case for something that is neither one nor the other. --001a11c3749e08038705067f5d22 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Oct 28, 2014 at 1:18 PM, Mike Hamburg <mike@shiftleft.org= > wrote:

Is it really modest?=C2=A0 P-256 is 4 times as fast as P-521. We don=E2=80= =99t have numbers for a 512-bit curve, but Goldilocks is just over 3 times = slower than Curve25519, whereas P-521 is 23 times slower.

So is there an argument to use #2 that is strong enough to overcome the per= formance penalty argument?

Yoav

 Actually, we do have numbers.=C2=A0 They aren't quite apples-to-apples = because of point formats, point compression, hashing and different benchmar= king suites, but they're close.=C2=A0 And of course, keep in mind that = these aren't benchmarks of curves, but of implementations.

Curve25519 takes 194kcy for an ECDH on Sandy Bridge (SUPERCOP).=C2=A0 I'= ;m using Sandy Bridge and ECDH because we have the most benchmarks on that = combination.=C2=A0 Point compression built-in.

Microsoft's ed-256-mers takes 234kcy (Bos et al, published).

P256 takes 374kcy for an ECDH on Sandy Bridge (Gueron and Krasnov, publishe= d).

ed-384-mers takes 617kcy (Bos et al, published).

Ed448-Goldilocks takes 667kcy (SUPERCOP), just under 3.5x Curve25519.=C2=A0= Point compression built-in.

ed-512-mers takes 1293kcy (Bos et al, published).

Granger and Scott posted an E-521 implementation and claimed much better pe= rformance than this, but their implementation is not constant-time and thei= r numbers didn't account for TurboBoost. Samuel Neves measured it with = TurboBoost disabled and got 1030kcy on Sandy Bridge.

I wrote an experimental constant-time implementation of E-521 using Goldilo= cks as a framework, and measured it at 803kcy on Haswell. This would probab= ly be in the same neighborhood as that 1030kcy on Sandy Bridge (~15% IPC di= fference and no AVX2).=C2=A0 Point compression built-in.

Trevor Perrin clocked OpenSSL 1.0.2's NIST P-521 at 1714kcy on Haswell,= which would probably be just under 2MCy on Sandy Bridge.

OpenSSL's NIST-P-384 implementation isn't optimized yet, so it'= s even slower than P-521 at 2.2M Haswell cycles (Trevor again).


For the sake of comparison, where d= o RSA1024 and RSA2048 fit in?

[Accepting that the = public/private key advantage flips]

And lets not f= orget that the performance issues are different for client and server.=C2= =A0


First, lets take the constr= ained devices off the table. Anything that is struggling with X25519 is not= going to look at anything stronger. So that leaves non constrained clients= and high volume servers.

As far as the client goe= s, the baseline is the RSA2048 public key operation. Anything that takes th= at number of cycles or less is going to be OK. Its moot anyway as the clien= t does not make the choice.

On the server side thi= ngs are a little more complex. But either it is crypto limited or limited b= y something else. All the curves are going to be faster than RSA2048 becaus= e we get the asymmetric advantage for private key operations but in the sor= t term at least, we might lose the crypto accelerator board advantage.


So I can see a strong argument for ~256= on the server and something much higher (i.e. ~512). I don't see a cas= e for something that is neither one nor the other.
--001a11c3749e08038705067f5d22-- From nobody Tue Oct 28 12:13:06 2014 Return-Path: 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 E387A1AC40A for ; Tue, 28 Oct 2014 12:13:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 pBOgUlX4Rz0H for ; Tue, 28 Oct 2014 12:12:47 -0700 (PDT) Received: from mail-wg0-f45.google.com (mail-wg0-f45.google.com [74.125.82.45]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6EF01AC43D for ; Tue, 28 Oct 2014 12:10:13 -0700 (PDT) Received: by mail-wg0-f45.google.com with SMTP id x12so220122wgg.32 for ; Tue, 28 Oct 2014 12:10:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=YE0fl6L5mT80MGhDQcZF9Jo+Ge5rsSC/UZSCXCz7TmI=; b=mVskv2J50xKlTNMYxpPuNszrFnbfOsLJw8sztBtYvQOtLFTDSTFN/kYOL98ovc8ZJD yPt/RKgZk+Z9Sw+dKsWB58/oz41VWdin0dfOCmcAC7CHPWRtXsxCyioIF3rUQYAW2189 B25J89OzSSOcgTvVdbYfdjwuu1tmOyM1+CiyqHmFJj7q/zBsjtbE/RmXK4v0HwyJb5Ub ZdYbn5GI/zZR5bMnmy2Wv6iGfTKz9rcuKn9mG6Cs1YrLM8DAnrnxo1s4RI+Z4q4p86CO jc7ugag5txbX5yz0WvH4DoGAnfBlu6js6Yy2I1sxd9iUnAzWSzxJafQ47MDIQxzvci5c uafg== X-Gm-Message-State: ALoCoQlOwl5MLmHt6SBnL9Rck7ZKlEaV5twI05u9QMw9ol+hd8YXkUdGbbTwSs/XMy7fG6cs5wRM X-Received: by 10.180.104.198 with SMTP id gg6mr30955602wib.76.1414523412056; Tue, 28 Oct 2014 12:10:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.217.14.70 with HTTP; Tue, 28 Oct 2014 12:09:51 -0700 (PDT) In-Reply-To: References: <20141027053452.13077.qmail@cr.yp.to> <544E4832.8030600@cs.tcd.ie> <544EE4F1.2070201@cs.tcd.ie> From: Benjamin Black Date: Tue, 28 Oct 2014 12:09:51 -0700 Message-ID: To: Watson Ladd Content-Type: multipart/alternative; boundary=f46d04426e1080a5590506806537 Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/OIYdUfMguH3uBPD0CooEe1XXEYs Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] Actual security levels for IETF crypto X-BeenThere: cfrg@irtf.org 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: Tue, 28 Oct 2014 19:13:01 -0000 --f46d04426e1080a5590506806537 Content-Type: text/plain; charset=UTF-8 Pardon the formatting, I'm responding to several of Watson's posts at once: "Even if we look at TLS, performance matters a lot: it's the number 1 cited reason for not deploying TLS, and the stated reason we had this Curve25519 in TLS draft in the first place." There is a very long tail effect here. While many individuals might express performance as a reason for not deploying TLS, sites which represent the vast majority of HTTP and SMTP user traffic are few and universally deploy TLS. The performance concerns for such major services are more about cost reduction: faster curves means fewer servers to handle a given request rate (where connection setup is the dominant consumer of resources). There is no option to not deploy TLS because such services can buy more servers but they can't buy more trust. "We could easily achieve higher levels of security by expanding RSA keys, or using larger Diffie Hellman moduli. The only reason we don't is that performance matters, and bandwidth matters. And when you ignore these factors, you get DNSSEC, which has massive amplification issues and is nowhere near as secure as it could be if elliptic curve signatures had been used instead of RSA." The amplification problems of DNSSEC are not related to the choice of cryptography. Regardless of signature algorithm, DNSSEC responses are significantly larger than requests, making them attractive for amplification attacks. DNSSEC did not use EC originally because 15+ years ago when it was designed EC was still young and the patent situation made such a move infeasible. RSA was prevalent, unencumbered, and implementations were fast. EC was specified for DNSSEC only within the last 5 years, yesterday in DNS deployment time, and for much of that time patent concerns persisted, further retarding adoption. None of this is indicative of a bunch of protocol design clowns screwing up crypto. These are reasonable, even unavoidable, trade-offs. Similar constraints resulted in the persistence of RSA for TLS certificates even as EC was rapidly adopted for key exchange. It is unclear to me what lessons you are taking from this history and what point you are trying to make. "NIST P-256 is in the DNSSEC spec, and does fit in 500 bytes." ECDSA, and with it P256, was not specified for DNSSEC until 2012, in RFC6605. RFC4034, which updates the original DNSSEC specification, includes an ECC code point for signatures, but does not offer anything more and this code point was not used for either P256 or P384 based signatures. "Just as if Microsoft thinks the numbers we are getting for their curves are wrong, they should submit them to SUPERCOP." To which numbers are "we" referring? The performance numbers from the NUMS papers have been independently validated with the ECCLib implementation, which was the reason for releasing it. If you mean that you are running different benchmarks and getting different numbers, well, certainly. I would expect that to be the case for any implementation of any curve. I would not, however, insinuate that the authors of any of these implementations are making false claims regarding performance. b On Mon, Oct 27, 2014 at 11:29 PM, Watson Ladd wrote: > On Mon, Oct 27, 2014 at 10:28 PM, Phillip Hallam-Baker > wrote: > > > > On Mon, Oct 27, 2014 at 8:36 PM, Stephen Farrell < > stephen.farrell@cs.tcd.ie> > > wrote: > >> > >> > >> > >> On 27/10/14 15:35, Watson Ladd wrote: > >> > Are you saying that DNSSEC isn't an IETF protocol? Or that we should > >> > only look at widely deployed protocols when determining how choices > >> > about what to deploy are made? Or that DNSSEC doesn't have the same > >> > "marketing issue" as TLS? > >> > >> None of the above. I was saying (only) that that extrapolation > >> is dodgy. > >> > >> If I measured a bunch of Dutch folks' heights, and assumed that > >> the average of those told me something about the average height > >> of a human I'd be making the same extrapolation mistake. > > > > > > A more apt comparison might be to try to measure average human height > from a > > sample of Formula One drivers. > > > > There is a good reason folk choose a small key for DNS related work, the > > original protocol was limited to 500 bytes and quite a few bits of the > > Internet are still limited by the ancient ethernet MTU which isn't much > > bigger. > > NIST P-256 is in the DNSSEC spec, and does fit in 500 bytes. (64 bytes > in fact). DNSSEC failed to select small keys with adequate security, > and instead selected medium size keys with poor security, for reasons > that are now irrelevant, and were probably bogus even then. But even > in the range of keys that do fit, people are not going to the maximum > possible security. > > > > > > > Funny that someone would present this particular argument then accuse > others > > of 'marketing' as if it was a bad thing. > > > > My actual argument was that the market is subject to a one-upmanship > effect > > that tends to drive key sizes upwards. So if there is 384 and 512 on > offer > > with the new curves, don't expect anyone to use 384. > > But this didn't happen to 256 bit curves, which are still widely used > to protect TLS. It also didn't happen to 384 bit curves in PKIX: no > one is moving to 521 bit curves, in part because of compatibility > issues, but also because of lack of demand. It also hasn't happened > to RSA key sizes: the most popular key size on the web from Mozilla > telemetry is 2048 bits, with 4096 the next most popular, and the > ludicrously oversized 16384 virtually unseen in comparison. > > It also hasn't happened to root certificates: Based on a cursory look > (because clicking through every CA preloaded on my Mac was too much) I > would say there are between 30-35 RSA 4096 certificates, compared to a > vast number of 2048 and 1024 bit certificates. (My favorite is the > MD2, 1024 bit RSA, root certificate) > > Looking at Mozilla's list of included CAs tells a similar story: the > spreadsheet is avalible at > > https://docs.google.com/spreadsheet/pub?key=0Ah-tHXMAwqU3dGx0cGFObG9QM192NFM4UWNBMlBaekE&single=true&gid=1&output=html > , > and shows limited effect of one-upmanship. > > In fact, the removal of 1024 bit root keys broke a fair number of > websites, and was only completed in 2013. > > We also have data from Internet-wide scans of servers. > http://cryptome.org/2013/11/ecc-practice.pdf for ECC. The most common > key size is 256, followed by 384, and lastly is 521. Sadly similar > breakdowns by keysize for a similar scan aimed at RSA and DSA host > keys does not appear to exist. I would be surprised if it actually > supported the hypothesis. > > What evidence do you have that this one-upsmanship actually happens in > selecting key sizes? > > Furthermore, even if a 384 bit options sees limited use, there is > little harm in including it. However, given that there are 480 bit > options offering better performance, why not pick those instead? > Similarly, if 512 bits would make you happy, why not an even faster > 521 bit option? And why deny users who want a 384 bit option for > performance reasons the option to have a more satisfactory for them > balance between paranoia and practicality? > > Sincerely, > Watson Ladd > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg > --f46d04426e1080a5590506806537 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Pardon the formatting, I'm responding to several = of Watson's posts at once:

"Even if we look at TLS, pe= rformance matters
a lot: it's the number 1 cited reason for not deploying = TLS, and the
stated reason= we had this Curve25519 in TLS draft in the first place."
<= font face=3D"arial, sans-serif">
There is a very long tail effect here. While many individuals m= ight express performance as a reason for not deploying TLS, sites which rep= resent the vast majority of HTTP and SMTP user traffic are few and universa= lly deploy TLS. The performance concerns for such major services are more a= bout cost reduction: faster curves means fewer servers to handle a given re= quest rate (where connection setup is the dominant consumer of resources). = There is no option to not deploy TLS because such services can buy more ser= vers but they can't buy more trust.

"We could easily achieve higher levels of security by = expanding RSA
keys, or using larger Diffie Hellman moduli. The only reason we = don't
<= span style=3D"font-family:arial,sans-serif;font-size:13px">is that performa= nce matters, and bandwidth matters. And when you
ignore these factors, you get DNSSEC, which has mass= ive amplification
issues a= nd is nowhere near as secure as it could be if elliptic curve
signatures had been used instead of RSA= ."

<= font face=3D"arial, sans-serif">The amplification problems of DNSSEC are no= t related to the choice of cryptography. Regardless of signature algorithm,= DNSSEC responses are significantly larger than requests, making them attra= ctive for amplification attacks.=C2=A0

DNSSEC= did not use EC originally because 15+ years ago when it was designed EC wa= s still young and the patent situation made such a move infeasible. RSA was= prevalent, unencumbered, and implementations were fast. EC was specified f= or DNSSEC only within the last 5 years, yesterday in DNS deployment time, a= nd for much of that time patent concerns persisted, further retarding adopt= ion.

None of this is indicative of a bunch of= protocol design clowns screwing up crypto. These are reasonable, even unav= oidable, trade-offs. Similar constraints resulted in the persistence of RSA= for TLS certificates even as EC was rapidly adopted for key exchange. It i= s unclear to me what lessons you are taking from this history and what poin= t you are trying to make.

"NIST P-256 is in the DNSSEC spec, and does fit in 500 bytes.&= quot;

<= span style=3D"font-family:arial,sans-serif;font-size:13px">ECDSA, and with = it P256, was not specified for DNSSEC until 2012, in RFC6605. RFC4034, whic= h updates the original DNSSEC specification, includes an ECC code point for= signatures, but does not offer anything more and this code point was not u= sed for either P256 or P384 based signatures.

"Just a= s if Microsoft thinks the numbers we are getting for their=C2=A0curves are wrong, t= hey should submit them to SUPERCOP."

To which numbers are "we&= quot; referring? The performance numbers from the NUMS papers have been ind= ependently validated with the ECCLib implementation, which was the reason f= or releasing it. If you mean that you are running different benchmarks and = getting different numbers, well, certainly. I would expect that to be the c= ase for any implementation of any curve. I would not, however, insinuate th= at the authors of any of these implementations are making false claims rega= rding performance.


b

On Mon, Oct 27, 2014 at 1= 1:29 PM, Watson Ladd <watsonbladd@gmail.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">On Mon, Oct 27, 2014 at 10:2= 8 PM, Phillip Hallam-Baker
<phill@hallambaker.com> = wrote:
>
> On Mon, Oct 27, 2014 at 8:36 PM, Stephen Farrell <stephen.farrell@cs.tcd.ie>
> wrote:
>>
>>
>>
>> On 27/10/14 15:35, Watson Ladd wrote:
>> > Are you saying that DNSSEC isn't an IETF protocol? Or tha= t we should
>> > only look at widely deployed protocols when determining how c= hoices
>> > about what to deploy are made? Or that DNSSEC doesn't hav= e the same
>> > "marketing issue" as TLS?
>>
>> None of the above. I was saying (only) that that extrapolation
>> is dodgy.
>>
>> If I measured a bunch of Dutch folks' heights, and assumed tha= t
>> the average of those told me something about the average height >> of a human I'd be making the same extrapolation mistake.
>
>
> A more apt comparison might be to try to measure average human height = from a
> sample of Formula One drivers.
>
> There is a good reason folk choose a small key for DNS related work, t= he
> original protocol was limited to 500 bytes and quite a few bits of the=
> Internet are still limited by the ancient ethernet MTU which isn't= much
> bigger.

NIST P-256 is in the DNSSEC spec, and does fit in 500 bytes. (64 byt= es
in fact). DNSSEC failed to select small keys with adequate security,
and instead selected medium size keys with poor security, for reasons
that are now irrelevant, and were probably bogus even then. But even
in the range of keys that do fit, people are not going to the maximum
possible security.

>
>
> Funny that someone would present this particular argument then accuse = others
> of 'marketing' as if it was a bad thing.
>
> My actual argument was that the market is subject to a one-upmanship e= ffect
> that tends to drive key sizes upwards. So if there is 384 and 512 on o= ffer
> with the new curves, don't expect anyone to use 384.

But this didn't happen to 256 bit curves, which are still widely= used
to protect TLS. It also didn't happen to 384 bit curves in PKIX: no
one is moving to 521 bit curves, in part because of compatibility
issues,=C2=A0 but also because of lack of demand.=C2=A0 It also hasn't = happened
to RSA key sizes: the most popular key size on the web from Mozilla
telemetry is 2048 bits, with 4096 the next most popular, and the
ludicrously oversized 16384 virtually unseen in comparison.

It also hasn't happened to root certificates: Based on a cursory look (because clicking through every CA preloaded on my Mac was too much) I
would say there are between 30-35 RSA 4096 certificates, compared to a
vast number of 2048 and 1024 bit certificates. (My favorite is the
MD2, 1024 bit RSA, root certificate)

Looking at Mozilla's list of included CAs tells a similar story: the spreadsheet is avalible at
https://docs.google.com/spreadsheet/pub?key= =3D0Ah-tHXMAwqU3dGx0cGFObG9QM192NFM4UWNBMlBaekE&amp;single=3Dtrue&a= mp;gid=3D1&amp;output=3Dhtml,
and shows limited effect of one-upmanship.

In fact, the removal of 1024 bit root keys broke a fair number of
websites, and was only completed in 2013.

We also have data from Internet-wide scans of servers.
= http://cryptome.org/2013/11/ecc-practice.pdf for ECC. The most common key size is 256, followed by 384, and lastly is 521. Sadly similar
breakdowns by keysize for a similar scan aimed at RSA and DSA host
keys does not appear to exist. I would be surprised if it actually
supported the hypothesis.

What evidence do you have that this one-upsmanship actually happens in
selecting key sizes?

Furthermore, even if a 384 bit options sees limited use, there is
little harm in including it. However, given that there are 480 bit
options offering better performance, why not pick those instead?
Similarly, if 512 bits would make you happy, why not an even faster
521 bit option? And why deny users who want a 384 bit option for
performance reasons the option to have a more satisfactory for them
balance between paranoia and practicality?

Sincerely,
Watson Ladd

_______________________________________________
Cfrg mailing list
Cfrg@irtf.org
htt= p://www.irtf.org/mailman/listinfo/cfrg

--f46d04426e1080a5590506806537-- From nobody Tue Oct 28 12:23:27 2014 Return-Path: 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 E39201A9078 for ; Tue, 28 Oct 2014 12:23:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 zGEvb2k4Zypk for ; Tue, 28 Oct 2014 12:23:15 -0700 (PDT) Received: from mail-wg0-f52.google.com (mail-wg0-f52.google.com [74.125.82.52]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 906011AC40D for ; Tue, 28 Oct 2014 12:23:07 -0700 (PDT) Received: by mail-wg0-f52.google.com with SMTP id y10so232873wgg.39 for ; Tue, 28 Oct 2014 12:23:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=2XGMv2CUpSkgMdrMTEV2lKq6nvkunbf3lZiyPd+yqbI=; b=egmkOsee5vs5VHsZW3p6Xp+vgnm9CKoCBdudDLbAj3xT/fqEj8AeQiJ+mqoFEp0Xnv 5HeG1zU5vVhck8Fhrn+OY2Mf9BfbZo57nNwwLmOolZWvOemhWbWE3UkYG4DDvXpdQ1mU ROKvpApbMhsrOkqfk/bzd2G0hINAIeaYHHyJb8NMcZlUZsAo0DhusV7bBOuOGS2p41b2 /owdsxuPDZ6jF2BN55dlqSpvj8k7ZLfHHlYRyeENdT0Xy6lvpThLxEym5mwO6/jGbZLv VqzNmPFtKnYU1t8petZoQiUJkfmOQvRkgtOrd5qDsHiQzfk/F1D9TJ+WUyR5etK/SyAx nGQw== X-Gm-Message-State: ALoCoQl9ZVfzEx5LHjyqaVQqwdqwVq4DgdoYzrw5717VO6Qj/MGOPhBm7bAWHyvQa12TooYH8MQ+ X-Received: by 10.180.149.169 with SMTP id ub9mr7354884wib.73.1414524185864; Tue, 28 Oct 2014 12:23:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.217.14.70 with HTTP; Tue, 28 Oct 2014 12:22:45 -0700 (PDT) In-Reply-To: References: <20141027053452.13077.qmail@cr.yp.to> <544E4832.8030600@cs.tcd.ie> <544EE4F1.2070201@cs.tcd.ie> From: Benjamin Black Date: Tue, 28 Oct 2014 12:22:45 -0700 Message-ID: To: Yoav Nir Content-Type: multipart/alternative; boundary=001a11c38aea9fffe705068093ee Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/gSlheotelJoVrGyVax-4pja16GQ Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] Actual security levels for IETF crypto X-BeenThere: cfrg@irtf.org 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: Tue, 28 Oct 2014 19:23:19 -0000 --001a11c38aea9fffe705068093ee Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Oct 28, 2014 at 6:26 AM, Yoav Nir wrote: > > > 1) Curve 25519 is too much overhead. > > 2) Curve 25519 is acceptable but ~512 is not. > > 3) ~512 is acceptable. > > > > For reasons discussed earlier, there will always be constrained devices > for which case 1 applies, but any device currently doing RSA2048 can do > ~512 without any difficulty. > > It=E2=80=99s not a question of what they can or cannot do. According to t= he > Mozilla telemetry, 95% of HTTP connections (unfortunately this statistic = is > not split by SSL/non-SSL) transfer less than 200 KB of data. Pretty much > regardless of which PK and symmetric algorithms you use, PK operations wi= ll > dominate. So if you have a lot of connections like this (think web servic= es > and simple sites), the number of machines you need to buy, power and > maintain is inversely proportional to the speed of the PK operation. > > Much like discussion of TLS deployment, discussion of which aspects dominate in resource consumption is heavily skewed. For certain large online retail operations, the resource requirements on front end systems for constructing pages were (are?) such that there was at least an order of magnitude more CPU consumed rendering pages than what would be needed to terminate the TLS connections. One might reasonably ask if the money is evenly distributed across 100% of connections in the Mozilla telemetry. While I also disagree with what I see as overly simplistic analysis of curve strength preferences, I see it as no better to base decisions on overly simplistic analyses of traffic data. b --001a11c38aea9fffe705068093ee Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Oct 28, 2014 at 6:26 AM, Yoav Nir <ynir.ietf@gmail.com> wrote:

> 1) Curve 25519 is too much overhead.
> 2) Curve 25519 is acceptable but ~512 is not.
> 3) ~512 is acceptable.
>
> For reasons discussed earlier, there will always be constrained device= s for which case 1 applies, but any device currently doing RSA2048 can do ~= 512 without any difficulty.

It=E2=80=99s not a question of what they can or cannot do. According= to the Mozilla telemetry, 95% of HTTP connections (unfortunately this stat= istic is not split by SSL/non-SSL) transfer less than 200 KB of data. Prett= y much regardless of which PK and symmetric algorithms you use, PK operatio= ns will dominate. So if you have a lot of connections like this (think web = services and simple sites), the number of machines you need to buy, power a= nd maintain is inversely proportional to the speed of the PK operation.


Much like disc= ussion of TLS deployment, discussion of which aspects dominate in resource = consumption is heavily skewed. For certain large online retail operations, = the resource requirements on front end systems for constructing pages were = (are?) such that there was at least an order of magnitude more CPU consumed= rendering pages than what would be needed to terminate the TLS connections= . One might reasonably ask if the money is evenly distributed across 100% o= f connections in the Mozilla telemetry.

While I al= so disagree with what I see as overly simplistic analysis of curve strength= preferences, I see it as no better to base decisions on overly simplistic = analyses of traffic data.


b
--001a11c38aea9fffe705068093ee-- From nobody Tue Oct 28 13:02:20 2014 Return-Path: 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 183681ACDDB for ; Tue, 28 Oct 2014 13:02:17 -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 iCF5EuiNnakF for ; Tue, 28 Oct 2014 13:02:13 -0700 (PDT) Received: from mail-yh0-x22a.google.com (mail-yh0-x22a.google.com [IPv6:2607:f8b0:4002:c01::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9EF41ACDF8 for ; Tue, 28 Oct 2014 13:02:05 -0700 (PDT) Received: by mail-yh0-f42.google.com with SMTP id 29so770464yhl.15 for ; Tue, 28 Oct 2014 13:02:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ZiuvgSxMjXwrb9492xr+bSjTAUjj83KdNFMoMtxEEYI=; b=a+qRCKiQuRgIQs9SCf8zGpr5AEfs8G4bo/19Gy/t9zlLI2qEO/fF+iMcRjKCPIGrhA zO95wmCQn7sbZ6fVLoyZau/R6CfUlY1s7NI+um3L4PTyWguYISD30jUybk32lnEnc20Y cjSBifFJFQNrtfa38idAlu1LKZ+J+xDV2c7ESC1TPv8d9C3DdOgLBc0cO50ulAa9Mxam lVQ1IP04cRX/SpGgibbndeBkiWr144fgH1TVyf0qPfI/USYG9882ik9uXTtDCmZORill J6hlW8uysH8Q0VAr65nfggDuH2YKhK8XMnxLh6xzOT1qaZwcU3HYlC/KAYHZZZccAbZw Jwbg== MIME-Version: 1.0 X-Received: by 10.236.17.197 with SMTP id j45mr5269246yhj.49.1414526523461; Tue, 28 Oct 2014 13:02:03 -0700 (PDT) Received: by 10.170.195.149 with HTTP; Tue, 28 Oct 2014 13:02:03 -0700 (PDT) Received: by 10.170.195.149 with HTTP; Tue, 28 Oct 2014 13:02:03 -0700 (PDT) In-Reply-To: References: <20141027053452.13077.qmail@cr.yp.to> <544E4832.8030600@cs.tcd.ie> <544EE4F1.2070201@cs.tcd.ie> Date: Tue, 28 Oct 2014 13:02:03 -0700 Message-ID: From: Watson Ladd To: Benjamin Black Content-Type: multipart/alternative; boundary=047d7b603c58f4d70e0506811eef Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/JLmSSIDm7drQtDeho9Hvir3GD_o Cc: cfrg@irtf.org Subject: Re: [Cfrg] Actual security levels for IETF crypto X-BeenThere: cfrg@irtf.org 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: Tue, 28 Oct 2014 20:02:17 -0000 --047d7b603c58f4d70e0506811eef Content-Type: text/plain; charset=UTF-8 On Oct 28, 2014 12:10 PM, "Benjamin Black" wrote: > > Pardon the formatting, I'm responding to several of Watson's posts at once: > > "Even if we look at TLS, performance matters > a lot: it's the number 1 cited reason for not deploying TLS, and the > stated reason we had this Curve25519 in TLS draft in the first place." > > There is a very long tail effect here. While many individuals might express performance as a reason for not deploying TLS, sites which represent the vast majority of HTTP and SMTP user traffic are few and universally deploy TLS. The performance concerns for such major services are more about cost reduction: faster curves means fewer servers to handle a given request rate (where connection setup is the dominant consumer of resources). There is no option to not deploy TLS because such services can buy more servers but they can't buy more trust. What's good about spending extra money? > > "We could easily achieve higher levels of security by expanding RSA > keys, or using larger Diffie Hellman moduli. The only reason we don't > is that performance matters, and bandwidth matters. And when you > ignore these factors, you get DNSSEC, which has massive amplification > issues and is nowhere near as secure as it could be if elliptic curve > signatures had been used instead of RSA." > > The amplification problems of DNSSEC are not related to the choice of cryptography. Regardless of signature algorithm, DNSSEC responses are significantly larger than requests, making them attractive for amplification attacks. This is unavoidable, but RSA makes it worse. > > DNSSEC did not use EC originally because 15+ years ago when it was designed EC was still young and the patent situation made such a move infeasible. RSA was prevalent, unencumbered, and implementations were fast. EC was specified for DNSSEC only within the last 5 years, yesterday in DNS deployment time, and for much of that time patent concerns persisted, further retarding adoption. > ECC was invented in 1986. Unlike RSA, the algorithm was not patented by its inventors. All of the patents were on implementation techniques, and none were required to implement. Picking RSA hasn't measurably speed DNSSEC adoption. Furthermore, if the cryptography was fast enough to apply to every packet, the design would look considerably different. As a result of slow signing, we got fast offline zone walking. > None of this is indicative of a bunch of protocol design clowns screwing up crypto. These are reasonable, even unavoidable, trade-offs. Similar constraints resulted in the persistence of RSA for TLS certificates even as EC was rapidly adopted for key exchange. It is unclear to me what lessons you are taking from this history and what point you are trying to make. > > "NIST P-256 is in the DNSSEC spec, and does fit in 500 bytes." > > ECDSA, and with it P256, was not specified for DNSSEC until 2012, in RFC6605. RFC4034, which updates the original DNSSEC specification, includes an ECC code point for signatures, but does not offer anything more and this code point was not used for either P256 or P384 based signatures. > > "Just as if Microsoft thinks the numbers we are getting for their curves are wrong, they should submit them to SUPERCOP." > > To which numbers are "we" referring? The performance numbers from the NUMS papers have been independently validated with the ECCLib implementation, which was the reason for releasing it. If you mean that you are running different benchmarks and getting different numbers, well, certainly. I would expect that to be the case for any implementation of any curve. I would not, however, insinuate that the authors of any of these implementations are making false claims regarding performance. This is a reason for using the same single measurement framework for all benchmarks. I could easily imagine a systematic 10% measurement error caused by differing overheads when measuring the same code. I don't think the claims are false. I think it's hard to compare measurements made different ways on different machines, which is why Mike Hamburg email above is as good as it gets, and with relatively little effort we could have much better data. But if we accept the numbers above, what does that say about NUMS vs. Other? It looks to me that for minor changes in security level or performance, major gains in the other variable are possible. > > > b > > --047d7b603c58f4d70e0506811eef Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Oct 28, 2014 12:10 PM, "Benjamin Black" <b@b3k.us> wrote:
>
> Pardon the formatting, I'm responding to several of Watson's p= osts at once:
>
> "Even if we look at TLS, performance matters
> a lot: it's the number 1 cited reason for not deploying TLS, and t= he
> stated reason we had this Curve25519 in TLS draft in the first place.&= quot;
>
> There is a very long tail effect here. While many individuals might ex= press performance as a reason for not deploying TLS, sites which represent = the vast majority of HTTP and SMTP user traffic are few and universally dep= loy TLS. The performance concerns for such major services are more about co= st reduction: faster curves means fewer servers to handle a given request r= ate (where connection setup is the dominant consumer of resources). There i= s no option to not deploy TLS because such services can buy more servers bu= t they can't buy more trust.

What's good about spending extra money?
>
> "We could easily achieve higher levels of security by expanding R= SA
> keys, or using larger Diffie Hellman moduli. The only reason we don= 9;t
> is that performance matters, and bandwidth matters. And when you
> ignore these factors, you get DNSSEC, which has massive amplification<= br> > issues and is nowhere near as secure as it could be if elliptic curve<= br> > signatures had been used instead of RSA."
>
> The amplification problems of DNSSEC are not related to the choice of = cryptography. Regardless of signature algorithm, DNSSEC responses are signi= ficantly larger than requests, making them attractive for amplification att= acks.=C2=A0

This is unavoidable,=C2=A0 but RSA makes it worse.

>
> DNSSEC did not use EC originally because 15+ years ago when it was des= igned EC was still young and the patent situation made such a move infeasib= le. RSA was prevalent, unencumbered, and implementations were fast. EC was = specified for DNSSEC only within the last 5 years, yesterday in DNS deploym= ent time, and for much of that time patent concerns persisted, further reta= rding adoption.
>

ECC was invented in 1986. Unlike RSA, the algorithm was not = patented by its inventors. All of the patents were on implementation techni= ques, and none were required to implement. Picking RSA hasn't measurabl= y speed DNSSEC adoption.

Furthermore,=C2=A0 if the cryptography was fast enough to ap= ply to every packet, the design would look considerably different. As a res= ult of slow signing, we got fast offline zone walking.

> None of this is indicative of a bunch of protocol desig= n clowns screwing up crypto. These are reasonable, even unavoidable, trade-= offs. Similar constraints resulted in the persistence of RSA for TLS certif= icates even as EC was rapidly adopted for key exchange. It is unclear to me= what lessons you are taking from this history and what point you are tryin= g to make.
>
> "NIST P-256 is in the DNSSEC spec, and does fit in 500 bytes.&quo= t;
>
> ECDSA, and with it P256, was not specified for DNSSEC until 2012, in R= FC6605. RFC4034, which updates the original DNSSEC specification, includes = an ECC code point for signatures, but does not offer anything more and this= code point was not used for either P256 or P384 based signatures.
>
> "Just as if Microsoft thinks the numbers we are getting for their= =C2=A0curves are wrong, they should submit them to SUPERCOP."
>
> To which numbers are "we" referring? The performance numbers= from the NUMS papers have been independently validated with the ECCLib imp= lementation, which was the reason for releasing it. If you mean that you ar= e running different benchmarks and getting different numbers, well, certain= ly. I would expect that to be the case for any implementation of any curve.= I would not, however, insinuate that the authors of any of these implement= ations are making false claims regarding performance.

This is a reason for using the same single measurement frame= work for all benchmarks. I could easily imagine a systematic 10% measuremen= t error caused by differing overheads when measuring the same code.

I don't think the claims are false. I think it's har= d to compare measurements made different ways on different machines, which = is why Mike Hamburg email above is as good as it gets, and with relatively = little effort we could have much better data.

But if we accept the numbers above, what does that say about= NUMS vs. Other? It looks to me that for minor changes in security level or= performance,=C2=A0 major gains in the other variable are possible.

>
>
> b
>
>

--047d7b603c58f4d70e0506811eef-- From nobody Tue Oct 28 14:02:08 2014 Return-Path: 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 9EA441ACF5E for ; Tue, 28 Oct 2014 14:02:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.424 X-Spam-Level: * X-Spam-Status: No, score=1.424 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, LOTS_OF_MONEY=0.001, SPF_PASS=-0.001] autolearn=no 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 zpYy_S7N-2aM for ; Tue, 28 Oct 2014 14:02:04 -0700 (PDT) Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE5A71ACF66 for ; Tue, 28 Oct 2014 14:02:03 -0700 (PDT) Received: by mail-la0-f49.google.com with SMTP id ge10so1392232lab.22 for ; Tue, 28 Oct 2014 14:02:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=vus5JDijK1RMZXBrMNsMI2xNzOd+pfUCUMbI6zlEj0U=; b=oNCipfGXkHmB533pnuKrgPcW5gfBJr6a7yWWCkZQ1K6jt4W+SLC2iPbhSVbEWBNjFK 4/oIiM55vKnv3iQVClvYPl7FLi09D4N02r/+RLE90m6Msj7wSr8Fg3EA+FWjjaqVf+ML Y6cabJ1ovEZDBx+eazD13NyfE4wsuGweJ0dYJB1VV32WKQ7nW4w+W8Y3hfKXH9gtcysq xKzF3daJSoo71It8T+6sjSe/qUKp+BRHxuPDW+9KxwP96HwyW4uUcqqAeghTmzrHpASP /aawb9/W9mEjwTpDfdcI4ynsRKmZv93UqnNkCxfU7PCX+taXtyyIV/uArOqf8GBMYMkp NHTg== MIME-Version: 1.0 X-Received: by 10.152.1.42 with SMTP id 10mr6991624laj.4.1414530122111; Tue, 28 Oct 2014 14:02:02 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.214.163 with HTTP; Tue, 28 Oct 2014 14:02:01 -0700 (PDT) In-Reply-To: References: <20141027053452.13077.qmail@cr.yp.to> <544E4832.8030600@cs.tcd.ie> <544EE4F1.2070201@cs.tcd.ie> Date: Tue, 28 Oct 2014 17:02:01 -0400 X-Google-Sender-Auth: w2OoUMM6p_41CP3WC1WNbJGqDG8 Message-ID: From: Phillip Hallam-Baker To: Watson Ladd Content-Type: multipart/alternative; boundary=089e013c65bc73e1a5050681f528 Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/TxR5M5nj19jI5D7Z85vOoXj9IrE Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] Actual security levels for IETF crypto X-BeenThere: cfrg@irtf.org 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: Tue, 28 Oct 2014 21:02:05 -0000 --089e013c65bc73e1a5050681f528 Content-Type: text/plain; charset=UTF-8 On Tue, Oct 28, 2014 at 4:02 PM, Watson Ladd wrote: > On Oct 28, 2014 12:10 PM, "Benjamin Black" wrote: > >ECC was invented in 1986. Unlike RSA, the algorithm was not patented by > its inventors. All of the patents were on implementation techniques, and > none were required to implement. Picking RSA hasn't measurably speed DNSSEC > adoption. > No but a great big troll went and sat on the optimizations necessary to make it practical effectively scaring people away for 20 years. Criticizing folk for decisions made 20 years ago is ok, but you have to take time to understand what the constraints were. ECC has only recently become viable commercially. RSA has been completely unencumbered since 2000. I would much rather solve my customers performance concerns by selling them a $10K crypto accelerator board than to risk them being hit with a lawsuit that will cost them $3 million just to defend, $20 million to settle and risk damages of $500 million if they lose. And those are real figures from cases I have been involved in. Prior art can avoid the $500 million damages but only if you get a judge who isn't a complete jackass and you are still out the $3 million defense costs. On the Web Mail cases the prior art I have is pretty much as good as it gets. I can prove that I invented Web Mail because it was one of the test applications I used to fix the HTTP protocol and discovered POST was utterly broken. But the defendants still pay big money to settle. Given the financial state of RIM, the chance that the patents end up being bought by a troll for trolling was quite high. --089e013c65bc73e1a5050681f528 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Oct 28, 2014 at 4:02 PM, Watson Ladd <watsonbladd@gmail.com>= ; wrote:

On Oct 28, 2014 12:10 PM, "Benjamin Black" <b@b3k.us> wrote:
>ECC was invented in 1986. Unlike RSA, the algorithm was not patented by= its inventors. All of the patents were on implementation techniques, and n= one were required to implement. Picking RSA hasn't measurably speed DNS= SEC adoption.

No but a great big troll went and= sat on the optimizations necessary to make it practical effectively scarin= g people away for 20 years.

Criticizing folk for d= ecisions made 20 years ago is ok, but you have to take time to understand w= hat the constraints were. ECC has only recently become viable commercially.= =C2=A0


RSA has been completely unen= cumbered since 2000. I would much rather solve my customers performance con= cerns by selling them a $10K crypto accelerator board than to risk them bei= ng hit with a lawsuit that will cost them $3 million just to defend, $20 mi= llion to settle and risk damages of $500 million if they lose.
And those are real figures from cases I have been involved in.= Prior art can avoid the $500 million damages but only if you get a judge w= ho isn't a complete jackass and you are still out the $3 million defens= e costs.=C2=A0

On the Web Mail cases the prior art= I have is pretty much as good as it gets. I can prove that I invented Web = Mail because it was one of the test applications I used to fix the HTTP pro= tocol and discovered POST was utterly broken. But the defendants still pay = big money to settle.


Given the fina= ncial state of RIM, the chance that the patents end up being bought by a tr= oll for trolling was quite high.=C2=A0
--089e013c65bc73e1a5050681f528-- From nobody Tue Oct 28 14:05:47 2014 Return-Path: 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 A45F41ACF9E for ; Tue, 28 Oct 2014 14:05:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 7WgaFzBINgkE for ; Tue, 28 Oct 2014 14:05:42 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9A9F1ACF9B for ; Tue, 28 Oct 2014 14:05:41 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1XjDxT-00063F-1r; Tue, 28 Oct 2014 21:05:39 +0000 Date: Wed, 29 Oct 2014 06:05:37 +0900 Message-ID: From: Randy Bush To: Phillip Hallam-Baker In-Reply-To: References: <20141027053452.13077.qmail@cr.yp.to> <544E4832.8030600@cs.tcd.ie> <544EE4F1.2070201@cs.tcd.ie> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/AZa_J7lnQZEaEKnV8M3dslm8zBQ Cc: IRTF CFRG Subject: Re: [Cfrg] Actual security levels for IETF crypto X-BeenThere: cfrg@irtf.org 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: Tue, 28 Oct 2014 21:05:43 -0000 > So I can understand why people might try to make DNSSEC work with RSA1024 > even though I don't think they have much chance of success. i run a few cctlds with 2048 for a long time and have no reports of problems. this is not to say that all crows are black. randy From nobody Tue Oct 28 15:07:35 2014 Return-Path: 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 B319F1AD38C for ; Tue, 28 Oct 2014 15:07:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 53ZAH13zC_2I for ; Tue, 28 Oct 2014 15:06:56 -0700 (PDT) Received: from mail-wg0-f53.google.com (mail-wg0-f53.google.com [74.125.82.53]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D5F41AD354 for ; Tue, 28 Oct 2014 15:06:07 -0700 (PDT) Received: by mail-wg0-f53.google.com with SMTP id b13so548067wgh.26 for ; Tue, 28 Oct 2014 15:06:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=oNKSCaEpOwAyHkcNDJ0uT9Bfq8Yxk2Vh0HPWToZYBMI=; b=mIQx9WmL0sJ/u3CV2LApEt2co9zbT0lVhQ7koQf3a0CtJ15kf7K6QjJvHUEUT6pgDt 3mv9ji+rvU928ZlRs7Gllyiav/xr2NsIMuWWUfWgxc1T8A3L0+sLxLRdohyvvNthMZZ5 ybTp+/teTyP9IEWn9MU7EmbaKD0RmHSxvqb4cTvvxQts/z6XSmDaQkgI+p4dCGE2EYT0 oHMMhiXUU3/F/p8vnznG7EhNRW1fmRY7zNDCc7yZrsknbs6v6HkxGrBrGKWQB9LRWYiF w8oPcePG+SRd/Ut5y19HeZnymoSvPfenQUgtdSxHiGIOzwHWjAUNVYf893rTFfQ50O64 +KEQ== X-Gm-Message-State: ALoCoQnnQoLQT4PGTe7hg7kSU1U7YZKlEGGzDiyZkpURdXCy9Gm083BaJZ83HiQrOeQNUDsnQ63f X-Received: by 10.180.149.169 with SMTP id ub9mr8216869wib.73.1414533965812; Tue, 28 Oct 2014 15:06:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.217.14.70 with HTTP; Tue, 28 Oct 2014 15:05:45 -0700 (PDT) In-Reply-To: References: <20141027053452.13077.qmail@cr.yp.to> <544E4832.8030600@cs.tcd.ie> <544EE4F1.2070201@cs.tcd.ie> From: Benjamin Black Date: Tue, 28 Oct 2014 15:05:45 -0700 Message-ID: To: Watson Ladd Content-Type: multipart/alternative; boundary=001a11c38aea8e2d38050682dadb Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/K4_HU5CsCRTLJzs4RlbTEwGuzEA Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] Actual security levels for IETF crypto X-BeenThere: cfrg@irtf.org 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: Tue, 28 Oct 2014 22:07:27 -0000 --001a11c38aea8e2d38050682dadb Content-Type: text/plain; charset=UTF-8 On Tue, Oct 28, 2014 at 1:02 PM, Watson Ladd wrote: > > On Oct 28, 2014 12:10 PM, "Benjamin Black" wrote: > > > > There is a very long tail effect here. While many individuals might > express performance as a reason for not deploying TLS, sites which > represent the vast majority of HTTP and SMTP user traffic are few and > universally deploy TLS. The performance concerns for such major services > are more about cost reduction: faster curves means fewer servers to handle > a given request rate (where connection setup is the dominant consumer of > resources). There is no option to not deploy TLS because such services can > buy more servers but they can't buy more trust. > > What's good about spending extra money? > You stated performance was the main concern slowing TLS deployment. That is only true for small sites who represent a small fraction of TLS connections. For large players, TLS is a given and performance is useful for reducing COGS or improving latency (where latency again is interesting because there is correlation between lower latency and more money). > > > > > The amplification problems of DNSSEC are not related to the choice of > cryptography. Regardless of signature algorithm, DNSSEC responses are > significantly larger than requests, making them attractive for > amplification attacks. > > This is unavoidable, but RSA makes it worse. > Glad we agree. It is unavoidable, not caused by algorithm choice. > > > > DNSSEC did not use EC originally because 15+ years ago when it was > designed EC was still young and the patent situation made such a move > infeasible. RSA was prevalent, unencumbered, and implementations were fast. > EC was specified for DNSSEC only within the last 5 years, yesterday in DNS > deployment time, and for much of that time patent concerns persisted, > further retarding adoption. > > > > ECC was invented in 1986. Unlike RSA, the algorithm was not patented by > its inventors. All of the patents were on implementation techniques, and > none were required to implement. Picking RSA hasn't measurably speed DNSSEC > adoption. > You are well aware the history of ECC for widespread industrial use starts with SECG, which formed in 1998 and published SEC1 1.0 in 2000. RSA was chosen at the time because it was the best available option. The speed of adoption is unrelated to the algorithm choice in DNSSEC, except that mandating ECC in 1999 (or 2004) would've precluded most deployment. Are you seriously now arguing that patents on implementation techniques are no big deal and people should just work around them? I recall the opposite position being vigorously argued in the recent past. > Furthermore, if the cryptography was fast enough to apply to every > packet, the design would look considerably different. As a result of slow > signing, we got fast offline zone walking. > No idea what point you're making. You seem to be simultaneously suggesting that current DNSSEC key sizes are somehow relevant and that DNSSEC itself is garbage, a case study in how not to do it, and would be far better if only they'd applied knowledge from 15 years in the future. > > > > "NIST P-256 is in the DNSSEC spec, and does fit in 500 bytes." > > > > ECDSA, and with it P256, was not specified for DNSSEC until 2012, in > RFC6605. RFC4034, which updates the original DNSSEC specification, includes > an ECC code point for signatures, but does not offer anything more and this > code point was not used for either P256 or P384 based signatures. > > > ... > This is a reason for using the same single measurement framework for all > benchmarks. I could easily imagine a systematic 10% measurement error > caused by differing overheads when measuring the same code. > > I don't think the claims are false. I think it's hard to compare > measurements made different ways on different machines, which is why Mike > Hamburg email above is as good as it gets, and with relatively little > effort we could have much better data. > > But if we accept the numbers above, what does that say about NUMS vs. > Other? It looks to me that for minor changes in security level or > performance, major gains in the other variable are possible. > Trustworthiness of the curves are also a consideration, though obviously one not as easily measured as performance. That it is hard to measure or not a serious concern for you does not invalidate its importance to many. b --001a11c38aea8e2d38050682dadb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Oct 28, 2014 at 1:02 PM, Watson Ladd <watsonbladd@gmail.com>= ; wrote:


On Oct 28, 2014 12:10 PM, "Benjamin Black" <b@b3k.us> wrote:
>
> There is a very long tail effect here. While many individuals might ex= press performance as a reason for not deploying TLS, sites which represent = the vast majority of HTTP and SMTP user traffic are few and universally dep= loy TLS. The performance concerns for such major services are more about co= st reduction: faster curves means fewer servers to handle a given request r= ate (where connection setup is the dominant consumer of resources). There i= s no option to not deploy TLS because such services can buy more servers bu= t they can't buy more trust.

What's good about spending extra money?

You stated performance was the main concern slowing TLS deploym= ent. That is only true for small sites who represent a small fraction of TL= S connections. For large players, TLS is a given and performance is useful = for reducing COGS or improving latency (where latency again is interesting = because there is correlation between lower latency and more money).
=C2=A0


>
> The amplification problems of DNSSEC are not related to the choice of = cryptography. Regardless of signature algorithm, DNSSEC responses are signi= ficantly larger than requests, making them attractive for amplification att= acks.=C2=A0

This is unavoidable,=C2=A0 but RSA makes it worse.

Glad we agree. It is unavoidable, not caused by algorithm choic= e.
=C2=A0

>
> DNSSEC did not use EC originally because 15+ years ago when it was des= igned EC was still young and the patent situation made such a move infeasib= le. RSA was prevalent, unencumbered, and implementations were fast. EC was = specified for DNSSEC only within the last 5 years, yesterday in DNS deploym= ent time, and for much of that time patent concerns persisted, further reta= rding adoption.
>

ECC was invented in 1986. Unlike RSA, the algorithm w= as not patented by its inventors. All of the patents were on implementation= techniques, and none were required to implement. Picking RSA hasn't me= asurably speed DNSSEC adoption.

You are well aware the= history of ECC for widespread industrial use starts with SECG, which forme= d in 1998 and published SEC1 1.0 in 2000. RSA was chosen at the time becaus= e it was the best available option. The speed of adoption is unrelated to t= he algorithm choice in DNSSEC, except that mandating ECC in 1999 (or 2004) = would've precluded most deployment.

Are you se= riously now arguing that patents on implementation techniques are no big de= al and people should just work around them? I recall the opposite position = being vigorously argued in the recent past.

Furthermore,=C2=A0 if the cryptography was fast enough to ap= ply to every packet, the design would look considerably different. As a res= ult of slow signing, we got fast offline zone walking.

No idea what point you're making. You seem to be simultaneously sugges= ting that current DNSSEC key sizes are somehow relevant and that DNSSEC its= elf is garbage, a case study in how not to do it, and would be far better i= f only they'd applied knowledge from 15 years in the future.=C2=A0

>
> "NIST P-256 is in the DNSSEC spec, and does fit in 500 bytes.&quo= t;
>
> ECDSA, and with it P256, was not specified for DNSSEC until 2012, in R= FC6605. RFC4034, which updates the original DNSSEC specification, includes = an ECC code point for signatures, but does not offer anything more and this= code point was not used for either P256 or P384 based signatures.
>

...
=C2=A0

This is a reason for usi= ng the same single measurement framework for all benchmarks. I could easily= imagine a systematic 10% measurement error caused by differing overheads w= hen measuring the same code.

I don't think the claims are false. I think it's har= d to compare measurements made different ways on different machines, which = is why Mike Hamburg email above is as good as it gets, and with relatively = little effort we could have much better data.

But if we accept the numbers above, what does that say about= NUMS vs. Other? It looks to me that for minor changes in security level or= performance,=C2=A0 major gains in the other variable are possible.

Trustworthiness of the curves are also a consideration, thoug= h obviously one not as easily measured as performance. That it is hard to m= easure or not a serious concern for you does not invalidate its importance = to many.


b=C2=A0
<= /div> --001a11c38aea8e2d38050682dadb-- From nobody Tue Oct 28 16:00:05 2014 Return-Path: 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 81D0D1A0687 for ; Tue, 28 Oct 2014 16:00:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 MeeDB9nnNijs for ; Tue, 28 Oct 2014 15:59:56 -0700 (PDT) Received: from mail-yk0-x22a.google.com (mail-yk0-x22a.google.com [IPv6:2607:f8b0:4002:c07::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A0BB1A0410 for ; Tue, 28 Oct 2014 15:59:56 -0700 (PDT) Received: by mail-yk0-f170.google.com with SMTP id 19so792561ykq.15 for ; Tue, 28 Oct 2014 15:59:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6ayLOq6KGjU3kz6RJSnxW5Z/rwAP/yPYJBVocR+MoTw=; b=JOjhRjf8kpOIPghy2XHXk7bs83lKiC3H7S5L4Ojg9UxZhagqMr/zVzwganTDDTUtmt F7lUz4Pj12bfL47KYsyZPUj6LbbXoI9x5ob+5jtlZq9tXBwG9Q9ywgBWqvtJiEDW0PS0 klbFY2oLsFczQMMNPQGk7TjjiJXHchNY5kawmDNlZYg/aeORbaCGM2tpsMrpngHcxtAh +EWwb0saXPUysMaLSGikyjEoZu3WJ74SUca3qfw09RZv59AWLnFd0vdUrhYZl3fgWJ3f YAvQzRlfLAjFoPetZ4nv4zNhwXBhBPALt0F9ajPL3zl4UqzPoRstq34UxpoCkrSFwEZP Ip8Q== MIME-Version: 1.0 X-Received: by 10.170.116.203 with SMTP id i194mr7273471ykb.52.1414537195386; Tue, 28 Oct 2014 15:59:55 -0700 (PDT) Received: by 10.170.195.149 with HTTP; Tue, 28 Oct 2014 15:59:54 -0700 (PDT) Received: by 10.170.195.149 with HTTP; Tue, 28 Oct 2014 15:59:54 -0700 (PDT) In-Reply-To: References: <20141027053452.13077.qmail@cr.yp.to> <544E4832.8030600@cs.tcd.ie> <544EE4F1.2070201@cs.tcd.ie> Date: Tue, 28 Oct 2014 15:59:54 -0700 Message-ID: From: Watson Ladd To: Benjamin Black Content-Type: multipart/alternative; boundary=001a1137d4c80d803a0506839b59 Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/v7xwz3-R8GGAQ5gGfd9clcEWlTY Cc: cfrg@irtf.org Subject: Re: [Cfrg] Actual security levels for IETF crypto X-BeenThere: cfrg@irtf.org 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: Tue, 28 Oct 2014 23:00:00 -0000 --001a1137d4c80d803a0506839b59 Content-Type: text/plain; charset=UTF-8 On Oct 28, 2014 3:06 PM, "Benjamin Black" wrote: > > On Tue, Oct 28, 2014 at 1:02 PM, Watson Ladd wrote: >> >> >> On Oct 28, 2014 12:10 PM, "Benjamin Black" wrote: >> > >> > There is a very long tail effect here. While many individuals might express performance as a reason for not deploying TLS, sites which represent the vast majority of HTTP and SMTP user traffic are few and universally deploy TLS. The performance concerns for such major services are more about cost reduction: faster curves means fewer servers to handle a given request rate (where connection setup is the dominant consumer of resources). There is no option to not deploy TLS because such services can buy more servers but they can't buy more trust. >> >> What's good about spending extra money? > > You stated performance was the main concern slowing TLS deployment. That is only true for small sites who represent a small fraction of TLS connections. For large players, TLS is a given and performance is useful for reducing COGS or improving latency (where latency again is interesting because there is correlation between lower latency and more money). I want every connection encrypted. To the extent that slow performance driven by acceptability concerns interferes with this, that's a problem. I'm already sad that the current best performer in eBATS, literally thousands of times faster then RSA of similar security levels, has been ruled out. Performance of ECC is a major reason Cloudflare could turn on TLS for everyone. If they were stuck with DHE and RSA, it wouldn't have happened. Let's not limit the scope of discussion to websites taking money. > >> >> >> > >> > The amplification problems of DNSSEC are not related to the choice of cryptography. Regardless of signature algorithm, DNSSEC responses are significantly larger than requests, making them attractive for amplification attacks. >> >> This is unavoidable, but RSA makes it worse. > > Glad we agree. It is unavoidable, not caused by algorithm choice. It's made worse by algorithm choice, and some misfeatures like domain suicide are directly caused by the barely adequate strength of RSA 1024, and consequent workarounds. > >> >> > >> > DNSSEC did not use EC originally because 15+ years ago when it was designed EC was still young and the patent situation made such a move infeasible. RSA was prevalent, unencumbered, and implementations were fast. EC was specified for DNSSEC only within the last 5 years, yesterday in DNS deployment time, and for much of that time patent concerns persisted, further retarding adoption. >> > >> >> ECC was invented in 1986. Unlike RSA, the algorithm was not patented by its inventors. All of the patents were on implementation techniques, and none were required to implement. Picking RSA hasn't measurably speed DNSSEC adoption. > > You are well aware the history of ECC for widespread industrial use starts with SECG, which formed in 1998 and published SEC1 1.0 in 2000. RSA was chosen at the time because it was the best available option. The speed of adoption is unrelated to the algorithm choice in DNSSEC, except that mandating ECC in 1999 (or 2004) would've precluded most deployment. > > Are you seriously now arguing that patents on implementation techniques are no big deal and people should just work around them? I recall the opposite position being vigorously argued in the recent past. By me? Which patent would that have been? Actually I'm arguing that ECC patent concerns were massively overblown, and that speed gains over RSA were attainable even without taking advantage of the specialness of the prime. But that's really far from the choice we face now. >> >> Furthermore, if the cryptography was fast enough to apply to every packet, the design would look considerably different. As a result of slow signing, we got fast offline zone walking. > > No idea what point you're making. You seem to be simultaneously suggesting that current DNSSEC key sizes are somehow relevant and that DNSSEC itself is garbage, a case study in how not to do it, and would be far better if only they'd applied knowledge from 15 years in the future. No: I'm arguing that the choice of RSA signing had implications for the design of DNSSEC that were negative, in part because of RSA key sizes and speed, and that users of DNSSEC are constrained by performance and other problems rather then going for the most secure option. It's a case study in slow crypto forcing bad design choices. >> >> > >> > "NIST P-256 is in the DNSSEC spec, and does fit in 500 bytes." >> > >> > ECDSA, and with it P256, was not specified for DNSSEC until 2012, in RFC6605. RFC4034, which updates the original DNSSEC specification, includes an ECC code point for signatures, but does not offer anything more and this code point was not used for either P256 or P384 based signatures. >> > > > ... > >> >> This is a reason for using the same single measurement framework for all benchmarks. I could easily imagine a systematic 10% measurement error caused by differing overheads when measuring the same code. >> >> I don't think the claims are false. I think it's hard to compare measurements made different ways on different machines, which is why Mike Hamburg email above is as good as it gets, and with relatively little effort we could have much better data. >> >> But if we accept the numbers above, what does that say about NUMS vs. Other? It looks to me that for minor changes in security level or performance, major gains in the other variable are possible. > > Trustworthiness of the curves are also a consideration, though obviously one not as easily measured as performance. That it is hard to measure or not a serious concern for you does not invalidate its importance to many. In what way is 25519 less trustworthy them the Microsoft proposal? Performance is also very demanding and imposes rigidity. How much performance are you willing to give up for a little trust, which can't be easily measured, and might point the other way in the case of E-521 with 3 independent discoveries? Curve choice matters less then point format and signature issues where we are also disappointingly far from agreement. Or maybe we are close enough that no one bothered to respond beyond Andy Lutomirski because the answers were obvious. > > > b --001a1137d4c80d803a0506839b59 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Oct 28, 2014 3:06 PM, "Benjamin Black" <b@b3k.us> wrote:
>
> On Tue, Oct 28, 2014 at 1:02 PM, Watson Ladd <watsonbladd@gmail.com> wrote:
>>
>>
>> On Oct 28, 2014 12:10 PM, "Benjamin Black" <b@b3k.us> wrote:
>> >
>> > There is a very long tail effect here. While many individuals= might express performance as a reason for not deploying TLS, sites which r= epresent the vast majority of HTTP and SMTP user traffic are few and univer= sally deploy TLS. The performance concerns for such major services are more= about cost reduction: faster curves means fewer servers to handle a given = request rate (where connection setup is the dominant consumer of resources)= . There is no option to not deploy TLS because such services can buy more s= ervers but they can't buy more trust.
>>
>> What's good about spending extra money?
>
> You stated performance was the main concern slowing TLS deployment. Th= at is only true for small sites who represent a small fraction of TLS conne= ctions. For large players, TLS is a given and performance is useful for red= ucing COGS or improving latency (where latency again is interesting because= there is correlation between lower latency and more money).

I want every connection encrypted. To the extent that slow p= erformance driven by acceptability concerns interferes with this, that'= s a problem. I'm already sad that the current best performer in eBATS,= =C2=A0 literally thousands of times faster then RSA of similar security lev= els,=C2=A0 has been ruled out.

Performance of ECC is a major reason Cloudflare could turn o= n TLS for everyone. If they were stuck with DHE and RSA, it wouldn't ha= ve happened. Let's not limit the scope of discussion to websites taking= money.

> =C2=A0
>>
>>
>> >
>> > The amplification problems of DNSSEC are not related to the c= hoice of cryptography. Regardless of signature algorithm, DNSSEC responses = are significantly larger than requests, making them attractive for amplific= ation attacks.=C2=A0
>>
>> This is unavoidable,=C2=A0 but RSA makes it worse.
>
> Glad we agree. It is unavoidable, not caused by algorithm choice.

It's made worse by algorithm choice, and some misfeature= s like domain suicide are directly caused by the barely adequate strength o= f RSA 1024, and consequent workarounds.

> =C2=A0
>>
>> >
>> > DNSSEC did not use EC originally because 15+ years ago when i= t was designed EC was still young and the patent situation made such a move= infeasible. RSA was prevalent, unencumbered, and implementations were fast= . EC was specified for DNSSEC only within the last 5 years, yesterday in DN= S deployment time, and for much of that time patent concerns persisted, fur= ther retarding adoption.
>> >
>>
>> ECC was invented in 1986. Unlike RSA, the algorithm was not patent= ed by its inventors. All of the patents were on implementation techniques, = and none were required to implement. Picking RSA hasn't measurably spee= d DNSSEC adoption.
>
> You are well aware the history of ECC for widespread industrial use st= arts with SECG, which formed in 1998 and published SEC1 1.0 in 2000. RSA wa= s chosen at the time because it was the best available option. The speed of= adoption is unrelated to the algorithm choice in DNSSEC, except that manda= ting ECC in 1999 (or 2004) would've precluded most deployment.
>
> Are you seriously now arguing that patents on implementation technique= s are no big deal and people should just work around them? I recall the opp= osite position being vigorously argued in the recent past.

By me? Which patent would that have been? Actually I'm a= rguing that ECC patent concerns were massively overblown, and that speed ga= ins over RSA were attainable even without taking advantage of the specialne= ss of the prime. But that's really far from the choice we face now.

>>
>> Furthermore,=C2=A0 if the cryptography was fast enough to apply to= every packet, the design would look considerably different. As a result of= slow signing, we got fast offline zone walking.
>
> No idea what point you're making. You seem to be simultaneously su= ggesting that current DNSSEC key sizes are somehow relevant and that DNSSEC= itself is garbage, a case study in how not to do it, and would be far bett= er if only they'd applied knowledge from 15 years in the future.=C2=A0<= /p>

No: I'm arguing that the choice of RSA signing had impli= cations for the design of DNSSEC that were negative,=C2=A0 in part because = of RSA key sizes and speed, and that users of DNSSEC are constrained by per= formance and other problems rather then going for the most secure option. I= t's a case study in slow crypto forcing bad design choices.

>>
>> >
>> > "NIST P-256 is in the DNSSEC spec, and does fit in 500 b= ytes."
>> >
>> > ECDSA, and with it P256, was not specified for DNSSEC until 2= 012, in RFC6605. RFC4034, which updates the original DNSSEC specification, = includes an ECC code point for signatures, but does not offer anything more= and this code point was not used for either P256 or P384 based signatures.=
>> >
>
> ...
> =C2=A0
>>
>> This is a reason for using the same single measurement framework f= or all benchmarks. I could easily imagine a systematic 10% measurement erro= r caused by differing overheads when measuring the same code.
>>
>> I don't think the claims are false. I think it's hard to c= ompare measurements made different ways on different machines, which is why= Mike Hamburg email above is as good as it gets, and with relatively little= effort we could have much better data.
>>
>> But if we accept the numbers above, what does that say about NUMS = vs. Other? It looks to me that for minor changes in security level or perfo= rmance,=C2=A0 major gains in the other variable are possible.
>
> Trustworthiness of the curves are also a consideration, though obvious= ly one not as easily measured as performance. That it is hard to measure or= not a serious concern for you does not invalidate its importance to many.<= /p>

In what way is 25519 less trustworthy them the Microsoft pro= posal? Performance is also very demanding and imposes rigidity. How much pe= rformance are you willing to give up for a little trust, which can't be= easily measured, and might point the other way in the case of E-521 with 3= independent discoveries?

Curve choice matters less then point format and signature is= sues where we are also disappointingly far from agreement. Or maybe we are = close enough that no one bothered to respond beyond Andy Lutomirski because= the answers were obvious.

>
>
> b

--001a1137d4c80d803a0506839b59-- From nobody Tue Oct 28 21:25:06 2014 Return-Path: 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 CD4AC1A6F67 for ; Tue, 28 Oct 2014 21:25:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.101 X-Spam-Level: X-Spam-Status: No, score=0.101 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, UNPARSEABLE_RELAY=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 v5l6D9qmNzkI for ; Tue, 28 Oct 2014 21:25:02 -0700 (PDT) Received: from mace.cs.uic.edu (mace.cs.uic.edu [131.193.32.224]) by ietfa.amsl.com (Postfix) with SMTP id 7427E1A0111 for ; Tue, 28 Oct 2014 21:25:02 -0700 (PDT) Received: (qmail 17806 invoked by uid 1011); 29 Oct 2014 04:24:57 -0000 Received: from unknown (unknown) by unknown with QMTP; 29 Oct 2014 04:24:57 -0000 Received: (qmail 16754 invoked by uid 1001); 29 Oct 2014 04:24:54 -0000 Date: 29 Oct 2014 04:24:54 -0000 Message-ID: <20141029042454.16752.qmail@cr.yp.to> From: "D. J. Bernstein" To: cfrg@irtf.org Mail-Followup-To: cfrg@irtf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/0K0XJYdXWnc64IcTEaBhHWjMk8A Subject: Re: [Cfrg] Actual security levels for IETF crypto X-BeenThere: cfrg@irtf.org 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: Wed, 29 Oct 2014 04:25:05 -0000 Benjamin Black writes: > While many individuals might express performance as a reason for not > deploying TLS, sites which represent the vast majority of HTTP and > SMTP user traffic are few and universally deploy TLS. I'm a big fan of basing decisions upon facts, so let's try an example. Would you claim that Amazon---obviously one of the world's most popular web sites; right now Alexa says #7---uses TLS? If I try https://www.amazon.com, Amazon's servers redirect my browser to http://www.amazon.com. Similarly, if I try a search on Amazon and then insert "https" into the URL, Amazon's servers redirect my browser back to unencrypted HTTP. Evidently Amazon has done all the work of setting up an HTTPS server whose only function is to give me "secured" redirections---a meaningless form of "security" when the redirections are to unprotected web pages. There are of course the occasional Amazon order/credit-card pages using TLS, but the big picture is that most Amazon traffic is unencrypted and unauthenticated. How do you explain Amazon redirecting HTTPS to HTTP, if not performance? What do you think will do the best job of actually encrypting Amazon's web pages: crypto that provides exceptional combinations of security and speed, or crypto that provides powers of 2 to the marketing department? As another example, I just tried https://www.msn.com with various free browsers (routing connections through proxies in a few countries), and in each case received the following error message: This page is not available right now We're working to restore it as soon as possible. Please check back soon. Click here to try this page again, or visit: http://www.msn.com http://www.msn.com is working fine, and I don't see people complaining on Twitter about MSN being down. What fraction of MSN traffic is HTTPS? There are a huge number of popular sites that redirect HTTPS to HTTP, or that allow manual HTTPS but advertise primarily HTTP, or that don't work at all through HTTPS. The use of HTTPS is slowly growing but real traffic measurements such as http://www.caida.org/data/passive/trace_stats/chicago-A/2014/?monitor=20140821-130000.UTC show that HTTP remains dominant---quite the opposite of your claim. Performance isn't the only obstacle to HTTPS deployment but it's clearly the primary obstacle in many cases, such as the HTTPS-redirect cases. Again, CFRG's stated goal in the curve-selection process is to "provide real value" not just to TLS but "the IETF more widely". The current reality is that ~2^0 security is dominant in pretty much every IETF protocol; ~2^80 security remains surprisingly popular despite many warnings; ~2^90 security is the fastest-growing level for DNSSEC TLDs; and ~2^110 security is the fastest-growing level for HTTPS. There's overwhelming evidence that these choices of security levels have been pushed downwards by real cost constraints. If CFRG actually wants to make a difference---especially for the quiet majority using 2^0 security---then it has to take these constraints into account. State-of-the-art ECC provides much better speed/security tradeoffs than RSA, and should drastically improve the situation. But it's clear that these tradeoffs will be damaged if CFRG imposes superficial marketing rules such as 2^2^k security levels. ---Dan From nobody Tue Oct 28 23:49:54 2014 Return-Path: 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 0D4271A19F4 for ; Tue, 28 Oct 2014 23:49:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.078 X-Spam-Level: X-Spam-Status: No, score=-0.078 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 abgfT53Kj1Mh for ; Tue, 28 Oct 2014 23:49:48 -0700 (PDT) Received: from mail-wg0-f45.google.com (mail-wg0-f45.google.com [74.125.82.45]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 466051A19F0 for ; Tue, 28 Oct 2014 23:49:48 -0700 (PDT) Received: by mail-wg0-f45.google.com with SMTP id x12so1146443wgg.18 for ; Tue, 28 Oct 2014 23:49:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type; bh=8yHys6GxuUCONx2t2wB2qA+fuD1ibLtoK4MMM/yrwlU=; b=FG6l4ITXwcQ30cgIM3oJoz0I/2eI/Pbkq2+Y6xt3pG3XDL9g8KQNqBUcNQolJzYQka fBtWbZuzhMLNrlY1auqPXyfSgtdUz1PVtiSGdI4F2b3eb0aSDKYjyJaMpvh80UHg3qHi cFLuJDxbbCgMBDesR9hO4YRzTiLov1Pmn80regI3fxWApnGA5cTF62TpjBFoXENWBnIF ytUpJHbUqjI2HvMbRLYyJgX3zbgbUizhtCQNIsyqjCrlQN2JUpdoSaoovMBSYOd+2vud Q6SLu6hD1SjctqdVBKeKI1LTqJ1fkMFmH6X8gFojXnieKiR/IBsuPBYy5agVNB9++WpN KCgw== X-Gm-Message-State: ALoCoQkrfm7euEJhkuAumfc//E2qHP7Dj4n8fvkxO1xl5Ca197wLTdZFHJJZFQuz0rQymAIo4sxe X-Received: by 10.181.11.131 with SMTP id ei3mr10231303wid.24.1414565386825; Tue, 28 Oct 2014 23:49:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.217.14.70 with HTTP; Tue, 28 Oct 2014 23:49:26 -0700 (PDT) In-Reply-To: <20141029042454.16752.qmail@cr.yp.to> References: <20141029042454.16752.qmail@cr.yp.to> From: Benjamin Black Date: Tue, 28 Oct 2014 23:49:26 -0700 Message-ID: To: "cfrg@irtf.org" Content-Type: multipart/alternative; boundary=f46d043c80ba64c81705068a2bba Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/NkTnJNo9YWiKXPCF8UsnVVsr224 Subject: Re: [Cfrg] Actual security levels for IETF crypto X-BeenThere: cfrg@irtf.org 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: Wed, 29 Oct 2014 06:49:52 -0000 --f46d043c80ba64c81705068a2bba Content-Type: text/plain; charset=UTF-8 On Tue, Oct 28, 2014 at 9:24 PM, D. J. Bernstein wrote: > Benjamin Black writes: > > While many individuals might express performance as a reason for not > > deploying TLS, sites which represent the vast majority of HTTP and > > SMTP user traffic are few and universally deploy TLS. > > I'm a big fan of basing decisions upon facts, so let's try an example. > Would you claim that Amazon---obviously one of the world's most popular > web sites; right now Alexa says #7---uses TLS? > > I would claim that you sought out the only US site in the top 25 that doesn't use TLS for every page. Every other US site in the global top 25 is TLS. How can that be if performance concerns are stopping deployment? > If I try https://www.amazon.com, Amazon's servers redirect my browser > to http://www.amazon.com. Similarly, if I try a search on Amazon and > then insert "https" into the URL, Amazon's servers redirect my browser > back to unencrypted HTTP. > > Evidently Amazon has done all the work of setting up an HTTPS server > whose only function is to give me "secured" redirections---a meaningless > form of "security" when the redirections are to unprotected web pages. > There are of course the occasional Amazon order/credit-card pages using > TLS, but the big picture is that most Amazon traffic is unencrypted and > unauthenticated. > > How do you explain Amazon redirecting HTTPS to HTTP, if not performance? What do you think will do the best job of actually encrypting Amazon's > web pages: crypto that provides exceptional combinations of security and > speed, or crypto that provides powers of 2 to the marketing department? > > Amazon, unlike email and search providers, has not been subject to significant public and commercial pressure to deploy HTTPS for all pages. They may choose to invest the resources to do such a transition, they may not. The question is not what would do the best job of encrypting their pages, it is what would cause them to move resources from building new features to converting to HTTPS. I suspect there could be zero performance overhead and they still wouldn't move without a business reason. > As another example, I just tried https://www.msn.com with various free > browsers (routing connections through proxies in a few countries), and > in each case received the following error message: > > This page is not available right now > We're working to restore it as soon as possible. Please check back soon. > Click here to try this page again, or visit: http://www.msn.com > > http://www.msn.com is working fine, and I don't see people complaining > on Twitter about MSN being down. What fraction of MSN traffic is HTTPS? > > Are you saying MSN isn't HTTPS today because of performance concerns or that people often don't know or care if their traffic is encrypted? > There are a huge number of popular sites that redirect HTTPS to HTTP, or > that allow manual HTTPS but advertise primarily HTTP, or that don't work > at all through HTTPS. The use of HTTPS is slowly growing but real > traffic measurements such as > > > http://www.caida.org/data/passive/trace_stats/chicago-A/2014/?monitor=20140821-130000.UTC > > show that HTTP remains dominant---quite the opposite of your claim. A one hour trace from one location showing bits/sec is not sufficient data to make claims about growth or relative scale. > Performance isn't the only obstacle to HTTPS deployment but it's clearly > the primary obstacle in many cases, such as the HTTPS-redirect cases. > > On what do you base this claim? My direct experience in recently working to move numerous, large sites to HTTPS-only is that performance issues are raised mostly for capacity planning and not to block deployment. Instead, people want to do the right thing for customers. In other contexts in the recent past, I've seen people refuse to deploy TLS because they don't want to pay for certificates, because they were put off by the perceived complexity, even because they were concerned about performance, but were either unable to articulate specifics or based their opinion on incorrect data (for example, comparing performance of DHE to unencrypted requests). None of those are overcome by offering a somewhat faster PFS they don't understand anyway. > Again, CFRG's stated goal in the curve-selection process is to "provide > real value" not just to TLS but "the IETF more widely". The current > reality is that > > ~2^0 security is dominant in pretty much every IETF protocol; > ~2^80 security remains surprisingly popular despite many warnings; ~2^90 security is the fastest-growing level for DNSSEC TLDs; and > ~2^110 security is the fastest-growing level for HTTPS. > > There's overwhelming evidence that these choices of security levels have > been pushed downwards by real cost constraints. If CFRG actually wants > to make a difference---especially for the quiet majority using 2^0 > security---then it has to take these constraints into account. > > Where is this overwhelming evidence? A 15 year old protocol in a scenario that makes upgrades glacially slow? A single US site in the Alexa global top 25 that doesn't use HTTPS for all pages? An hour of traffic at a single point? There has been a massive acceleration in HTTPS deployment in the past 18 months and it has been driven by exactly one cause: Snowden. The same cause will continue to drive most deployment, regardless of what CFRG does and despite the cost. Large operators aren't pushing for faster crypto because the current stuff is too slow to deploy. They are doing it because they have _already_ deployed the crypto and want to reduce costs. > State-of-the-art ECC provides much better speed/security tradeoffs than > RSA, and should drastically improve the situation. But it's clear that > these tradeoffs will be damaged if CFRG imposes superficial marketing > rules such as 2^2^k security levels. > > You're arguing it's Performance! Performance! Performance! then talking about speed/security tradeoffs? RSA is plenty fast for key exchange and TLS deployment is what it is. Giving people more security for similar performance won't move the needle. Moving the needle on this is not exciting. It involves sending lots of pull requests to open source projects so they have sane TLS defaults, including ECDHE, and grinding away for years getting TLS deployed on large services. My trustworthiness comment was not related to security levels. b --f46d043c80ba64c81705068a2bba Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Oct 28, 2014 at 9:24 PM, D. J. Bernstein <djb@cr.yp.to> wrot= e:
Benjamin Black writes:
> While many individuals might express performance as a reason for not > deploying TLS, sites which represent the vast majority of HTTP and
> SMTP user traffic are few and universally deploy TLS.

I'm a big fan of basing decisions upon facts, so let's try a= n example.
Would you claim that Amazon---obviously one of the world's most popular=
web sites; right now Alexa says #7---uses TLS?


I would claim that you sought out the = only US site in the top 25 that doesn't use TLS for every page. Every o= ther US site in the global top 25 is TLS. How can that be if performance co= ncerns are stopping deployment?
=C2=A0
If I try https://www.a= mazon.com, Amazon's servers redirect my browser
to http://www.amazon.co= m. Similarly, if I try a search on Amazon and
then insert "https" into the URL, Amazon's servers redirect m= y browser
back to unencrypted HTTP.

Evidently Amazon has done all the work of setting up an HTTPS server
whose only function is to give me "secured" redirections---a mean= ingless
form of "security" when the redirections are to unprotected web p= ages.
There are of course the occasional Amazon order/credit-card pages using
TLS, but the big picture is that most Amazon traffic is unencrypted and
unauthenticated.

How do you explain Amazon redirecting HTTPS to HTTP, if not performance?=C2= =A0
What do you think will do the best job of actually encrypting Amazon's<= br> web pages: crypto that provides exceptional combinations of security and speed, or crypto that provides powers of 2 to the marketing department?


Amazon, unlike email and search provid= ers, has not been subject to significant public and commercial pressure to = deploy HTTPS for all pages. They may choose to invest the resources to do s= uch a transition, they may not. The question is not what would do the best = job of encrypting their pages, it is what would cause them to move resource= s from building new features to converting to HTTPS. I suspect there could = be zero performance overhead and they still wouldn't move without a bus= iness reason.
=C2=A0
As another example, I just tried https://www.msn.com with various free
browsers (routing connections through proxies in a few countries), and
in each case received the following error message:

=C2=A0 =C2=A0This page is not available right now
=C2=A0 =C2=A0We're working to restore it as soon as possible. Please ch= eck back soon.
=C2=A0 =C2=A0Click here to try this page again, or visit: http://www.msn.com

http://www.msn.com is = working fine, and I don't see people complaining
on Twitter about MSN being down. What fraction of MSN traffic is HTTPS?


Are you saying MSN isn't HTTPS tod= ay because of performance concerns or that people often don't know or c= are if their traffic is encrypted?
=C2=A0
There are a huge number of popular sites that redirect HTTPS to HTTP, or that allow manual HTTPS but advertise primarily HTTP, or that don't wor= k
at all through HTTPS. The use of HTTPS is slowly growing but real
traffic measurements such as

=C2=A0 =C2=A0http://www.caid= a.org/data/passive/trace_stats/chicago-A/2014/?monitor=3D20140821-130000.UT= C

show that HTTP remains dominant---quite the opposite of your claim.=C2=A0

A one hour trace from one location showing b= its/sec is not sufficient data to make claims about growth or relative scal= e.
=C2=A0
Performance isn't the only obstacle to HTTPS deployment but it's cl= early
the primary obstacle in many cases, such as the HTTPS-redirect cases.


On what do you base this claim? My dir= ect experience in recently working to move numerous, large sites to HTTPS-o= nly is that performance issues are raised mostly for capacity planning and = not to block deployment. Instead, people want to do the right thing for cus= tomers.

In other contexts in the recent past, I= 9;ve seen people refuse to deploy TLS because they don't want to pay fo= r certificates, because they were put off by the perceived complexity, even= because they were concerned about performance, but were either unable to a= rticulate specifics or based their opinion on incorrect data (for example, = comparing performance of DHE to unencrypted requests). None of those are ov= ercome by offering a somewhat faster PFS they don't understand anyway.<= /div>
=C2=A0
Again, CFRG's stated goal in the curve-selection process is to "pr= ovide
real value" not just to TLS but "the IETF more widely". The = current
reality is that

=C2=A0 =C2=A0 =C2=A0~2^0 security is dominant in pretty much every IETF pro= tocol;
=C2=A0 =C2=A0 ~2^80 security remains surprisingly popular despite many warn= ings;=C2=A0
=C2=A0 =C2=A0 ~2^90 security is the fastest-growing level for DNSSEC TLDs; = and
=C2=A0 =C2=A0~2^110 security is the fastest-growing level for HTTPS.

There's overwhelming evidence that these choices of security levels hav= e
been pushed downwards by real cost constraints. If CFRG actually wants
to make a difference---especially for the quiet majority using 2^0
security---then it has to take these constraints into account.


Where is this overwhelming evidence? A= 15 year old protocol in a scenario that makes upgrades glacially slow? A s= ingle US site in the Alexa global top 25 that doesn't use HTTPS for all= pages? An hour of traffic at a single point? There has been a massive acce= leration in HTTPS deployment in the past 18 months and it has been driven b= y exactly one cause: Snowden. The same cause will continue to drive most de= ployment, regardless of what CFRG does and despite the cost.

=
Large operators aren't pushing for faster crypto because the= current stuff is too slow to deploy. They are doing it because they have _= already_ deployed the crypto and want to reduce costs.
=C2=A0
State-of-the-art ECC provides much better speed/security tradeoffs than
RSA, and should drastically improve the situation. But it's clear that<= br> these tradeoffs will be damaged if CFRG imposes superficial marketing
rules such as 2^2^k security levels.


You're arguing it's Performanc= e! Performance! Performance! then talking about speed/security tradeoffs? R= SA is plenty fast for key exchange and TLS deployment is what it is. Giving= people more security for similar performance won't move the needle. Mo= ving the needle on this is not exciting. It involves sending lots of pull r= equests to open source projects so they have sane TLS defaults, including E= CDHE, and grinding away for years getting TLS deployed on large services.

My trustworthiness comment was not related to secur= ity levels.


b

<= /div>
--f46d043c80ba64c81705068a2bba-- From nobody Wed Oct 29 04:36:49 2014 Return-Path: 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 A54711A0029 for ; Wed, 29 Oct 2014 04:36:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.798 X-Spam-Level: X-Spam-Status: No, score=0.798 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_HELO_PASS=-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 HADKK6ZngUAi for ; Wed, 29 Oct 2014 04:36:42 -0700 (PDT) Received: from entima.net (entima.net [78.129.143.175]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 803041A0035 for ; Wed, 29 Oct 2014 04:36:42 -0700 (PDT) In-Reply-To: References: <20141029042454.16752.qmail@cr.yp.to> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 From: Alyssa Rowan Date: Wed, 29 Oct 2014 11:36:36 +0000 To: cfrg@irtf.org Message-ID: <824DE505-598D-4B32-8EFC-F69B2672A51A@akr.io> Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/Jfh1gXvasjSisThG8Db1xq3H11Q Subject: Re: [Cfrg] Actual security levels for IETF crypto X-BeenThere: cfrg@irtf.org 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: Wed, 29 Oct 2014 11:36:46 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 29 October 2014 06:49:26 GMT+00:00, Benjamin Black wrote: >>> sites which represent the vast majority of HTTP and SMTP user traffic are few and universally deploy TLS. >> [djb]: …Amazon… >I would claim that you sought out the only US site in the top 25 that doesn't use TLS for every page. Every other US site in the global top 25 is TLS. How can that be if performance concerns are stopping deployment? Um, your claim is patently false. I can name one right off the top of my head: eBay. We are nowhere near universal TLS. Three things typically hold back universal TLS deployment: • Cost - CAs, especially with a myriad smaller sites Thanks StartSSL for leading with this with free DV certs. Unfortunately they charge for multidomain, wildcards and worst of all, revocation - a security disaster in the wake of Heartbleed and they refused to make an exception, so, um, thanks for all the fish but that's less helpful than we'd probably like for universal TLS. Thanks to the CAs working with Cloudflare, including Comodo, for doing even better and doing this with ECC. Thanks to the DANE WG for showing a potential way forward to replace and/or augment DV certs from CAs - if it gets traction. • Performance Directly and clearly tied in with cost. Cloudflare's recent improvements would have been impractical without the performance afforded by ECC. Performance is a very major, even primary, concern for CDNs - ask Rich Salz? State-of-the-art ECC to enable TLS everywhere is what we're being asked for, and what is needed. • Deployment of universal TLS Thanks to ad networks, transclusion and embedding, and the mixed-content problem, the other big barrier to universal TLS adoption seems to be simply that it hasn't happened already! That probably explains MSN, if the ad networks don't support it. And why wouldn't they? Well, the above two give the big reasons. If we can lower the barrier to adoption, in any way, we probably should. Higher performance crypto lowers that barrier. - -- /akr -----BEGIN PGP SIGNATURE----- Version: APG v1.1.1 iQI3BAEBCgAhBQJUUNFDGhxBbHlzc2EgUm93YW4gPGFrckBha3IuaW8+AAoJEOyE jtkWi2t6m14P/0RMHc6MHWIcKruFgKa0Egah2czmpSS/7VH5HiSONDAaFLh42ACd ESXalxQou+nOHi6cmYdaMMEyfd92b1o7zM8d9ONGy5JHOD4nAOFjije5ISKo/ZMZ xiAUUSYXeRaMG6yLX0BAnHZlis3HYpsd71exWRZ5WjpSSne6IqNrqfrAiS1idE/K tdnAq8V+C/BdqmrAlJBDjJ+xN+3MvlNYGwAlYJJM1h0n4TdrRCtTUzJT90Dko5lW XVtbyU65bLW3gCpimOAwYSVsB6sHnKhdOgHhy7evKFtuFXKjkJinn8J74YcpIZ4R cZfhokAXDcykVin/LQPK8kbwHO54kEztBj/pEDqsd4DugXbJEMIfq8mnrDw7RSjA NBebtCaIVNh5ES2CtjiDeKdH6+zXmq+jKM4G2Ekt4fHkGnVZ0uaeyYDOX+fZhqlr cc3F7fpFsb2RxZtyLuCXptVGcl13mKirctoPHD8TiafmR5kCNIoOb+R2we5fYLrn kkFT/xyBYtW4hDRXkllBz/KykVhjaWSrp3vWFqeIrhWAuGZQJdaWfbHoQv+T8SkF dJ8/2dg4ewM408oRbtnxu8K16dYI/fdwhTniKMKEuJ8EdQBsmp7Inl0Z1oYmdrsT JcmPVQBTb3EeonLnu4IS9Gzcivkv4lsTHq1V7GXCftbnZd4S8ubBSZtY =tI/J -----END PGP SIGNATURE----- From nobody Wed Oct 29 07:05:45 2014 Return-Path: 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 6189F1A0119 for ; Wed, 29 Oct 2014 07:05:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 rhLMScDl4gZK for ; Wed, 29 Oct 2014 07:05:39 -0700 (PDT) Received: from mail-yk0-x235.google.com (mail-yk0-x235.google.com [IPv6:2607:f8b0:4002:c07::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D09E21A0102 for ; Wed, 29 Oct 2014 07:05:38 -0700 (PDT) Received: by mail-yk0-f181.google.com with SMTP id 19so1290371ykq.26 for ; Wed, 29 Oct 2014 07:05:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=guMo5jX9Y78w42jlC4DkdTRfrtq/85auc1sdXCwx3Bg=; b=UdgAjZYicLKt50SucTv+x0d+Ey2cjg4nTQNW4g+/WrHmvREUTaOsx/fnhpAYyTrGvO KnZaD5FaOvc+arDAq610DosN1hzsX9mUCqTdqmPHIMJgARgN4BBy3qU41fAbydPbXdzV XZTbwETtUkkyTE199yNC2JgNkGiS8IVeAGh7ktYeWQvaeZlTepKuaIPcP9obkPozzC14 pUnpmOnnBBs4/BbUlSFGY0RnGnstp9uqzLMCv7mbcbtjodsZX9pfc5oc85t5XmywYYLM ikCbkfn9cpzk4qUoNWk5nIUG0pGYfbBfpTX0C7zaOs3Xp5cmSNGWgNo4tZE7KcLSVQzW fZMA== MIME-Version: 1.0 X-Received: by 10.170.214.6 with SMTP id g6mr11467093ykf.34.1414591538098; Wed, 29 Oct 2014 07:05:38 -0700 (PDT) Received: by 10.170.195.149 with HTTP; Wed, 29 Oct 2014 07:05:37 -0700 (PDT) In-Reply-To: References: <20141029042454.16752.qmail@cr.yp.to> Date: Wed, 29 Oct 2014 07:05:37 -0700 Message-ID: From: Watson Ladd To: Benjamin Black Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/F2O4n5pO0sZTPR7daOVMsRjIZ9s Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] Actual security levels for IETF crypto X-BeenThere: cfrg@irtf.org 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: Wed, 29 Oct 2014 14:05:42 -0000 On Tue, Oct 28, 2014 at 11:49 PM, Benjamin Black wrote: > On Tue, Oct 28, 2014 at 9:24 PM, D. J. Bernstein wrote: >> >> Benjamin Black writes: >> > While many individuals might express performance as a reason for not >> > deploying TLS, sites which represent the vast majority of HTTP and >> > SMTP user traffic are few and universally deploy TLS. >> >> I'm a big fan of basing decisions upon facts, so let's try an example. >> Would you claim that Amazon---obviously one of the world's most popular >> web sites; right now Alexa says #7---uses TLS? >> > > I would claim that you sought out the only US site in the top 25 that > doesn't use TLS for every page. Every other US site in the global top 25 is > TLS. How can that be if performance concerns are stopping deployment? Is this actually true? go.com isn't. craigslist.org isn't, imgur.com isn't, ESPN isn't, tumblr.com isn't, CNN isn't, apple.com isn't, instagram.com isn't, and huffingtonpost.com isn't. That's nearly half of the top 25. Maybe this is because the secret police aren't interested in the news you read. >> > > You're arguing it's Performance! Performance! Performance! then talking > about speed/security tradeoffs? RSA is plenty fast for key exchange and TLS > deployment is what it is. Giving people more security for similar > performance won't move the needle. Moving the needle on this is not > exciting. It involves sending lots of pull requests to open source projects > so they have sane TLS defaults, including ECDHE, and grinding away for years > getting TLS deployed on large services. > > My trustworthiness comment was not related to security levels. What was it related to? You've never explained in detail why the choice of your curve at the 512 bitlevel is more trustworthy than E-521, with three independent discoveries, or how consequential the choices in Curve25519 are for trustworthiness. We've kept asking about this, and the story comes down to a generation method that doesn't look that different, except it started with powers of 2 instead of primes with the maximum performance possible. Even if there is a loss in "trustworthness", how substantial is it? Furthermore, what do you think about point formats? Our work is not limited to to picking a formula, and while arguing about this is amusing, it isn't actually going anywhere: the chairs are going to have to decide. Sincerely, Watson Ladd > > > b > > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg > -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Wed Oct 29 07:26:06 2014 Return-Path: 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 9EA6B1A0102 for ; Wed, 29 Oct 2014 07:26:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 RQWagdOkLjv8 for ; Wed, 29 Oct 2014 07:26:04 -0700 (PDT) Received: from smtp-p01.blackberry.com (smtp-p01.blackberry.com [208.65.78.88]) by ietfa.amsl.com (Postfix) with ESMTP id A1CBA1A00EF for ; Wed, 29 Oct 2014 07:26:03 -0700 (PDT) Received: from xct107cnc.rim.net ([10.65.161.207]) by mhs211cnc.rim.net with ESMTP/TLS/AES128-SHA; 29 Oct 2014 10:25:58 -0400 Received: from XCT114CNC.rim.net (10.65.161.214) by XCT107CNC.rim.net (10.65.161.207) with Microsoft SMTP Server (TLS) id 14.3.174.1; Wed, 29 Oct 2014 10:25:57 -0400 Received: from XMB116CNC.rim.net ([fe80::45d:f4fe:6277:5d1b]) by XCT114CNC.rim.net ([::1]) with mapi id 14.03.0174.001; Wed, 29 Oct 2014 10:25:57 -0400 From: Dan Brown To: "'watsonbladd@gmail.com'" Thread-Topic: Signature question ... [RE: [Cfrg] Actual security levels for IETF crypto] Thread-Index: Ac/zgLptfQSZffggRLmwGpAylbDbAQ== Date: Wed, 29 Oct 2014 14:25:56 +0000 Message-ID: <810C31990B57ED40B2062BA10D43FBF5CF7DEC@XMB116CNC.rim.net> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.252] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0008_01CFF362.B95CB940" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/pa5tdXzpgP6A5TvziDjw9wRrHfU Cc: "'cfrg@irtf.org'" Subject: [Cfrg] Signature question ... [RE: Actual security levels for IETF crypto] X-BeenThere: cfrg@irtf.org 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: Wed, 29 Oct 2014 14:26:05 -0000 ------=_NextPart_000_0008_01CFF362.B95CB940 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit > From: Cfrg [mailto:cfrg-bounces@irtf.org] On Behalf Of Watson Ladd >Curve choice matters less then point format and signature issues where we are >also disappointingly far from agreement. Or maybe we are close enough that no >one bothered to respond beyond Andy Lutomirski because the answers were >obvious. Hi Watson, I didn't respond to your question on signatures because the CFRG chairs asked us to focus on curve choice. Nonetheless, I'll briefly answer your questions, in case you infer too much by the lack of response. I slightly prefer ECDSA over Schnorr for provable security reasons: specifically in the generic group model, ECDSA relies on standard hash function assumptions whereas Schnorr does not. I haven't studied other options like ECKDSA and ECGDSA and a quite a few others. I have briefly studied a variant of Schnorr called Pintsov-Vanstone signatures, which adds a block cipher into the mix. I've also heard about Goh-Jarecki signatures, which rely on the ECDH problem, but I haven't looked closely at it: I don't know how efficient it is. If one worries about collisions and chosen-message existential forgery against ECDSA, or one just prefers loose random oracle model proofs, then one can add randomized hashing to ECDSA, which seems to combine the best of ECDSA and Schorr, in terms of security. There's even a NIST spec for that. A free specification of ECDSA is available in SEC1 version 2.0, which has some additional formatting options that make batching, etc, feasible. I agree with others that, in many cases, signatures are not needed for authentication. For example, in an interactive setting, or when the recipient has a public key (aside: even for RSA public keys). Actually, I already suggested to CFRG that consider using ECMQV for TLS and similar IETF protocols, which means no signatures. There's also the option of using implicit ECQV certificates instead, as in SEC4, instead signature-based certifcates -- (but there's one important item of research that I mean to write up about that!) Best regards, Dan ------=_NextPart_000_0008_01CFF362.B95CB940 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUoDCCBo8w ggV3oAMCAQICCm2p3UcABAAABWowDQYJKoZIhvcNAQEFBQAwUDETMBEGCgmSJomT8ixkARkWA25l dDETMBEGCgmSJomT8ixkARkWA3JpbTEkMCIGA1UEAxMbUklNIFN1Ym9yZGluYXRlIENBIE1DQTAy WUtGMB4XDTE0MDUxNDE0MzYzOFoXDTE1MDUxNDE0MzYzOFowgaQxEzARBgoJkiaJk/IsZAEZFgNu ZXQxEzARBgoJkiaJk/IsZAEZFgNyaW0xDTALBgNVBAsTBEFNRVIxCzAJBgNVBAsTAkNBMRQwEgYD VQQLEwtNaXNzaXNzYXVnYTEOMAwGA1UECxMFVXNlcnMxEjAQBgNVBAMTCURhbiBCcm93bjEiMCAG CSqGSIb3DQEJARYTZGJyb3duQGNlcnRpY29tLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEA54YaBOai2UDS89LoHMbDcC4+c8dEl5TpkJWz0muqjnXP6xpSYqBzotsw9SpPD3/0wF8Dz77Z hkYN8BDSF0RAdtmfXKXe40tQkHoplN4pos9jnBZW5e8HuTZUkEVC/q7bf399cskpxMt9MA934gvB rSk1QNbR3D7Hq34t4bOHXSUCAwEAAaOCA5gwggOUMAsGA1UdDwQEAwIFoDBEBgkqhkiG9w0BCQ8E NzA1MA4GCCqGSIb3DQMCAgIAgDAOBggqhkiG9w0DBAICAIAwBwYFKw4DAgcwCgYIKoZIhvcNAwcw FwYJKwYBBAGCNxQCBAoeCABVAHMAZQByMCkGA1UdJQQiMCAGCisGAQQBgjcKAwQGCCsGAQUFBwME BggrBgEFBQcDAjBBBgNVHREEOjA4oCEGCisGAQQBgjcUAgOgEwwRZGFuaWJyb3duQHJpbS5uZXSB E2Ricm93bkBjZXJ0aWNvbS5jb20wHQYDVR0OBBYEFFdFrujr5LyMGa3Hl1U4MTjlEtfvMB8GA1Ud IwQYMBaAFObbryVSYEL0jYI1VF2A64ahrO/cMIIBMQYDVR0fBIIBKDCCASQwggEgoIIBHKCCARiG gctsZGFwOi8vL0NOPVJJTSUyMFN1Ym9yZGluYXRlJTIwQ0ElMjBNQ0EwMllLRixDTj1NQ0EwMllL RixDTj1DRFAsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmln dXJhdGlvbixEQz13aW5kb3dzLERDPWxvY2FsP2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFz ZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2ludIZIaHR0cDovL21jYTAyeWtmLnJpbS5u ZXQvQ2VydEVucm9sbC9SSU0lMjBTdWJvcmRpbmF0ZSUyMENBJTIwTUNBMDJZS0YuY3JsMIIBQQYI KwYBBQUHAQEEggEzMIIBLzCBwgYIKwYBBQUHMAKGgbVsZGFwOi8vL0NOPVJJTSUyMFN1Ym9yZGlu YXRlJTIwQ0ElMjBNQ0EwMllLRixDTj1BSUEsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049 U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz13aW5kb3dzLERDPWxvY2FsP2NBQ2VydGlmaWNh dGU/YmFzZT9vYmplY3RDbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MGgGCCsGAQUFBzAChlxo dHRwOi8vbWNhMDJ5a2YucmltLm5ldC9DZXJ0RW5yb2xsL01DQTAyWUtGLnJpbS5uZXRfUklNJTIw U3Vib3JkaW5hdGUlMjBDQSUyME1DQTAyWUtGKDQpLmNydDANBgkqhkiG9w0BAQUFAAOCAQEActBk hryrMh5+C+8YiOrR8xi+G1NkUycfNLuz4fYdQzFNB9yWxyRs2K0ydl0X5PZXejhbIif0dFoyaxnh g/D5hYfeGIhXfAOFG22EpMJWXVOavqYLxslnc2enihWAYcWkjPfE6tf3XMXkodFkMYvEd+qFj8eU vxbbcR1dBqiBFNNDcKlAKn/oElp/iI/LjUGMEb+tJdHttsGExvQzSd1zwk1U6cOinYD82Y08zA5b z38l5bE2+plmfX3EQ8vCKYA95psgGg3hsffn150smpY7HeEPGRZh9vglGfi2wnMqY/QgO+qs78dq O/C1be3quQU3WHQ6YcZr3JP1Rc7yj76K7jCCBr8wggSnoAMCAQICEDIa85KxFFmUTU0vlRGze+Ew DQYJKoZIhvcNAQEFBQAwTzEVMBMGCgmSJomT8ixkARkWBWxvY2FsMRcwFQYKCZImiZPyLGQBGRYH d2luZG93czEdMBsGA1UEAxMUUklNIFJvb3QgQ0EgTUNBMDFZS0YwHhcNMDYxMDEzMDEyNDU1WhcN MTYxMDEzMDEzMDQxWjBPMRUwEwYKCZImiZPyLGQBGRYFbG9jYWwxFzAVBgoJkiaJk/IsZAEZFgd3 aW5kb3dzMR0wGwYDVQQDExRSSU0gUm9vdCBDQSBNQ0EwMVlLRjCCAiIwDQYJKoZIhvcNAQEBBQAD ggIPADCCAgoCggIBAMbous78rVQBLT87+jYSuzmZ2osP40BMhFbJA3+cs3BZC0//uT87SG7/nhZi 9Qj9hYby7/HkGSQyheGL/lLIzxDdZV+AwxiirdDT6ck/acEMxWolLdK5xEYEmm6OxLaUuEvg7i/B vXPpZlsA6m9FFrTzHVX2693w8IoMs9cofr1TAB3YYDnvZTwupz7YifSF02pu1eZiZg09Jjaav9Hy aNyRGjbwyqFwTpCr+iHW7SsSszyJxulWGgnYCQgE95loK/ZMYhEBFCSq7yNn1yNM0WJ5S+uPILyv OKXbE9sWSxba+DnWQJuEZCvFPnILq5Ugq+jVap326uv9zejBpsnPUgdgMoZNlUuuu+e1eJwc3mng /rK6ZOCF1NzUzP/mIEdc1UuNV8L2WqvVH+fY9EyYTfcRlWTvO9XlVa9lXzca9MTqlKcHMYeSWWJF nJlCRZWIkIdAjNj632g0U06kWUHeBd8VJXFxQFzhob2lyr4pHiOv7rZ1+rwpw8DFMZnp85b/HqTW rcQ7LiIDljuKX6oBjMs1qNobnUPe/ucp1Kgy19+J61M7MxniBNyqKmLJLMTBd7aiIGnbfYTVl2j/ xJJ2aUQJmj9LNFeWb4Isl8PVK6p1sJkWy0JOx52HNIR0AY16AcikojsoYEkvci+mvuwANq4QT6bE lSPS2AbNnDSpT7GXAgMBAAGjggGVMIIBkTATBgkrBgEEAYI3FAIEBh4EAEMAQTALBgNVHQ8EBAMC AUYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQU1mmCZCQWwcwk2/EUfUcSfNzJTe4wggEpBgNV HR8EggEgMIIBHDCCARigggEUoIIBEIaBxGxkYXA6Ly8vQ049UklNJTIwUm9vdCUyMENBJTIwTUNB MDFZS0YsQ049TUNBMDFZS0YsQ049Q0RQLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNl cnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9d2luZG93cyxEQz1sb2NhbD9jZXJ0aWZpY2F0ZVJl dm9jYXRpb25MaXN0P2Jhc2U/b2JqZWN0Q2xhc3M9Y1JMRGlzdHJpYnV0aW9uUG9pbnSGR2h0dHA6 Ly9tY2EwMXlrZi53aW5kb3dzLmxvY2FsL0NlcnRFbnJvbGwvUklNJTIwUm9vdCUyMENBJTIwTUNB MDFZS0YuY3JsMBAGCSsGAQQBgjcVAQQDAgEAMA0GCSqGSIb3DQEBBQUAA4ICAQBDnlhbuDlU58ff o2JPdog62tn9QXOY9VnrBBiDZeFQmPVicup9e2/4dnw5o4/SnyLaNyxNlno++5Uiar/y0ne8J300 FWVW9cAXtmbfi7jwKour1kgwEFTn3TjGFbuYps553/mTTC3bk6l2f2xUCk1rINqoQVsGomH8RGO5 1YN/mX0rasHPUd7/7Rx/m/ZF9xbii6FUOikq6lMgYn4SEY+e3jsOvyYzwPkiHf6dshGfsZgDUN9b xNwRxUZttJGRx6gH3Qpk7dUuyw0ixwY9xmVyBVIHvWjyqswF3ntgwmEz92GHIKz/xWxRdkahkSIT zPjHYya2jI3sfpzU/tigvxCFrG1PQ4BSCNMByqUcfK5STTfJJm/x/ahqnDWlvUP6cFE6V9W10nW8 72BbNzWOypmGIouENEUAhq/ejrw09P0uvyK51vr6mY5z1djF6hLskNC+R11Tpwou+vbhmHEZBKOc cxCfxDL49O7wlpxu4fcpDYSxBDHMoFZgXVz/ajqqIHcjyQdAM8QGBqgkjE/Dq7NTP7K2Ul1An0nx DR+YgXe28R+7l5he5GzhIIaJuwHHAtgpbeA1NLY/bBciFoOR+s8ujS3rZtv5M3Q95hmN7trVrYo1 Z3dglmNmLM2KNZWwwHxH4xi//bhaR+/WbfXpEUg+WW0p9Uja9Z443hqVd48MrjCCB0YwggUuoAMC AQICChJuoPAAAAAAAiswDQYJKoZIhvcNAQEFBQAwTzEVMBMGCgmSJomT8ixkARkWBWxvY2FsMRcw FQYKCZImiZPyLGQBGRYHd2luZG93czEdMBsGA1UEAxMUUklNIFJvb3QgQ0EgTUNBMDFZS0YwHhcN MTQwNDAyMDA1MTEyWhcNMTYwNDAyMDEwMTEyWjBQMRMwEQYKCZImiZPyLGQBGRYDbmV0MRMwEQYK CZImiZPyLGQBGRYDcmltMSQwIgYDVQQDExtSSU0gU3Vib3JkaW5hdGUgQ0EgTUNBMDJZS0YwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCzrn3UT996pLvUIVlnExxcXGmYftIOq1qMwitW RCBe2j32VmDvzlJseIkfQuXDqjWnoqoE4sxQjxD5QNwhyBw9eXMCvLjHBW+HM4+HcmGIdan2w17E 4rR+RHVK6NzvkE1Gm4ziBTDr2jzSliZJpowLM+M/+cY2pyym074TQx+QCZQOKIqLnEgZ2uYw4kSj nCcE7eJ+WmJFq9bX6Cv9SONQfgN5Z3O1N/36lgavm/G6Amt/ePNE0AhcJwxin7Fahkx6/SjRbf0r Oa8uhCMxK8ebqTqD0+0VpViARFterasW5FTU2rcRFLHwwWV67yoFc2fbozkj5iseBXctM8NmqKt5 AgMBAAGjggMhMIIDHTAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBTm268lUmBC9I2CNVRdgOuG oazv3DALBgNVHQ8EBAMCAYYwEAYJKwYBBAGCNxUBBAMCAQQwIwYJKwYBBAGCNxUCBBYEFCLdxB/L akuvuaYdTyqIgHmfibLUMBkGCSsGAQQBgjcUAgQMHgoAUwB1AGIAQwBBMB8GA1UdIwQYMBaAFNZp gmQkFsHMJNvxFH1HEnzcyU3uMIIBKQYDVR0fBIIBIDCCARwwggEYoIIBFKCCARCGgcRsZGFwOi8v L0NOPVJJTSUyMFJvb3QlMjBDQSUyME1DQTAxWUtGLENOPU1DQTAxWUtGLENOPUNEUCxDTj1QdWJs aWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPXdpbmRv d3MsREM9bG9jYWw/Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdD9iYXNlP29iamVjdENsYXNzPWNS TERpc3RyaWJ1dGlvblBvaW50hkdodHRwOi8vbWNhMDF5a2Yud2luZG93cy5sb2NhbC9DZXJ0RW5y b2xsL1JJTSUyMFJvb3QlMjBDQSUyME1DQTAxWUtGLmNybDCCATwGCCsGAQUFBwEBBIIBLjCCASow gbsGCCsGAQUFBzAChoGubGRhcDovLy9DTj1SSU0lMjBSb290JTIwQ0ElMjBNQ0EwMVlLRixDTj1B SUEsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlv bixEQz13aW5kb3dzLERDPWxvY2FsP2NBQ2VydGlmaWNhdGU/YmFzZT9vYmplY3RDbGFzcz1jZXJ0 aWZpY2F0aW9uQXV0aG9yaXR5MGoGCCsGAQUFBzAChl5odHRwOi8vbWNhMDF5a2Yud2luZG93cy5s b2NhbC9DZXJ0RW5yb2xsL01DQTAxWUtGLndpbmRvd3MubG9jYWxfUklNJTIwUm9vdCUyMENBJTIw TUNBMDFZS0YuY3J0MA0GCSqGSIb3DQEBBQUAA4ICAQCUe8BMuuw2GW4AUAag80hqgwOQyezrSatL SIadEDvzg3LgXMJcN7onC+1B7vHsMxVMbFz3V+85WSKtzCtaBe5rhUCXLBZEGbM+WPavYgYMnUsD TpJwSXiDaM9Ym/ZLFsgfo3Qv7rfglydpqPCBfHUEQys2KeBVsDGd7HDK5Nk5fNaSmK0KgIBIvbXR bJKzhTsuctYGlOf/2nFtuoxWcdhu7t6UR7DbSTerjug7rvCZH4bie5cphsu4lZDXdNRp2IKWVEF6 0VcEK8dXK1hZXEGgjuen7R03uaA+7VsSr7eUZSLiouG7XnvXWik11aNCgBiQcIGsHVRIccHphmfS sFaZ0Bc+4/c/+K/v7X7RvdE29J9b1DqB2iV2SGZp58M0JLscohJ9uY0SJj8Hwl9YeuznijFBIC2y Psb1V9CgoRtBl+Ek37tPp1Wm4XSS+as2kcdcsZwiM/LywbFvYDEBa71b0mquxjisPyPvmVccA0e6 WW6RDNYKUqBJsZDpjTbRZkQA7CmzrOK6YHip2F/92ZYmpqM84BsEkLuf6kzzk+r0OVsWaFP+plU3 MfqtAeKtBgJu6yd4SYbA9eFX9ePeIzBaCjTzIcd+CclwA8SeoAgP07Ut2WcB3QnD7fcU6CBegHSd 7504Ty34G+FymbG6ZBBUU0exF44VAplxv4rWFA7mPTGCAvMwggLvAgEBMF4wUDETMBEGCgmSJomT 8ixkARkWA25ldDETMBEGCgmSJomT8ixkARkWA3JpbTEkMCIGA1UEAxMbUklNIFN1Ym9yZGluYXRl IENBIE1DQTAyWUtGAgptqd1HAAQAAAVqMAkGBSsOAwIaBQCgggHrMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE0MTAyOTE0MjU1NVowIwYJKoZIhvcNAQkEMRYEFG17 LX9bWKsv/rXJnpPqHzqkyJJkMG0GCSsGAQQBgjcQBDFgMF4wUDETMBEGCgmSJomT8ixkARkWA25l dDETMBEGCgmSJomT8ixkARkWA3JpbTEkMCIGA1UEAxMbUklNIFN1Ym9yZGluYXRlIENBIE1DQTAy WUtGAgptqd1HAAQAAAVqMG8GCyqGSIb3DQEJEAILMWCgXjBQMRMwEQYKCZImiZPyLGQBGRYDbmV0 MRMwEQYKCZImiZPyLGQBGRYDcmltMSQwIgYDVQQDExtSSU0gU3Vib3JkaW5hdGUgQ0EgTUNBMDJZ S0YCCm2p3UcABAAABWowgasGCSqGSIb3DQEJDzGBnTCBmjALBglghkgBZQMEASowCwYJYIZIAWUD BAEWMAoGCCqGSIb3DQMHMAsGCWCGSAFlAwQBAjAOBggqhkiG9w0DAgICAIAwBwYFKw4DAgcwDQYI KoZIhvcNAwICAUAwDQYIKoZIhvcNAwICASgwBwYFKw4DAhowCwYJYIZIAWUDBAIDMAsGCWCGSAFl AwQCAjALBglghkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEgYBqUbn3LIKIiN5MNPGL3RJLPpDj7pVB u3kugdeeyNxfoApmXGhKTIP4UefVvxBDWlwGAEmF/KsaruRFoiKQ14zYmLPnllFqzt78xaA7lgvX BfKqGS7KAdaHJwoMkfd3/xR69KLr449k0R2Dsk/rWPcotuRmLHYgx4ovF3xXfUzIkQAAAAAAAA== ------=_NextPart_000_0008_01CFF362.B95CB940-- From nobody Wed Oct 29 08:25:15 2014 Return-Path: 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 1E3261A035F for ; Wed, 29 Oct 2014 08:25:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.8 X-Spam-Level: * X-Spam-Status: No, score=1.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, J_BACKHAIR_13=1] autolearn=no 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 XdpDG4pcp97c for ; Wed, 29 Oct 2014 08:25:01 -0700 (PDT) Received: from smtp-p02.blackberry.com (smtp-p02.blackberry.com [208.65.78.89]) by ietfa.amsl.com (Postfix) with ESMTP id E61341A026C for ; Wed, 29 Oct 2014 08:25:00 -0700 (PDT) Received: from xct108cnc.rim.net ([10.65.161.208]) by mhs213cnc.rim.net with ESMTP/TLS/AES128-SHA; 29 Oct 2014 11:24:55 -0400 Received: from XCT111CNC.rim.net (10.65.161.211) by XCT108CNC.rim.net (10.65.161.208) with Microsoft SMTP Server (TLS) id 14.3.174.1; Wed, 29 Oct 2014 11:24:54 -0400 Received: from XMB116CNC.rim.net ([fe80::45d:f4fe:6277:5d1b]) by XCT111CNC.rim.net ([::1]) with mapi id 14.03.0174.001; Wed, 29 Oct 2014 11:24:54 -0400 From: Dan Brown To: "cfrg@irtf.org" Thread-Topic: Terms for comparing curves and other algorithms, on the basis of security and efficiency Thread-Index: Ac/zi9pJuvI2S4d+RgS+72aHpc20iQ== Date: Wed, 29 Oct 2014 15:24:54 +0000 Message-ID: <810C31990B57ED40B2062BA10D43FBF5CF7EA5@XMB116CNC.rim.net> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.252] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0010_01CFF36A.F629EF20" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/uev4e2Ei-KLUgr8cwSVcLigGxbo Subject: [Cfrg] Terms for comparing curves and other algorithms, on the basis of security and efficiency X-BeenThere: cfrg@irtf.org 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: Wed, 29 Oct 2014 15:25:03 -0000 ------=_NextPart_000_0010_01CFF36A.F629EF20 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dear CFRG, I've noticed some discussions on the CFRG list about security-efficiency tradeoffs and so on. It seems that every time the topic arises, somebody has to explain the assumptions and so forth, all from first principles. In some cases, I even wonder if people are talking past each other, by misunderstanding each other's explanations and positions. In that regards, perhaps a standardized terminology might help. As part of a rather rushed research report http://eprint.iacr.org/2014/877, Appendix B, I made an effort at this, but I'll summarize the ideas here in an email. First, we need to establish (non-trivial) and define some things: - To establish absolute security and efficiency metrics, s and e (usable across multiple algorithm types). - To establish _defective_ security and efficiency levels, s_0, and e_0. - To establish _saturated_ security and efficiency levels, s_1 and e_1 (beyond which no utility is gained). - To define _tolerable_ security and efficiency levels, as those between defective and saturated (assuming defective is strictly less than saturated). - To define _work ratio_ w = se - To define _progressive ratio_ p = log(s)e Next, consider two curve (or algorithm) choices with levels (s,e) and (s',e') with it being non-trivial to determine these levels, - If ss_1, then choose the higher of e and e'. - If both e and e' are saturated, that is, e,e'>e_1, then choose the higher of s and s'. - Otherwise, pick some ordering of e or s or w or p to maximize (i.e. a lexicographic order). I recommend maximizing work ratio w first, then maximizing progressive ratio p, because using s or e first risks having small gains in one metric for large loss in the other: whereas w and p try to balance the s and e metrics. Also, the systems above algorithm-agnostic, so can be used to compare block ciphers, hash functions, not just elliptic curves. I felt most of the above is more or less self-evident, albeit simplistic and abstract, and is a paraphrasing of my understanding of most people's arguments, but perhaps I am missing something (see below). When I tried to apply the regimen above to elliptic curve selection, I had two problems, which make me worry that the analysis is missing something fundamental. First, the conventional practice of offering multiple curves sizes does not fit well into the system above: it defers too much of the decision process to the user and seems to imply some kind of ambiguity about the saturated security levels. Second, optimizing work ratio w seems to favor large cofactor, which seems very strange to me, and is certainly unconventional (though I ignored public key size in the efficiency metric). Maybe these strange discrepancies are not faults in the comparison system above but merely discrepancies in my bounds for s_1 and e_0. For example, perhaps my saturated security level is much higher than conventional, and my defective efficiency is much lower than conventional. Returning to the issues of debates about curves on the CFRG list, if two people have different values of, say, s_1, but don't really know it, then they are likely to disagree on the best curve or algorithm, and perhaps not understand why. Perhaps stating one's metrics, one's saturated and defective levels, will help resolve some disagreements, or at least enable better understanding of the disagreements. Best regards, Daniel Brown Research In Motion Limited ------=_NextPart_000_0010_01CFF36A.F629EF20 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUoDCCBo8w ggV3oAMCAQICCm2p3UcABAAABWowDQYJKoZIhvcNAQEFBQAwUDETMBEGCgmSJomT8ixkARkWA25l dDETMBEGCgmSJomT8ixkARkWA3JpbTEkMCIGA1UEAxMbUklNIFN1Ym9yZGluYXRlIENBIE1DQTAy WUtGMB4XDTE0MDUxNDE0MzYzOFoXDTE1MDUxNDE0MzYzOFowgaQxEzARBgoJkiaJk/IsZAEZFgNu ZXQxEzARBgoJkiaJk/IsZAEZFgNyaW0xDTALBgNVBAsTBEFNRVIxCzAJBgNVBAsTAkNBMRQwEgYD VQQLEwtNaXNzaXNzYXVnYTEOMAwGA1UECxMFVXNlcnMxEjAQBgNVBAMTCURhbiBCcm93bjEiMCAG CSqGSIb3DQEJARYTZGJyb3duQGNlcnRpY29tLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEA54YaBOai2UDS89LoHMbDcC4+c8dEl5TpkJWz0muqjnXP6xpSYqBzotsw9SpPD3/0wF8Dz77Z hkYN8BDSF0RAdtmfXKXe40tQkHoplN4pos9jnBZW5e8HuTZUkEVC/q7bf399cskpxMt9MA934gvB rSk1QNbR3D7Hq34t4bOHXSUCAwEAAaOCA5gwggOUMAsGA1UdDwQEAwIFoDBEBgkqhkiG9w0BCQ8E NzA1MA4GCCqGSIb3DQMCAgIAgDAOBggqhkiG9w0DBAICAIAwBwYFKw4DAgcwCgYIKoZIhvcNAwcw FwYJKwYBBAGCNxQCBAoeCABVAHMAZQByMCkGA1UdJQQiMCAGCisGAQQBgjcKAwQGCCsGAQUFBwME BggrBgEFBQcDAjBBBgNVHREEOjA4oCEGCisGAQQBgjcUAgOgEwwRZGFuaWJyb3duQHJpbS5uZXSB E2Ricm93bkBjZXJ0aWNvbS5jb20wHQYDVR0OBBYEFFdFrujr5LyMGa3Hl1U4MTjlEtfvMB8GA1Ud IwQYMBaAFObbryVSYEL0jYI1VF2A64ahrO/cMIIBMQYDVR0fBIIBKDCCASQwggEgoIIBHKCCARiG gctsZGFwOi8vL0NOPVJJTSUyMFN1Ym9yZGluYXRlJTIwQ0ElMjBNQ0EwMllLRixDTj1NQ0EwMllL RixDTj1DRFAsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmln dXJhdGlvbixEQz13aW5kb3dzLERDPWxvY2FsP2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFz ZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2ludIZIaHR0cDovL21jYTAyeWtmLnJpbS5u ZXQvQ2VydEVucm9sbC9SSU0lMjBTdWJvcmRpbmF0ZSUyMENBJTIwTUNBMDJZS0YuY3JsMIIBQQYI KwYBBQUHAQEEggEzMIIBLzCBwgYIKwYBBQUHMAKGgbVsZGFwOi8vL0NOPVJJTSUyMFN1Ym9yZGlu YXRlJTIwQ0ElMjBNQ0EwMllLRixDTj1BSUEsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049 U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz13aW5kb3dzLERDPWxvY2FsP2NBQ2VydGlmaWNh dGU/YmFzZT9vYmplY3RDbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MGgGCCsGAQUFBzAChlxo dHRwOi8vbWNhMDJ5a2YucmltLm5ldC9DZXJ0RW5yb2xsL01DQTAyWUtGLnJpbS5uZXRfUklNJTIw U3Vib3JkaW5hdGUlMjBDQSUyME1DQTAyWUtGKDQpLmNydDANBgkqhkiG9w0BAQUFAAOCAQEActBk hryrMh5+C+8YiOrR8xi+G1NkUycfNLuz4fYdQzFNB9yWxyRs2K0ydl0X5PZXejhbIif0dFoyaxnh g/D5hYfeGIhXfAOFG22EpMJWXVOavqYLxslnc2enihWAYcWkjPfE6tf3XMXkodFkMYvEd+qFj8eU vxbbcR1dBqiBFNNDcKlAKn/oElp/iI/LjUGMEb+tJdHttsGExvQzSd1zwk1U6cOinYD82Y08zA5b z38l5bE2+plmfX3EQ8vCKYA95psgGg3hsffn150smpY7HeEPGRZh9vglGfi2wnMqY/QgO+qs78dq O/C1be3quQU3WHQ6YcZr3JP1Rc7yj76K7jCCBr8wggSnoAMCAQICEDIa85KxFFmUTU0vlRGze+Ew DQYJKoZIhvcNAQEFBQAwTzEVMBMGCgmSJomT8ixkARkWBWxvY2FsMRcwFQYKCZImiZPyLGQBGRYH d2luZG93czEdMBsGA1UEAxMUUklNIFJvb3QgQ0EgTUNBMDFZS0YwHhcNMDYxMDEzMDEyNDU1WhcN MTYxMDEzMDEzMDQxWjBPMRUwEwYKCZImiZPyLGQBGRYFbG9jYWwxFzAVBgoJkiaJk/IsZAEZFgd3 aW5kb3dzMR0wGwYDVQQDExRSSU0gUm9vdCBDQSBNQ0EwMVlLRjCCAiIwDQYJKoZIhvcNAQEBBQAD ggIPADCCAgoCggIBAMbous78rVQBLT87+jYSuzmZ2osP40BMhFbJA3+cs3BZC0//uT87SG7/nhZi 9Qj9hYby7/HkGSQyheGL/lLIzxDdZV+AwxiirdDT6ck/acEMxWolLdK5xEYEmm6OxLaUuEvg7i/B vXPpZlsA6m9FFrTzHVX2693w8IoMs9cofr1TAB3YYDnvZTwupz7YifSF02pu1eZiZg09Jjaav9Hy aNyRGjbwyqFwTpCr+iHW7SsSszyJxulWGgnYCQgE95loK/ZMYhEBFCSq7yNn1yNM0WJ5S+uPILyv OKXbE9sWSxba+DnWQJuEZCvFPnILq5Ugq+jVap326uv9zejBpsnPUgdgMoZNlUuuu+e1eJwc3mng /rK6ZOCF1NzUzP/mIEdc1UuNV8L2WqvVH+fY9EyYTfcRlWTvO9XlVa9lXzca9MTqlKcHMYeSWWJF nJlCRZWIkIdAjNj632g0U06kWUHeBd8VJXFxQFzhob2lyr4pHiOv7rZ1+rwpw8DFMZnp85b/HqTW rcQ7LiIDljuKX6oBjMs1qNobnUPe/ucp1Kgy19+J61M7MxniBNyqKmLJLMTBd7aiIGnbfYTVl2j/ xJJ2aUQJmj9LNFeWb4Isl8PVK6p1sJkWy0JOx52HNIR0AY16AcikojsoYEkvci+mvuwANq4QT6bE lSPS2AbNnDSpT7GXAgMBAAGjggGVMIIBkTATBgkrBgEEAYI3FAIEBh4EAEMAQTALBgNVHQ8EBAMC AUYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQU1mmCZCQWwcwk2/EUfUcSfNzJTe4wggEpBgNV HR8EggEgMIIBHDCCARigggEUoIIBEIaBxGxkYXA6Ly8vQ049UklNJTIwUm9vdCUyMENBJTIwTUNB MDFZS0YsQ049TUNBMDFZS0YsQ049Q0RQLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNl cnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9d2luZG93cyxEQz1sb2NhbD9jZXJ0aWZpY2F0ZVJl dm9jYXRpb25MaXN0P2Jhc2U/b2JqZWN0Q2xhc3M9Y1JMRGlzdHJpYnV0aW9uUG9pbnSGR2h0dHA6 Ly9tY2EwMXlrZi53aW5kb3dzLmxvY2FsL0NlcnRFbnJvbGwvUklNJTIwUm9vdCUyMENBJTIwTUNB MDFZS0YuY3JsMBAGCSsGAQQBgjcVAQQDAgEAMA0GCSqGSIb3DQEBBQUAA4ICAQBDnlhbuDlU58ff o2JPdog62tn9QXOY9VnrBBiDZeFQmPVicup9e2/4dnw5o4/SnyLaNyxNlno++5Uiar/y0ne8J300 FWVW9cAXtmbfi7jwKour1kgwEFTn3TjGFbuYps553/mTTC3bk6l2f2xUCk1rINqoQVsGomH8RGO5 1YN/mX0rasHPUd7/7Rx/m/ZF9xbii6FUOikq6lMgYn4SEY+e3jsOvyYzwPkiHf6dshGfsZgDUN9b xNwRxUZttJGRx6gH3Qpk7dUuyw0ixwY9xmVyBVIHvWjyqswF3ntgwmEz92GHIKz/xWxRdkahkSIT zPjHYya2jI3sfpzU/tigvxCFrG1PQ4BSCNMByqUcfK5STTfJJm/x/ahqnDWlvUP6cFE6V9W10nW8 72BbNzWOypmGIouENEUAhq/ejrw09P0uvyK51vr6mY5z1djF6hLskNC+R11Tpwou+vbhmHEZBKOc cxCfxDL49O7wlpxu4fcpDYSxBDHMoFZgXVz/ajqqIHcjyQdAM8QGBqgkjE/Dq7NTP7K2Ul1An0nx DR+YgXe28R+7l5he5GzhIIaJuwHHAtgpbeA1NLY/bBciFoOR+s8ujS3rZtv5M3Q95hmN7trVrYo1 Z3dglmNmLM2KNZWwwHxH4xi//bhaR+/WbfXpEUg+WW0p9Uja9Z443hqVd48MrjCCB0YwggUuoAMC AQICChJuoPAAAAAAAiswDQYJKoZIhvcNAQEFBQAwTzEVMBMGCgmSJomT8ixkARkWBWxvY2FsMRcw FQYKCZImiZPyLGQBGRYHd2luZG93czEdMBsGA1UEAxMUUklNIFJvb3QgQ0EgTUNBMDFZS0YwHhcN MTQwNDAyMDA1MTEyWhcNMTYwNDAyMDEwMTEyWjBQMRMwEQYKCZImiZPyLGQBGRYDbmV0MRMwEQYK CZImiZPyLGQBGRYDcmltMSQwIgYDVQQDExtSSU0gU3Vib3JkaW5hdGUgQ0EgTUNBMDJZS0YwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCzrn3UT996pLvUIVlnExxcXGmYftIOq1qMwitW RCBe2j32VmDvzlJseIkfQuXDqjWnoqoE4sxQjxD5QNwhyBw9eXMCvLjHBW+HM4+HcmGIdan2w17E 4rR+RHVK6NzvkE1Gm4ziBTDr2jzSliZJpowLM+M/+cY2pyym074TQx+QCZQOKIqLnEgZ2uYw4kSj nCcE7eJ+WmJFq9bX6Cv9SONQfgN5Z3O1N/36lgavm/G6Amt/ePNE0AhcJwxin7Fahkx6/SjRbf0r Oa8uhCMxK8ebqTqD0+0VpViARFterasW5FTU2rcRFLHwwWV67yoFc2fbozkj5iseBXctM8NmqKt5 AgMBAAGjggMhMIIDHTAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBTm268lUmBC9I2CNVRdgOuG oazv3DALBgNVHQ8EBAMCAYYwEAYJKwYBBAGCNxUBBAMCAQQwIwYJKwYBBAGCNxUCBBYEFCLdxB/L akuvuaYdTyqIgHmfibLUMBkGCSsGAQQBgjcUAgQMHgoAUwB1AGIAQwBBMB8GA1UdIwQYMBaAFNZp gmQkFsHMJNvxFH1HEnzcyU3uMIIBKQYDVR0fBIIBIDCCARwwggEYoIIBFKCCARCGgcRsZGFwOi8v L0NOPVJJTSUyMFJvb3QlMjBDQSUyME1DQTAxWUtGLENOPU1DQTAxWUtGLENOPUNEUCxDTj1QdWJs aWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPXdpbmRv d3MsREM9bG9jYWw/Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdD9iYXNlP29iamVjdENsYXNzPWNS TERpc3RyaWJ1dGlvblBvaW50hkdodHRwOi8vbWNhMDF5a2Yud2luZG93cy5sb2NhbC9DZXJ0RW5y b2xsL1JJTSUyMFJvb3QlMjBDQSUyME1DQTAxWUtGLmNybDCCATwGCCsGAQUFBwEBBIIBLjCCASow gbsGCCsGAQUFBzAChoGubGRhcDovLy9DTj1SSU0lMjBSb290JTIwQ0ElMjBNQ0EwMVlLRixDTj1B SUEsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlv bixEQz13aW5kb3dzLERDPWxvY2FsP2NBQ2VydGlmaWNhdGU/YmFzZT9vYmplY3RDbGFzcz1jZXJ0 aWZpY2F0aW9uQXV0aG9yaXR5MGoGCCsGAQUFBzAChl5odHRwOi8vbWNhMDF5a2Yud2luZG93cy5s b2NhbC9DZXJ0RW5yb2xsL01DQTAxWUtGLndpbmRvd3MubG9jYWxfUklNJTIwUm9vdCUyMENBJTIw TUNBMDFZS0YuY3J0MA0GCSqGSIb3DQEBBQUAA4ICAQCUe8BMuuw2GW4AUAag80hqgwOQyezrSatL SIadEDvzg3LgXMJcN7onC+1B7vHsMxVMbFz3V+85WSKtzCtaBe5rhUCXLBZEGbM+WPavYgYMnUsD TpJwSXiDaM9Ym/ZLFsgfo3Qv7rfglydpqPCBfHUEQys2KeBVsDGd7HDK5Nk5fNaSmK0KgIBIvbXR bJKzhTsuctYGlOf/2nFtuoxWcdhu7t6UR7DbSTerjug7rvCZH4bie5cphsu4lZDXdNRp2IKWVEF6 0VcEK8dXK1hZXEGgjuen7R03uaA+7VsSr7eUZSLiouG7XnvXWik11aNCgBiQcIGsHVRIccHphmfS sFaZ0Bc+4/c/+K/v7X7RvdE29J9b1DqB2iV2SGZp58M0JLscohJ9uY0SJj8Hwl9YeuznijFBIC2y Psb1V9CgoRtBl+Ek37tPp1Wm4XSS+as2kcdcsZwiM/LywbFvYDEBa71b0mquxjisPyPvmVccA0e6 WW6RDNYKUqBJsZDpjTbRZkQA7CmzrOK6YHip2F/92ZYmpqM84BsEkLuf6kzzk+r0OVsWaFP+plU3 MfqtAeKtBgJu6yd4SYbA9eFX9ePeIzBaCjTzIcd+CclwA8SeoAgP07Ut2WcB3QnD7fcU6CBegHSd 7504Ty34G+FymbG6ZBBUU0exF44VAplxv4rWFA7mPTGCAvMwggLvAgEBMF4wUDETMBEGCgmSJomT 8ixkARkWA25ldDETMBEGCgmSJomT8ixkARkWA3JpbTEkMCIGA1UEAxMbUklNIFN1Ym9yZGluYXRl IENBIE1DQTAyWUtGAgptqd1HAAQAAAVqMAkGBSsOAwIaBQCgggHrMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE0MTAyOTE1MjQ1M1owIwYJKoZIhvcNAQkEMRYEFOCD lSoFVW9X/nB9WVBKm+B3ov73MG0GCSsGAQQBgjcQBDFgMF4wUDETMBEGCgmSJomT8ixkARkWA25l dDETMBEGCgmSJomT8ixkARkWA3JpbTEkMCIGA1UEAxMbUklNIFN1Ym9yZGluYXRlIENBIE1DQTAy WUtGAgptqd1HAAQAAAVqMG8GCyqGSIb3DQEJEAILMWCgXjBQMRMwEQYKCZImiZPyLGQBGRYDbmV0 MRMwEQYKCZImiZPyLGQBGRYDcmltMSQwIgYDVQQDExtSSU0gU3Vib3JkaW5hdGUgQ0EgTUNBMDJZ S0YCCm2p3UcABAAABWowgasGCSqGSIb3DQEJDzGBnTCBmjALBglghkgBZQMEASowCwYJYIZIAWUD BAEWMAoGCCqGSIb3DQMHMAsGCWCGSAFlAwQBAjAOBggqhkiG9w0DAgICAIAwBwYFKw4DAgcwDQYI KoZIhvcNAwICAUAwDQYIKoZIhvcNAwICASgwBwYFKw4DAhowCwYJYIZIAWUDBAIDMAsGCWCGSAFl AwQCAjALBglghkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEgYBGetiCXWohw2q0X+ioK0UoIs/19dZW 5HQ0jXvp7XnrjJc1RhqfZdn0LqIWwgF493TxCbCgtwm8TZ+LVKv/vsddLrRmOaAXCiYtQZjs180x 4K74MP+yTe4NQvZat8qZ/RHBefwspQJpxL/FTR5ts2e0DeKOTtmVlvsrnCcbgBL9BAAAAAAAAA== ------=_NextPart_000_0010_01CFF36A.F629EF20-- From nobody Wed Oct 29 09:11:23 2014 Return-Path: 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 766081A1B31 for ; Wed, 29 Oct 2014 09:11:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.723 X-Spam-Level: X-Spam-Status: No, score=0.723 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 l__bLBp3l33T for ; Wed, 29 Oct 2014 09:11:07 -0700 (PDT) Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com [209.85.212.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64AA31A1B20 for ; Wed, 29 Oct 2014 09:11:01 -0700 (PDT) Received: by mail-wi0-f173.google.com with SMTP id n3so2148570wiv.6 for ; Wed, 29 Oct 2014 09:10:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=kOp4ro7OLyYijXvv2IuJvq8Fm/+sfFa9KDp3/0p2ab0=; b=DrBK45FDOEb2Se1vAYock70YI+Be40Lg/HcE74pv4Wvdi2zzlWKOdSev8J4ttYBZY6 27ODoMAYEhosONMth7raGZnwUziqcGs/aucdOBK/wk7ZTVtrU27QWljKqD3G4mZgX35g LNE1sug1q3N3neJEdlU9mbZspBAtXgfGWBHvnHms1GUMWbIO8qWmsa181fYqxHKE5YNE PJpoX4PFgdZvPBMhryJGZsplDtIFPSoNseOShtA9fT0ZMZobzr9ZJV5XXTd5Skqq55iY NpvzQWmfHjmkrmDZdUaaSVJU3ocX4sSkpq7aZeUH1RPp6fASUIow8c8FQWNex7ErOowc RCRw== X-Gm-Message-State: ALoCoQkzYVYUyufbsq472jNMZyrnWI1Dk9gBHKBVxwy02NnZXPea8x/QKKTF8U573cLyzBMPKqNC X-Received: by 10.194.242.4 with SMTP id wm4mr13375749wjc.61.1414599059484; Wed, 29 Oct 2014 09:10:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.217.14.70 with HTTP; Wed, 29 Oct 2014 09:10:39 -0700 (PDT) In-Reply-To: <824DE505-598D-4B32-8EFC-F69B2672A51A@akr.io> References: <20141029042454.16752.qmail@cr.yp.to> <824DE505-598D-4B32-8EFC-F69B2672A51A@akr.io> From: Benjamin Black Date: Wed, 29 Oct 2014 09:10:39 -0700 Message-ID: To: Alyssa Rowan Content-Type: multipart/alternative; boundary=089e01419af670c7c50506920270 Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/haSmclKmHe3sBgfRT8hopVYEDec Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] Actual security levels for IETF crypto X-BeenThere: cfrg@irtf.org 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: Wed, 29 Oct 2014 16:11:11 -0000 --089e01419af670c7c50506920270 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Oct 29, 2014 at 4:36 AM, Alyssa Rowan wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > On 29 October 2014 06:49:26 GMT+00:00, Benjamin Black wrote: > > >>> sites which represent the vast majority of HTTP and SMTP user traffic > are few and universally deploy TLS. > >> [djb]: =E2=80=A6Amazon=E2=80=A6 > >I would claim that you sought out the only US site in the top 25 that > doesn't use TLS for every page. Every other US site in the global top 25 = is > TLS. How can that be if performance concerns are stopping deployment? > > Um, your claim is patently false. I can name one right off the top of my > head: eBay. > My claim is that performance is clearly not stopping deployment for major sites, so let's whip out the data and break down the entire top 25: 1. google.com - TLS 2. facebook.com - TLS 3. youtube.com - TLS 4. yahoo.com - TLS 5. baidu.com - NO TLS; China 6. wikipedia.org - TLS 7. amazon.com - only TLS for account & payments 8. twitter.com TLS 9. qq.com - NO TLS; China 10. taobao - NO TLS; China 11. google.co.in - TLS 12. live.com - TLS 13. linkedin.com - TLS 14. sina.com.cn - NO TLS; China 15. hao123.com - NO TLS; China 16. weibo.com - NO TLS; China 17. blogspot.com - TLS 18. yahoo.co.jp - NO TLS 19. tmall.com - NO TLS; China 20. yandex.ru - NO TLS 21. vk.com - TLS 22. ebay.com - only TLS for account & payments 23. google.de - TLS 24. bing.com - TLS 25. sohu.com - NO TLS; China 13 of the top 25 have TLS enabled for everything. Of the 12 that don't, 8 are in China, precluding their use of TLS in any meaningful way. That leaves us with 4 sites in the top 25 that could but don't yet have TLS enabled for everything: amazon.com, ebay.com, yahoo.co.jp, and yandex.ru. Why might Amazon and eBay not bother with it? Performance could certainly be a concern, but I doubt, based on direct experience, that is the case. As I said in my previous email, the Snowden leaks did not blowback on them so they haven't been presented with the business requirement faced by many others who recently enabled TLS everywhere. As Yahoo has already gone TLS for their main site, lack of TLS on their Japanese site suggests either they haven't gotten to it yet or they don't see a business requirement to do so. I have no insight into Yandex not being TLS, but let's assume the reason is entirely performance of ECDHE and if only they had faster curves they would enable TLS. That's a single site in the top 25. A majority of the top 25 already have TLS enabled. The number one reason for sites in the top 25 not having TLS: they are in China. That covers 21 of the top 25. This data shows clearly that performance concerns are not stopping the largest sites, who have the most to lose, from deploying TLS. > > We are nowhere near universal TLS. Three things typically hold back > universal TLS deployment: > =E2=80=A2 Cost - CAs, especially with a myriad smaller sites > > s/especially/only/ Large sites are not concerned by this. Their costs are much larger and unrelated to TLS. > =E2=80=A2 Performance > > Directly and clearly tied in with cost. Cloudflare's recent improvements > would have been impractical without the performance afforded by ECC. > > Enabling TLS and enabling PFS are not the same thing. Sites using RSA for kx already see the sort of performance we are discussing, and without clients taking a large performance hit. Clients are hit disproportionately by (EC)DHE, which is a particular concern for mobile. Do the curves we are discussing take the client resource consumption for ECDHE below RSA? If not, they won't help with TLS deployment, even if they increase the number of TLS sites that enable PFS. > Performance is a very major, even primary, concern for CDNs - ask Rich > Salz? > > CDNs have long offered TLS services because their customers require them. There is a cost associated with this, of course. As none of the curves we are discussing offer better performance than not using TLS at all, I don't see that overhead changing much. > State-of-the-art ECC to enable TLS everywhere is what we're being asked > for, and what is needed. > > Enabling TLS and enabling PFS are not the same thing. > =E2=80=A2 Deployment of universal TLS > > Thanks to ad networks, transclusion and embedding, and the mixed-content > problem, the other big barrier to universal TLS adoption seems to be simp= ly > that it hasn't happened already! That probably explains MSN, if the ad > networks don't support it. > > And why wouldn't they? Well, the above two give the big reasons. > > Not the right answer on MSN, but you have hit on the real cost of conversion which is that you can't simply flip a switch to enable TLS and roll out. You have to deal with all the dependencies, whether it is your own content, CDNs, ad networks, partners, etc. None of which has anything to do with performance. > If we can lower the barrier to adoption, in any way, we probably should. > Higher performance crypto lowers that barrier. > > No doubt. However, if the goal is universal TLS, then simply making it faster is useful but probably not the most efficient path to get there. b --089e01419af670c7c50506920270 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Oct 29, 2014 at 4:36 AM, Alyssa Rowan <akr@akr.io> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 29 October 2014 06:49:26 GMT+00:00, Benjamin Black <b@b3k.us> wrote:

>>> sites which represent the vast majority of HTTP and SMTP user = traffic are few and universally deploy TLS.
>> [djb]: =E2=80=A6Amazon=E2=80=A6
>I would claim that you sought out the only US site in = the top 25 that doesn't use TLS for every page. Every other US site in = the global top 25 is TLS. How can that be if performance concerns are stopp= ing deployment?

Um, your claim is patently false. I can name one right off the top o= f my head: eBay.

My claim is that perfo= rmance is clearly not stopping deployment for major sites, so let's whi= p out the data and break down the entire top 25:

1= . google.com - TLS
2. facebook.com - TLS
3. youtube.com - TLS
4. yahoo.com - TLS
5. baidu.c= om - NO TLS; China
7. amazon.com= - only TLS for account & payments
12. live.com - TLS
13. linkedin.com - TLS
14. = sina.com.cn - NO TLS; China
15. hao123.com - NO TLS; China
16. = weibo.com - NO TLS; China
17. blogspot.com - TLS
18. yahoo.= co.jp - NO TLS
19. tmall.com= - NO TLS; China
20. yandex.ru -= NO TLS
21. vk.com - TLS
= 22. ebay.com - only TLS for account & p= ayments
23. google.de - TLS
24. bing.com - TLS
25. sohu.com - NO TLS; China

13 of the top 25 have TLS enabled for everything. Of the 12 that don'= ;t, 8 are in China, precluding their use of TLS in any meaningful way. That= leaves us with 4 sites in the top 25 that could but don't yet have TLS= enabled for everything: amazon.com, ebay.com, yahoo.= co.jp, and yandex.ru.

Why might Amazon and eBay not bother with it? Performance could ce= rtainly be a concern, but I doubt, based on direct experience, that is the = case. As I said in my previous email, the Snowden leaks did not blowback on= them so they haven't been presented with the business requirement face= d by many others who recently enabled TLS everywhere.

<= div>As Yahoo has already gone TLS for their main site, lack of TLS on their= Japanese site suggests either they haven't gotten to it yet or they do= n't see a business requirement to do so. I have no insight into Yandex = not being TLS, but let's assume the reason is entirely performance of E= CDHE and if only they had faster curves they would enable TLS. That's a= single site in the top 25.=C2=A0

A majority of th= e top 25 already have TLS enabled. The number one reason for sites in the t= op 25 not having TLS: they are in China. That covers 21 of the top 25. This= data shows clearly that performance concerns are not stopping the largest = sites, who have the most to lose, from deploying TLS.
=C2=A0

We are nowhere near universal TLS. Three things typically hold back univers= al TLS deployment:=C2=A0
=C2=A0
=E2=80=A2 Cost - CAs, especially with a myriad smaller sites


s/especially/only/=C2=A0

Large sites are not concerned by this. Their costs are much larger and unr= elated to TLS.
=C2=A0
=E2=80=A2 Performance

Directly and clearly tied in with cost. Cloudflare's recent improvement= s would have been impractical without the performance afforded by ECC.


Enabling TLS and enabling PFS are not = the same thing. Sites using RSA for kx already see the sort of performance = we are discussing, and without clients taking a large performance hit. Clie= nts are hit disproportionately by (EC)DHE, which is a particular concern fo= r mobile. Do the curves we are discussing take the client resource consumpt= ion for ECDHE below RSA? If not, they won't help with TLS deployment, e= ven if they increase the number of TLS sites that enable PFS.
=C2= =A0
Performance is a very major, even primary, concern for CDNs - ask Rich Salz= ?


CDNs have long offered TLS services be= cause their customers require them. There is a cost associated with this, o= f course. As none of the curves we are discussing offer better performance = than not using TLS at all, I don't see that overhead changing much.
=C2=A0
State-of-the-art ECC to enable TLS everywhere is what we're being asked= for, and what is needed.


Enabling TLS and enabling PFS are not = the same thing.
=C2=A0
=E2=80=A2 Deployment of universal TLS

Thanks to ad networks, transclusion and embedding, and the mixed-content pr= oblem, the other big barrier to universal TLS adoption seems to be simply t= hat it hasn't happened already! That probably explains MSN, if the ad n= etworks don't support it.

And why wouldn't they? Well, the above two give the big reasons.


Not the right answer on MSN, but you h= ave hit on the real cost of conversion which is that you can't simply f= lip a switch to enable TLS and roll out. You have to deal with all the depe= ndencies, whether it is your own content, CDNs, ad networks, partners, etc.= None of which has anything to do with performance.=C2=A0
=C2=A0<= /div>
If we can lower the barrier to adoption, in any way, we probably should. Hi= gher performance crypto lowers that barrier.


No doubt. However, if the goal is univ= ersal TLS, then simply making it faster is useful but probably not the most= efficient path to get there.=C2=A0



b
--089e01419af670c7c50506920270-- From nobody Wed Oct 29 09:17:55 2014 Return-Path: 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 8230C1A1B1C for ; Wed, 29 Oct 2014 09:17:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.207 X-Spam-Level: X-Spam-Status: No, score=-4.207 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=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 5JxVyRrlf4cA for ; Wed, 29 Oct 2014 09:17:46 -0700 (PDT) Received: from mx1.ll.mit.edu (MX1.LL.MIT.EDU [129.55.12.45]) by ietfa.amsl.com (Postfix) with ESMTP id 810B51A01FA for ; Wed, 29 Oct 2014 09:17:44 -0700 (PDT) Received: from LLE2K10-HUB02.mitll.ad.local (LLE2K10-HUB02.mitll.ad.local) by mx1.ll.mit.edu (unknown) with ESMTP id s9TGHfv9016155; Wed, 29 Oct 2014 12:17:41 -0400 From: "Blumenthal, Uri - 0558 - MITLL" To: Benjamin Black , "cfrg@irtf.org" Thread-Topic: [Cfrg] Actual security levels for IETF crypto Thread-Index: AQHP8kclyBJktumKTkOlVDCBDIGoOpxFPp0AgAARAgCAANRggIAAmxQAgAAoYgCAAFA8AIAATJGA//++4QA= Date: Wed, 29 Oct 2014 16:17:41 +0000 Message-ID: References: <20141029042454.16752.qmail@cr.yp.to> <824DE505-598D-4B32-8EFC-F69B2672A51A@akr.io> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-originating-ip: [172.25.177.187] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3497429854_5818816" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.28, 0.0.0000 definitions=2014-10-29_06:2014-10-28,2014-10-29,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1410290160 Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/3FaqS1zO4NzgGUVOhA0uNjBBNgw Subject: Re: [Cfrg] Actual security levels for IETF crypto X-BeenThere: cfrg@irtf.org 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: Wed, 29 Oct 2014 16:17:48 -0000 --B_3497429854_5818816 Content-type: multipart/alternative; boundary="B_3497429854_5780073" --B_3497429854_5780073 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable > 13 of the top 25 have TLS enabled for everything. Of the 12 that don't, 8= are > in China, precluding their use of TLS in any meaningful way. That leaves = us > with 4 sites in the top 25 that could but don't yet have TLS enabled for > everything: amazon.com , ebay.com , > yahoo.co.jp , and yandex.ru =E2=80=A6=E2=80= =A6=E2=80=A6=E2=80=A6=E2=80=A6.. >=20 > I have no insight into Yandex not being TLS, but let's assume the reason = is > entirely performance of ECDHE and if only they had faster curves they wou= ld > enable TLS. That's a single site in the top 25. Yandex is in Russia. Russia used to have rather strict regulations regardin= g crypto (not unlike China). Possibly it still does. I would not be surprised if there are policies affecting how much or how little TLS Yandex is allowe= d to do. --B_3497429854_5780073 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable
13 of the top 25 have TLS enabled for= everything. Of the 12 that don't, 8 are in China, precluding their use of T= LS in any meaningful way. That leaves us with 4 sites in the top 25 that cou= ld but don't yet have TLS enabled for everything: amazon.com, ebay.= com, yahoo.co.jp, and yandex.ru……………..

I have no insight into Yandex not being TLS, but let's assume the reason is entirely performance of ECDHE and if only they had faster curves they w= ould enable TLS. That's a single site in the top 25. 
=

Yandex is in Russia. Russia us= ed to have rather strict regulations regarding crypto (not unlike China). Po= ssibly it still does. I would not be surprised if there are policies affecti= ng how much or how little TLS Yandex is allowed to do.

<= /body> --B_3497429854_5780073-- --B_3497429854_5818816 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIUOAYJKoZIhvcNAQcCoIIUKTCCFCUCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGgghIHMIIE6jCCA9KgAwIBAgIKH0XZoAAAAAABzTANBgkqhkiG9w0BAQsFADBRMQswCQYD VQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJ MRMwEQYDVQQDEwpNSVRMTCBDQS0zMB4XDTE0MDQxNjIxNTMwMloXDTE1MDQxNjIxNTMwMlow YTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNV BAsTBlBlb3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQCx/gK75UYos2g8JavX0BVfe3TCGsmjQY34z9ZVeucP 8dGtqRA8T5i1OKdf++Jd81a0/qQA6mIGyzTW6lOtY+77qKUJtEeLM5URd+iv2EejAwxsa2B5 pMq9L9qWuVokR1rTEfEcuUeKR1Kko6xmRE/y6AzBnUhTvHx2X9F6JSVdR36Lx3R62CNeQqFi ZDeHuTI8AhRY4UdPkri1FTDxV6gLYaLKxsGIurrL/6EzdlkX8ImTcxKzEmxX1VjTPy9ZRNYj akDGcJF9clCfcwbq3DI3gAUkVxXf+UbHEjzOCVNQcoga7bYbBUuDpN25Lc86P9RaOiiICtyu ZZP2P/2kkKYRAgMBAAGjggGyMIIBrjAdBgNVHQ4EFgQUEN9QHIi9GvlGjs9Th46jrfPir+Uw DgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1Ud HwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYB BQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExD QTMwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3 FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+KcwIBZAIBBTAi BgNVHSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAYBgNVHSAEETAPMA0GCyqGSIb3 EgIBAwEIMBkGA1UdEQQSMBCBDnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABM AFUAcwBlAHIAUwBpAGcALQBTAFcwDQYJKoZIhvcNAQELBQADggEBAL2kCh9ovO8AbHgAVU6T eH5qRmKnOrfTUfn9JnHzkspdWMQA1IdtftSpiZZ7C3lCmblSDCgPqbQl4zMZxXeTgxnQsB6m 1LA6uDHM/0G27RcOJH4OTN9sQ0/2CKb4JPIXXIps1z+s8XjSRzPJZuD8fPC8R8QWvOH3owL2 BLzZebZTOMa5yws3kohY02vP/Clv0KQXYVzUZUYXoYmhUSYmQ1UZZZSFJ2rNdgNn0z8fPrUQ NIYlVaJV0kKQYjlHWTfomVapLEfIY7xRHZy9g997IjYReD0t9IZd6tTwcJES+2ijFM8l/fxk u/cQ4WCYyI+58DaBaV9p68/AC147b0HhvLUwggS8MIIDpKADAgECAgEpMA0GCSqGSIb3DQEB BQUAMFQxCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQww CgYDVQQLEwNQS0kxFjAUBgNVBAMTDU1JVExMIFJvb3QgQ0EwHhcNMTMxMjE3MDAwMDAwWhcN MjAxMjMxMjM1OTU5WjBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFi b3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2jBSdW18tuW1tNxG6h8B0kqckFZQAAtoHCkvUpUEX6jF vBd8mQI53GyLYRuAo4HWJpe7/izFXOfSJDs6UM5ovvCOfXg2bJgDYlBC9JDcLBFIn0nppOu9 RvpjWSixtC56crwJ5Us5QPdtxtKdek5LJXl2oKw3w8lihUixePbxWad1m7ZMKKagvm9zTybP 6FumKRxeYJjSpB2+cAYjoGGEbSVHyx8uzHm6xAoBMHxa8by+yDz8Jzk6sP9iilgP3iXSGoCA mhyBzvlQQ5QNNWP+Emo9jz/ukKhYVB/VwdxtoquPAqn4ifDAIaM9dtb05cy1gXAFSP3Z/iUk xyBZZUORfwIDAQABo4IBmjCCAZYwEgYDVR0TAQH/BAgwBgEB/wIBADAdBgNVHQ4EFgQU12Bm DntJjXVMDf3PRt7IxxKHyr8wHwYDVR0jBBgwFoAUZ6p6z/QKprlytYqg0p3yEMND7SkwDgYD VR0PAQH/BAQDAgGGMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0cDovL2NybC5s bC5taXQuZWR1L2dldHRvP0xMUkNBMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5sbC5taXQu ZWR1L29jc3AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNy bD9MTFJDQTCBkgYDVR0gBIGKMIGHMA0GCyqGSIb3EgIBAwEGMA0GCyqGSIb3EgIBAwEIMA0G CyqGSIb3EgIBAwEHMA0GCyqGSIb3EgIBAwEJMA0GCyqGSIb3EgIBAwEKMA0GCyqGSIb3EgIB AwELMA0GCyqGSIb3EgIBAwEOMA0GCyqGSIb3EgIBAwEPMA0GCyqGSIb3EgIBAwEQMA0GCSqG SIb3DQEBBQUAA4IBAQAsf9HBn72qU7UTgkxarjAc7iynhcDEgWwezYKtd/SLGSQ0DhtzIV/L TCxqULjOd+H+HTqMJXB8+nHnzhyqQ43RsnGZOFT5RfzPh94db/ZJ3ql244DwlJI7yXBA2DkZ cEEgOWC9bHcrElzU6NnigahSW5odVJrhmH/XhQAcMS77E5H62yyxK1WPPgcBipGVnu1xSHbT iHe7DqfWQ2tVMLUf23XYhIua94kJsQd4jSh71NVD0e7F4snAoqQMI98MzDYeLOkjlzKRs77r /aMsPAKx6nMaOvRL7Cy0Pjp51i2qFkbGmX8ofnh2kerjTTvRJ/g22r1MV8RR1PktjMsNOsPf MIIDgzCCAmugAwIBAgIBATANBgkqhkiG9w0BAQUFADBUMQswCQYDVQQGEwJVUzEfMB0GA1UE ChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRYwFAYDVQQDEw1NSVRM TCBSb290IENBMB4XDTA4MDkyMzEyMDAwMFoXDTI5MTIzMTIzNTk1OVowVDELMAkGA1UEBhMC VVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTEWMBQG A1UEAxMNTUlUTEwgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMVO KRdYsiay+a2Kv1wQCoPd5AkwExuwcNDRhaRCdQN17K+lCCKvf9VSQToAsA6q1bACtZUcMv5Z Kx8z5KG4jK9cM40NvEkf/bIOZAHJqzKgWG3N9NqrcAhimcXTXYQIdp1DgjtdADKVLAjXaYpD 2PbpE/JbAPnqKzOENa3Py9CegB0abTlOyLgwXWY/rXTW+4L/hipJ6+sI/ZtrFRmsKGhuwAKo bFr0FDP6uIfx+RaWJcJ1QBIdgM4aohvW8JeriSSMyf/LlFpXTZFcM9SOX0f7wmsYi1yFuKFM nQbkSkxvnpBKMRxrg+98seSbbEnIkvB0C9qBDPLb/lQAvmpW6oMCAwEAAaNgMF4wDwYDVR0T AQH/BAUwAwEB/zAdBgNVHQ4EFgQUZ6p6z/QKprlytYqg0p3yEMND7SkwHwYDVR0jBBgwFoAU Z6p6z/QKprlytYqg0p3yEMND7SkwCwYDVR0PBAQDAgGGMA0GCSqGSIb3DQEBBQUAA4IBAQA+ G20FYNB4eNhKWF+PyT5DUtzlABFkf2IM2VGNUBova0GeKX3I1Nf02qDU/GO2H9ETvnvTYhvf gQ4UB/5EImTkKPa7/TVG/MQ7SgmAmne8xELVbGLFrrytly8PyYtZtngb6DgeEUv+SwFnzcLO 1vg1rdmss3kwsqy0q8e2VYAY8zTptEzyJG36aXcIMbqOxWS/LbPjNuPdgJfO3d1WrHr1Etaa a0QRLqQoZj07dYY7Wo5EDqU+AUAMz9ZVRGK1s5b/jv5Wz/YroyqWFnH2KkNxRn9+2Ar7g3rn rOMZvp6psq2jbDXiPBod1wyMKn8x5y4cuGPNFcqjfyY/HX90ivQAMIIEzjCCA7agAwIBAgIK PVEvPAAAAACTsDANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlU IExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0y MB4XDTE0MDIxMjE4NTMwMVoXDTE1MDIxMjE4NTMwMVowYTELMAkGA1UEBhMCVVMxHzAdBgNV BAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsTBlBlb3BsZTEgMB4GA1UEAxMX Qmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCKHhhu75bRiOvWhbZ//TxS76yI2d+rHN2s8bp8wxW8oMjmsaplLeGQusUFRyRNSkfYtdB4 YApjnV6TCxS0Mqzly5BaoeZWoP+CbbMDNGYMszus9iFj22SSlTzGRo+gaL6rqsDKdwDOzs3C PYqh4Uu8sLzEq+QD9rhqAuMJ76635JKWELxK0uDehpNBMCGqVeAY8ht5u2h4ojPdwiuDQDW2 QxWRJjPDL8n1JczuEHY71jHldER3b2+UhpDDYRQ9aVOiGCjW8BwJOruVsBfLNxyDxgffNQ1D 1konuneMpL9H2S8ciHOdy5+Gi7snCQJ+7w30rIJ2NTldWaY6avZAaCa3AgMBAAGjggGWMIIB kjAdBgNVHQ4EFgQUZ7oGjnu6gWRmom/4UswgdVBW/3wwDgYDVR0PAQH/BAQDAgUgMB8GA1Ud IwQYMBaAFI5KfYmhYxccgYg0VzcmRV4Zin4kMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9j cmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTIwYgYIKwYBBQUHAQEEVjBUMC0GCCsGAQUFBzAC hiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTIwIwYIKwYBBQUHMAGGF2h0dHA6 Ly9vY3NwLmxsLm1pdC5lZHUvMAwGA1UdEwEB/wQCMAAwPQYJKwYBBAGCNxUHBDAwLgYmKwYB BAGCNxUIg4PlHYfsp2aGrYcVg+rwRYW2oR8dhevQcIPr7SACAWQCAQQwJQYDVR0lBB4wHAYE VR0lAAYIKwYBBQUHAwQGCisGAQQBgjcKAwQwGAYDVR0gBBEwDzANBgsqhkiG9xICAQMBCDAZ BgNVHREEEjAQgQ51cmlAbGwubWl0LmVkdTANBgkqhkiG9w0BAQsFAAOCAQEAJiU3WfJ9GvGJ iDNPClLazyh252wxxOc/TmClMKtyqHnbFObDEoXAMaoHGxrvs+lU8fU2F2ELpV8q8eYgqLLw 7PG09z5s/GkajlxVZ/FHj/9hNHTfwlicrCRY3zrna1GbOMZgWFz8R6akAoLKpqGulNrvjvU8 c63U+JVmgJmBPCMv5JlH10m87+WPJ+ToK0m4XfZjl7n5OKDJ/hOyBwbBntc+W2gDppfR1BCt DNfEG0+zHjFqF+Of1Q5NI5abhgvw5IEuVA1M4SV/utwmmdreBEv/YuLnDd/PhVgQwp3LHGCX X1dANyiKso2aACl9jrkylq39cA/WgvAlS21w9vxVpDGCAfUwggHxAgEBMF8wUTELMAkGA1UE BhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTET MBEGA1UEAxMKTUlUTEwgQ0EtMwIKH0XZoAAAAAABzTANBglghkgBZQMEAgEFAKBpMC8GCSqG SIb3DQEJBDEiBCDVa6WVk4mEdeX+D8nqhdyklVDPGnsymBhwP4GdXXBKaTAYBgkqhkiG9w0B CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNDEwMjkxNjE3MzRaMA0GCSqGSIb3 DQEBAQUABIIBAEXb/WnplyESxFXd8HJJhv2AXTxTFnpNIfk8cTrjOvQdpvH80Zcg4W6a7v1i q9G8k6oGQdKREzSxZPBF4LittYaKAajtZB6hzfnOtiPqgv0SMzy61cUVZtuCRkwsDfV7ugO9 pIfCQFB+4Cmd5BAD560wGL1EHQf+hOe9Aik+ZPUrCPHcJlIhHCAkPSGBOfy/rLDYIGX7vVdv 9zQVu7J0tM/+G4zX3NMREyI5f/eTNjZkr1/nA2pdg2iUkol2tDbk/ZizCFY4bhx7jMEb6aoI briv5FYsY8dAuhXj/ZpDoeNUqvamdM+54mge+vG/8FS+ck+NVpQNiqlp7uo/QUwSG6E= --B_3497429854_5818816-- From nobody Wed Oct 29 09:18:12 2014 Return-Path: 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 4E08D1A1ADD for ; Wed, 29 Oct 2014 09:18:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 ARseSnu8qMKM for ; Wed, 29 Oct 2014 09:18:04 -0700 (PDT) Received: from mail-wi0-f169.google.com (mail-wi0-f169.google.com [209.85.212.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 246CC1A1B4A for ; Wed, 29 Oct 2014 09:17:59 -0700 (PDT) Received: by mail-wi0-f169.google.com with SMTP id n3so1978169wiv.2 for ; Wed, 29 Oct 2014 09:17:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=OAdkVXgfS5h12Zd2fknzSL7ATjH/hFJODhGZoze67io=; b=IfN5AoUgjbDYnNNQ+w5vzxissM1iw4QV0Hw9sbhy6VB1xJCCUJtr4Dv1BBQIeT/PEP aZhT6u0INrVsq6vSYncn7nrvsF21at40vNq4DkIUOs8Cpk3DojX4w53hRx4Bc+NfGdD3 QsxDYWgv776GbQdXdpFxUllO4a6xDaV/XNIRRZlRVRhoR6c0iZl/oYC80L1aqTsy8Meu KovI7im/t99cnZ792pC2WtiwDpF9sIB8j79bq9asoMcooInLG1Z2dBGzYraE3HMpplU4 zp9Irt0nE2wnWLfOZBZZnPlAPBWnOYVUEFgs9doeVYdz3ENs5/pZgj4zUmGUupNwp4Xa L9NA== X-Gm-Message-State: ALoCoQmf6j7qHxn6DpdinpOcYCsOkKVV52ke8ca6jiGVaP4Ny6X4dB+dUyQHcUrN4VMh7GUDycju X-Received: by 10.194.81.70 with SMTP id y6mr12565458wjx.113.1414599478403; Wed, 29 Oct 2014 09:17:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.217.14.70 with HTTP; Wed, 29 Oct 2014 09:17:37 -0700 (PDT) In-Reply-To: References: <20141029042454.16752.qmail@cr.yp.to> From: Benjamin Black Date: Wed, 29 Oct 2014 09:17:37 -0700 Message-ID: To: Watson Ladd Content-Type: multipart/alternative; boundary=047d7bf0ca4a68f84b0506921ba8 Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/k9tuIttdkx_8KtdPGmDb3od1OsU Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] Actual security levels for IETF crypto X-BeenThere: cfrg@irtf.org 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: Wed, 29 Oct 2014 16:18:09 -0000 --047d7bf0ca4a68f84b0506921ba8 Content-Type: text/plain; charset=UTF-8 On Wed, Oct 29, 2014 at 7:05 AM, Watson Ladd wrote: > On Tue, Oct 28, 2014 at 11:49 PM, Benjamin Black wrote: > > > > I would claim that you sought out the only US site in the top 25 that > > doesn't use TLS for every page. Every other US site in the global top 25 > is > > TLS. How can that be if performance concerns are stopping deployment? > > Is this actually true? go.com isn't. craigslist.org isn't, imgur.com > isn't, ESPN isn't, tumblr.com isn't, CNN isn't, apple.com isn't, > instagram.com isn't, and huffingtonpost.com isn't. That's nearly half > of the top 25. > > Global: http://www.alexa.com/topsites --047d7bf0ca4a68f84b0506921ba8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Oct 29, 2014 at 7:05 AM, Watson Ladd <watsonbladd@gmail.com>= ; wrote:
On Tue, Oct 28, 2014 a= t 11:49 PM, Benjamin Black <b@b3k.us>= wrote:
>
> I would claim that you sought out the only US site in the top 25 that<= br> > doesn't use TLS for every page. Every other US site in the global = top 25 is
> TLS. How can that be if performance concerns are stopping deployment?<= br>
Is this actually true? g= o.com isn't. cr= aigslist.org isn't, = imgur.com
isn't, ESPN isn't, = tumblr.com isn't, CNN isn't, apple.com isn't,
instagram.com isn= 9;t, and huffington= post.com isn't. That's nearly half
of the top 25.



--047d7bf0ca4a68f84b0506921ba8-- From nobody Wed Oct 29 09:22:11 2014 Return-Path: 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 0043F1A1B79 for ; Wed, 29 Oct 2014 09:22:02 -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 fCFehKVvFbpl for ; Wed, 29 Oct 2014 09:21:57 -0700 (PDT) Received: from mail-yk0-x234.google.com (mail-yk0-x234.google.com [IPv6:2607:f8b0:4002:c07::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A73661A1B5C for ; Wed, 29 Oct 2014 09:21:54 -0700 (PDT) Received: by mail-yk0-f180.google.com with SMTP id 9so1450701ykp.11 for ; Wed, 29 Oct 2014 09:21:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=x+DBr+tXK/GF1fUXOwqW3Oe7Zi2W0YaD+uTMhiQxp4I=; b=0f7FfUMV6i5s7uG8C9W+SdEwLVJE0k2r46f7ovbOuUkjfjnq2cDEirTb2heXnjxYnM 1THE2nfOp8fPSFMz0Cx/xa9BRg/JVd0fXtD6wFtdxQCcKIhdlzQtlV9EFAVTRyK0wyCt P9sESuKUvs/KjyjKSSg78BWB0izTLjVjsq/Yya/N1PL7Od9r3Eyx2vxYuqtD+WxOBvl0 dgLBQLkRimUYxiHuEeNZmIjY5OqJK6zL/v24zx1USbZBDdnYS6wcqJybyZ0XwScDvOEJ /mn51P1IkfDVDd6Y8ucYfEOqagIZKFNlSXsXYw2GMNEwwJY/DdJRP4fIMpsBAM/6EZe/ 56qQ== MIME-Version: 1.0 X-Received: by 10.236.17.197 with SMTP id j45mr2631179yhj.49.1414599713827; Wed, 29 Oct 2014 09:21:53 -0700 (PDT) Received: by 10.170.195.149 with HTTP; Wed, 29 Oct 2014 09:21:53 -0700 (PDT) Received: by 10.170.195.149 with HTTP; Wed, 29 Oct 2014 09:21:53 -0700 (PDT) In-Reply-To: References: <20141029042454.16752.qmail@cr.yp.to> Date: Wed, 29 Oct 2014 09:21:53 -0700 Message-ID: From: Watson Ladd To: Benjamin Black Content-Type: multipart/alternative; boundary=047d7b603c58713047050692299e Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/gFG-GNHV4H9kfJrAydumekDiYAs Cc: cfrg@irtf.org Subject: Re: [Cfrg] Actual security levels for IETF crypto X-BeenThere: cfrg@irtf.org 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: Wed, 29 Oct 2014 16:22:03 -0000 --047d7b603c58713047050692299e Content-Type: text/plain; charset=UTF-8 On Oct 29, 2014 9:17 AM, "Benjamin Black" wrote: > > On Wed, Oct 29, 2014 at 7:05 AM, Watson Ladd wrote: >> >> On Tue, Oct 28, 2014 at 11:49 PM, Benjamin Black wrote: >> > >> > I would claim that you sought out the only US site in the top 25 that >> > doesn't use TLS for every page. Every other US site in the global top 25 is >> > TLS. How can that be if performance concerns are stopping deployment? >> >> Is this actually true? go.com isn't. craigslist.org isn't, imgur.com >> isn't, ESPN isn't, tumblr.com isn't, CNN isn't, apple.com isn't, >> instagram.com isn't, and huffingtonpost.com isn't. That's nearly half >> of the top 25. >> > > Global: http://www.alexa.com/topsites Ok, I did US top 25. What does that say for your argument? Also, we can fix TLS 1.3 to be faster, and use ECDSA certificates. > --047d7b603c58713047050692299e Content-Type: text/html; charset=UTF-8


On Oct 29, 2014 9:17 AM, "Benjamin Black" <b@b3k.us> wrote:
>
> On Wed, Oct 29, 2014 at 7:05 AM, Watson Ladd <watsonbladd@gmail.com> wrote:
>>
>> On Tue, Oct 28, 2014 at 11:49 PM, Benjamin Black <b@b3k.us> wrote:
>> >
>> > I would claim that you sought out the only US site in the top 25 that
>> > doesn't use TLS for every page. Every other US site in the global top 25 is
>> > TLS. How can that be if performance concerns are stopping deployment?
>>
>> Is this actually true? go.com isn't. craigslist.org isn't, imgur.com
>> isn't, ESPN isn't, tumblr.com isn't, CNN isn't, apple.com isn't,
>> instagram.com isn't, and huffingtonpost.com isn't. That's nearly half
>> of the top 25.
>>
>
> Global: http://www.alexa.com/topsites

Ok, I did US top 25. What does that say for your argument? Also, we can fix TLS 1.3 to be faster, and use ECDSA certificates.

>

--047d7b603c58713047050692299e-- From nobody Wed Oct 29 09:36:53 2014 Return-Path: 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 C83A61A1BA3 for ; Wed, 29 Oct 2014 09:36:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 zKgLzmTkrCxS for ; Wed, 29 Oct 2014 09:36:24 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A81561A1BA7 for ; Wed, 29 Oct 2014 09:36:17 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id bs8so2217563wib.11 for ; Wed, 29 Oct 2014 09:36:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=xDs6kA58tI/U3eoortWwdrY8OAet4LI6z7u82jLl0Fw=; b=Z6jM7Ti0uZ38unLfXp0RoNv3f20FN/tw4K7vpHBrhC5ULF+BqcbTgOhsO/UIP+qzcP sL2jmMInYyl+rLwzyEYRexHhhJw6sVvTUBacjFflmTTMzji+EdBsyqUhtxYZ68zEOD45 N5g2jVnon/9OVqQtxwpY1glot3oaz9FLymhkU7uWVPuM9qaLQEwY+EREwO/SzQt497F9 gkFkx7XTtUSMs7bSMHd4/+HjN6xZF85QwZoncJ2SqvZ6lVC4wAn2UEOB145eR+YHG30g YlUVzlVvmGKYlYeIOyq8lHK+gdDHWJ7NPOvPUgMCMHBkdH2cEGGPiZYXNqdhhnaRfLJ+ gmsQ== X-Gm-Message-State: ALoCoQm1tZJ7eSW4rofqR1jWUBdK3PL7zbleli8WfZpDB4+H7SEyiqv2nXOwUT/WDgXGNhbGEQxK X-Received: by 10.180.104.198 with SMTP id gg6mr37767170wib.76.1414600575849; Wed, 29 Oct 2014 09:36:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.217.14.70 with HTTP; Wed, 29 Oct 2014 09:35:55 -0700 (PDT) In-Reply-To: References: <20141029042454.16752.qmail@cr.yp.to> From: Benjamin Black Date: Wed, 29 Oct 2014 09:35:55 -0700 Message-ID: To: Watson Ladd Content-Type: multipart/alternative; boundary=f46d04426e10d2a52c0506925ccf Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/0s31NGudQoEKklGbXPpAQXhB5fM Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] Actual security levels for IETF crypto X-BeenThere: cfrg@irtf.org 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: Wed, 29 Oct 2014 16:36:33 -0000 --f46d04426e10d2a52c0506925ccf Content-Type: text/plain; charset=UTF-8 It says even your cherrypicked data tells a similar story. More than half the US top 25 are already TLS for everything. Doesn't sound like evidence supporting the claim that performance is the main impediment to TLS adoption. Faster is good, but let's not delude ourselves on the impact faster will have. On Wed, Oct 29, 2014 at 9:21 AM, Watson Ladd wrote: > > On Oct 29, 2014 9:17 AM, "Benjamin Black" wrote: > > > > On Wed, Oct 29, 2014 at 7:05 AM, Watson Ladd > wrote: > >> > >> On Tue, Oct 28, 2014 at 11:49 PM, Benjamin Black wrote: > >> > > >> > I would claim that you sought out the only US site in the top 25 that > >> > doesn't use TLS for every page. Every other US site in the global top > 25 is > >> > TLS. How can that be if performance concerns are stopping deployment? > >> > >> Is this actually true? go.com isn't. craigslist.org isn't, imgur.com > >> isn't, ESPN isn't, tumblr.com isn't, CNN isn't, apple.com isn't, > >> instagram.com isn't, and huffingtonpost.com isn't. That's nearly half > >> of the top 25. > >> > > > > Global: http://www.alexa.com/topsites > > Ok, I did US top 25. What does that say for your argument? Also, we can > fix TLS 1.3 to be faster, and use ECDSA certificates. > > > > --f46d04426e10d2a52c0506925ccf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
It says even your cherrypicked data tells a similar s= tory. More than half the US top 25 are already TLS for everything. Doesn= 9;t sound like evidence supporting the claim that performance is the main i= mpediment to TLS adoption. Faster is good, but let's not delude ourselv= es on the impact faster will have.
On Wed, Oct 29, 2014 at 9:21 AM, Watson Ladd <= span dir=3D"ltr"><watsonbladd@gmail.com> wrote:


On Oct 29, 2014 9:17 AM, "Benjamin Black" <b@b3k.us> wrote:
>
> On Wed, Oct 29, 2014 at 7:05 AM, Watson Ladd <watsonbladd@gmail.com> wrote:<= br> >>
>> On Tue, Oct 28, 2014 at 11:49 PM, Benjamin Black <b@b3k.us> wrote:
>> >
>> > I would claim that you sought out the only US site in the top= 25 that
>> > doesn't use TLS for every page. Every other US site in th= e global top 25 is
>> > TLS. How can that be if performance concerns are stopping dep= loyment?
>>
>> Is this actually true? go.com isn't. = craigslist.org isn't, imgur.com
>> isn't, ESPN isn't, tumblr.com isn't, CNN isn't, apple.com isn't,
>> instagram.com isn't, and h= uffingtonpost.com isn't. That's nearly half
>> of the top 25.
>>
>
> Global: ht= tp://www.alexa.com/topsites

Ok, I did US top 25. What does that say for your= argument? Also, we can fix TLS 1.3 to be faster, and use ECDSA certificate= s.

>


--f46d04426e10d2a52c0506925ccf-- From nobody Wed Oct 29 09:42:40 2014 Return-Path: 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 AA2B01A0187 for ; Wed, 29 Oct 2014 09:42:36 -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 EOd08H6Nz2_f for ; Wed, 29 Oct 2014 09:42:29 -0700 (PDT) Received: from mail-yh0-x236.google.com (mail-yh0-x236.google.com [IPv6:2607:f8b0:4002:c01::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 387781A0A85 for ; Wed, 29 Oct 2014 09:42:26 -0700 (PDT) Received: by mail-yh0-f54.google.com with SMTP id 29so825429yhl.13 for ; Wed, 29 Oct 2014 09:42:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=UwYMun5tWLjlsYsgHSXwbjrCcKoLW2hdMYIBBl/puko=; b=TO78hxAYBUVRwRVB+Sow7nszezE4UNUJCtOQztFO8hbyYTRmd8fTxKZgaDkjDHgqcb nz9jGbf7Dh22aQCq6yq7autGyv4oqXAGkDwr7E3FS123a8EmrALATpu2CBfXu8Ndcjnz 51RG+eBRWVqoVMN6HwUhLbASIhpIftWokWFr240JjEJIE2bEi3OHw3ww2yv7VQ+TDJ37 ngf0q84dUdrzqaAZcT9Qrkz7jZQkoSayw/yAM1UW3tDusBHPYeBhQ1haLmGSZIPTLxfC 1Sjua8FXK896Ug5+wyQRLI4c+UOzdsxL6yTI/NT0Msb07PZ/aq1rWnCIl8gpYxMQeI/a ekgg== MIME-Version: 1.0 X-Received: by 10.236.22.36 with SMTP id s24mr2774243yhs.138.1414600945595; Wed, 29 Oct 2014 09:42:25 -0700 (PDT) Received: by 10.170.195.149 with HTTP; Wed, 29 Oct 2014 09:42:25 -0700 (PDT) Received: by 10.170.195.149 with HTTP; Wed, 29 Oct 2014 09:42:25 -0700 (PDT) In-Reply-To: References: <20141029042454.16752.qmail@cr.yp.to> Date: Wed, 29 Oct 2014 09:42:25 -0700 Message-ID: From: Watson Ladd To: Benjamin Black Content-Type: multipart/alternative; boundary=e89a8f646d93dc79fc05069272c3 Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/mdOv2jSfTSVhzenqRXGfqAlDfDc Cc: cfrg@irtf.org Subject: Re: [Cfrg] Actual security levels for IETF crypto X-BeenThere: cfrg@irtf.org 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: Wed, 29 Oct 2014 16:42:36 -0000 --e89a8f646d93dc79fc05069272c3 Content-Type: text/plain; charset=UTF-8 On Oct 29, 2014 9:36 AM, "Benjamin Black" wrote: > > It says even your cherrypicked data tells a similar story. More than half the US top 25 are already TLS for everything. Doesn't sound like evidence supporting the claim that performance is the main impediment to TLS adoption. Faster is good, but let's not delude ourselves on the impact faster will have. If you think I cherrypicked, go look at all national top 25 lists, and show the US is a laggard. Throwing out unsupported accusations of misconduct isn't helping. You still haven't explained the merits of your proposal over the counterproposal, instead choosing to double down on the "performance doesn't matter" argument in the face of significant evidence. I saw the top 25 list on the Alexa site and didn't realize this was not the global one. I then went down and looked at each site. Accidentally using the wrong data set is not cherrypicking. > > On Wed, Oct 29, 2014 at 9:21 AM, Watson Ladd wrote: >> >> >> On Oct 29, 2014 9:17 AM, "Benjamin Black" wrote: >> > >> > On Wed, Oct 29, 2014 at 7:05 AM, Watson Ladd wrote: >> >> >> >> On Tue, Oct 28, 2014 at 11:49 PM, Benjamin Black wrote: >> >> > >> >> > I would claim that you sought out the only US site in the top 25 that >> >> > doesn't use TLS for every page. Every other US site in the global top 25 is >> >> > TLS. How can that be if performance concerns are stopping deployment? >> >> >> >> Is this actually true? go.com isn't. craigslist.org isn't, imgur.com >> >> isn't, ESPN isn't, tumblr.com isn't, CNN isn't, apple.com isn't, >> >> instagram.com isn't, and huffingtonpost.com isn't. That's nearly half >> >> of the top 25. >> >> >> > >> > Global: http://www.alexa.com/topsites >> >> Ok, I did US top 25. What does that say for your argument? Also, we can fix TLS 1.3 to be faster, and use ECDSA certificates. >> >> > > > --e89a8f646d93dc79fc05069272c3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Oct 29, 2014 9:36 AM, "Benjamin Black" <b@b3k.us> wrote:
>
> It says even your cherrypicked data tells a similar story. More than h= alf the US top 25 are already TLS for everything. Doesn't sound like ev= idence supporting the claim that performance is the main impediment to TLS = adoption. Faster is good, but let's not delude ourselves on the impact = faster will have.

If you think I cherrypicked, go look at all national top 25 = lists, and show the US is a laggard. Throwing out unsupported accusations o= f misconduct isn't helping.

You still haven't explained the merits of your proposal = over the counterproposal, instead choosing to double down on the "perf= ormance doesn't matter" argument in the face of significant eviden= ce.

I saw the top 25 list on the Alexa site and didn't reali= ze this was not the global one. I then went down and looked at each site. A= ccidentally using the wrong data set is not cherrypicking.

>
> On Wed, Oct 29, 2014 at 9:21 AM, Watson Ladd <watsonbladd@gmail.com> wrote:
>>
>>
>> On Oct 29, 2014 9:17 AM, "Benjamin Black" <b@b3k.us> wrote:
>> >
>> > On Wed, Oct 29, 2014 at 7:05 AM, Watson Ladd <watsonbladd@gmail.com> wrote:
>> >>
>> >> On Tue, Oct 28, 2014 at 11:49 PM, Benjamin Black <b@b3k.us> wrote:
>> >> >
>> >> > I would claim that you sought out the only US site i= n the top 25 that
>> >> > doesn't use TLS for every page. Every other US s= ite in the global top 25 is
>> >> > TLS. How can that be if performance concerns are sto= pping deployment?
>> >>
>> >> Is this actually true? go.com isn't. craigslist.org isn'= t, imgur.com
>> >> isn't, ESPN isn't, = tumblr.com isn't, CNN isn't, apple= .com isn't,
>> >> instagram.com isn= 9;t, and huffingtonpost.com isn&#= 39;t. That's nearly half
>> >> of the top 25.
>> >>
>> >
>> > Global: http://www.= alexa.com/topsites
>>
>> Ok, I did US top 25. What does that say for your argument? Also, w= e can fix TLS 1.3 to be faster, and use ECDSA certificates.
>>
>> >
>
>

--e89a8f646d93dc79fc05069272c3-- From nobody Wed Oct 29 10:50:00 2014 Return-Path: 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 07F961A8753 for ; Wed, 29 Oct 2014 10:49:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 0xWPfNHMfH9S for ; Wed, 29 Oct 2014 10:49:57 -0700 (PDT) Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 837101A066B for ; Wed, 29 Oct 2014 10:49:56 -0700 (PDT) Received: by mail-lb0-f170.google.com with SMTP id 10so2975160lbg.1 for ; Wed, 29 Oct 2014 10:49:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=DTMWBoeQQAbKk83jjaYB+3g4LFWPTB0K0fOZz/GFwl4=; b=dMzeHa/bVDMOvqrTOQ6PV9z3SBaVxXwcKSk2Wsflja3Z0CUSt640gyfqH2M8lEida6 v/UQMCaeWc/n7CiEMcERKWPeKfZ3MWz6oBAhnmw+RekrLa2p7EwWWitKBe7c6iDcxxW2 k1r1FJkkx0qOcsYwNIQKUXk/Fe0+74iknLE6xsxJ0kQuQuIfBkggC2pSBlyA8hx/2xCI 3vmVUBxmvApupKwACeZU7KdUDOPlS3ORouN4xJffYqtvwdx93wcxc8lyfeYqQplBz4dx hh+8xqhkqC3O4i5fSmlvI/1C5erQ1l8BGbcj82O8ViMYllYdH6JeSF/BpTq0z6QlsTXP zT3w== X-Received: by 10.152.163.101 with SMTP id yh5mr12692126lab.68.1414604994638; Wed, 29 Oct 2014 10:49:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.218.145 with HTTP; Wed, 29 Oct 2014 10:49:34 -0700 (PDT) In-Reply-To: <810C31990B57ED40B2062BA10D43FBF5CF7DEC@XMB116CNC.rim.net> References: <810C31990B57ED40B2062BA10D43FBF5CF7DEC@XMB116CNC.rim.net> From: David Leon Gil Date: Wed, 29 Oct 2014 13:49:34 -0400 Message-ID: To: Dan Brown Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/jq3x_3HCelLMIOml1oeqtSHHOaM Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] Signature question ... [RE: Actual security levels for IETF crypto] X-BeenThere: cfrg@irtf.org 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: Wed, 29 Oct 2014 17:49:59 -0000 On Wed, Oct 29, 2014 at 10:25 AM, Dan Brown wrote: > I slightly prefer ECDSA over Schnorr for provable security reasons: > specifically in the generic group model, ECDSA relies on standard hash > function assumptions whereas Schnorr does not. What are you talking about? [Neven et al.] give a reduction for Schnorr that is, IIRC, tight for, e.g., Ed25519-SHA2-512 in the generic group model. A collision-resistant hash-function is sufficient. Chop(SHA2-512, 256), which is what Ed25510-SHA2-512 uses, satisfies a stronger property: It is indifferentiable from a random oracle. See [Coron et al.] [Neven et al.] on the randomized prefix second-preimage assumptions: "Both of the above assumptions are directly implied by the collision resistance of H, a result which we leave to the reader[.]" (Perhaps, in fact, this is not true?) And their proof obviously goes through fine with a hash function indifferentiable from a random oracle; both SHAKE and Blake2 have been designed to satisfy this property. [Coron et al.] -- However, the [Neven et al.] reduction is, I think, non-tight for Ed25519-SHA2-512's parameters with just the RO assumption. [Seurin] There are, in fact, signature schemes with tight reductions to CDH. E.g., [Katz et al.] gives a reduction for a variant of EDL-Chaum-Pedersen which is tight to CDH in the RO model; it requires hashing to a curve, but recent results have showed this can be done cheaply.[*] I'd prefer a scheme of that sort for standardization to Schnorr, especially given Seurin's meta-reduction for the latter. -- [Seurin]: http://eprint.iacr.org/2012/029 "On the exact security of Schnorr-Type signatures in the random oracle model" [Neven et al.]: http://www.neven.org/papers/schnorr.pdf "Hash function requirements for Schnorr signatures" [Katz et al.]: https://www.cs.umd.edu/~jkatz/papers/dh-sigs-full.pdf "Efficient signature schemes with tight reductions to the Diffie-Hellman problems" [Coron et al.] http://www.cs.nyu.edu/~dodis/ps/merkle.pdf "Merkle-Damgard revisited: How to construct a hash function" -- [*] The cheapest option to hash onto a curve is, perhaps, to use an IRO PRF and take the first fragment of its output that is on the curve; this is fast for all but a super-exponentially small fraction of points. (So always, in practice.) From nobody Wed Oct 29 10:53:30 2014 Return-Path: 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 ED5961A8760 for ; Wed, 29 Oct 2014 10:53:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.255 X-Spam-Level: **** X-Spam-Status: No, score=4.255 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.982, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no 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 drAL4rsNErtf for ; Wed, 29 Oct 2014 10:53:27 -0700 (PDT) Received: from aspartame.shiftleft.org (199-116-74-168-v301.PUBLIC.monkeybrains.net [199.116.74.168]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09B941A875F for ; Wed, 29 Oct 2014 10:53:27 -0700 (PDT) Received: from [192.168.1.124] (unknown [192.168.1.1]) by aspartame.shiftleft.org (Postfix) with ESMTPSA id C117AF2208; Wed, 29 Oct 2014 10:50:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=shiftleft.org; s=sldo; t=1414605038; bh=7cqucdCR6UZ/pJU2uF7tr3dgsKuoqoW5YCE/QYJSljM=; h=Date:From:To:Subject:References:In-Reply-To:From; b=SQGof75ufiB2Zt1LdYaldrq0tZujrzUqWMFplTnbbVoNrFMcpKa5Y9hwN1weEC3wo XajtdQp7DhA+dyLV5oZ0WfIUbyvKItbUM67l5SNHUyRNf6vmnVQoLp8EU0E0ZcNDjE 0dcogzD1/74EV9BGSHaRSSb0ES5y1MoA1R064ttk= Message-ID: <54512995.8040505@shiftleft.org> Date: Wed, 29 Oct 2014 10:53:25 -0700 From: Mike Hamburg User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Dan Brown , "cfrg@irtf.org" References: <810C31990B57ED40B2062BA10D43FBF5CF7EA5@XMB116CNC.rim.net> In-Reply-To: <810C31990B57ED40B2062BA10D43FBF5CF7EA5@XMB116CNC.rim.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/2WTXxil0-JfPApTRbiUsVX1FuH8 Subject: Re: [Cfrg] Terms for comparing curves and other algorithms, on the basis of security and efficiency X-BeenThere: cfrg@irtf.org 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: Wed, 29 Oct 2014 17:53:29 -0000 On 10/29/2014 08:24 AM, Dan Brown wrote: > Dear CFRG, > > I've noticed some discussions on the CFRG list about security-efficiency > tradeoffs and so on. It seems that every time the topic arises, somebody > has to explain the assumptions and so forth, all from first principles. In > some cases, I even wonder if people are talking past each other, by > misunderstanding each other's explanations and positions. In that regards, > perhaps a standardized terminology might help. > > As part of a rather rushed research report http://eprint.iacr.org/2014/877, > Appendix B, I made an effort at this, but I'll summarize the ideas here in > an email. > > First, we need to establish (non-trivial) and define some things: > - To establish absolute security and efficiency metrics, s and e (usable > across multiple algorithm types). > - To establish _defective_ security and efficiency levels, s_0, and e_0. > - To establish _saturated_ security and efficiency levels, s_1 and e_1 > (beyond which no utility is gained). > - To define _tolerable_ security and efficiency levels, as those between > defective and saturated (assuming defective is strictly less than > saturated). > - To define _work ratio_ w = se > - To define _progressive ratio_ p = log(s)e > > Next, consider two curve (or algorithm) choices with levels (s,e) and > (s',e') with it being non-trivial to determine these levels, > - If s (s',e') is obviously better. > - If both s and s' are saturated, that is, s,s'>s_1, then choose the higher > of e and e'. > - If both e and e' are saturated, that is, e,e'>e_1, then choose the higher > of s and s'. > - Otherwise, pick some ordering of e or s or w or p to maximize (i.e. a > lexicographic order). I recommend maximizing work ratio w first, then > maximizing progressive ratio p, because using s or e first risks having > small gains in one metric for large loss in the other: whereas w and p try > to balance the s and e metrics. I have a couple issues with this strategy overall. The first is that we don't know when security saturates. If attacks don't improve then Curve25519 might never fall. Bigger curves are a hedge, but it's hard to determine how much of a hedge or what its value is. Likewise e_0 and e_1 vary between users, devices and protocols. That's why multiple curves are used in practice. As for work and progressive ratios, if you aren't careful your metric will simply force a curve on one of the bounds of the e_01, s_01 rectangle, which would be OK except that we don't know e01 or s1. For example, if e ~ field order^3, so that order s ~ 2^(k/(cbrt(e))) for some constant k, then maximizing the work ratio will always lead to a curve which is as big as possible. Likewise maximizing the progressive ratio will lead to a curve which is as small as possible. Trevor and I have been ranking with an "efficiency ratio" of e (log s)^k, where the Karatsuba-2 power k = 1 + log_2(3) is roughly the trendline of the graph. This metric has no intuitive meaning in terms of security trade-offs; it just captures the practical aspect of what it means for a curve implementation to be "efficient for its size". > Also, the systems above algorithm-agnostic, so can be used to compare block > ciphers, hash functions, not just elliptic curves. > > I felt most of the above is more or less self-evident, albeit simplistic and > abstract, and is a paraphrasing of my understanding of most people's > arguments, but perhaps I am missing something (see below). > > When I tried to apply the regimen above to elliptic curve selection, I had > two problems, which make me worry that the analysis is missing something > fundamental. First, the conventional practice of offering multiple curves > sizes does not fit well into the system above: it defers too much of the > decision process to the user and seems to imply some kind of ambiguity about > the saturated security levels. Second, optimizing work ratio w seems to > favor large cofactor, which seems very strange to me, and is certainly > unconventional (though I ignored public key size in the efficiency metric). I don't think this is true. First of all, in some protocols you need to clear the cofactor, so having a huge cofactor doesn't improve efficiency at all. But even if you don't need to clear it, a big cofactor generically only helps the user by log h / log n, and hurts security by a much larger sqrt(h) factor, so it doesn't improve work ratio. It probably doesn't make a difference to progressive ratio, but a smaller field is usually going to have a better progressive ratio. > Maybe these strange discrepancies are not faults in the comparison system > above but merely discrepancies in my bounds for s_1 and e_0. For example, > perhaps my saturated security level is much higher than conventional, and my > defective efficiency is much lower than conventional. > > Returning to the issues of debates about curves on the CFRG list, if two > people have different values of, say, s_1, but don't really know it, then > they are likely to disagree on the best curve or algorithm, and perhaps not > understand why. Perhaps stating one's metrics, one's saturated and > defective levels, will help resolve some disagreements, or at least enable > better understanding of the disagreements. > > Best regards, > > Daniel Brown > Research In Motion Limited I think you're partly correct about this. Most people on this list seem to have implicitly set s0 ~ 2^128, s1 ~ 2^512, and are optimizing metrics which force curves to the edges. But given the Snowden, NSA and NIST backdrop of this discussion, there's also a NUMS component in security. And NUMS is a vague property which is hard to incorporate into a metric. CFRGers can argue all year about whether the NUMS component is maximized by 2^(2*AES security level) - (smallest), or a curve over a Mersenne prime found by 3 groups, or VPR; and if a prime constrained by high performance even counts as NUMS. -- Mike From nobody Wed Oct 29 11:53:28 2014 Return-Path: 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 34E4D1A8843 for ; Wed, 29 Oct 2014 11:53:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 1XYFgG5Kbp_v for ; Wed, 29 Oct 2014 11:53:24 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7136D1A88AD for ; Wed, 29 Oct 2014 11:53:09 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id x12so2027966wgg.3 for ; Wed, 29 Oct 2014 11:53:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=/yCEDgDaZIXTxQzG7CM7SxagHYnaG+Cnw6+wEH6TbJc=; b=dcfVQt3bgI9R/rdzzx6zNloJt0L2aVbahpV+zJVyVeYFBbGFglXHMjK59oZUKl0YcI XuSiBRy0uSQnCdjlvk99Cc8rH/Py6/14pyU38dfbq13CcD2XjxZiiYuuoDxGdznoY2I7 aTcvGl3sAscisKTpmxRPKzcmOFvHy+FobEphyrIoU59CYz0kEgJmh82JmuzxLrXAxsHG INF1oUpEhPr2mIadjt0/cf+iRDXaC3tbExQ8yfnMcjA87d1Tv2GtVcWwqJ45D5XqeoUD RWlvwB8fdsHzqtrYjFfECC0KA38npyqNY/rScUUF/XpueAiG5vtcOydi4QsSalynZgfT yWwg== X-Gm-Message-State: ALoCoQnh1NG5w7rrs/L0b33fqYB1esmu9g+rSk8/JtILVTYDtWVFrcjaQMYdcoKVGyqhC+e6Ykts X-Received: by 10.194.209.230 with SMTP id mp6mr14934795wjc.2.1414608787536; Wed, 29 Oct 2014 11:53:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.217.14.70 with HTTP; Wed, 29 Oct 2014 11:52:46 -0700 (PDT) In-Reply-To: References: <20141029042454.16752.qmail@cr.yp.to> From: Benjamin Black Date: Wed, 29 Oct 2014 11:52:46 -0700 Message-ID: To: Watson Ladd Content-Type: multipart/alternative; boundary=047d7b3a8c08471765050694467d Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/IN6n4DI7FqnEI9sWWhRbfc0qhuU Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] Actual security levels for IETF crypto X-BeenThere: cfrg@irtf.org 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: Wed, 29 Oct 2014 18:53:27 -0000 --047d7b3a8c08471765050694467d Content-Type: text/plain; charset=UTF-8 On Wed, Oct 29, 2014 at 9:42 AM, Watson Ladd wrote: > > On Oct 29, 2014 9:36 AM, "Benjamin Black" wrote: > > > > It says even your cherrypicked data tells a similar story. More than > half the US top 25 are already TLS for everything. Doesn't sound like > evidence supporting the claim that performance is the main impediment to > TLS adoption. Faster is good, but let's not delude ourselves on the impact > faster will have. > > If you think I cherrypicked, go look at all national top 25 lists, and > show the US is a laggard. Throwing out unsupported accusations of > misconduct isn't helping. > I said global top 25, you dug down to a specific country. The US is not a laggard, it is just a typical subset. Any country is going to show a larger non-TLS percentage in the top N than the global top N because you are moving further into the tail. Over time, the minimum size at which we can expect TLS deployment will continue to drop and the per-country top N stats will look more like today's global top N. The largest sites are also the most performance sensitive/conscious, yet are significantly more likely than smaller sites to use TLS for everything. Why? Site operators deploy TLS because they see business value in it, whether that value is "This is the right thing for customers" or "We must address government snooping concerns" or "I think people will trust us more if they see the little green lock in the browser bar". Without business value, it is hard to justify the resources required to enable TLS, regardless of performance. > You still haven't explained the merits of your proposal over the > counterproposal, instead choosing to double down on the "performance > doesn't matter" argument in the face of significant evidence. > I am not saying performance doesn't matter. I am saying: 1) There are other important considerations, as well. 2) There is little evidence supporting, and what I see contradicts, the claim that performance concerns are the main impediment to TLS deployment. Again, please provide this significant evidence which unambiguously shows actual, as opposed to perceived, performance concerns impeding TLS deployment today. Fast curves will change the actual performance, but they won't change the TLS is slow perception and they won't show the business value to drive deployment. > I saw the top 25 list on the Alexa site and didn't realize this was not > the global one. I then went down and looked at each site. Accidentally > using the wrong data set is not cherrypicking. > Sure. b --047d7b3a8c08471765050694467d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Oct 29, 2014 at 9:42 AM, Watson Ladd <watsonbladd@gmail.com>= ; wrote:


On Oct 29, 2014 9:36 AM, "Benjamin Black" <b@b3k.us> wrote:
>
> It says even your cherrypicked data tells a similar story. More than h= alf the US top 25 are already TLS for everything. Doesn't sound like ev= idence supporting the claim that performance is the main impediment to TLS = adoption. Faster is good, but let's not delude ourselves on the impact = faster will have.

If you think I cherrypicked, go look at all national = top 25 lists, and show the US is a laggard. Throwing out unsupported accusa= tions of misconduct isn't helping.

I said global t= op 25, you dug down to a specific country. The US is not a laggard, it is j= ust a typical subset. Any country is going to show a larger non-TLS percent= age in the top N than the global top N because you are moving further into = the tail. Over time, the minimum size at which we can expect TLS deployment= will continue to drop and the per-country top N stats will look more like = today's global top N.

The largest sites are al= so the most performance sensitive/conscious, yet are significantly more lik= ely than smaller sites to use TLS for everything. Why? Site operators deplo= y TLS because they see business value in it, whether that value is "Th= is is the right thing for customers" or "We must address governme= nt snooping concerns" or "I think people will trust us more if th= ey see the little green lock in the browser bar". Without business val= ue, it is hard to justify the resources required to enable TLS, regardless = of performance.

You still haven't explained the merits of your proposal = over the counterproposal, instead choosing to double down on the "perf= ormance doesn't matter" argument in the face of significant eviden= ce.

I am not saying performance doesn't matter. I = am saying:

1) There are other important considerat= ions, as well.
2) There is little evidence supporting, and what I= see contradicts, the claim that performance concerns are the main impedime= nt to TLS deployment.

Again, please provide this s= ignificant evidence which unambiguously shows actual, as opposed to perceiv= ed, performance concerns impeding TLS deployment today. Fast curves will ch= ange the actual performance, but they won't change the TLS is slow perc= eption and they won't show the business value to drive deployment.

I saw the top 25 list on the Alexa site and didn't reali= ze this was not the global one. I then went down and looked at each site. A= ccidentally using the wrong data set is not cherrypicking.

=
Sure.


b

--047d7b3a8c08471765050694467d-- From nobody Wed Oct 29 12:13:18 2014 Return-Path: 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 D6BBF1A88E1 for ; Wed, 29 Oct 2014 12:13:16 -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 QOUBV35fTXBK for ; Wed, 29 Oct 2014 12:13:13 -0700 (PDT) Received: from mail-yk0-x236.google.com (mail-yk0-x236.google.com [IPv6:2607:f8b0:4002:c07::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A280E1A88CE for ; Wed, 29 Oct 2014 12:13:13 -0700 (PDT) Received: by mail-yk0-f182.google.com with SMTP id q200so1584081ykb.41 for ; Wed, 29 Oct 2014 12:13:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=PVB5zXP5SuZsETmqIwKhbV3nW+ylJ3xxosT5VHqhovI=; b=vqKoi0tBxGguLYhKfIjdV31/UUD2lzqSQJV6zBbV7OHRXigTo7TG1d9+ZDJ+v5Hafz SWJlYhu+/HfFDsLjUfmIaxdDvVT15gVafK0yG0xfizV96CprKQWVMfDjJEQlO3FyDfwW bjRwvDswizqdqzTiy1SeFlqEepASB0qAAHG49jDwEzSdoDagces+zk9nbhtze/yf93ez twvbBY8RyHM2LIbBYCrXCzdl8pVx4M4bh2ehp8ee+2E/fRwR5WMvwLyTO+sim8z8Ne2u 8folRAB8Ykpa+sGnjAYnRLXqvdf1pYKABYwMqh6CwbP+rPqBJnPTb8hAralTjq9wNZR9 f5FA== MIME-Version: 1.0 X-Received: by 10.236.53.69 with SMTP id f45mr3462782yhc.65.1414609992888; Wed, 29 Oct 2014 12:13:12 -0700 (PDT) Received: by 10.170.195.149 with HTTP; Wed, 29 Oct 2014 12:13:12 -0700 (PDT) Received: by 10.170.195.149 with HTTP; Wed, 29 Oct 2014 12:13:12 -0700 (PDT) In-Reply-To: References: <20141029042454.16752.qmail@cr.yp.to> Date: Wed, 29 Oct 2014 12:13:12 -0700 Message-ID: From: Watson Ladd To: Benjamin Black Content-Type: multipart/alternative; boundary=089e0122971c1f38ce0506948e5a Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/kuUQWfcivr-J0ZulvVZ2UUjylxc Cc: cfrg@irtf.org Subject: Re: [Cfrg] Actual security levels for IETF crypto X-BeenThere: cfrg@irtf.org 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: Wed, 29 Oct 2014 19:13:17 -0000 --089e0122971c1f38ce0506948e5a Content-Type: text/plain; charset=UTF-8 On Oct 29, 2014 11:53 AM, "Benjamin Black" wrote: > > On Wed, Oct 29, 2014 at 9:42 AM, Watson Ladd wrote: >> >> >> On Oct 29, 2014 9:36 AM, "Benjamin Black" wrote: >> > >> > It says even your cherrypicked data tells a similar story. More than half the US top 25 are already TLS for everything. Doesn't sound like evidence supporting the claim that performance is the main impediment to TLS adoption. Faster is good, but let's not delude ourselves on the impact faster will have. >> >> If you think I cherrypicked, go look at all national top 25 lists, and show the US is a laggard. Throwing out unsupported accusations of misconduct isn't helping. > > I said global top 25, you dug down to a specific country. The US is not a laggard, it is just a typical subset. Any country is going to show a larger non-TLS percentage in the top N than the global top N because you are moving further into the tail. Over time, the minimum size at which we can expect TLS deployment will continue to drop and the per-country top N stats will look more like today's global top N. That seems reasonable. However, it means that the percentage of data encrypted with TLS is far below the percentage one would get from your preferred methodology. I'm starting to think that looking at the percentage of data encrypted is more useful then percentage of big sites encrypting as a result. > > The largest sites are also the most performance sensitive/conscious, yet are significantly more likely than smaller sites to use TLS for everything. Why? Site operators deploy TLS because they see business value in it, whether that value is "This is the right thing for customers" or "We must address government snooping concerns" or "I think people will trust us more if they see the little green lock in the browser bar". Without business value, it is hard to justify the resources required to enable TLS, regardless of performance. What if those resources in administrator time and effort were zero? Obviously ECDHE is one part of this: one needs to work on making the handshake more efficient. Part of the problem as I understand is that browser vendors have historically treated TLS sans certificate worse then cleartext. My potentially wrong idea was that this was being changed in http/2. But we can't all race to be the last to fix things, or nothing will ever get fixed. >> >> You still haven't explained the merits of your proposal over the counterproposal, instead choosing to double down on the "performance doesn't matter" argument in the face of significant evidence. > > I am not saying performance doesn't matter. I am saying: > > 1) There are other important considerations, as well. > 2) There is little evidence supporting, and what I see contradicts, the claim that performance concerns are the main impediment to TLS deployment. How do those other considerations support the NUMS proposal? It's not obvious they do. Furthermore, the argument is high performance is extremely demanding on curves: there aren't that many choices involved, as shown by the independent generation of the 521 bit curve. > > Again, please provide this significant evidence which unambiguously shows actual, as opposed to perceived, performance concerns impeding TLS deployment today. Fast curves will change the actual performance, but they won't change the TLS is slow perception and they won't show the business value to drive deployment. >> >> I saw the top 25 list on the Alexa site and didn't realize this was not the global one. I then went down and looked at each site. Accidentally using the wrong data set is not cherrypicking. > > Sure. > > > b > --089e0122971c1f38ce0506948e5a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Oct 29, 2014 11:53 AM, "Benjamin Black" <b@b3k.us> wrote:
>
> On Wed, Oct 29, 2014 at 9:42 AM, Watson Ladd <watsonbladd@gmail.com> wrote:
>>
>>
>> On Oct 29, 2014 9:36 AM, "Benjamin Black" <b@b3k.us> wrote:
>> >
>> > It says even your cherrypicked data tells a similar story. Mo= re than half the US top 25 are already TLS for everything. Doesn't soun= d like evidence supporting the claim that performance is the main impedimen= t to TLS adoption. Faster is good, but let's not delude ourselves on th= e impact faster will have.
>>
>> If you think I cherrypicked, go look at all national top 25 lists,= and show the US is a laggard. Throwing out unsupported accusations of misc= onduct isn't helping.
>
> I said global top 25, you dug down to a specific country. The US is no= t a laggard, it is just a typical subset. Any country is going to show a la= rger non-TLS percentage in the top N than the global top N because you are = moving further into the tail. Over time, the minimum size at which we can e= xpect TLS deployment will continue to drop and the per-country top N stats = will look more like today's global top N.

That seems reasonable. However, it means that the percentage= of data encrypted with TLS is far below the percentage one would get from = your preferred methodology. I'm starting to think that looking at the p= ercentage of data encrypted is more useful then percentage of big sites enc= rypting as a result.

>
> The largest sites are also the most performance sensitive/conscious, y= et are significantly more likely than smaller sites to use TLS for everythi= ng. Why? Site operators deploy TLS because they see business value in it, w= hether that value is "This is the right thing for customers" or &= quot;We must address government snooping concerns" or "I think pe= ople will trust us more if they see the little green lock in the browser ba= r". Without business value, it is hard to justify the resources requir= ed to enable TLS, regardless of performance.

What if those resources in administrator time and effort wer= e zero? Obviously ECDHE is one part of this: one needs to work on making th= e handshake more efficient.

Part of the problem as I understand is that browser vendors = have historically treated TLS sans certificate worse then cleartext. My pot= entially wrong idea was that this was being changed in http/2.

But we can't all race to be the last to fix things, or n= othing will ever get fixed.

>>
>> You still haven't explained the merits of your proposal over t= he counterproposal, instead choosing to double down on the "performanc= e doesn't matter" argument in the face of significant evidence. >
> I am not saying performance doesn't matter. I am saying:
>
> 1) There are other important considerations, as well.
> 2) There is little evidence supporting, and what I see contradicts, th= e claim that performance concerns are the main impediment to TLS deployment= .

How do those other considerations support the NUMS proposal?= It's not obvious they do. Furthermore, the argument is high performanc= e is extremely demanding on curves: there aren't that many choices invo= lved, as shown by the independent generation of the 521 bit curve.

>
> Again, please provide this significant evidence which unambiguously sh= ows actual, as opposed to perceived, performance concerns impeding TLS depl= oyment today. Fast curves will change the actual performance, but they won&= #39;t change the TLS is slow perception and they won't show the busines= s value to drive deployment.
>>
>> I saw the top 25 list on the Alexa site and didn't realize thi= s was not the global one. I then went down and looked at each site. Acciden= tally using the wrong data set is not cherrypicking.
>
> Sure.
>
>
> b
>

--089e0122971c1f38ce0506948e5a-- From nobody Wed Oct 29 12:34:13 2014 Return-Path: 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 BA4D21A89A3 for ; Wed, 29 Oct 2014 12:34:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 JqHv-KTJ3GWY for ; Wed, 29 Oct 2014 12:34:08 -0700 (PDT) Received: from mail-wi0-f179.google.com (mail-wi0-f179.google.com [209.85.212.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 636991A89A0 for ; Wed, 29 Oct 2014 12:34:07 -0700 (PDT) Received: by mail-wi0-f179.google.com with SMTP id h11so5547888wiw.0 for ; Wed, 29 Oct 2014 12:34:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=p+ncyDjEWfeNMgctPZo2IJkcJj2Sx8MWvW2LR8a5MjA=; b=QIO3dTaClQSXVLIIc30YRcbRP2qEjgzxA8ZaNTB8w4bAH5wDT5u+hwTQbYzNQM+JbU 3smtunCnoVJ8dSpa3AptUJiFT3yVwKIrPOQEfQbN7+tqcfk4vZqcOKglEroc+vbLbvL/ NDe2VZIAhj3/gGFJdivYa144VrH1/AoTbQl6rJSOAukpRMoUoydie4ss8Z+Zc1nkBf7O ep6V7bGVlX1v9Z/0CBWfwJsO3KeVbXBD7e3sJryIDPP/OTDLVyUiVwP6H2U9U0N0XpkQ EugJjG4yqhesHStc4/ZSAoE+Ho0t3eb58rJ5v4ckWO7J4axbk1YbDQCP0gEU5WIu2+01 flGQ== X-Gm-Message-State: ALoCoQmDqPQyWBQVLnkw+LuLfmgwb4spD0dhbpTCNnAOrYHWFeIOOQXusdQR0OXesTRX8PgHpR77 X-Received: by 10.194.81.70 with SMTP id y6mr13744282wjx.113.1414611245716; Wed, 29 Oct 2014 12:34:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.217.14.70 with HTTP; Wed, 29 Oct 2014 12:33:45 -0700 (PDT) In-Reply-To: References: <20141029042454.16752.qmail@cr.yp.to> From: Benjamin Black Date: Wed, 29 Oct 2014 12:33:45 -0700 Message-ID: To: Watson Ladd Content-Type: multipart/alternative; boundary=047d7bf0ca4acbeb14050694d8e1 Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/4VtNUOLKYwTV7Gtg7Z6TunndgZg Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] Actual security levels for IETF crypto X-BeenThere: cfrg@irtf.org 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: Wed, 29 Oct 2014 19:34:10 -0000 --047d7bf0ca4acbeb14050694d8e1 Content-Type: text/plain; charset=UTF-8 On Wed, Oct 29, 2014 at 12:13 PM, Watson Ladd wrote: > > On Oct 29, 2014 11:53 AM, "Benjamin Black" wrote: > > > > I said global top 25, you dug down to a specific country. The US is not > a laggard, it is just a typical subset. Any country is going to show a > larger non-TLS percentage in the top N than the global top N because you > are moving further into the tail. Over time, the minimum size at which we > can expect TLS deployment will continue to drop and the per-country top N > stats will look more like today's global top N. > > That seems reasonable. However, it means that the percentage of data > encrypted with TLS is far below the percentage one would get from your > preferred methodology. I'm starting to think that looking at the percentage > of data encrypted is more useful then percentage of big sites encrypting as > a result. > Percentage of traffic via TLS is a useful adoption metric, but I don't think it tells us much about what sites are or are not deploying TLS. As an example on the extreme end of the spectrum, if you looked at Chinese traffic you would see far less TLS for reasons entirely unrelated to performance or cost. > > > > The largest sites are also the most performance sensitive/conscious, yet > are significantly more likely than smaller sites to use TLS for everything. > Why? Site operators deploy TLS because they see business value in it, > whether that value is "This is the right thing for customers" or "We must > address government snooping concerns" or "I think people will trust us more > if they see the little green lock in the browser bar". Without business > value, it is hard to justify the resources required to enable TLS, > regardless of performance. > > What if those resources in administrator time and effort were zero? > Obviously ECDHE is one part of this: one needs to work on making the > handshake more efficient. > > The problems here are: 1) the administration time and effort are not zero. 2) the administration costs are likely far less than the developer and infrastructure costs. For example, without TLS I needn't concern myself with secrets management. I configure Apache to use TLS, and then I have to enter a password to decrypt the private key whenever the daemon starts. Do I store it without a password? Do I have to enter it manually? Do I have automation do it, in which case where do I store the password? It's not that these problems don't have solutions, it's that they create overhead. On the actual costs for enabling TLS there are so many details to get right. Ensuring every piece of content goes via TLS so there are no mixed content warnings and all functionality is present can be quite involved. And then, what if I am not running the latest code on my trusty F5 load balancer so I can't use ECDHE? Do I skip PFS altogether? Take the performance hit of DHE? Pay more license fees? Buy a new load balancer? These are all real problems I have personally faced repeatedly in deploying TLS and they represent, in my experience, the real impediments to deployment. > Part of the problem as I understand is that browser vendors have > historically treated TLS sans certificate worse then cleartext. My > potentially wrong idea was that this was being changed in http/2. > But we can't all race to be the last to fix things, or nothing will ever > get fixed. > Resources are limited, so we should set our priorities based on data. The data does show TLS adoption below where we all want it. It does not show that to be caused by performance concerns. > >> > >> You still haven't explained the merits of your proposal over the > counterproposal, instead choosing to double down on the "performance > doesn't matter" argument in the face of significant evidence. > > > > I am not saying performance doesn't matter. I am saying: > > > > 1) There are other important considerations, as well. > > 2) There is little evidence supporting, and what I see contradicts, the > claim that performance concerns are the main impediment to TLS deployment. > > How do those other considerations support the NUMS proposal? It's not > obvious they do. Furthermore, the argument is high performance is extremely > demanding on curves: there aren't that many choices involved, as shown by > the independent generation of the 521 bit curve. > I've said repeatedly in public and private that I am committed to an open and thorough process, regardless of the outcome. I've also said repeatedly that we should be starting from requirements and then consider _generating_ curves to meet them, rather than limiting ourselves to the curves at hand or trying to contort the requirements to match an existing favorite. b --047d7bf0ca4acbeb14050694d8e1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Oct 29, 2014 at 12:13 PM, Watson Ladd <watsonbladd@gmail.com&g= t; wrote:


On Oct 29, 2014 11:53 AM, "Benjamin Black" <b@b3k.us> wrote:
>
> I said global top 25, you dug down to a specific country. The US is no= t a laggard, it is just a typical subset. Any country is going to show a la= rger non-TLS percentage in the top N than the global top N because you are = moving further into the tail. Over time, the minimum size at which we can e= xpect TLS deployment will continue to drop and the per-country top N stats = will look more like today's global top N.

That seems reasonable. However, it means that the per= centage of data encrypted with TLS is far below the percentage one would ge= t from your preferred methodology. I'm starting to think that looking a= t the percentage of data encrypted is more useful then percentage of big si= tes encrypting as a result.

Percentage of traffic via = TLS is a useful adoption metric, but I don't think it tells us much abo= ut what sites are or are not deploying TLS. As an example on the extreme en= d of the spectrum, if you looked at Chinese traffic you would see far less = TLS for reasons entirely unrelated to performance or cost.

>
> The largest sites are also the most performance sensitive/conscious, y= et are significantly more likely than smaller sites to use TLS for everythi= ng. Why? Site operators deploy TLS because they see business value in it, w= hether that value is "This is the right thing for customers" or &= quot;We must address government snooping concerns" or "I think pe= ople will trust us more if they see the little green lock in the browser ba= r". Without business value, it is hard to justify the resources requir= ed to enable TLS, regardless of performance.

What if those resources in administrator time and eff= ort were zero? Obviously ECDHE is one part of this: one needs to work on ma= king the handshake more efficient.

The problems here are:

<= /div>
1) the administration time and effort are not zero.
2) = the administration costs are likely far less than the developer and infrast= ructure costs.=C2=A0

For example, without TLS I ne= edn't concern myself with secrets management. I configure Apache to use= TLS, and then I have to enter a password to decrypt the private key whenev= er the daemon starts. Do I store it without a password? Do I have to enter = it manually? Do I have automation do it, in which case where do I store the= password? It's not that these problems don't have solutions, it= 9;s that they create overhead.=C2=A0

On the actual= costs for enabling TLS there are so many details to get right. Ensuring ev= ery piece of content goes via TLS so there are no mixed content warnings an= d all functionality is present can be quite involved. And then, what if I a= m not running the latest code on my trusty F5 load balancer so I can't = use ECDHE? Do I skip PFS altogether? Take the performance hit of DHE? Pay m= ore license fees? Buy a new load balancer?

These a= re all real problems I have personally faced repeatedly in deploying TLS an= d they represent, in my experience, the real impediments to deployment.

Part of the problem as I un= derstand is that browser vendors have historically treated TLS sans certifi= cate worse then cleartext. My potentially wrong idea was that this was bein= g changed in http/2.

But we can't all race to be the last to fix things, or n= othing will ever get fixed.

Resources are limited, so = we should set our priorities based on data. The data does show TLS adoption= below where we all want it. It does not show that to be caused by performa= nce concerns.=C2=A0

>>
>> You still haven't explained the merits of your proposal over t= he counterproposal, instead choosing to double down on the "performanc= e doesn't matter" argument in the face of significant evidence. >
> I am not saying performance doesn't matter. I am saying:
>
> 1) There are other important considerations, as well.
> 2) There is little evidence supporting, and what I see contradicts, th= e claim that performance concerns are the main impediment to TLS deployment= .

How do those other considerations support the NUMS pr= oposal? It's not obvious they do. Furthermore, the argument is high per= formance is extremely demanding on curves: there aren't that many choic= es involved, as shown by the independent generation of the 521 bit curve.

I've said repeatedly in public and private that I a= m committed to an open and thorough process, regardless of the outcome. I&#= 39;ve also said repeatedly that we should be starting from requirements and= then consider _generating_ curves to meet them, rather than limiting ourse= lves to the curves at hand or trying to contort the requirements to match a= n existing favorite.


b
--047d7bf0ca4acbeb14050694d8e1-- From nobody Wed Oct 29 12:47:21 2014 Return-Path: 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 7546F1A8A44 for ; Wed, 29 Oct 2014 12:47:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.101 X-Spam-Level: X-Spam-Status: No, score=0.101 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, UNPARSEABLE_RELAY=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 bN_kug3Ql0lC for ; Wed, 29 Oct 2014 12:47:16 -0700 (PDT) Received: from mace.cs.uic.edu (mace.cs.uic.edu [131.193.32.224]) by ietfa.amsl.com (Postfix) with SMTP id D321F1A8A29 for ; Wed, 29 Oct 2014 12:47:15 -0700 (PDT) Received: (qmail 18601 invoked by uid 1011); 29 Oct 2014 19:47:11 -0000 Received: from unknown (unknown) by unknown with QMTP; 29 Oct 2014 19:47:11 -0000 Received: (qmail 5995 invoked by uid 1001); 29 Oct 2014 19:47:08 -0000 Date: 29 Oct 2014 19:47:08 -0000 Message-ID: <20141029194708.5993.qmail@cr.yp.to> From: "D. J. Bernstein" To: cfrg@irtf.org Mail-Followup-To: cfrg@irtf.org In-Reply-To: <810FD859-5CE9-4163-9749-973ED4F810CA@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/lObDaCSu4E72LVs7LIS0iW4aIms Subject: Re: [Cfrg] Actual security levels for IETF crypto X-BeenThere: cfrg@irtf.org 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: Wed, 29 Oct 2014 19:47:18 -0000 Yoav Nir writes: > As the IETF or the IRTF all we can ever do is publish RFCs > recommending this or that. What is deployed is not up to us. [ ... ] > So no, we don’t recommend 90-bit security for DNSSEC I have bad news for you: IETF has always recommended, and continues to recommend, security levels of 2^90 or lower for DNSSEC. RFC 2541 (March 1999) stated that "larger keys are more secure" but "slower" and more of a bandwidth problem. It recommended a "minimum algorithm modulus size" of "704 bits". For comparison, my recollection is that actual early-2000s DNSSEC software documentation used 768 bits. RFC 4641 (September 2006) again pointed to performance costs ("sizes" and "time"---"don't needlessly double your key sizes"). It recommended "1024 bits for low-value domains, 1300 bits for medium-value domains, and 2048 bits for high-value domains" for key-signing keys, and "about 100 bits" fewer for zone-signing keys. RFC 6781 (December 2012, current) again points to performance and claims that "most zones can safely use 1024-bit keys for at least the next ten years". What's actually deployed today, as I mentioned before, is mostly a mix of 1024-bit RSA and 1280-bit RSA for TLD zone-signing keys. (The key-signing keys tend to be much larger, an interesting example of users happily pumping up the security when the speed doesn't matter.) I'm pointing to DNSSEC because its performance problems are particularly clear, but there are many other IETF documents complaining about crypto performance and suggesting many different security levels. The smaller recommended levels, and the smaller deployed levels, have always ignored clear earlier warnings in the cryptographic literature. Security is job #1, and I think everyone agrees that CFRG shouldn't even consider curves that don't improve upon the RSA-2048 security level. But this doesn't mean that CFRG should blithely ignore the performance constraints that have led to low security levels in IETF documents _and_ in real deployments. It's clear that paying attention to the "Powers of 2!" marketing department would seriously damage the tradeoffs available between speed and security---and it's quite difficult to believe that this is what the TLS WG wanted from CFRG. Benjamin Black writes, regarding HTTPS: > Why might Amazon and eBay not bother with it? Amazon _did_ bother fully configuring HTTPS---and then configured _redirections_ from HTTPS back to HTTP for the vast majority of its web pages. For example, https://www.amazon.com/No-Place-Hide-Snowden-Surveillance/dp/162779073X redirects to http://www.amazon.com/No-Place-Hide-Snowden-Surveillance/dp/162779073X rather than simply providing the same data through HTTPS. The typical URLs on that page are of course HTTP rather than HTTPS, so subsequent clicks will be much cheaper for Amazon's servers, and since the active redirection kills all security there's no real incentive for users to start with HTTPS in the first place. The cost consequences are clear. Amazon is making HTTPS URLs work not in the easiest way, and of course not in a secure way, but in the way that ends up being cheapest for Amazon's servers. If you think that there's a plausible alternative reason for Amazon to have set up these HTTPS-to-HTTP redirects, feel free to say what that reason is. Similarly, if you don't think that dnssec-deployment.org chose a 1024-bit zone-signing key for performance reasons, feel free to present your alternative explanation. > I've seen people refuse to deploy TLS because they don't want to pay > for certificates, because they were put off by the perceived > complexity, So you think Amazon didn't pay for a certificate, or was put off by the perceived complexity? Do you understand that https://www.amazon.com is in fact talking HTTPS to the browser? > youtube.com - TLS YouTube is an obvious surveillance target (e.g., named as an NSA PRISM partner) for essentially all of the reasons that it is a censorship target (see http://en.wikipedia.org/wiki/Censorship_of_YouTube), and is a subsidiary of Google, which has been pushing fairly hard for nuking HTTP in favor of HTTPS. So one would certainly _expect_ a redirection from http://www.youtube.com to https://www.youtube.com. However, I just connected to http://www.youtube.com and was _not_ redirected to https://www.youtube.com. I also tried various subpages, again finding no redirections to HTTPS. In this case, unlike Amazon, HTTPS doesn't redirect back to HTTP. So it's possible that most YouTube users are using HTTPS. But you haven't provided any evidence for this. You seem to have a very strange notion of "deploy TLS" where setting up a TLS server constitutes success, no matter how little traffic is actually being encrypted---so obviously you aren't seeing what the performance impact of full HTTPS would be. > Are you saying MSN isn't HTTPS today because of performance concerns > or that people often don't know or care if their traffic is encrypted? There _is_ an https://www.msn.com. It successfully negotiates HTTPS with my browser and sends a web page---namely an error message with a manual redirect to HTTP. Earlier you wrote "While many individuals might express performance as a reason for not deploying TLS, sites which represent the vast majority of HTTP and SMTP user traffic are few and universally deploy TLS." Surely you can see that some explanation is required. Whether or not you're counting MSN as part of "the vast majority of HTTP user traffic", would you claim that MSN "deploys TLS"? How do you explain MSN going through all the work to set up an HTTPS server but then having the server produce this error message? > A one hour trace from one location showing bits/sec is not sufficient > data to make claims about growth or relative scale. It's publicly verifiable data at a typical link, accompanied by similar traces from many other time periods, and it's obviously enough to put the ball in your court. Do you have _any_ publicly verifiable evidence to support your picture of HTTPS dominating total web traffic? ---Dan From nobody Wed Oct 29 12:48:30 2014 Return-Path: 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 186261A8989 for ; Wed, 29 Oct 2014 12:48:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.207 X-Spam-Level: X-Spam-Status: No, score=-4.207 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=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 vXO45nGODf-G for ; Wed, 29 Oct 2014 12:48:22 -0700 (PDT) Received: from mx1.ll.mit.edu (MX1.LL.MIT.EDU [129.55.12.45]) by ietfa.amsl.com (Postfix) with ESMTP id D148C1A8A6D for ; Wed, 29 Oct 2014 12:48:21 -0700 (PDT) Received: from LLE2K10-HUB01.mitll.ad.local (LLE2K10-HUB01.mitll.ad.local) by mx1.ll.mit.edu (unknown) with ESMTP id s9TJmKPK019608 for ; Wed, 29 Oct 2014 15:48:20 -0400 From: "Blumenthal, Uri - 0558 - MITLL" To: "cfrg@irtf.org" Thread-Topic: [Cfrg] Actual security levels for IETF crypto Thread-Index: AQHP8kclyBJktumKTkOlVDCBDIGoOpxFPp0AgAARAgCAANRggIAAmxQAgAAoYgCAAHnegIAAJOKAgAABMYCAAAPrgIAAAdGAgAAkbACAAAW1AIAABb6A///Az4A= Date: Wed, 29 Oct 2014 19:48:20 +0000 Message-ID: References: <20141029042454.16752.qmail@cr.yp.to> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-originating-ip: [172.25.177.187] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3497442455_6533939" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.28, 0.0.0000 definitions=2014-10-29_07:2014-10-28,2014-10-29,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1410290194 Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/91dWfd6_nDp8MKAbw4DBP5jcXI0 Subject: Re: [Cfrg] Actual security levels for IETF crypto X-BeenThere: cfrg@irtf.org 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: Wed, 29 Oct 2014 19:48:26 -0000 --B_3497442455_6533939 Content-type: multipart/alternative; boundary="B_3497442455_6568085" --B_3497442455_6568085 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit > I've also said repeatedly that we should be starting from requirements and > then consider _generating_ curves to meet them, rather than limiting ourselves > to the curves at hand or trying to contort the requirements to match an > existing favorite. Strongly +1 --B_3497442455_6568085 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable
 I've also said repeat= edly that we should be starting from requirements and then consider _generat= ing_ curves to meet them, rather than limiting ourselves to the curves at hand or trying to contort the req= uirements to match an existing favorite.
=

Strongly +1
--B_3497442455_6568085-- --B_3497442455_6533939 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIUOAYJKoZIhvcNAQcCoIIUKTCCFCUCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGgghIHMIIE6jCCA9KgAwIBAgIKH0XZoAAAAAABzTANBgkqhkiG9w0BAQsFADBRMQswCQYD VQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJ MRMwEQYDVQQDEwpNSVRMTCBDQS0zMB4XDTE0MDQxNjIxNTMwMloXDTE1MDQxNjIxNTMwMlow YTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNV BAsTBlBlb3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQCx/gK75UYos2g8JavX0BVfe3TCGsmjQY34z9ZVeucP 8dGtqRA8T5i1OKdf++Jd81a0/qQA6mIGyzTW6lOtY+77qKUJtEeLM5URd+iv2EejAwxsa2B5 pMq9L9qWuVokR1rTEfEcuUeKR1Kko6xmRE/y6AzBnUhTvHx2X9F6JSVdR36Lx3R62CNeQqFi ZDeHuTI8AhRY4UdPkri1FTDxV6gLYaLKxsGIurrL/6EzdlkX8ImTcxKzEmxX1VjTPy9ZRNYj akDGcJF9clCfcwbq3DI3gAUkVxXf+UbHEjzOCVNQcoga7bYbBUuDpN25Lc86P9RaOiiICtyu ZZP2P/2kkKYRAgMBAAGjggGyMIIBrjAdBgNVHQ4EFgQUEN9QHIi9GvlGjs9Th46jrfPir+Uw DgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1Ud HwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYB BQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExD QTMwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3 FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+KcwIBZAIBBTAi BgNVHSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAYBgNVHSAEETAPMA0GCyqGSIb3 EgIBAwEIMBkGA1UdEQQSMBCBDnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABM AFUAcwBlAHIAUwBpAGcALQBTAFcwDQYJKoZIhvcNAQELBQADggEBAL2kCh9ovO8AbHgAVU6T eH5qRmKnOrfTUfn9JnHzkspdWMQA1IdtftSpiZZ7C3lCmblSDCgPqbQl4zMZxXeTgxnQsB6m 1LA6uDHM/0G27RcOJH4OTN9sQ0/2CKb4JPIXXIps1z+s8XjSRzPJZuD8fPC8R8QWvOH3owL2 BLzZebZTOMa5yws3kohY02vP/Clv0KQXYVzUZUYXoYmhUSYmQ1UZZZSFJ2rNdgNn0z8fPrUQ NIYlVaJV0kKQYjlHWTfomVapLEfIY7xRHZy9g997IjYReD0t9IZd6tTwcJES+2ijFM8l/fxk u/cQ4WCYyI+58DaBaV9p68/AC147b0HhvLUwggS8MIIDpKADAgECAgEpMA0GCSqGSIb3DQEB BQUAMFQxCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQww CgYDVQQLEwNQS0kxFjAUBgNVBAMTDU1JVExMIFJvb3QgQ0EwHhcNMTMxMjE3MDAwMDAwWhcN MjAxMjMxMjM1OTU5WjBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFi b3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2jBSdW18tuW1tNxG6h8B0kqckFZQAAtoHCkvUpUEX6jF vBd8mQI53GyLYRuAo4HWJpe7/izFXOfSJDs6UM5ovvCOfXg2bJgDYlBC9JDcLBFIn0nppOu9 RvpjWSixtC56crwJ5Us5QPdtxtKdek5LJXl2oKw3w8lihUixePbxWad1m7ZMKKagvm9zTybP 6FumKRxeYJjSpB2+cAYjoGGEbSVHyx8uzHm6xAoBMHxa8by+yDz8Jzk6sP9iilgP3iXSGoCA mhyBzvlQQ5QNNWP+Emo9jz/ukKhYVB/VwdxtoquPAqn4ifDAIaM9dtb05cy1gXAFSP3Z/iUk xyBZZUORfwIDAQABo4IBmjCCAZYwEgYDVR0TAQH/BAgwBgEB/wIBADAdBgNVHQ4EFgQU12Bm DntJjXVMDf3PRt7IxxKHyr8wHwYDVR0jBBgwFoAUZ6p6z/QKprlytYqg0p3yEMND7SkwDgYD VR0PAQH/BAQDAgGGMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0cDovL2NybC5s bC5taXQuZWR1L2dldHRvP0xMUkNBMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5sbC5taXQu ZWR1L29jc3AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNy bD9MTFJDQTCBkgYDVR0gBIGKMIGHMA0GCyqGSIb3EgIBAwEGMA0GCyqGSIb3EgIBAwEIMA0G CyqGSIb3EgIBAwEHMA0GCyqGSIb3EgIBAwEJMA0GCyqGSIb3EgIBAwEKMA0GCyqGSIb3EgIB AwELMA0GCyqGSIb3EgIBAwEOMA0GCyqGSIb3EgIBAwEPMA0GCyqGSIb3EgIBAwEQMA0GCSqG SIb3DQEBBQUAA4IBAQAsf9HBn72qU7UTgkxarjAc7iynhcDEgWwezYKtd/SLGSQ0DhtzIV/L TCxqULjOd+H+HTqMJXB8+nHnzhyqQ43RsnGZOFT5RfzPh94db/ZJ3ql244DwlJI7yXBA2DkZ cEEgOWC9bHcrElzU6NnigahSW5odVJrhmH/XhQAcMS77E5H62yyxK1WPPgcBipGVnu1xSHbT iHe7DqfWQ2tVMLUf23XYhIua94kJsQd4jSh71NVD0e7F4snAoqQMI98MzDYeLOkjlzKRs77r /aMsPAKx6nMaOvRL7Cy0Pjp51i2qFkbGmX8ofnh2kerjTTvRJ/g22r1MV8RR1PktjMsNOsPf MIIDgzCCAmugAwIBAgIBATANBgkqhkiG9w0BAQUFADBUMQswCQYDVQQGEwJVUzEfMB0GA1UE ChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRYwFAYDVQQDEw1NSVRM TCBSb290IENBMB4XDTA4MDkyMzEyMDAwMFoXDTI5MTIzMTIzNTk1OVowVDELMAkGA1UEBhMC VVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTEWMBQG A1UEAxMNTUlUTEwgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMVO KRdYsiay+a2Kv1wQCoPd5AkwExuwcNDRhaRCdQN17K+lCCKvf9VSQToAsA6q1bACtZUcMv5Z Kx8z5KG4jK9cM40NvEkf/bIOZAHJqzKgWG3N9NqrcAhimcXTXYQIdp1DgjtdADKVLAjXaYpD 2PbpE/JbAPnqKzOENa3Py9CegB0abTlOyLgwXWY/rXTW+4L/hipJ6+sI/ZtrFRmsKGhuwAKo bFr0FDP6uIfx+RaWJcJ1QBIdgM4aohvW8JeriSSMyf/LlFpXTZFcM9SOX0f7wmsYi1yFuKFM nQbkSkxvnpBKMRxrg+98seSbbEnIkvB0C9qBDPLb/lQAvmpW6oMCAwEAAaNgMF4wDwYDVR0T AQH/BAUwAwEB/zAdBgNVHQ4EFgQUZ6p6z/QKprlytYqg0p3yEMND7SkwHwYDVR0jBBgwFoAU Z6p6z/QKprlytYqg0p3yEMND7SkwCwYDVR0PBAQDAgGGMA0GCSqGSIb3DQEBBQUAA4IBAQA+ G20FYNB4eNhKWF+PyT5DUtzlABFkf2IM2VGNUBova0GeKX3I1Nf02qDU/GO2H9ETvnvTYhvf gQ4UB/5EImTkKPa7/TVG/MQ7SgmAmne8xELVbGLFrrytly8PyYtZtngb6DgeEUv+SwFnzcLO 1vg1rdmss3kwsqy0q8e2VYAY8zTptEzyJG36aXcIMbqOxWS/LbPjNuPdgJfO3d1WrHr1Etaa a0QRLqQoZj07dYY7Wo5EDqU+AUAMz9ZVRGK1s5b/jv5Wz/YroyqWFnH2KkNxRn9+2Ar7g3rn rOMZvp6psq2jbDXiPBod1wyMKn8x5y4cuGPNFcqjfyY/HX90ivQAMIIEzjCCA7agAwIBAgIK PVEvPAAAAACTsDANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlU IExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0y MB4XDTE0MDIxMjE4NTMwMVoXDTE1MDIxMjE4NTMwMVowYTELMAkGA1UEBhMCVVMxHzAdBgNV BAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsTBlBlb3BsZTEgMB4GA1UEAxMX Qmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCKHhhu75bRiOvWhbZ//TxS76yI2d+rHN2s8bp8wxW8oMjmsaplLeGQusUFRyRNSkfYtdB4 YApjnV6TCxS0Mqzly5BaoeZWoP+CbbMDNGYMszus9iFj22SSlTzGRo+gaL6rqsDKdwDOzs3C PYqh4Uu8sLzEq+QD9rhqAuMJ76635JKWELxK0uDehpNBMCGqVeAY8ht5u2h4ojPdwiuDQDW2 QxWRJjPDL8n1JczuEHY71jHldER3b2+UhpDDYRQ9aVOiGCjW8BwJOruVsBfLNxyDxgffNQ1D 1konuneMpL9H2S8ciHOdy5+Gi7snCQJ+7w30rIJ2NTldWaY6avZAaCa3AgMBAAGjggGWMIIB kjAdBgNVHQ4EFgQUZ7oGjnu6gWRmom/4UswgdVBW/3wwDgYDVR0PAQH/BAQDAgUgMB8GA1Ud IwQYMBaAFI5KfYmhYxccgYg0VzcmRV4Zin4kMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9j cmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTIwYgYIKwYBBQUHAQEEVjBUMC0GCCsGAQUFBzAC hiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTIwIwYIKwYBBQUHMAGGF2h0dHA6 Ly9vY3NwLmxsLm1pdC5lZHUvMAwGA1UdEwEB/wQCMAAwPQYJKwYBBAGCNxUHBDAwLgYmKwYB BAGCNxUIg4PlHYfsp2aGrYcVg+rwRYW2oR8dhevQcIPr7SACAWQCAQQwJQYDVR0lBB4wHAYE VR0lAAYIKwYBBQUHAwQGCisGAQQBgjcKAwQwGAYDVR0gBBEwDzANBgsqhkiG9xICAQMBCDAZ BgNVHREEEjAQgQ51cmlAbGwubWl0LmVkdTANBgkqhkiG9w0BAQsFAAOCAQEAJiU3WfJ9GvGJ iDNPClLazyh252wxxOc/TmClMKtyqHnbFObDEoXAMaoHGxrvs+lU8fU2F2ELpV8q8eYgqLLw 7PG09z5s/GkajlxVZ/FHj/9hNHTfwlicrCRY3zrna1GbOMZgWFz8R6akAoLKpqGulNrvjvU8 c63U+JVmgJmBPCMv5JlH10m87+WPJ+ToK0m4XfZjl7n5OKDJ/hOyBwbBntc+W2gDppfR1BCt DNfEG0+zHjFqF+Of1Q5NI5abhgvw5IEuVA1M4SV/utwmmdreBEv/YuLnDd/PhVgQwp3LHGCX X1dANyiKso2aACl9jrkylq39cA/WgvAlS21w9vxVpDGCAfUwggHxAgEBMF8wUTELMAkGA1UE BhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTET MBEGA1UEAxMKTUlUTEwgQ0EtMwIKH0XZoAAAAAABzTANBglghkgBZQMEAgEFAKBpMC8GCSqG SIb3DQEJBDEiBCDugBbv7NhaT7KfAwHtMU800SiEoBSJlhBlS6JVtxw2MDAYBgkqhkiG9w0B CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNDEwMjkxOTQ3MzVaMA0GCSqGSIb3 DQEBAQUABIIBAHA9cA9qo48SC40XyKMexe4KxDA9UjJEXARFBo7yfRdztR0vVab5JY2xU422 s3ifKh/lt1q9mZFYXAPf56M3QGXrmYcuCbuOSjb1QNtya7ZDtZMe8eJpiu371AiOq5eYBhAS 4jZpZvoi44jp0dRmt6UjJfM6WxIj7eKXKdFLOWngp3Ybwbk3bnkzhchN4wJu3eYAlKluvm0e 2qVJX8P2Rr4gxVhZUAnszUhTyfffP0jVRQi3LNngyF6M5FnKQzBusDpvTYv8v20ZnLcnrP/b Kqf7XHVTTqM6KRR3ZzlpqvJCTvqy9hyPOOe0aKNxAhS5x7kkmEqP6e8nnU2KKD2C7Ho= --B_3497442455_6533939-- From nobody Wed Oct 29 13:46:47 2014 Return-Path: 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 AF9A21A8AD0 for ; Wed, 29 Oct 2014 13:46:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 EZdmljP_-Ua1 for ; Wed, 29 Oct 2014 13:46:44 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 715DF1A8987 for ; Wed, 29 Oct 2014 13:46:43 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id bs8so2810310wib.5 for ; Wed, 29 Oct 2014 13:46:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type; bh=0gNtqdOmmYEYzpF0ipAk0u9HX8cYOyrywYW5qTCsIYU=; b=lKVl0eScnHHPjg8Js4ywApbb+p1/cqaLYKRKLGsBVdXwBh02CrAuoi2mnc2BvgG4Tb nEalOmpyFUpbXtPyferDcSJbkq9leuABm2KynWcGpzTIu6d7X/t5Hk9/isNoJ2dol2+4 gfKBSb8CZ9uem2q3GcPWMDd6q9XCmdVvY6nExvK9sO30Dx9yzebiQU64r+igKo+n/NiT EtWASJUrqjqQBuPTzTSNQNYRdTjFu/hpmWtFNI/EqWX3ZjSSMOS83GCwB32uiJQLZI27 u+j90D4r2fjHbSJIhqynwtRWIP0vANjMSFvuiLXVCZxP4/OUommOZJeQPnWOpts8Ltf+ v+5Q== X-Gm-Message-State: ALoCoQl4nzlc2kTAyYRq9tt+5r8Bi3PiO8xc7skP5sLPk8TT2VA4o/F5lkeRXh/GhhB39zDznyWG X-Received: by 10.194.242.4 with SMTP id wm4mr14977799wjc.61.1414615601991; Wed, 29 Oct 2014 13:46:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.217.14.70 with HTTP; Wed, 29 Oct 2014 13:46:21 -0700 (PDT) In-Reply-To: <20141029194708.5993.qmail@cr.yp.to> References: <810FD859-5CE9-4163-9749-973ED4F810CA@gmail.com> <20141029194708.5993.qmail@cr.yp.to> From: Benjamin Black Date: Wed, 29 Oct 2014 13:46:21 -0700 Message-ID: To: "cfrg@irtf.org" Content-Type: multipart/alternative; boundary=089e01419af6736f5f050695dc4c Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/Mqm4oCr1LFxFscSb58SPmL_JeZU Subject: Re: [Cfrg] Actual security levels for IETF crypto X-BeenThere: cfrg@irtf.org 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: Wed, 29 Oct 2014 20:46:46 -0000 --089e01419af6736f5f050695dc4c Content-Type: text/plain; charset=UTF-8 On Wed, Oct 29, 2014 at 12:47 PM, D. J. Bernstein wrote: > > Benjamin Black writes, regarding HTTPS: > > Why might Amazon and eBay not bother with it? > > Amazon _did_ bother fully configuring HTTPS---and then configured > _redirections_ from HTTPS back to HTTP for the vast majority of its > web pages. For example, > > https://www.amazon.com/No-Place-Hide-Snowden-Surveillance/dp/162779073X > > redirects to > > http://www.amazon.com/No-Place-Hide-Snowden-Surveillance/dp/162779073X > > rather than simply providing the same data through HTTPS. The typical > URLs on that page are of course HTTP rather than HTTPS, so subsequent > clicks will be much cheaper for Amazon's servers, and since the active > redirection kills all security there's no real incentive for users to > start with HTTPS in the first place. > The cost consequences are clear. Amazon is making HTTPS URLs work not in > the easiest way, and of course not in a secure way, but in the way that > ends up being cheapest for Amazon's servers. > If you think that there's a plausible alternative reason for Amazon to > have set up these HTTPS-to-HTTP redirects, feel free to say what that > reason is. > Usability and discoverability. Amazon wants to ensure that, to the extent possible, regardless of what users type into the browser to find a thing on Amazon, they find that thing. This discoverability in turn maximizes opportunities for purchases. Converting to have everything served over HTTPS would be an involved process to ensure all content and all dependencies are also HTTPS and that all features and scenarios work as expected. The additional infrastructure cost for HTTPS would be noise. > > > I've seen people refuse to deploy TLS because they don't want to pay > > for certificates, because they were put off by the perceived > > complexity, > > So you think Amazon didn't pay for a certificate, or was put off by the > perceived complexity? Do you understand that https://www.amazon.com is > in fact talking HTTPS to the browser? > > As I said previously, Amazon has no compelling business reason to deploy TLS for all pages, so they don't do it. It really is that simple. If that changes, they will deploy it, regardless of the performance. > > youtube.com - TLS > > YouTube is an obvious surveillance target (e.g., named as an NSA PRISM > partner) for essentially all of the reasons that it is a censorship > target (see http://en.wikipedia.org/wiki/Censorship_of_YouTube), and is > a subsidiary of Google, which has been pushing fairly hard for nuking > HTTP in favor of HTTPS. So one would certainly _expect_ a redirection > from http://www.youtube.com to https://www.youtube.com. > > However, I just connected to http://www.youtube.com and was _not_ > redirected to https://www.youtube.com. I also tried various subpages, > again finding no redirections to HTTPS. > > You were not redirected because you were not logged in. If you are logged into Google, Youtube HTTP redirects to HTTPS. https://support.google.com/youtube/answer/2985327?hl=en In this case, unlike Amazon, HTTPS doesn't redirect back to HTTP. So > it's possible that most YouTube users are using HTTPS. But you haven't > provided any evidence for this. If they are logged in, they get HTTPS. I have no data on what percentage of Youtube pages are served to logged in users. I would be pleasantly surprised if Google shared that information. You seem to have a very strange notion > of "deploy TLS" where setting up a TLS server constitutes success, no > matter how little traffic is actually being encrypted---so obviously you > aren't seeing what the performance impact of full HTTPS would be. > > That is not my definition, as explained above. > > Are you saying MSN isn't HTTPS today because of performance concerns > > or that people often don't know or care if their traffic is encrypted? > > There _is_ an https://www.msn.com. It successfully negotiates HTTPS with > my browser and sends a web page---namely an error message with a manual > redirect to HTTP. > > Earlier you wrote "While many individuals might express performance as a > reason for not deploying TLS, sites which represent the vast majority of > HTTP and SMTP user traffic are few and universally deploy TLS." > > Surely you can see that some explanation is required. Whether or not > you're counting MSN as part of "the vast majority of HTTP user traffic", > would you claim that MSN "deploys TLS"? How do you explain MSN going > through all the work to set up an HTTPS server but then having the > server produce this error message? > > I would not claim that MSN deploys TLS today. I would claim that its not having TLS deployed today is not due to performance. > > A one hour trace from one location showing bits/sec is not sufficient > > data to make claims about growth or relative scale. > > It's publicly verifiable data at a typical link, accompanied by similar > traces from many other time periods, and it's obviously enough to put > the ball in your court. Do you have _any_ publicly verifiable evidence > to support your picture of HTTPS dominating total web traffic? > > Your data does not support the claim that performance is the limiting factor in TLS deployment. Please provide such data or stop making the claim. b --089e01419af6736f5f050695dc4c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Oct 29, 2014 at 12:47 PM, D. J. Bernstein <djb@cr.yp.to> wrot= e:
Benjamin Black writes, regarding HTTPS:
> Why might Amazon and eBay not bother with it?

Amazon _did_ bother fully configuring HTTPS---and then configured _redirections_ from HTTPS back to HTTP for the vast majority of its
web pages. For example,

=C2=A0 =C2=A0https://www.amazon.com/No-Place-Hid= e-Snowden-Surveillance/dp/162779073X

redirects to

=C2=A0 =C2=A0http://www.amazon.com/No-Place-Hide-= Snowden-Surveillance/dp/162779073X

rather than simply providing the same data through HTTPS. The typical
URLs on that page are of course HTTP rather than HTTPS, so subsequent
clicks will be much cheaper for Amazon's servers, and since the active<= br> redirection kills all security there's no real incentive for users to start with HTTPS in the first place.=C2=A0

The cost consequences are clear. Amazon is making HTTPS URLs work not in the easiest way, and of course not in a secure way, but in the way that
ends up being cheapest for Amazon's servers.=C2=A0
=C2=A0
If you think that there's a plausible alternative reason for Amazon to<= br> have set up these HTTPS-to-HTTP redirects, feel free to say what that
reason is.

Usability and discoverabili= ty. Amazon wants to ensure that, to the extent possible, regardless of what= users type into the browser to find a thing on Amazon, they find that thin= g. This discoverability in turn maximizes opportunities for purchases. Conv= erting to have everything served over HTTPS would be an involved process to= ensure all content and all dependencies are also HTTPS and that all featur= es and scenarios work as expected.

The additional = infrastructure cost for HTTPS would be noise.
=C2=A0

> I've seen people refuse to deploy TLS because they don't want = to pay
> for certificates, because they were put off by the perceived
> complexity,

So you think Amazon didn't pay for a certificate, or was put off= by the
perceived complexity? Do you understand that https://www.amazon.com is
in fact talking HTTPS to the browser?


As I said previously, Amazon has no co= mpelling business reason to deploy TLS for all pages, so they don't do = it. It really is that simple. If that changes, they will deploy it, regardl= ess of the performance.
=C2=A0
> youtube.com - TLS=

YouTube is an obvious surveillance target (e.g., named as an NSA PRISM
partner) for essentially all of the reasons that it is a censorship
target (see http://en.wikipedia.org/wiki/Censorship_of_YouTube), = and is
a subsidiary of Google, which has been pushing fairly hard for nuking
HTTP in favor of HTTPS. So one would certainly _expect_ a redirection
from http://www.youtub= e.com to https://= www.youtube.com.

However, I just connected to http://www.youtube.com and was _not_
redirected to https:/= /www.youtube.com. I also tried various subpages,
again finding no redirections to HTTPS.


You were not redirected because you we= re not logged in. If you are logged into Google, Youtube HTTP redirects to = HTTPS.
=C2=A0

In this case, unlike Amazon, HTTPS doesn't redirect back to HTTP. So it's possible that most YouTube users are using HTTPS. But you haven= 9;t
provided any evidence for this.

If th= ey are logged in, they get HTTPS. I have no data on what percentage of Yout= ube pages are served to logged in users. I would be pleasantly surprised if= Google shared that information.=C2=A0

You seem to have a very strange notion
of "deploy TLS" where setting up a TLS server constitutes success= , no
matter how little traffic is actually being encrypted---so obviously you aren't seeing what the performance impact of full HTTPS would be.


That is not my= definition, as explained above.
=C2=A0
> Are you saying MSN isn't HTTPS today because of performance concer= ns
> or that people often don't know or care if their traffic is encryp= ted?

There _is_ an http= s://www.msn.com. It successfully negotiates HTTPS with
my browser and sends a web page---namely an error message with a manual
redirect to HTTP.

Earlier you wrote "While many individuals might express performance as= a
reason for not deploying TLS, sites which represent the vast majority of HTTP and SMTP user traffic are few and universally deploy = TLS."

Surely you can see that some explanation is required. Whether or not=
you're counting MSN as part of "the vast majority of HTTP user tra= ffic",
would you claim that MSN "deploys TLS"? How do you explain MSN go= ing
through all the work to set up an HTTPS server but then having the
server produce this error message?


I would not cl= aim that MSN deploys TLS today. I would claim that its not having TLS deplo= yed today is not due to performance.
=C2=A0
> A one hour trace from one location showing bits/sec is not sufficient<= br> > data to make claims about growth or relative scale.

It's publicly verifiable data at a typical link, accompanied by = similar
traces from many other time periods, and it's obviously enough to put the ball in your court. Do you have _any_ publicly verifiable evidence
to support your picture of HTTPS dominating total web traffic?


Your data does not support the claim t= hat performance is the limiting factor in TLS deployment. Please provide su= ch data or stop making the claim.


b=
=C2=A0
--089e01419af6736f5f050695dc4c-- From nobody Wed Oct 29 14:29:31 2014 Return-Path: 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 AC4021A9088 for ; Wed, 29 Oct 2014 14:29:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.938 X-Spam-Level: X-Spam-Status: No, score=-0.938 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 co15j0eIZ2Pr for ; Wed, 29 Oct 2014 14:29:18 -0700 (PDT) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.131]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D6671A9081 for ; Wed, 29 Oct 2014 14:29:18 -0700 (PDT) Received: from mail-yh0-f53.google.com (mail-yh0-f53.google.com [209.85.213.53]) by mrelayeu.kundenserver.de (node=mreue005) with ESMTP (Nemesis) id 0McAb5-1XTIbc3ATn-00JZuJ; Wed, 29 Oct 2014 22:29:16 +0100 Received: by mail-yh0-f53.google.com with SMTP id z6so1016349yhz.12 for ; Wed, 29 Oct 2014 14:29:13 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.170.33.68 with SMTP id 65mr3945411ykb.121.1414618153605; Wed, 29 Oct 2014 14:29:13 -0700 (PDT) Received: by 10.170.99.4 with HTTP; Wed, 29 Oct 2014 14:29:13 -0700 (PDT) In-Reply-To: <20141029194708.5993.qmail@cr.yp.to> References: <810FD859-5CE9-4163-9749-973ED4F810CA@gmail.com> <20141029194708.5993.qmail@cr.yp.to> Date: Wed, 29 Oct 2014 22:29:13 +0100 Message-ID: From: Bodo Moeller To: "cfrg@irtf.org" Content-Type: multipart/alternative; boundary=001a1134f4ec89e15505069674ed X-Provags-ID: V02:K0:QgE1yNNNW8lhxnT9P1UVOPvLCNBayoPAzeNRQIcH69e X69ssymR8AtT5gikuTga1LsYKB3598trTvOrcCbiMUpXKqNnKl PPxe4cy640gqsaQcSq/uNk90qZ40nG5NDz7Wy4dsYxPYZmiL/2 jwPmycFvf6d3i6os6vL8A/sVjhiaDiaSkqCsquqO5xT77xcpZ3 c32UJYukS2AOlCBON6km+oQva+D2TRRcH2sZsa2cJL9pHQuqCQ ARtdicieFlc1hLG7bsZRNF8MUSC35gRmwLAAYejlcbRAjdHxCp B+BhZQ7e0MkfyjqONz3CaAwfgJ7U+W+tg5qwW1/JC+H63wYlTn 9QibXDqI8a0Dfta5p5GXQoJIph3DqkHhx+897HEdH2z1AUCLbJ 7k9yvLD6fXwQTAHjMx2ZMgLr0+DjHnNh49N7PFY653pKM9k9zj 8FqJT X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/GQGxfK0mvKRrWWNKl6JHQCCB0kY Subject: Re: [Cfrg] Actual security levels for IETF crypto X-BeenThere: cfrg@irtf.org 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: Wed, 29 Oct 2014 21:29:19 -0000 --001a1134f4ec89e15505069674ed Content-Type: text/plain; charset=UTF-8 D. J. Bernstein : The cost consequences are clear. Amazon is making HTTPS URLs work not in > the easiest way, and of course not in a secure way, but in the way that > ends up being cheapest for Amazon's servers. > > If you think that there's a plausible alternative reason for Amazon to > have set up these HTTPS-to-HTTP redirects, feel free to say what that > reason is. Obviously, www.amazon.com isn't simply a single server. There will be fewer HTTP servers handling cleartext traffic (port 80) than servers handling TLS-encrypted traffic (port 443). That's convenient even if you entirely ignore the computational cost of handling TLS, simply because it makes private-key management much easier. --001a1134f4ec89e15505069674ed Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
D. J= . Bernstein <djb@cr.yp.to>:

<= /div>
The cost consequences are clear. Amazon is making HTTPS URLs work not in the easiest way, and of course not in a secure way, but in the way that
ends up being cheapest for Amazon's servers.

If you think that there's a plausible alternative reason for Amazon to<= br> have set up these HTTPS-to-HTTP redirects, feel free to say what that
reason is.

Obviously, www.amazon.com isn't simply a single server. There wil= l be fewer HTTP servers handling cleartext traffic (port 80) than servers h= andling TLS-encrypted traffic (port 443). That's convenient even if you= entirely ignore the computational cost of handling TLS, simply because it = makes private-key management much easier.

<= /div> --001a1134f4ec89e15505069674ed-- From nobody Thu Oct 30 07:54:47 2014 Return-Path: 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 8A3D91A00EB for ; Thu, 30 Oct 2014 07:54:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 9bUQtODlZmiL for ; Thu, 30 Oct 2014 07:54:41 -0700 (PDT) Received: from mail-yh0-x234.google.com (mail-yh0-x234.google.com [IPv6:2607:f8b0:4002:c01::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA7A41AD41B for ; Thu, 30 Oct 2014 07:54:41 -0700 (PDT) Received: by mail-yh0-f52.google.com with SMTP id a41so1712685yho.11 for ; Thu, 30 Oct 2014 07:54:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=pcqqGwDO0ACcCud5scG8jZAysG3vyNq8KsUH95quK3s=; b=KuXz4dknT2l7peIMSs/oo1Z8Ouw/V3PAraJPgkZti+Ny5uv/GPK8o2v9m0pTM4PE09 Fd6enB7bOv60vpkxQx9qVamlTxvfxNUL1bEA8/ULsnNKZXEzolmdKXYNxgV8MAwRIJFl q1T/J/PT6mxNjrozj4vIDGCe/B2E1oQq3Zc/0TgtTc1tX6rVqFPJq2Gl4hgg+Tv5U2fa j72/k8f6803HQQq95ZJHORXVDktmYnbTaolOg0OE1dTOlnPEEcZ3mEb69sITJsmux3X6 DxVayA4Lj5izcHrAxcciqxgyJo5uTiS0u8NypbyxVXLINPKpByZepXXbFPiH/KA+/Lnx H86A== MIME-Version: 1.0 X-Received: by 10.236.7.52 with SMTP id 40mr3120514yho.172.1414680881110; Thu, 30 Oct 2014 07:54:41 -0700 (PDT) Received: by 10.170.195.149 with HTTP; Thu, 30 Oct 2014 07:54:41 -0700 (PDT) In-Reply-To: References: <810C31990B57ED40B2062BA10D43FBF5CF7DEC@XMB116CNC.rim.net> Date: Thu, 30 Oct 2014 07:54:41 -0700 Message-ID: From: Watson Ladd To: David Leon Gil Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/Y-9TR5e4xlweUWuJecnebagNZFc Cc: Dan Brown , "cfrg@irtf.org" Subject: Re: [Cfrg] Signature question ... [RE: Actual security levels for IETF crypto] X-BeenThere: cfrg@irtf.org 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: Thu, 30 Oct 2014 14:54:44 -0000 On Wed, Oct 29, 2014 at 10:49 AM, David Leon Gil wrote: > On Wed, Oct 29, 2014 at 10:25 AM, Dan Brown wrote: >> I slightly prefer ECDSA over Schnorr for provable security reasons: >> specifically in the generic group model, ECDSA relies on standard hash >> function assumptions whereas Schnorr does not. > > What are you talking about? > > [Neven et al.] give a reduction for Schnorr that is, IIRC, tight for, > e.g., Ed25519-SHA2-512 in the generic group model. > > A collision-resistant hash-function is sufficient. Chop(SHA2-512, > 256), which is what Ed25510-SHA2-512 uses, satisfies a stronger > property: It is indifferentiable from a random oracle. See [Coron et > al.] > > [Neven et al.] on the randomized prefix second-preimage assumptions: > "Both of the above assumptions are directly implied by the collision > resistance of H, a result which we leave to the reader[.]" (Perhaps, > in fact, this is not true?) > > And their proof obviously goes through fine with a hash function > indifferentiable from a random oracle; both SHAKE and Blake2 have been > designed to satisfy this property. [Coron et al.] While the above is certainly interesting theoretically, I doubt it matters practically. Schnorr signatures have been intensively studied for many years, with no attacks, as have ECDSA. The alternatives you mention are significantly less efficient, for no gain in security. The question is one over how annoyed you want the implementor to be, when they have to try to make a constant time inversion modulo an ugly prime. What I'm much more interested in is the choice of point formats, and whether to recommend the use of Montgomery form or not. There are real security benefits to Montgomery ladders: nearly impossible to screw up. There are similar benefits to the use of compressed points. There's also the question over how much transmitting Weierstrass points will improve adoption, and how much it will hurt security due to incomplete formulas being a natural choice, and the persistent temptation to use these formulas for everything. I'm increasingly coming around to the advantages, but this assumes that cofactors won't be a problem for implementations, which sadly isn't actually true all the time. Adding the isomorphism is a minor problem, but does make existing, deployed Curve25519 code incompatible. We'll need to carefully explain how to eek reasonable performance from the new curves, which is an area where this WG has fallen flat on its face before. (See RFC 6090 errata for details, and ensuing discussion of how the formulas presented weren't the most efficient ones, even if the correct ones had been presented). We need to address these questions *regardless* of which formulas get picked: it's not clear to me we have consensus on *any* of these. From nobody Thu Oct 30 08:29:01 2014 Return-Path: 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 8459B1AD4FB for ; Thu, 30 Oct 2014 08:28:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 2UWduOFFy2iy for ; Thu, 30 Oct 2014 08:28:54 -0700 (PDT) Received: from emh07.mail.saunalahti.fi (emh07.mail.saunalahti.fi [62.142.5.117]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB15E1AD509 for ; Thu, 30 Oct 2014 08:27:50 -0700 (PDT) Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh07.mail.saunalahti.fi (Postfix) with ESMTP id BB0B64032; Thu, 30 Oct 2014 17:27:47 +0200 (EET) Date: Thu, 30 Oct 2014 17:27:47 +0200 From: Ilari Liusvaara To: Watson Ladd Message-ID: <20141030152747.GA23650@LK-Perkele-VII> References: <810C31990B57ED40B2062BA10D43FBF5CF7DEC@XMB116CNC.rim.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/NLS2Un4pQ3QBZXMHBQVUDUoyHko Cc: Dan Brown , "cfrg@irtf.org" Subject: Re: [Cfrg] Signature question ... [RE: Actual security levels for IETF crypto] X-BeenThere: cfrg@irtf.org 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: Thu, 30 Oct 2014 15:28:57 -0000 On Thu, Oct 30, 2014 at 07:54:41AM -0700, Watson Ladd wrote: > > There's also the question over how much transmitting Weierstrass > points will improve adoption, and how much it will hurt security due > to incomplete formulas being a natural choice, and the persistent > temptation to use these formulas for everything. IMO, none (adotpion) and a lot (security). Looks like TLS v1.3 will go with fixed-per-group-format DH, which can easily take even the most bizarre formats (even if there is currently 255 byte limit for ECDH). And I don't think backport into TLS v1.2 would be difficult (violates RFC 4492, but one can overrule the offending parts of that without interop trouble[1]). As for cofactors, Weierstrass coordinates won't help with those. And besides, everything important should be able to deal with cofactors anyway. [1] Make it work like it does in v1.3. -Ilari From nobody Thu Oct 30 08:34:01 2014 Return-Path: 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 143161AD487 for ; Thu, 30 Oct 2014 08:33:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=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 TJ6M62hUViaJ for ; Thu, 30 Oct 2014 08:33:55 -0700 (PDT) Received: from mx1.ll.mit.edu (MX1.LL.MIT.EDU [129.55.12.45]) by ietfa.amsl.com (Postfix) with ESMTP id 397B41AD514 for ; Thu, 30 Oct 2014 08:33:54 -0700 (PDT) Received: from LLE2K10-HUB01.mitll.ad.local (LLE2K10-HUB01.mitll.ad.local) by mx1.ll.mit.edu (unknown) with ESMTP id s9UFX1lv001984; Thu, 30 Oct 2014 11:33:01 -0400 From: "Blumenthal, Uri - 0558 - MITLL" To: Ilari Liusvaara , Watson Ladd Thread-Topic: [Cfrg] Signature question ... [RE: Actual security levels for IETF crypto] Thread-Index: Ac/zgLptfQSZffggRLmwGpAylbDbAQAQX+cAACwvBoAAASfwgP//vmIA Date: Thu, 30 Oct 2014 15:33:00 +0000 Message-ID: References: <810C31990B57ED40B2062BA10D43FBF5CF7DEC@XMB116CNC.rim.net> <20141030152747.GA23650@LK-Perkele-VII> In-Reply-To: <20141030152747.GA23650@LK-Perkele-VII> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-originating-ip: [172.25.177.187] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3497513576_10857581" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.28, 0.0.0000 definitions=2014-10-30_07:2014-10-30,2014-10-30,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1410300141 Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/iZYsNF4-DGeOsWTQF35GHcgXuYI Cc: Dan Brown , "cfrg@irtf.org" Subject: Re: [Cfrg] Signature question ... [RE: Actual security levels for IETF crypto] X-BeenThere: cfrg@irtf.org 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: Thu, 30 Oct 2014 15:33:58 -0000 --B_3497513576_10857581 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit On 10/30/14, 11:27 , "Ilari Liusvaara" wrote: >On Thu, Oct 30, 2014 at 07:54:41AM -0700, Watson Ladd wrote: >> >> There's also the question over how much transmitting Weierstrass >> points will improve adoption, and how much it will hurt security due >> to incomplete formulas being a natural choice, and the persistent >> temptation to use these formulas for everything. > >IMO, none (adotpion) and a lot (security). AFAIK, whatever code exists now in released/deployed products, it uses Weierstrass points. Thus, IMHO it would improve adoption a lot. As for security - it could improve it because Weierstrass curves tend to have no cofactors. --B_3497513576_10857581 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIUOAYJKoZIhvcNAQcCoIIUKTCCFCUCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGgghIHMIIE6jCCA9KgAwIBAgIKH0XZoAAAAAABzTANBgkqhkiG9w0BAQsFADBRMQswCQYD VQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJ MRMwEQYDVQQDEwpNSVRMTCBDQS0zMB4XDTE0MDQxNjIxNTMwMloXDTE1MDQxNjIxNTMwMlow YTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNV BAsTBlBlb3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQCx/gK75UYos2g8JavX0BVfe3TCGsmjQY34z9ZVeucP 8dGtqRA8T5i1OKdf++Jd81a0/qQA6mIGyzTW6lOtY+77qKUJtEeLM5URd+iv2EejAwxsa2B5 pMq9L9qWuVokR1rTEfEcuUeKR1Kko6xmRE/y6AzBnUhTvHx2X9F6JSVdR36Lx3R62CNeQqFi ZDeHuTI8AhRY4UdPkri1FTDxV6gLYaLKxsGIurrL/6EzdlkX8ImTcxKzEmxX1VjTPy9ZRNYj akDGcJF9clCfcwbq3DI3gAUkVxXf+UbHEjzOCVNQcoga7bYbBUuDpN25Lc86P9RaOiiICtyu ZZP2P/2kkKYRAgMBAAGjggGyMIIBrjAdBgNVHQ4EFgQUEN9QHIi9GvlGjs9Th46jrfPir+Uw DgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1Ud HwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYB BQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExD QTMwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3 FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+KcwIBZAIBBTAi BgNVHSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAYBgNVHSAEETAPMA0GCyqGSIb3 EgIBAwEIMBkGA1UdEQQSMBCBDnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABM AFUAcwBlAHIAUwBpAGcALQBTAFcwDQYJKoZIhvcNAQELBQADggEBAL2kCh9ovO8AbHgAVU6T eH5qRmKnOrfTUfn9JnHzkspdWMQA1IdtftSpiZZ7C3lCmblSDCgPqbQl4zMZxXeTgxnQsB6m 1LA6uDHM/0G27RcOJH4OTN9sQ0/2CKb4JPIXXIps1z+s8XjSRzPJZuD8fPC8R8QWvOH3owL2 BLzZebZTOMa5yws3kohY02vP/Clv0KQXYVzUZUYXoYmhUSYmQ1UZZZSFJ2rNdgNn0z8fPrUQ NIYlVaJV0kKQYjlHWTfomVapLEfIY7xRHZy9g997IjYReD0t9IZd6tTwcJES+2ijFM8l/fxk u/cQ4WCYyI+58DaBaV9p68/AC147b0HhvLUwggS8MIIDpKADAgECAgEpMA0GCSqGSIb3DQEB BQUAMFQxCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQww CgYDVQQLEwNQS0kxFjAUBgNVBAMTDU1JVExMIFJvb3QgQ0EwHhcNMTMxMjE3MDAwMDAwWhcN MjAxMjMxMjM1OTU5WjBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFi b3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2jBSdW18tuW1tNxG6h8B0kqckFZQAAtoHCkvUpUEX6jF vBd8mQI53GyLYRuAo4HWJpe7/izFXOfSJDs6UM5ovvCOfXg2bJgDYlBC9JDcLBFIn0nppOu9 RvpjWSixtC56crwJ5Us5QPdtxtKdek5LJXl2oKw3w8lihUixePbxWad1m7ZMKKagvm9zTybP 6FumKRxeYJjSpB2+cAYjoGGEbSVHyx8uzHm6xAoBMHxa8by+yDz8Jzk6sP9iilgP3iXSGoCA mhyBzvlQQ5QNNWP+Emo9jz/ukKhYVB/VwdxtoquPAqn4ifDAIaM9dtb05cy1gXAFSP3Z/iUk xyBZZUORfwIDAQABo4IBmjCCAZYwEgYDVR0TAQH/BAgwBgEB/wIBADAdBgNVHQ4EFgQU12Bm DntJjXVMDf3PRt7IxxKHyr8wHwYDVR0jBBgwFoAUZ6p6z/QKprlytYqg0p3yEMND7SkwDgYD VR0PAQH/BAQDAgGGMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0cDovL2NybC5s bC5taXQuZWR1L2dldHRvP0xMUkNBMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5sbC5taXQu ZWR1L29jc3AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNy bD9MTFJDQTCBkgYDVR0gBIGKMIGHMA0GCyqGSIb3EgIBAwEGMA0GCyqGSIb3EgIBAwEIMA0G CyqGSIb3EgIBAwEHMA0GCyqGSIb3EgIBAwEJMA0GCyqGSIb3EgIBAwEKMA0GCyqGSIb3EgIB AwELMA0GCyqGSIb3EgIBAwEOMA0GCyqGSIb3EgIBAwEPMA0GCyqGSIb3EgIBAwEQMA0GCSqG SIb3DQEBBQUAA4IBAQAsf9HBn72qU7UTgkxarjAc7iynhcDEgWwezYKtd/SLGSQ0DhtzIV/L TCxqULjOd+H+HTqMJXB8+nHnzhyqQ43RsnGZOFT5RfzPh94db/ZJ3ql244DwlJI7yXBA2DkZ cEEgOWC9bHcrElzU6NnigahSW5odVJrhmH/XhQAcMS77E5H62yyxK1WPPgcBipGVnu1xSHbT iHe7DqfWQ2tVMLUf23XYhIua94kJsQd4jSh71NVD0e7F4snAoqQMI98MzDYeLOkjlzKRs77r /aMsPAKx6nMaOvRL7Cy0Pjp51i2qFkbGmX8ofnh2kerjTTvRJ/g22r1MV8RR1PktjMsNOsPf MIIDgzCCAmugAwIBAgIBATANBgkqhkiG9w0BAQUFADBUMQswCQYDVQQGEwJVUzEfMB0GA1UE ChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRYwFAYDVQQDEw1NSVRM TCBSb290IENBMB4XDTA4MDkyMzEyMDAwMFoXDTI5MTIzMTIzNTk1OVowVDELMAkGA1UEBhMC VVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTEWMBQG A1UEAxMNTUlUTEwgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMVO KRdYsiay+a2Kv1wQCoPd5AkwExuwcNDRhaRCdQN17K+lCCKvf9VSQToAsA6q1bACtZUcMv5Z Kx8z5KG4jK9cM40NvEkf/bIOZAHJqzKgWG3N9NqrcAhimcXTXYQIdp1DgjtdADKVLAjXaYpD 2PbpE/JbAPnqKzOENa3Py9CegB0abTlOyLgwXWY/rXTW+4L/hipJ6+sI/ZtrFRmsKGhuwAKo bFr0FDP6uIfx+RaWJcJ1QBIdgM4aohvW8JeriSSMyf/LlFpXTZFcM9SOX0f7wmsYi1yFuKFM nQbkSkxvnpBKMRxrg+98seSbbEnIkvB0C9qBDPLb/lQAvmpW6oMCAwEAAaNgMF4wDwYDVR0T AQH/BAUwAwEB/zAdBgNVHQ4EFgQUZ6p6z/QKprlytYqg0p3yEMND7SkwHwYDVR0jBBgwFoAU Z6p6z/QKprlytYqg0p3yEMND7SkwCwYDVR0PBAQDAgGGMA0GCSqGSIb3DQEBBQUAA4IBAQA+ G20FYNB4eNhKWF+PyT5DUtzlABFkf2IM2VGNUBova0GeKX3I1Nf02qDU/GO2H9ETvnvTYhvf gQ4UB/5EImTkKPa7/TVG/MQ7SgmAmne8xELVbGLFrrytly8PyYtZtngb6DgeEUv+SwFnzcLO 1vg1rdmss3kwsqy0q8e2VYAY8zTptEzyJG36aXcIMbqOxWS/LbPjNuPdgJfO3d1WrHr1Etaa a0QRLqQoZj07dYY7Wo5EDqU+AUAMz9ZVRGK1s5b/jv5Wz/YroyqWFnH2KkNxRn9+2Ar7g3rn rOMZvp6psq2jbDXiPBod1wyMKn8x5y4cuGPNFcqjfyY/HX90ivQAMIIEzjCCA7agAwIBAgIK PVEvPAAAAACTsDANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlU IExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0y MB4XDTE0MDIxMjE4NTMwMVoXDTE1MDIxMjE4NTMwMVowYTELMAkGA1UEBhMCVVMxHzAdBgNV BAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsTBlBlb3BsZTEgMB4GA1UEAxMX Qmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCKHhhu75bRiOvWhbZ//TxS76yI2d+rHN2s8bp8wxW8oMjmsaplLeGQusUFRyRNSkfYtdB4 YApjnV6TCxS0Mqzly5BaoeZWoP+CbbMDNGYMszus9iFj22SSlTzGRo+gaL6rqsDKdwDOzs3C PYqh4Uu8sLzEq+QD9rhqAuMJ76635JKWELxK0uDehpNBMCGqVeAY8ht5u2h4ojPdwiuDQDW2 QxWRJjPDL8n1JczuEHY71jHldER3b2+UhpDDYRQ9aVOiGCjW8BwJOruVsBfLNxyDxgffNQ1D 1konuneMpL9H2S8ciHOdy5+Gi7snCQJ+7w30rIJ2NTldWaY6avZAaCa3AgMBAAGjggGWMIIB kjAdBgNVHQ4EFgQUZ7oGjnu6gWRmom/4UswgdVBW/3wwDgYDVR0PAQH/BAQDAgUgMB8GA1Ud IwQYMBaAFI5KfYmhYxccgYg0VzcmRV4Zin4kMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9j cmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTIwYgYIKwYBBQUHAQEEVjBUMC0GCCsGAQUFBzAC hiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTIwIwYIKwYBBQUHMAGGF2h0dHA6 Ly9vY3NwLmxsLm1pdC5lZHUvMAwGA1UdEwEB/wQCMAAwPQYJKwYBBAGCNxUHBDAwLgYmKwYB BAGCNxUIg4PlHYfsp2aGrYcVg+rwRYW2oR8dhevQcIPr7SACAWQCAQQwJQYDVR0lBB4wHAYE VR0lAAYIKwYBBQUHAwQGCisGAQQBgjcKAwQwGAYDVR0gBBEwDzANBgsqhkiG9xICAQMBCDAZ BgNVHREEEjAQgQ51cmlAbGwubWl0LmVkdTANBgkqhkiG9w0BAQsFAAOCAQEAJiU3WfJ9GvGJ iDNPClLazyh252wxxOc/TmClMKtyqHnbFObDEoXAMaoHGxrvs+lU8fU2F2ELpV8q8eYgqLLw 7PG09z5s/GkajlxVZ/FHj/9hNHTfwlicrCRY3zrna1GbOMZgWFz8R6akAoLKpqGulNrvjvU8 c63U+JVmgJmBPCMv5JlH10m87+WPJ+ToK0m4XfZjl7n5OKDJ/hOyBwbBntc+W2gDppfR1BCt DNfEG0+zHjFqF+Of1Q5NI5abhgvw5IEuVA1M4SV/utwmmdreBEv/YuLnDd/PhVgQwp3LHGCX X1dANyiKso2aACl9jrkylq39cA/WgvAlS21w9vxVpDGCAfUwggHxAgEBMF8wUTELMAkGA1UE BhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTET MBEGA1UEAxMKTUlUTEwgQ0EtMwIKH0XZoAAAAAABzTANBglghkgBZQMEAgEFAKBpMC8GCSqG SIb3DQEJBDEiBCDZOE39W8LzSj4aXE7B5aa3F3Fwve53l3q8/Vzk3rEbEzAYBgkqhkiG9w0B CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNDEwMzAxNTMyNTZaMA0GCSqGSIb3 DQEBAQUABIIBAF88x3gwZHkOwFa5PIi9/8kcFsxdA4u7F7ONi0fweA8KcJ+w7FFYSWDeuRi9 YS1akbZ0iN32qsXe97qNtsInID8q91uB3ZQhghv+mrGrG+G5MEAG9Qo2qspaq1qEqXBzcP2N 5eXJ9JQGUZA92bN64iCjlXXZJ+BEDeSA3hPhx2A1SUIugprWZP95Sc+FzmQFnSL3m9f72vpk b9kNaSTwKP2yoB+wQ+o9hChBcQSJ5KdNNmwiIV3IyE2UJSZAxIHkvIz96ktHNDsruwImRZLQ YID8zmOkC74pWU4/GTSvzlE40nn4zwhDIbdnN5SahhC/cosccqmEAqaEWwv8LKhbNuY= --B_3497513576_10857581-- From nobody Thu Oct 30 08:47:29 2014 Return-Path: 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 C4C341AD4F8 for ; Thu, 30 Oct 2014 08:47:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 2EruO5EvqIFj for ; Thu, 30 Oct 2014 08:47:20 -0700 (PDT) Received: from emh03.mail.saunalahti.fi (emh03.mail.saunalahti.fi [62.142.5.109]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54EC01AD45B for ; Thu, 30 Oct 2014 08:47:19 -0700 (PDT) Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh03.mail.saunalahti.fi (Postfix) with ESMTP id 4BFEA188816; Thu, 30 Oct 2014 17:47:15 +0200 (EET) Date: Thu, 30 Oct 2014 17:47:15 +0200 From: Ilari Liusvaara To: "Blumenthal, Uri - 0558 - MITLL" Message-ID: <20141030154715.GA23772@LK-Perkele-VII> References: <810C31990B57ED40B2062BA10D43FBF5CF7DEC@XMB116CNC.rim.net> <20141030152747.GA23650@LK-Perkele-VII> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/e65kXpZV22k-i1AKEfuRByaO8Gg Cc: Dan Brown , "cfrg@irtf.org" Subject: Re: [Cfrg] Signature question ... [RE: Actual security levels for IETF crypto] X-BeenThere: cfrg@irtf.org 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: Thu, 30 Oct 2014 15:47:25 -0000 On Thu, Oct 30, 2014 at 03:33:00PM +0000, Blumenthal, Uri - 0558 - MITLL wrote: > On 10/30/14, 11:27 , "Ilari Liusvaara" wrote: > > >On Thu, Oct 30, 2014 at 07:54:41AM -0700, Watson Ladd wrote: > >> > >> There's also the question over how much transmitting Weierstrass > >> points will improve adoption, and how much it will hurt security due > >> to incomplete formulas being a natural choice, and the persistent > >> temptation to use these formulas for everything. > > > >IMO, none (adotpion) and a lot (security). > > AFAIK, whatever code exists now in released/deployed products, it uses > Weierstrass points. Thus, IMHO it would improve adoption a lot. As for > security - it could improve it because Weierstrass curves tend to have no > cofactors. No existing software has these new curves nor does any existing software have TLS v1.3. And it is really easy to screw up Weierstrass implementation (heck, even RFC 6090 got it wrong). Also, allegedly some implementations have a presentation for infinity, which is a VERY nasty surprise. -Ilari From nobody Thu Oct 30 08:58:00 2014 Return-Path: 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 BDEF21AD50E for ; Thu, 30 Oct 2014 08:57:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 uLypJvcuSoo4 for ; Thu, 30 Oct 2014 08:57:55 -0700 (PDT) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7853B1AD507 for ; Thu, 30 Oct 2014 08:57:44 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id bs8so4957454wib.5 for ; Thu, 30 Oct 2014 08:57:43 -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 :content-transfer-encoding:message-id:references:to; bh=pF7kRGjh88zSOFQ+y9slzaa1Ds1Y808sRq3htZiPeSM=; b=ZcvEcp7fM7PKwTRbAFNRjJ5e6jd0piaU4tUpnDJmfiuNV2YJevHeAgvOuDK+9VC505 weO0GzXZrEvqeWKYrwyzV9P2CfUJ4N9EfNKDg/XQUBv8q5e7TAI9hXqn4M/oSIbiyZEB 9xTgIaI9ON3ITge9lOrWLoOE1w+hDfaFHzBAA9NALLIhStpvHut8WsaBM32MNM9Dlukq b+VS696+xJWDksE5ccKCe/M1s3Su/6XiWbneyKi1tPfqK6yY53i0hMjB+r1OSfUDJMKp XjedSjusp1/47yMb+fsPPwUdTLrcXIPc+sFtJn3lVOrjkg1HzVxlBNZuFPGUQiV5eVPg tTMA== X-Received: by 10.180.99.105 with SMTP id ep9mr21291375wib.82.1414684663135; Thu, 30 Oct 2014 08:57:43 -0700 (PDT) Received: from [172.24.249.90] (dyn32-131.checkpoint.com. [194.29.32.131]) by mx.google.com with ESMTPSA id fx2sm9113605wjb.37.2014.10.30.08.57.42 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 30 Oct 2014 08:57:42 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Yoav Nir In-Reply-To: <20141030154715.GA23772@LK-Perkele-VII> Date: Thu, 30 Oct 2014 17:57:39 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8BBA75FE-FB7C-41F2-AFC3-B9C8D19C8929@gmail.com> References: <810C31990B57ED40B2062BA10D43FBF5CF7DEC@XMB116CNC.rim.net> <20141030152747.GA23650@LK-Perkele-VII> <20141030154715.GA23772@LK-Perkele-VII> To: Ilari Liusvaara X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/DWWp8H1X7QN_RAHjLjDBGrB70IY Cc: Dan Brown , "cfrg@irtf.org" Subject: Re: [Cfrg] Signature question ... [RE: Actual security levels for IETF crypto] X-BeenThere: cfrg@irtf.org 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: Thu, 30 Oct 2014 15:57:58 -0000 > On Oct 30, 2014, at 5:47 PM, Ilari Liusvaara = wrote: >=20 > On Thu, Oct 30, 2014 at 03:33:00PM +0000, Blumenthal, Uri - 0558 - = MITLL wrote: >> On 10/30/14, 11:27 , "Ilari Liusvaara" = wrote: >>=20 >>> On Thu, Oct 30, 2014 at 07:54:41AM -0700, Watson Ladd wrote: >>>>=20 >>>> There's also the question over how much transmitting Weierstrass >>>> points will improve adoption, and how much it will hurt security = due >>>> to incomplete formulas being a natural choice, and the persistent >>>> temptation to use these formulas for everything. >>>=20 >>> IMO, none (adotpion) and a lot (security). >>=20 >> AFAIK, whatever code exists now in released/deployed products, it = uses >> Weierstrass points. Thus, IMHO it would improve adoption a lot. As = for >> security - it could improve it because Weierstrass curves tend to = have no >> cofactors. >=20 > No existing software has these new curves nor does any existing = software > have TLS v1.3. +1 about adoption. Currently my code can do exactly three NIST curves and generates point = representations as they are required in IKE and TLS. Adding anything will require writing or copying a bunch of new code. = It=E2=80=99s true that if we keep Weierstrass points I may need to write = or copy less code, reducing the time I spend on writing it. But getting = these new curves into the product requires adding support for using the = new code in TLS and IKE, UI, testing, documentation, test cycles with = other implementations. Every one of those things totally dominates the = time I spend writing or copying the code, and none of them is in any way = affected by point format. So without expressing any opinion on which is better, saving the likes = of me some work should not be a consideration. Yoav From nobody Thu Oct 30 09:03:55 2014 Return-Path: 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 F0B511AD490 for ; Thu, 30 Oct 2014 09:03:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 tF95qZiAr6Xg for ; Thu, 30 Oct 2014 09:03:35 -0700 (PDT) Received: from mail-yk0-x235.google.com (mail-yk0-x235.google.com [IPv6:2607:f8b0:4002:c07::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB56A1AD52E for ; Thu, 30 Oct 2014 09:02:18 -0700 (PDT) Received: by mail-yk0-f181.google.com with SMTP id 19so2428562ykq.12 for ; Thu, 30 Oct 2014 09:02:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qDrWNuQJlCo74ZV7bI22MLw18iEBil11U+LjHtHrWAY=; b=yz3zE31HfBgJ28eZH0LsXGSAPJkA8WPt3k0iKk7P5CeQMBfaS8eU7u6GLEqoQPOM5X 5rF9w0uOFU3iOf8ZlD2/bqtBE6024Xw7eaOxIqCt2HsFuJU7NEwNI677ZPJ1E2WkYz3+ FjdC+oXL8E/zkzr+4Iry+lhM3PfFpmps5TC8OAB6+OHvZrN72f9SfzqacwNInq3Iw2wa NjgVa74Yxi+s+cUaZC2oJrRBP+fgr/TZrGfFdU2Bj/o63yZO0o1m4LTMR3ZT2nu72fR3 A5NKxwFcs3h/tAmY+/wnTRA9xu9Hql9BISMkQ/t5XYMTzXnenORfhedeiFc/JkVQauSt eIjA== MIME-Version: 1.0 X-Received: by 10.170.209.206 with SMTP id a197mr18325788ykf.24.1414684938000; Thu, 30 Oct 2014 09:02:18 -0700 (PDT) Received: by 10.170.195.149 with HTTP; Thu, 30 Oct 2014 09:02:17 -0700 (PDT) In-Reply-To: <20141030154715.GA23772@LK-Perkele-VII> References: <810C31990B57ED40B2062BA10D43FBF5CF7DEC@XMB116CNC.rim.net> <20141030152747.GA23650@LK-Perkele-VII> <20141030154715.GA23772@LK-Perkele-VII> Date: Thu, 30 Oct 2014 09:02:17 -0700 Message-ID: From: Watson Ladd To: Ilari Liusvaara Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/Dxb0PHLBxLJb3fUkfu5aQaEPpD0 Cc: Dan Brown , "cfrg@irtf.org" Subject: Re: [Cfrg] Signature question ... [RE: Actual security levels for IETF crypto] X-BeenThere: cfrg@irtf.org 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: Thu, 30 Oct 2014 16:03:44 -0000 On Thu, Oct 30, 2014 at 8:47 AM, Ilari Liusvaara wrote: > On Thu, Oct 30, 2014 at 03:33:00PM +0000, Blumenthal, Uri - 0558 - MITLL wrote: >> On 10/30/14, 11:27 , "Ilari Liusvaara" wrote: >> >> >On Thu, Oct 30, 2014 at 07:54:41AM -0700, Watson Ladd wrote: >> >> >> >> There's also the question over how much transmitting Weierstrass >> >> points will improve adoption, and how much it will hurt security due >> >> to incomplete formulas being a natural choice, and the persistent >> >> temptation to use these formulas for everything. >> > >> >IMO, none (adotpion) and a lot (security). >> >> AFAIK, whatever code exists now in released/deployed products, it uses >> Weierstrass points. Thus, IMHO it would improve adoption a lot. As for >> security - it could improve it because Weierstrass curves tend to have no >> cofactors. > > No existing software has these new curves nor does any existing software > have TLS v1.3. > > And it is really easy to screw up Weierstrass implementation (heck, even > RFC 6090 got it wrong). Also, allegedly some implementations have > a presentation for infinity, which is a VERY nasty surprise. Furthermore, the small-subgroup confinement attack only works when transcripts aren't hashed. But this needs to happen anyway. Existing standards use cofactor 1 for efficiency, not security. However, some code on HSMs supports specified curves in Weierstrass form. For PKIX this may be advantage on uptake. But yes, it's marginal when we talk about specialized per-prime code etc, none of which is compatible with specified curves. Really, I feel like I could replace myself with a perl script that reposts DJB's emails to the list and have a similar effect on the conversation: I think this email I'm sending now is his email from 2 August. > > > -Ilari -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Thu Oct 30 09:33:44 2014 Return-Path: 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 4318B1A008A for ; Thu, 30 Oct 2014 09:33:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.208 X-Spam-Level: X-Spam-Status: No, score=-4.208 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=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 WEr_V_WycEw4 for ; Thu, 30 Oct 2014 09:33:40 -0700 (PDT) Received: from mx1.ll.mit.edu (MX1.LL.MIT.EDU [129.55.12.45]) by ietfa.amsl.com (Postfix) with ESMTP id 138561A0095 for ; Thu, 30 Oct 2014 09:33:39 -0700 (PDT) Received: from LLE2K10-HUB02.mitll.ad.local (LLE2K10-HUB02.mitll.ad.local) by mx1.ll.mit.edu (unknown) with ESMTP id s9UGXMfD001818; Thu, 30 Oct 2014 12:33:25 -0400 From: "Blumenthal, Uri - 0558 - MITLL" To: Watson Ladd , Ilari Liusvaara Thread-Topic: [Cfrg] Signature question ... [RE: Actual security levels for IETF crypto] Thread-Index: Ac/zgLptfQSZffggRLmwGpAylbDbAQAQX+cAACwvBoAAASfwgP//vmIAgABHDoCAAAQzgP//xZSA Date: Thu, 30 Oct 2014 16:33:22 +0000 Message-ID: References: <810C31990B57ED40B2062BA10D43FBF5CF7DEC@XMB116CNC.rim.net> <20141030152747.GA23650@LK-Perkele-VII> <20141030154715.GA23772@LK-Perkele-VII> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-originating-ip: [172.25.177.187] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3497517191_11036834" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.28, 0.0.0000 definitions=2014-10-30_07:2014-10-30,2014-10-30,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1410300149 Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/YxoS5W_GOn-7NfsypPr-noOt8vE Cc: Dan Brown , "cfrg@irtf.org" Subject: Re: [Cfrg] Signature question ... [RE: Actual security levels for IETF crypto] X-BeenThere: cfrg@irtf.org 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: Thu, 30 Oct 2014 16:33:42 -0000 --B_3497517191_11036834 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable On 10/30/14, 12:02 , "Watson Ladd" wrote: >>And it is really easy to screw up Weierstrass implementation (heck, even >> RFC 6090 got it wrong). Also, allegedly some implementations have >> a presentation for infinity, which is a VERY nasty surprise. > >Furthermore, the small-subgroup confinement attack only works when >transcripts aren't hashed. But this needs to happen anyway. Existing >standards use cofactor 1 for efficiency, not security. I=E2=80=99ve been a *long-time fan* of HMQV-type protocols. But alas, the patents aren=E2=80=99t likely to allow developers to write and vendors to deploy them for quite some time. :-( >However, some code on HSMs supports specified curves in Weierstrass >form. For PKIX this may be advantage on uptake. Yes. >But yes, it's marginal when we talk about specialized per-prime code etc, >none of which is >compatible with specified curves. I don=E2=80=99t know. Yoav seems to agree with you here. I=E2=80=99d like to hear from hardware manufacturers though. >Really, I feel like I could replace myself with a perl script that >reposts DJB's emails to the list and have a similar effect on the >conversation: I think this email I'm sending now is his email from 2 >August. You noticed it too? :-) :-) --B_3497517191_11036834 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIUOAYJKoZIhvcNAQcCoIIUKTCCFCUCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGgghIHMIIE6jCCA9KgAwIBAgIKH0XZoAAAAAABzTANBgkqhkiG9w0BAQsFADBRMQswCQYD VQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJ MRMwEQYDVQQDEwpNSVRMTCBDQS0zMB4XDTE0MDQxNjIxNTMwMloXDTE1MDQxNjIxNTMwMlow YTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNV BAsTBlBlb3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQCx/gK75UYos2g8JavX0BVfe3TCGsmjQY34z9ZVeucP 8dGtqRA8T5i1OKdf++Jd81a0/qQA6mIGyzTW6lOtY+77qKUJtEeLM5URd+iv2EejAwxsa2B5 pMq9L9qWuVokR1rTEfEcuUeKR1Kko6xmRE/y6AzBnUhTvHx2X9F6JSVdR36Lx3R62CNeQqFi ZDeHuTI8AhRY4UdPkri1FTDxV6gLYaLKxsGIurrL/6EzdlkX8ImTcxKzEmxX1VjTPy9ZRNYj akDGcJF9clCfcwbq3DI3gAUkVxXf+UbHEjzOCVNQcoga7bYbBUuDpN25Lc86P9RaOiiICtyu ZZP2P/2kkKYRAgMBAAGjggGyMIIBrjAdBgNVHQ4EFgQUEN9QHIi9GvlGjs9Th46jrfPir+Uw DgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1Ud HwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYB BQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExD QTMwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3 FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+KcwIBZAIBBTAi BgNVHSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAYBgNVHSAEETAPMA0GCyqGSIb3 EgIBAwEIMBkGA1UdEQQSMBCBDnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABM AFUAcwBlAHIAUwBpAGcALQBTAFcwDQYJKoZIhvcNAQELBQADggEBAL2kCh9ovO8AbHgAVU6T eH5qRmKnOrfTUfn9JnHzkspdWMQA1IdtftSpiZZ7C3lCmblSDCgPqbQl4zMZxXeTgxnQsB6m 1LA6uDHM/0G27RcOJH4OTN9sQ0/2CKb4JPIXXIps1z+s8XjSRzPJZuD8fPC8R8QWvOH3owL2 BLzZebZTOMa5yws3kohY02vP/Clv0KQXYVzUZUYXoYmhUSYmQ1UZZZSFJ2rNdgNn0z8fPrUQ NIYlVaJV0kKQYjlHWTfomVapLEfIY7xRHZy9g997IjYReD0t9IZd6tTwcJES+2ijFM8l/fxk u/cQ4WCYyI+58DaBaV9p68/AC147b0HhvLUwggS8MIIDpKADAgECAgEpMA0GCSqGSIb3DQEB BQUAMFQxCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQww CgYDVQQLEwNQS0kxFjAUBgNVBAMTDU1JVExMIFJvb3QgQ0EwHhcNMTMxMjE3MDAwMDAwWhcN MjAxMjMxMjM1OTU5WjBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFi b3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2jBSdW18tuW1tNxG6h8B0kqckFZQAAtoHCkvUpUEX6jF vBd8mQI53GyLYRuAo4HWJpe7/izFXOfSJDs6UM5ovvCOfXg2bJgDYlBC9JDcLBFIn0nppOu9 RvpjWSixtC56crwJ5Us5QPdtxtKdek5LJXl2oKw3w8lihUixePbxWad1m7ZMKKagvm9zTybP 6FumKRxeYJjSpB2+cAYjoGGEbSVHyx8uzHm6xAoBMHxa8by+yDz8Jzk6sP9iilgP3iXSGoCA mhyBzvlQQ5QNNWP+Emo9jz/ukKhYVB/VwdxtoquPAqn4ifDAIaM9dtb05cy1gXAFSP3Z/iUk xyBZZUORfwIDAQABo4IBmjCCAZYwEgYDVR0TAQH/BAgwBgEB/wIBADAdBgNVHQ4EFgQU12Bm DntJjXVMDf3PRt7IxxKHyr8wHwYDVR0jBBgwFoAUZ6p6z/QKprlytYqg0p3yEMND7SkwDgYD VR0PAQH/BAQDAgGGMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0cDovL2NybC5s bC5taXQuZWR1L2dldHRvP0xMUkNBMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5sbC5taXQu ZWR1L29jc3AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNy bD9MTFJDQTCBkgYDVR0gBIGKMIGHMA0GCyqGSIb3EgIBAwEGMA0GCyqGSIb3EgIBAwEIMA0G CyqGSIb3EgIBAwEHMA0GCyqGSIb3EgIBAwEJMA0GCyqGSIb3EgIBAwEKMA0GCyqGSIb3EgIB AwELMA0GCyqGSIb3EgIBAwEOMA0GCyqGSIb3EgIBAwEPMA0GCyqGSIb3EgIBAwEQMA0GCSqG SIb3DQEBBQUAA4IBAQAsf9HBn72qU7UTgkxarjAc7iynhcDEgWwezYKtd/SLGSQ0DhtzIV/L TCxqULjOd+H+HTqMJXB8+nHnzhyqQ43RsnGZOFT5RfzPh94db/ZJ3ql244DwlJI7yXBA2DkZ cEEgOWC9bHcrElzU6NnigahSW5odVJrhmH/XhQAcMS77E5H62yyxK1WPPgcBipGVnu1xSHbT iHe7DqfWQ2tVMLUf23XYhIua94kJsQd4jSh71NVD0e7F4snAoqQMI98MzDYeLOkjlzKRs77r /aMsPAKx6nMaOvRL7Cy0Pjp51i2qFkbGmX8ofnh2kerjTTvRJ/g22r1MV8RR1PktjMsNOsPf MIIDgzCCAmugAwIBAgIBATANBgkqhkiG9w0BAQUFADBUMQswCQYDVQQGEwJVUzEfMB0GA1UE ChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRYwFAYDVQQDEw1NSVRM TCBSb290IENBMB4XDTA4MDkyMzEyMDAwMFoXDTI5MTIzMTIzNTk1OVowVDELMAkGA1UEBhMC VVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTEWMBQG A1UEAxMNTUlUTEwgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMVO KRdYsiay+a2Kv1wQCoPd5AkwExuwcNDRhaRCdQN17K+lCCKvf9VSQToAsA6q1bACtZUcMv5Z Kx8z5KG4jK9cM40NvEkf/bIOZAHJqzKgWG3N9NqrcAhimcXTXYQIdp1DgjtdADKVLAjXaYpD 2PbpE/JbAPnqKzOENa3Py9CegB0abTlOyLgwXWY/rXTW+4L/hipJ6+sI/ZtrFRmsKGhuwAKo bFr0FDP6uIfx+RaWJcJ1QBIdgM4aohvW8JeriSSMyf/LlFpXTZFcM9SOX0f7wmsYi1yFuKFM nQbkSkxvnpBKMRxrg+98seSbbEnIkvB0C9qBDPLb/lQAvmpW6oMCAwEAAaNgMF4wDwYDVR0T AQH/BAUwAwEB/zAdBgNVHQ4EFgQUZ6p6z/QKprlytYqg0p3yEMND7SkwHwYDVR0jBBgwFoAU Z6p6z/QKprlytYqg0p3yEMND7SkwCwYDVR0PBAQDAgGGMA0GCSqGSIb3DQEBBQUAA4IBAQA+ G20FYNB4eNhKWF+PyT5DUtzlABFkf2IM2VGNUBova0GeKX3I1Nf02qDU/GO2H9ETvnvTYhvf gQ4UB/5EImTkKPa7/TVG/MQ7SgmAmne8xELVbGLFrrytly8PyYtZtngb6DgeEUv+SwFnzcLO 1vg1rdmss3kwsqy0q8e2VYAY8zTptEzyJG36aXcIMbqOxWS/LbPjNuPdgJfO3d1WrHr1Etaa a0QRLqQoZj07dYY7Wo5EDqU+AUAMz9ZVRGK1s5b/jv5Wz/YroyqWFnH2KkNxRn9+2Ar7g3rn rOMZvp6psq2jbDXiPBod1wyMKn8x5y4cuGPNFcqjfyY/HX90ivQAMIIEzjCCA7agAwIBAgIK PVEvPAAAAACTsDANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlU IExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0y MB4XDTE0MDIxMjE4NTMwMVoXDTE1MDIxMjE4NTMwMVowYTELMAkGA1UEBhMCVVMxHzAdBgNV BAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsTBlBlb3BsZTEgMB4GA1UEAxMX Qmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCKHhhu75bRiOvWhbZ//TxS76yI2d+rHN2s8bp8wxW8oMjmsaplLeGQusUFRyRNSkfYtdB4 YApjnV6TCxS0Mqzly5BaoeZWoP+CbbMDNGYMszus9iFj22SSlTzGRo+gaL6rqsDKdwDOzs3C PYqh4Uu8sLzEq+QD9rhqAuMJ76635JKWELxK0uDehpNBMCGqVeAY8ht5u2h4ojPdwiuDQDW2 QxWRJjPDL8n1JczuEHY71jHldER3b2+UhpDDYRQ9aVOiGCjW8BwJOruVsBfLNxyDxgffNQ1D 1konuneMpL9H2S8ciHOdy5+Gi7snCQJ+7w30rIJ2NTldWaY6avZAaCa3AgMBAAGjggGWMIIB kjAdBgNVHQ4EFgQUZ7oGjnu6gWRmom/4UswgdVBW/3wwDgYDVR0PAQH/BAQDAgUgMB8GA1Ud IwQYMBaAFI5KfYmhYxccgYg0VzcmRV4Zin4kMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9j cmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTIwYgYIKwYBBQUHAQEEVjBUMC0GCCsGAQUFBzAC hiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTIwIwYIKwYBBQUHMAGGF2h0dHA6 Ly9vY3NwLmxsLm1pdC5lZHUvMAwGA1UdEwEB/wQCMAAwPQYJKwYBBAGCNxUHBDAwLgYmKwYB BAGCNxUIg4PlHYfsp2aGrYcVg+rwRYW2oR8dhevQcIPr7SACAWQCAQQwJQYDVR0lBB4wHAYE VR0lAAYIKwYBBQUHAwQGCisGAQQBgjcKAwQwGAYDVR0gBBEwDzANBgsqhkiG9xICAQMBCDAZ BgNVHREEEjAQgQ51cmlAbGwubWl0LmVkdTANBgkqhkiG9w0BAQsFAAOCAQEAJiU3WfJ9GvGJ iDNPClLazyh252wxxOc/TmClMKtyqHnbFObDEoXAMaoHGxrvs+lU8fU2F2ELpV8q8eYgqLLw 7PG09z5s/GkajlxVZ/FHj/9hNHTfwlicrCRY3zrna1GbOMZgWFz8R6akAoLKpqGulNrvjvU8 c63U+JVmgJmBPCMv5JlH10m87+WPJ+ToK0m4XfZjl7n5OKDJ/hOyBwbBntc+W2gDppfR1BCt DNfEG0+zHjFqF+Of1Q5NI5abhgvw5IEuVA1M4SV/utwmmdreBEv/YuLnDd/PhVgQwp3LHGCX X1dANyiKso2aACl9jrkylq39cA/WgvAlS21w9vxVpDGCAfUwggHxAgEBMF8wUTELMAkGA1UE BhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTET MBEGA1UEAxMKTUlUTEwgQ0EtMwIKH0XZoAAAAAABzTANBglghkgBZQMEAgEFAKBpMC8GCSqG SIb3DQEJBDEiBCBSRT+xRPqqvwbJkP+5PoTHBmn0udmosU8S1Y9QSyJuhzAYBgkqhkiG9w0B CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNDEwMzAxNjMzMTFaMA0GCSqGSIb3 DQEBAQUABIIBAIvPJ8W06uF53rHQ+e3hGtgxS+MAF4U1m60bv3L2bx2cWctJZCfzuutheS9K uOMzDfDGMcs7f/aEPqlD3fCYpRszBcL6ejG0ExyOdX8pwifZIQpjKa0A8avUAvTPSlvGqqxQ UycJL23vO/w+MrYtJgRNVK/a6GGxx5zwvmTkYDcPcm7/1JGoD0kf0xXmNGbCrxMN5KH/lvfo wWRC7e5cxIQwKzpFVW3XH6IfHZ9rYGAKWAKfFV0dYeanvGEvPQ4ApPEoV25PgW3Hp+9mJ6iW YP21P1mhy11pQKjKKZwfMsmXtXbtbX0mn5ZudHkMmdNFtYTqbpCAtbsmNbu5mOMIl34= --B_3497517191_11036834-- From nobody Thu Oct 30 10:55:38 2014 Return-Path: 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 D37011A19F7 for ; Thu, 30 Oct 2014 10:55:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 BJBDA1JVvugk for ; Thu, 30 Oct 2014 10:55:35 -0700 (PDT) Received: from mail-la0-x229.google.com (mail-la0-x229.google.com [IPv6:2a00:1450:4010:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CAD81A19EE for ; Thu, 30 Oct 2014 10:55:34 -0700 (PDT) Received: by mail-la0-f41.google.com with SMTP id s18so294092lam.28 for ; Thu, 30 Oct 2014 10:55:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=NH4Cm6OXVTKXBYpyIZkdpDlQfgV6e4LG0VfkB7UIndc=; b=z97h7F6+toWUNeSVAFYLpDp6NX6nf+8N6XrPP7kvr5RhZ35uzGMLvMwD9kAMhUiThv 0SUWmx8t5wwYQ0kiHpOgAXCkqCri1yIu/CmPKxgTI/jf4knEsCsgRK885UynANeKZ5oP l+svrvCQHHN+H0LHNGNNF9OJ64o9ZY2yR6QDv4ER91soWUcgwNsXl0J+1K09KPhOALI5 aF6rXEsCjLNyo703VuYd/WHiLDCSta/6g8seZZ2LBKNn7hRsEq6/Jujs+wS5Tt7XAULB Jyn/R4Ck11ehWBFVacVvaAGwrT8S7rdJGzuyuO2M/gfoobYZvXnA+PcVLl+yK2quGenS 0MbQ== X-Received: by 10.152.163.101 with SMTP id yh5mr20134286lab.68.1414691732634; Thu, 30 Oct 2014 10:55:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.218.145 with HTTP; Thu, 30 Oct 2014 10:55:12 -0700 (PDT) In-Reply-To: References: <810C31990B57ED40B2062BA10D43FBF5CF7DEC@XMB116CNC.rim.net> From: David Leon Gil Date: Thu, 30 Oct 2014 13:55:12 -0400 Message-ID: To: Watson Ladd Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/p4faTLdODdNH-qzyCNq2QtV6SdI Cc: Dan Brown , "cfrg@irtf.org" Subject: Re: [Cfrg] Signature question ... [RE: Actual security levels for IETF crypto] X-BeenThere: cfrg@irtf.org 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: Thu, 30 Oct 2014 17:55:37 -0000 On Thu, Oct 30, 2014 at 10:54 AM, Watson Ladd wrote: > While the above is certainly interesting theoretically, I doubt it > matters practically. Schnorr signatures have been intensively studied > for many years, with no attacks, as have ECDSA. Agreed: But I prefer security reductions to the absence of attacks, where at all possible. The former proves security; the latter only proves a lack of cleverness. > The question is one over how annoyed you want the implementor to be, > when they have to try to make a constant time inversion modulo an ugly > prime. Well, doing arithmetic modulo an ugly prime is already necessary for Schnorr. And if you read the Katz et al. paper, you will see that signing does not require performing an inversion mod #K. From nobody Thu Oct 30 13:17:25 2014 Return-Path: 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 CD6701A6F3D for ; Thu, 30 Oct 2014 13:17:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.741 X-Spam-Level: X-Spam-Status: No, score=0.741 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_BR=0.955, HOST_EQ_BR=1.295, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 klY62dQ3-uYe for ; Thu, 30 Oct 2014 13:17:20 -0700 (PDT) Received: from ephesus.correio.usp.br (ephesus.correio.usp.br [200.144.182.205]) by ietfa.amsl.com (Postfix) with ESMTP id 36F061A6F5A for ; Thu, 30 Oct 2014 13:17:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ephesus.correio.usp.br (Postfix) with ESMTP id 2E9751ECE47 for ; Thu, 30 Oct 2014 18:17:11 -0200 (BRST) X-Virus-Scanned: amavisd-new at ephesus.correio.usp.br Received: from ephesus.correio.usp.br ([127.0.0.1]) by localhost (ephesus.correio.usp.br [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 84sXHRc+A8dr for ; Thu, 30 Oct 2014 18:17:10 -0200 (BRST) Received: from cuzco.correio.usp.br (unknown [10.0.22.2]) by ephesus.correio.usp.br (Postfix) with ESMTP id A4ABA1ECE3E for ; Thu, 30 Oct 2014 18:17:10 -0200 (BRST) Date: Thu, 30 Oct 2014 18:17:10 -0200 (BRST) From: Paulo Sergio Licciardi Messeder Barreto To: cfrg@irtf.org Message-ID: <166744094.11552779.1414700230636.JavaMail.root@larc.usp.br> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_11552778_1524216051.1414700230635" X-Originating-IP: [143.107.151.34] X-Mailer: Zimbra 7.2.0_GA_2681 (ZimbraWebClient - FF3.0 (Win)/7.2.0_GA_2681) Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/OQtFbeGMXd9FRpOTV-sNaX2LJQA Subject: Re: [Cfrg] Signature question ... [RE: Actual security levels for IETF crypto] X-BeenThere: cfrg@irtf.org 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: Thu, 30 Oct 2014 20:17:24 -0000 ------=_Part_11552778_1524216051.1414700230635 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit > Date: Thu, 30 Oct 2014 13:55:12 -0400 > From: David Leon Gil > To: Watson Ladd > Cc: Dan Brown , "cfrg@irtf.org" > Subject: Re: [Cfrg] Signature question ... [RE: Actual security > levels > for IETF crypto] > Message-ID: > > Content-Type: text/plain; charset=UTF-8 > On Thu, Oct 30, 2014 at 10:54 AM, Watson Ladd > wrote: > > While the above is certainly interesting theoretically, I doubt it > > matters practically. Schnorr signatures have been intensively > > studied > > for many years, with no attacks, as have ECDSA. > Agreed: But I prefer security reductions to the absence of attacks, > where at all possible. The former proves security; the latter only > proves a lack of cleverness. > > The question is one over how annoyed you want the implementor to > > be, > > when they have to try to make a constant time inversion modulo an > > ugly > > prime. > Well, doing arithmetic modulo an ugly prime is already necessary for > Schnorr. > And if you read the Katz et al. paper, you will see that signing does > not require performing an inversion mod #K. The Katz et al. scheme is a direct variant of Schnorr, *not* of ECDSA. It also requires *two* exponentiations for signing, which is worse than doing an inversion. It is also inferior on all accounts to Shao's variant of Schnorr [Shao], whose security reduction is as tight as it can be (and it requires a single exponentiation and no modular inversion, just an extra hash, with negligible computational overhead). P. -- [Shao] Z. Shao, A provably secure short signature scheme based on discrete logarithms, Information Sciences 177(23), 2007, pp. 5432--5440, Elsevier. ------=_Part_11552778_1524216051.1414700230635 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <= div style=3D'font-family: times new roman,new york,times,serif; font-size: = 12pt; color: #000000'>
Date: Thu, 30 Oct 2014 13:55:12 -0400
From: David Leo= n Gil <coruus@gmail.com>
To: Watson Ladd <watsonbladd@gmail.com= >
Cc: Dan Brown <dbrown@certicom.com>, "cfrg@irtf.org" <cfrg= @irtf.org>
Subject: Re: [Cfrg] Signature question ... [RE: Actual sec= urity levels
        for IETF cr= ypto]
Message-ID:
        <= ;CAA7UWsU2wgDdEt+KJB13c_DCL+_sHZNOwEJDb0cZ6YbKHuReTQ@mail.gmail.com>
= Content-Type: text/plain; charset=3DUTF-8

On Thu, Oct 30, 2014 at 10= :54 AM, Watson Ladd <watsonbladd@gmail.com> wrote:
> While the = above is certainly interesting theoretically, I doubt it
> matters pr= actically. Schnorr signatures have been intensively studied
> for man= y years, with no attacks, as have ECDSA.

Agreed: But I prefer securi= ty reductions to the absence of attacks,
where at all possible. The form= er proves security; the latter only
proves a lack of cleverness.

= > The question is one over how annoyed you want the implementor to be,> when they have to try to make a constant time inversion modulo an ug= ly
> prime.

Well, doing arithmetic modulo an ugly prime is alr= eady necessary for Schnorr.

And if you read the Katz et al. paper, y= ou will see that signing does
not require performing an inversion mod #K= .

The Katz et al. scheme is a direct variant of Schnorr= , *not* of ECDSA. It also requires *two* exponentiations for signing, which= is worse than doing an inversion. It is also inferior on all accounts to S= hao's variant of Schnorr [Shao], whose security reduction is as tight as it= can be (and it requires a single exponentiation and no modular inversion, = just an extra hash, with negligible computational overhead).

P.
<= br>--

[Shao] Z. Shao, A provably secure short signature scheme based= on discrete logarithms, Information Sciences 177(23), 2007, pp. 5432--5440= , Elsevier. <http://www.sciencedirect.com/science/article/pii/S002002550= 7002757>

------=_Part_11552778_1524216051.1414700230635-- From nobody Thu Oct 30 14:06:26 2014 Return-Path: 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 BB6941A87C8 for ; Thu, 30 Oct 2014 14:06:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.51 X-Spam-Level: X-Spam-Status: No, score=-0.51 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, T_RP_MATCHES_RCVD=-0.01] 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 so9srI77y3sy for ; Thu, 30 Oct 2014 14:06:23 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 255671A87C4 for ; Thu, 30 Oct 2014 14:06:23 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1XjwvD-0000jT-JO; Thu, 30 Oct 2014 21:06:20 +0000 Date: Fri, 31 Oct 2014 06:06:18 +0900 Message-ID: From: Randy Bush To: "D. J. Bernstein" In-Reply-To: <20141029194708.5993.qmail@cr.yp.to> References: <810FD859-5CE9-4163-9749-973ED4F810CA@gmail.com> <20141029194708.5993.qmail@cr.yp.to> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/OppYEUoSe31WzyOm28XLT8Ydw-E Cc: IRTF CFRG Subject: Re: [Cfrg] Actual security levels for IETF crypto X-BeenThere: cfrg@irtf.org 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: Thu, 30 Oct 2014 21:06:25 -0000 for an actual measurement of port use of broadband users, see page 31 of http://www.iij.ad.jp/en/company/development/iir/pdf/iir_vol24_report_EN.pdf note that iij is more enterprise than consumer. randy From nobody Thu Oct 30 14:12:39 2014 Return-Path: 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 AE86B1A87D9 for ; Thu, 30 Oct 2014 14:12:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] 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 QgE1aiFnhqBn for ; Thu, 30 Oct 2014 14:12:35 -0700 (PDT) Received: from smtp-p02.blackberry.com (smtp-p02.blackberry.com [208.65.78.89]) by ietfa.amsl.com (Postfix) with ESMTP id 6965A1A87C8 for ; Thu, 30 Oct 2014 14:12:33 -0700 (PDT) Received: from xct101cnc.rim.net ([10.65.161.201]) by mhs214cnc.rim.net with ESMTP/TLS/AES128-SHA; 30 Oct 2014 17:12:07 -0400 Received: from XCT114CNC.rim.net (10.65.161.214) by XCT101CNC.rim.net (10.65.161.201) with Microsoft SMTP Server (TLS) id 14.3.174.1; Thu, 30 Oct 2014 17:12:07 -0400 Received: from XMB116CNC.rim.net ([fe80::45d:f4fe:6277:5d1b]) by XCT114CNC.rim.net ([::1]) with mapi id 14.03.0174.001; Thu, 30 Oct 2014 17:12:06 -0400 From: Dan Brown To: "'mike@shiftleft.org'" , "'cfrg@irtf.org'" Thread-Topic: [Cfrg] Terms for comparing curves and other algorithms, on the basis of security and efficiency Thread-Index: Ac/zi9pJuvI2S4d+RgS+72aHpc20iQANulyAADA/G2A= Date: Thu, 30 Oct 2014 21:12:06 +0000 Message-ID: <810C31990B57ED40B2062BA10D43FBF5CF8FB8@XMB116CNC.rim.net> References: <810C31990B57ED40B2062BA10D43FBF5CF7EA5@XMB116CNC.rim.net> <54512995.8040505@shiftleft.org> In-Reply-To: <54512995.8040505@shiftleft.org> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.250] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0052_01CFF464.A196DF40" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/B4unFkPwYd8oBMqEifNnvs_w3DY Subject: Re: [Cfrg] Terms for comparing curves and other algorithms, on the basis of security and efficiency X-BeenThere: cfrg@irtf.org 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: Thu, 30 Oct 2014 21:12:36 -0000 ------=_NextPart_000_0052_01CFF464.A196DF40 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Mike Hamburg [mailto:mike@shiftleft.org] > On 10/29/2014 08:24 AM, Dan Brown wrote: > > Second, optimizing work ratio w seems to > > favor large cofactor, which seems very strange to me, and is certainly > > unconventional (though I ignored public key size in the efficiency metric). > I don't think this is true. First of all, in some protocols you need to clear the > cofactor, so having a huge cofactor doesn't improve efficiency at all. But even > if you don't need to clear it, a big cofactor generically only helps the user by log > h / log n, and hurts security by a much larger sqrt(h) factor, so it doesn't > improve work ratio. It probably doesn't make a difference to progressive > ratio, but a smaller field is usually going to have a better progressive ratio. You're right! Thank you for looking into this and finding my mistake, wow. I'm relieved that I was just making a silly mistake (mixing up h and log h - argh, how bad) in applying the system, so perhaps the overall system (of saturation, defective, work and progressive ratios) is somewhat reasonable after all, although perhaps too simplistic. ------=_NextPart_000_0052_01CFF464.A196DF40 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUoDCCBo8w ggV3oAMCAQICCm2p3UcABAAABWowDQYJKoZIhvcNAQEFBQAwUDETMBEGCgmSJomT8ixkARkWA25l dDETMBEGCgmSJomT8ixkARkWA3JpbTEkMCIGA1UEAxMbUklNIFN1Ym9yZGluYXRlIENBIE1DQTAy WUtGMB4XDTE0MDUxNDE0MzYzOFoXDTE1MDUxNDE0MzYzOFowgaQxEzARBgoJkiaJk/IsZAEZFgNu ZXQxEzARBgoJkiaJk/IsZAEZFgNyaW0xDTALBgNVBAsTBEFNRVIxCzAJBgNVBAsTAkNBMRQwEgYD VQQLEwtNaXNzaXNzYXVnYTEOMAwGA1UECxMFVXNlcnMxEjAQBgNVBAMTCURhbiBCcm93bjEiMCAG CSqGSIb3DQEJARYTZGJyb3duQGNlcnRpY29tLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEA54YaBOai2UDS89LoHMbDcC4+c8dEl5TpkJWz0muqjnXP6xpSYqBzotsw9SpPD3/0wF8Dz77Z hkYN8BDSF0RAdtmfXKXe40tQkHoplN4pos9jnBZW5e8HuTZUkEVC/q7bf399cskpxMt9MA934gvB rSk1QNbR3D7Hq34t4bOHXSUCAwEAAaOCA5gwggOUMAsGA1UdDwQEAwIFoDBEBgkqhkiG9w0BCQ8E NzA1MA4GCCqGSIb3DQMCAgIAgDAOBggqhkiG9w0DBAICAIAwBwYFKw4DAgcwCgYIKoZIhvcNAwcw FwYJKwYBBAGCNxQCBAoeCABVAHMAZQByMCkGA1UdJQQiMCAGCisGAQQBgjcKAwQGCCsGAQUFBwME BggrBgEFBQcDAjBBBgNVHREEOjA4oCEGCisGAQQBgjcUAgOgEwwRZGFuaWJyb3duQHJpbS5uZXSB E2Ricm93bkBjZXJ0aWNvbS5jb20wHQYDVR0OBBYEFFdFrujr5LyMGa3Hl1U4MTjlEtfvMB8GA1Ud IwQYMBaAFObbryVSYEL0jYI1VF2A64ahrO/cMIIBMQYDVR0fBIIBKDCCASQwggEgoIIBHKCCARiG gctsZGFwOi8vL0NOPVJJTSUyMFN1Ym9yZGluYXRlJTIwQ0ElMjBNQ0EwMllLRixDTj1NQ0EwMllL RixDTj1DRFAsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmln dXJhdGlvbixEQz13aW5kb3dzLERDPWxvY2FsP2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFz ZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2ludIZIaHR0cDovL21jYTAyeWtmLnJpbS5u ZXQvQ2VydEVucm9sbC9SSU0lMjBTdWJvcmRpbmF0ZSUyMENBJTIwTUNBMDJZS0YuY3JsMIIBQQYI KwYBBQUHAQEEggEzMIIBLzCBwgYIKwYBBQUHMAKGgbVsZGFwOi8vL0NOPVJJTSUyMFN1Ym9yZGlu YXRlJTIwQ0ElMjBNQ0EwMllLRixDTj1BSUEsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049 U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz13aW5kb3dzLERDPWxvY2FsP2NBQ2VydGlmaWNh dGU/YmFzZT9vYmplY3RDbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MGgGCCsGAQUFBzAChlxo dHRwOi8vbWNhMDJ5a2YucmltLm5ldC9DZXJ0RW5yb2xsL01DQTAyWUtGLnJpbS5uZXRfUklNJTIw U3Vib3JkaW5hdGUlMjBDQSUyME1DQTAyWUtGKDQpLmNydDANBgkqhkiG9w0BAQUFAAOCAQEActBk hryrMh5+C+8YiOrR8xi+G1NkUycfNLuz4fYdQzFNB9yWxyRs2K0ydl0X5PZXejhbIif0dFoyaxnh g/D5hYfeGIhXfAOFG22EpMJWXVOavqYLxslnc2enihWAYcWkjPfE6tf3XMXkodFkMYvEd+qFj8eU vxbbcR1dBqiBFNNDcKlAKn/oElp/iI/LjUGMEb+tJdHttsGExvQzSd1zwk1U6cOinYD82Y08zA5b z38l5bE2+plmfX3EQ8vCKYA95psgGg3hsffn150smpY7HeEPGRZh9vglGfi2wnMqY/QgO+qs78dq O/C1be3quQU3WHQ6YcZr3JP1Rc7yj76K7jCCBr8wggSnoAMCAQICEDIa85KxFFmUTU0vlRGze+Ew DQYJKoZIhvcNAQEFBQAwTzEVMBMGCgmSJomT8ixkARkWBWxvY2FsMRcwFQYKCZImiZPyLGQBGRYH d2luZG93czEdMBsGA1UEAxMUUklNIFJvb3QgQ0EgTUNBMDFZS0YwHhcNMDYxMDEzMDEyNDU1WhcN MTYxMDEzMDEzMDQxWjBPMRUwEwYKCZImiZPyLGQBGRYFbG9jYWwxFzAVBgoJkiaJk/IsZAEZFgd3 aW5kb3dzMR0wGwYDVQQDExRSSU0gUm9vdCBDQSBNQ0EwMVlLRjCCAiIwDQYJKoZIhvcNAQEBBQAD ggIPADCCAgoCggIBAMbous78rVQBLT87+jYSuzmZ2osP40BMhFbJA3+cs3BZC0//uT87SG7/nhZi 9Qj9hYby7/HkGSQyheGL/lLIzxDdZV+AwxiirdDT6ck/acEMxWolLdK5xEYEmm6OxLaUuEvg7i/B vXPpZlsA6m9FFrTzHVX2693w8IoMs9cofr1TAB3YYDnvZTwupz7YifSF02pu1eZiZg09Jjaav9Hy aNyRGjbwyqFwTpCr+iHW7SsSszyJxulWGgnYCQgE95loK/ZMYhEBFCSq7yNn1yNM0WJ5S+uPILyv OKXbE9sWSxba+DnWQJuEZCvFPnILq5Ugq+jVap326uv9zejBpsnPUgdgMoZNlUuuu+e1eJwc3mng /rK6ZOCF1NzUzP/mIEdc1UuNV8L2WqvVH+fY9EyYTfcRlWTvO9XlVa9lXzca9MTqlKcHMYeSWWJF nJlCRZWIkIdAjNj632g0U06kWUHeBd8VJXFxQFzhob2lyr4pHiOv7rZ1+rwpw8DFMZnp85b/HqTW rcQ7LiIDljuKX6oBjMs1qNobnUPe/ucp1Kgy19+J61M7MxniBNyqKmLJLMTBd7aiIGnbfYTVl2j/ xJJ2aUQJmj9LNFeWb4Isl8PVK6p1sJkWy0JOx52HNIR0AY16AcikojsoYEkvci+mvuwANq4QT6bE lSPS2AbNnDSpT7GXAgMBAAGjggGVMIIBkTATBgkrBgEEAYI3FAIEBh4EAEMAQTALBgNVHQ8EBAMC AUYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQU1mmCZCQWwcwk2/EUfUcSfNzJTe4wggEpBgNV HR8EggEgMIIBHDCCARigggEUoIIBEIaBxGxkYXA6Ly8vQ049UklNJTIwUm9vdCUyMENBJTIwTUNB MDFZS0YsQ049TUNBMDFZS0YsQ049Q0RQLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNl cnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9d2luZG93cyxEQz1sb2NhbD9jZXJ0aWZpY2F0ZVJl dm9jYXRpb25MaXN0P2Jhc2U/b2JqZWN0Q2xhc3M9Y1JMRGlzdHJpYnV0aW9uUG9pbnSGR2h0dHA6 Ly9tY2EwMXlrZi53aW5kb3dzLmxvY2FsL0NlcnRFbnJvbGwvUklNJTIwUm9vdCUyMENBJTIwTUNB MDFZS0YuY3JsMBAGCSsGAQQBgjcVAQQDAgEAMA0GCSqGSIb3DQEBBQUAA4ICAQBDnlhbuDlU58ff o2JPdog62tn9QXOY9VnrBBiDZeFQmPVicup9e2/4dnw5o4/SnyLaNyxNlno++5Uiar/y0ne8J300 FWVW9cAXtmbfi7jwKour1kgwEFTn3TjGFbuYps553/mTTC3bk6l2f2xUCk1rINqoQVsGomH8RGO5 1YN/mX0rasHPUd7/7Rx/m/ZF9xbii6FUOikq6lMgYn4SEY+e3jsOvyYzwPkiHf6dshGfsZgDUN9b xNwRxUZttJGRx6gH3Qpk7dUuyw0ixwY9xmVyBVIHvWjyqswF3ntgwmEz92GHIKz/xWxRdkahkSIT zPjHYya2jI3sfpzU/tigvxCFrG1PQ4BSCNMByqUcfK5STTfJJm/x/ahqnDWlvUP6cFE6V9W10nW8 72BbNzWOypmGIouENEUAhq/ejrw09P0uvyK51vr6mY5z1djF6hLskNC+R11Tpwou+vbhmHEZBKOc cxCfxDL49O7wlpxu4fcpDYSxBDHMoFZgXVz/ajqqIHcjyQdAM8QGBqgkjE/Dq7NTP7K2Ul1An0nx DR+YgXe28R+7l5he5GzhIIaJuwHHAtgpbeA1NLY/bBciFoOR+s8ujS3rZtv5M3Q95hmN7trVrYo1 Z3dglmNmLM2KNZWwwHxH4xi//bhaR+/WbfXpEUg+WW0p9Uja9Z443hqVd48MrjCCB0YwggUuoAMC AQICChJuoPAAAAAAAiswDQYJKoZIhvcNAQEFBQAwTzEVMBMGCgmSJomT8ixkARkWBWxvY2FsMRcw FQYKCZImiZPyLGQBGRYHd2luZG93czEdMBsGA1UEAxMUUklNIFJvb3QgQ0EgTUNBMDFZS0YwHhcN MTQwNDAyMDA1MTEyWhcNMTYwNDAyMDEwMTEyWjBQMRMwEQYKCZImiZPyLGQBGRYDbmV0MRMwEQYK CZImiZPyLGQBGRYDcmltMSQwIgYDVQQDExtSSU0gU3Vib3JkaW5hdGUgQ0EgTUNBMDJZS0YwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCzrn3UT996pLvUIVlnExxcXGmYftIOq1qMwitW RCBe2j32VmDvzlJseIkfQuXDqjWnoqoE4sxQjxD5QNwhyBw9eXMCvLjHBW+HM4+HcmGIdan2w17E 4rR+RHVK6NzvkE1Gm4ziBTDr2jzSliZJpowLM+M/+cY2pyym074TQx+QCZQOKIqLnEgZ2uYw4kSj nCcE7eJ+WmJFq9bX6Cv9SONQfgN5Z3O1N/36lgavm/G6Amt/ePNE0AhcJwxin7Fahkx6/SjRbf0r Oa8uhCMxK8ebqTqD0+0VpViARFterasW5FTU2rcRFLHwwWV67yoFc2fbozkj5iseBXctM8NmqKt5 AgMBAAGjggMhMIIDHTAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBTm268lUmBC9I2CNVRdgOuG oazv3DALBgNVHQ8EBAMCAYYwEAYJKwYBBAGCNxUBBAMCAQQwIwYJKwYBBAGCNxUCBBYEFCLdxB/L akuvuaYdTyqIgHmfibLUMBkGCSsGAQQBgjcUAgQMHgoAUwB1AGIAQwBBMB8GA1UdIwQYMBaAFNZp gmQkFsHMJNvxFH1HEnzcyU3uMIIBKQYDVR0fBIIBIDCCARwwggEYoIIBFKCCARCGgcRsZGFwOi8v L0NOPVJJTSUyMFJvb3QlMjBDQSUyME1DQTAxWUtGLENOPU1DQTAxWUtGLENOPUNEUCxDTj1QdWJs aWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPXdpbmRv d3MsREM9bG9jYWw/Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdD9iYXNlP29iamVjdENsYXNzPWNS TERpc3RyaWJ1dGlvblBvaW50hkdodHRwOi8vbWNhMDF5a2Yud2luZG93cy5sb2NhbC9DZXJ0RW5y b2xsL1JJTSUyMFJvb3QlMjBDQSUyME1DQTAxWUtGLmNybDCCATwGCCsGAQUFBwEBBIIBLjCCASow gbsGCCsGAQUFBzAChoGubGRhcDovLy9DTj1SSU0lMjBSb290JTIwQ0ElMjBNQ0EwMVlLRixDTj1B SUEsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlv bixEQz13aW5kb3dzLERDPWxvY2FsP2NBQ2VydGlmaWNhdGU/YmFzZT9vYmplY3RDbGFzcz1jZXJ0 aWZpY2F0aW9uQXV0aG9yaXR5MGoGCCsGAQUFBzAChl5odHRwOi8vbWNhMDF5a2Yud2luZG93cy5s b2NhbC9DZXJ0RW5yb2xsL01DQTAxWUtGLndpbmRvd3MubG9jYWxfUklNJTIwUm9vdCUyMENBJTIw TUNBMDFZS0YuY3J0MA0GCSqGSIb3DQEBBQUAA4ICAQCUe8BMuuw2GW4AUAag80hqgwOQyezrSatL SIadEDvzg3LgXMJcN7onC+1B7vHsMxVMbFz3V+85WSKtzCtaBe5rhUCXLBZEGbM+WPavYgYMnUsD TpJwSXiDaM9Ym/ZLFsgfo3Qv7rfglydpqPCBfHUEQys2KeBVsDGd7HDK5Nk5fNaSmK0KgIBIvbXR bJKzhTsuctYGlOf/2nFtuoxWcdhu7t6UR7DbSTerjug7rvCZH4bie5cphsu4lZDXdNRp2IKWVEF6 0VcEK8dXK1hZXEGgjuen7R03uaA+7VsSr7eUZSLiouG7XnvXWik11aNCgBiQcIGsHVRIccHphmfS sFaZ0Bc+4/c/+K/v7X7RvdE29J9b1DqB2iV2SGZp58M0JLscohJ9uY0SJj8Hwl9YeuznijFBIC2y Psb1V9CgoRtBl+Ek37tPp1Wm4XSS+as2kcdcsZwiM/LywbFvYDEBa71b0mquxjisPyPvmVccA0e6 WW6RDNYKUqBJsZDpjTbRZkQA7CmzrOK6YHip2F/92ZYmpqM84BsEkLuf6kzzk+r0OVsWaFP+plU3 MfqtAeKtBgJu6yd4SYbA9eFX9ePeIzBaCjTzIcd+CclwA8SeoAgP07Ut2WcB3QnD7fcU6CBegHSd 7504Ty34G+FymbG6ZBBUU0exF44VAplxv4rWFA7mPTGCAvMwggLvAgEBMF4wUDETMBEGCgmSJomT 8ixkARkWA25ldDETMBEGCgmSJomT8ixkARkWA3JpbTEkMCIGA1UEAxMbUklNIFN1Ym9yZGluYXRl IENBIE1DQTAyWUtGAgptqd1HAAQAAAVqMAkGBSsOAwIaBQCgggHrMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE0MTAzMDIxMTIwNlowIwYJKoZIhvcNAQkEMRYEFKCJ KMcUQVteQ+qCVAaUjQYafceYMG0GCSsGAQQBgjcQBDFgMF4wUDETMBEGCgmSJomT8ixkARkWA25l dDETMBEGCgmSJomT8ixkARkWA3JpbTEkMCIGA1UEAxMbUklNIFN1Ym9yZGluYXRlIENBIE1DQTAy WUtGAgptqd1HAAQAAAVqMG8GCyqGSIb3DQEJEAILMWCgXjBQMRMwEQYKCZImiZPyLGQBGRYDbmV0 MRMwEQYKCZImiZPyLGQBGRYDcmltMSQwIgYDVQQDExtSSU0gU3Vib3JkaW5hdGUgQ0EgTUNBMDJZ S0YCCm2p3UcABAAABWowgasGCSqGSIb3DQEJDzGBnTCBmjALBglghkgBZQMEASowCwYJYIZIAWUD BAEWMAoGCCqGSIb3DQMHMAsGCWCGSAFlAwQBAjAOBggqhkiG9w0DAgICAIAwBwYFKw4DAgcwDQYI KoZIhvcNAwICAUAwDQYIKoZIhvcNAwICASgwBwYFKw4DAhowCwYJYIZIAWUDBAIDMAsGCWCGSAFl AwQCAjALBglghkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEgYCuzhGT9afiAIo6k6IGCLPdsJivUVnF pjBeDxaURyQN/bG7xQYyonPwTdZsRl3R6qcnWJP7tsxWB5hMYFdv6Rf6N9tWh2muNRn78yZNKiAC PEDR6NCWIlVxB4Ybx2GA7/rhdzy/p301YC7qLl2pSbGaa8qFWhKn1E5c4OZZJkMyBQAAAAAAAA== ------=_NextPart_000_0052_01CFF464.A196DF40-- From nobody Thu Oct 30 14:24:11 2014 Return-Path: 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 A70E21A87D8 for ; Thu, 30 Oct 2014 14:24:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 cG2XVS3JppCM for ; Thu, 30 Oct 2014 14:24:08 -0700 (PDT) Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A603B1A6FBA for ; Thu, 30 Oct 2014 14:24:07 -0700 (PDT) Received: by mail-wi0-f174.google.com with SMTP id d1so5717833wiv.13 for ; Thu, 30 Oct 2014 14:24:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=eIUQ66BQEFkxN6ayhLiL0MUEnBgZnohZY+u99pfdWAs=; b=fV5/QXyT4fhFG8x39K7351IsMmYVAnruKt4YbIWzB2sFLhOPqGRtS/unc8CE64OLvH KOqpNIoPFBMSQOonbEUwP8DgnnMVeCFbO1H8bPnbf2lRFqTccpTFjyKm/RRAjpjY6JkX 4b4QC4Dlvf1LKy/OM/QEQa4YEaJe0FVO4nK6j00I/fRJS76wWoKvwUnCS7D+neENlOTE AIzmr1xHmJCSh/nQoVrNhEgnN9+6kAVJki/jV6LauKwxq8G9oJ5TCaXWOVJtwv0vhvjC XAIdk0W8hO7Axa0qX7jZ1zkP3ME6lA+Y+1lmEOD9FQ6Qqro4TAUaeOjFi8KkMdSwNGGF n2Fw== X-Gm-Message-State: ALoCoQkAgcdgyKJu5fpwCJhjkcatq/diLNmIizNRvxiDovQR3NXVFhXsD2pNh1CPdSu1MmaTUohp X-Received: by 10.194.173.10 with SMTP id bg10mr23205459wjc.16.1414704246264; Thu, 30 Oct 2014 14:24:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.217.14.70 with HTTP; Thu, 30 Oct 2014 14:23:45 -0700 (PDT) In-Reply-To: References: <810FD859-5CE9-4163-9749-973ED4F810CA@gmail.com> <20141029194708.5993.qmail@cr.yp.to> From: Benjamin Black Date: Thu, 30 Oct 2014 14:23:45 -0700 Message-ID: To: Randy Bush Content-Type: multipart/alternative; boundary=089e0122f20e0faeb90506aa8068 Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/VGnCUlMSIqInM2oWuJFpopjdyg0 Cc: IRTF CFRG , "D. J. Bernstein" Subject: Re: [Cfrg] Actual security levels for IETF crypto X-BeenThere: cfrg@irtf.org 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: Thu, 30 Oct 2014 21:24:09 -0000 --089e0122f20e0faeb90506aa8068 Content-Type: text/plain; charset=UTF-8 Thanks, Randy. 200% YoY increase in port 443 attributed to Snowden leaks, with anticipation of that trend continuing, matches my anecdotal evidence and expectation. On Thu, Oct 30, 2014 at 2:06 PM, Randy Bush wrote: > for an actual measurement of port use of broadband users, see page 31 of > http://www.iij.ad.jp/en/company/development/iir/pdf/iir_vol24_report_EN.pdf > note that iij is more enterprise than consumer. > > randy > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg > --089e0122f20e0faeb90506aa8068 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks, Randy. 200% YoY increase in port 443 attributed to= Snowden leaks, with anticipation of that trend continuing, matches my anec= dotal evidence and expectation.

On Thu, Oct 30, 2014 at 2:06 PM, Randy Bush <randy@psg.c= om> wrote:
for an actual me= asurement of port use of broadband users, see page 31 of
http://www.iij.ad.jp/en/company/development/= iir/pdf/iir_vol24_report_EN.pdf
note that iij is more enterprise than consumer.

randy

_______________________________________________
Cfrg mailing list
Cfrg@irtf.org
htt= p://www.irtf.org/mailman/listinfo/cfrg

--089e0122f20e0faeb90506aa8068-- From nobody Thu Oct 30 17:17:02 2014 Return-Path: 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 A2C1B1A8A1E for ; Thu, 30 Oct 2014 17:16:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.556 X-Spam-Level: * X-Spam-Status: No, score=1.556 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, RDNS_DYNAMIC=0.982, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no 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 FzraiG59ZfDr for ; Thu, 30 Oct 2014 17:16:42 -0700 (PDT) Received: from aspartame.shiftleft.org (199-116-74-168-v301.PUBLIC.monkeybrains.net [199.116.74.168]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 036EA1A8A1C for ; Thu, 30 Oct 2014 17:16:37 -0700 (PDT) Received: from [10.184.148.249] (unknown [209.36.6.242]) by aspartame.shiftleft.org (Postfix) with ESMTPSA id 1B5D83A9C1; Thu, 30 Oct 2014 17:13:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=shiftleft.org; s=sldo; t=1414714425; bh=tAsuIYm5luSUeBICYTfTvC9QZ5+4V6sAfKpoMV6Cu6A=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=Tz1z2vUKzFwM5zJmX+ax/oqXO0UIl+2KGapA4zs2FqAYKhaFgs8ZnUhPQq4dkoHrM KiSJie10BzUCN44H5pbKtXDexF+GAwa7iVnEHw0iCwRnqeHfvp06gGgrOW4T9TgcQ4 1j410e/LB4MLVHZ5RFOcbb6xzP+VEMnhDXMPvnHg= Content-Type: multipart/alternative; boundary="Apple-Mail=_9DB6390D-A4CC-4CF5-9579-2D74B37AB2F2" Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Michael Hamburg In-Reply-To: <166744094.11552779.1414700230636.JavaMail.root@larc.usp.br> Date: Thu, 30 Oct 2014 17:16:35 -0700 Message-Id: <32FC2030-4423-44BD-83F8-A4D6305A4FA7@shiftleft.org> References: <166744094.11552779.1414700230636.JavaMail.root@larc.usp.br> To: Paulo Sergio Licciardi Messeder Barreto X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/spRvy9z8RppkawS1NME_ruf3l_Q Cc: cfrg@irtf.org Subject: Re: [Cfrg] Signature question ... [RE: Actual security levels for IETF crypto] X-BeenThere: cfrg@irtf.org 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, 31 Oct 2014 00:16:46 -0000 --Apple-Mail=_9DB6390D-A4CC-4CF5-9579-2D74B37AB2F2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Oct 30, 2014, at 1:17 PM, Paulo Sergio Licciardi Messeder Barreto = wrote: >=20 >=20 > Date: Thu, 30 Oct 2014 13:55:12 -0400 > From: David Leon Gil > > To: Watson Ladd > > Cc: Dan Brown >, = "cfrg@irtf.org " > > Subject: Re: [Cfrg] Signature question ... [RE: Actual security levels > for IETF crypto] > Message-ID: > = > > Content-Type: text/plain; charset=3DUTF-8 >=20 > On Thu, Oct 30, 2014 at 10:54 AM, Watson Ladd > wrote: > > While the above is certainly interesting theoretically, I doubt it > > matters practically. Schnorr signatures have been intensively = studied > > for many years, with no attacks, as have ECDSA. >=20 > Agreed: But I prefer security reductions to the absence of attacks, > where at all possible. The former proves security; the latter only > proves a lack of cleverness. >=20 > > The question is one over how annoyed you want the implementor to be, > > when they have to try to make a constant time inversion modulo an = ugly > > prime. >=20 > Well, doing arithmetic modulo an ugly prime is already necessary for = Schnorr. >=20 > And if you read the Katz et al. paper, you will see that signing does > not require performing an inversion mod #K. >=20 > The Katz et al. scheme is a direct variant of Schnorr, *not* of ECDSA. = It also requires *two* exponentiations for signing, which is worse than = doing an inversion. It is also inferior on all accounts to Shao's = variant of Schnorr [Shao], whose security reduction is as tight as it = can be (and it requires a single exponentiation and no modular = inversion, just an extra hash, with negligible computational overhead). >=20 > P. >=20 > -- >=20 > [Shao] Z. Shao, A provably secure short signature scheme based on = discrete logarithms, Information Sciences 177(23), 2007, pp. 5432--5440, = Elsevier. = > That sounds really useful. Do you have a quick description for those of = us who aren=E2=80=99t at a university? Thanks, =E2=80=94 Mike= --Apple-Mail=_9DB6390D-A4CC-4CF5-9579-2D74B37AB2F2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Oct 30, 2014, at 1:17 PM, Paulo Sergio Licciardi Messeder = Barreto <pbarreto@larc.usp.br> wrote:


Date: Thu, 30 Oct 2014 13:55:12 = -0400
From: David Leon Gil <coruus@gmail.com>
To: Watson Ladd <watsonbladd@gmail.com>
Cc: Dan Brown = <dbrown@certicom.com>, "cfrg@irtf.org" <cfrg@irtf.org>
Subject: Re: [Cfrg] = Signature question ... [RE: Actual security levels
        for IETF = crypto]
Message-ID:
        <CAA7UWsU2wgDdEt+KJB13c_DCL+_sHZNOwEJDb0cZ6YbKHuReTQ@mail.gmail.= com>
Content-Type: text/plain; charset=3DUTF-8

On Thu, Oct 30, 2014 at 10:54 AM, Watson Ladd = <watsonbladd@gmail.com> wrote:
> While = the above is certainly interesting theoretically, I doubt it
> matters practically. Schnorr signatures have been = intensively studied
> for many years, with no attacks, = as have ECDSA.

Agreed: But I prefer = security reductions to the absence of attacks,
where at = all possible. The former proves security; the latter only
proves a lack of cleverness.

> = The question is one over how annoyed you want the implementor to be,
> when they have to try to make a constant time inversion = modulo an ugly
> prime.

Well, doing arithmetic modulo an ugly prime is already = necessary for Schnorr.

And if you read the = Katz et al. paper, you will see that signing does
not = require performing an inversion mod #K.

The Katz et al. scheme is a direct variant of Schnorr, *not* = of ECDSA. It also requires *two* exponentiations for signing, which is = worse than doing an inversion. It is also inferior on all accounts to = Shao's variant of Schnorr [Shao], whose security reduction is as tight = as it can be (and it requires a single exponentiation and no modular = inversion, just an extra hash, with negligible computational = overhead).

P.

--

[Shao] Z. Shao, A provably = secure short signature scheme based on discrete logarithms, Information = Sciences 177(23), 2007, pp. 5432--5440, Elsevier. <http://www.sciencedirect.com/science/article/pii/S0020025507002= 757>

That sounds really useful.  Do you have = a quick description for those of us who aren=E2=80=99t at a = university?

Thanks,
=E2=80=94 = Mike
= --Apple-Mail=_9DB6390D-A4CC-4CF5-9579-2D74B37AB2F2-- From nobody Thu Oct 30 18:12:37 2014 Return-Path: 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 C044E1A8A40 for ; Thu, 30 Oct 2014 18:12:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.941 X-Spam-Level: X-Spam-Status: No, score=0.941 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_BR=0.955, HOST_EQ_BR=1.295, HTML_MESSAGE=0.001, J_CHICKENPOX_41=0.6, MANGLED_OFF=2.3, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 Rh7f85IkOefs for ; Thu, 30 Oct 2014 18:12:31 -0700 (PDT) Received: from syracusa.correio.usp.br (syracusa.correio.usp.br [200.144.182.206]) by ietfa.amsl.com (Postfix) with ESMTP id AA51A1A8A4C for ; Thu, 30 Oct 2014 18:12:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by syracusa.correio.usp.br (Postfix) with ESMTP id 7725496CD9 for ; Thu, 30 Oct 2014 23:12:28 -0200 (BRST) X-Virus-Scanned: amavisd-new at syracusa.correio.usp.br Received: from syracusa.correio.usp.br ([127.0.0.1]) by localhost (syracusa.correio.usp.br [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BS1kLbsaQpfD for ; Thu, 30 Oct 2014 23:12:27 -0200 (BRST) Received: from cuzco.correio.usp.br (unknown [10.0.22.2]) by syracusa.correio.usp.br (Postfix) with ESMTP id 65EBB968D5 for ; Thu, 30 Oct 2014 23:12:27 -0200 (BRST) Date: Thu, 30 Oct 2014 23:12:27 -0200 (BRST) From: Paulo Sergio Licciardi Messeder Barreto To: cfrg@irtf.org Message-ID: <2083991331.11598304.1414717947333.JavaMail.root@larc.usp.br> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_11598303_897858279.1414717947332" X-Originating-IP: [201.87.69.248] X-Mailer: Zimbra 7.2.0_GA_2681 (ZimbraWebClient - FF3.0 (Win)/7.2.0_GA_2681) Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/RwGVapsPKK8pVBkivC7QPxDmPk0 Subject: Re: [Cfrg] Signature question ... [RE: Actual security levels for IETF crypto] X-BeenThere: cfrg@irtf.org 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, 31 Oct 2014 01:12:35 -0000 ------=_Part_11598303_897858279.1414717947332 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit > Message: 5 > Date: Thu, 30 Oct 2014 17:16:35 -0700 > From: Michael Hamburg > To: Paulo Sergio Licciardi Messeder Barreto > Cc: cfrg@irtf.org > Subject: Re: [Cfrg] Signature question ... [RE: Actual security > levels > for IETF crypto] > Message-ID: <32FC2030-4423-44BD-83F8-A4D6305A4FA7@shiftleft.org> > Content-Type: text/plain; charset="utf-8" > > On Oct 30, 2014, at 1:17 PM, Paulo Sergio Licciardi Messeder > > Barreto wrote: > > > > > > Date: Thu, 30 Oct 2014 13:55:12 -0400 > > From: David Leon Gil > > > To: Watson Ladd > > > > Cc: Dan Brown >, > > "cfrg@irtf.org " > > > > Subject: Re: [Cfrg] Signature question ... [RE: Actual security > > levels > > for IETF crypto] > > Message-ID: > > > > > > Content-Type: text/plain; charset=UTF-8 > > > > On Thu, Oct 30, 2014 at 10:54 AM, Watson Ladd > > > wrote: > > > While the above is certainly interesting theoretically, I doubt > > > it > > > matters practically. Schnorr signatures have been intensively > > > studied > > > for many years, with no attacks, as have ECDSA. > > > > Agreed: But I prefer security reductions to the absence of attacks, > > where at all possible. The former proves security; the latter only > > proves a lack of cleverness. > > > > > The question is one over how annoyed you want the implementor to > > > be, > > > when they have to try to make a constant time inversion modulo an > > > ugly > > > prime. > > > > Well, doing arithmetic modulo an ugly prime is already necessary > > for Schnorr. > > > > And if you read the Katz et al. paper, you will see that signing > > does > > not require performing an inversion mod #K. > > > > The Katz et al. scheme is a direct variant of Schnorr, *not* of > > ECDSA. It also requires *two* exponentiations for signing, which > > is worse than doing an inversion. It is also inferior on all > > accounts to Shao's variant of Schnorr [Shao], whose security > > reduction is as tight as it can be (and it requires a single > > exponentiation and no modular inversion, just an extra hash, with > > negligible computational overhead). > > > > P. > > > > -- > > > > [Shao] Z. Shao, A provably secure short signature scheme based on > > discrete logarithms, Information Sciences 177(23), 2007, pp. > > 5432--5440, Elsevier. > > > > > That sounds really useful. Do you have a quick description for those > of us who aren?t at a university? > Thanks, > ? Mike Sure. Here you go (I presume you want to know the algorithmic differences, not the security reduction right now). Let be the underlying group (in additive notation) of order q. Key pairs are (s, V) where s is sampled uniformly from Z/qZ, and V = s*G. Let H: {0,1}^* x -> Z/qZ and F: {0,1}^* -> be random oracles. To sign a message m, sample k uniformly from Z/qZ; then, while Schnorr would compute R = k*G, Shao computes R = k*G + F(m), and after that both compute h = H(m, R), z = k - h*s (mod q), and the signature is (h, z). To verify a signature (h, z) for m, while Schnorr would compute R = z*G + h*V, Shao computes R = z*G + h*V + F(m), and after that both check whether H(m, R) = h. There are a few practical considerations here. The computation of F(m) and H(m, .) might involve a single underlying hash whose internal state (assumed to be large enough) is divided in two pieces right after m has been processed; one piece is finalized to yield F(m), the other is extended to process R (a modern sponge could do it more easily). So the overhead is essentially one group mapping and one addition; the cost is less than two scalar multiplications, and it does not require additional randomness. Besides, the security reduction only requires H to be preimage-resistant, not collision-resistant, so that its size could in principle be half that of the ECDSA hash size for the same security level; the shorter h may also reduce a bit the verification time. P. ------=_Part_11598303_897858279.1414717947332 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <= div style=3D'font-family: times new roman,new york,times,serif; font-size: = 12pt; color: #000000'>

Message: 5
Date: Thu, 30 Oct 2014 17:16:35 -0700<= br>From: Michael Hamburg <mike@shiftleft.org>
To: Paulo Sergio Lic= ciardi Messeder Barreto <pbarreto@larc.usp.br>
Cc: cfrg@irtf.orgSubject: Re: [Cfrg] Signature question ... [RE: Actual security levels        for IETF crypto]
Messag= e-ID: <32FC2030-4423-44BD-83F8-A4D6305A4FA7@shiftleft.org>
Content= -Type: text/plain; charset=3D"utf-8"


> On Oct 30, 2014, at 1:= 17 PM, Paulo Sergio Licciardi Messeder Barreto <pbarreto@larc.usp.br>= wrote:
>
>
> Date: Thu, 30 Oct 2014 13:55:12 -0400
= > From: David Leon Gil <coruus@gmail.com <mailto:coruus@gmail.com&= gt;>
> To: Watson Ladd <watsonbladd@gmail.com <mailto:watson= bladd@gmail.com>>
> Cc: Dan Brown <dbrown@certicom.com <m= ailto:dbrown@certicom.com>>, "cfrg@irtf.org <mailto:cfrg@irtf.org&= gt;" <cfrg@irtf.org <mailto:cfrg@irtf.org>>
> Subject: Re= : [Cfrg] Signature question ... [RE: Actual security levels
>   =       for IETF crypto]
> Message-ID:
>   &n= bsp;     <CAA7UWsU2wgDdEt+KJB13c_DCL+_sHZNOwEJDb0cZ6YbKHuReTQ@= mail.gmail.com <mailto:CAA7UWsU2wgDdEt+KJB13c_DCL+_sHZNOwEJDb0cZ6YbKHuRe= TQ@mail.gmail.com>>
> Content-Type: text/plain; charset=3DUTF-8=
>
> On Thu, Oct 30, 2014 at 10:54 AM, Watson Ladd <watsonb= ladd@gmail.com <mailto:watsonbladd@gmail.com>> wrote:
> >= While the above is certainly interesting theoretically, I doubt it
>= > matters practically. Schnorr signatures have been intensively studied=
> > for many years, with no attacks, as have ECDSA.
>
&= gt; Agreed: But I prefer security reductions to the absence of attacks,
= > where at all possible. The former proves security; the latter only
= > proves a lack of cleverness.
>
> > The question is one= over how annoyed you want the implementor to be,
> > when they ha= ve to try to make a constant time inversion modulo an ugly
> > pri= me.
>
> Well, doing arithmetic modulo an ugly prime is already= necessary for Schnorr.
>
> And if you read the Katz et al. pa= per, you will see that signing does
> not require performing an inver= sion mod #K.
>
> The Katz et al. scheme is a direct variant of= Schnorr, *not* of ECDSA. It also requires *two* exponentiations for signin= g, which is worse than doing an inversion. It is also inferior on all accou= nts to Shao's variant of Schnorr [Shao], whose security reduction is as tig= ht as it can be (and it requires a single exponentiation and no modular inv= ersion, just an extra hash, with negligible computational overhead).
>= ;
> P.
>
> --
>
> [Shao] Z. Shao, A provab= ly secure short signature scheme based on discrete logarithms, Information = Sciences 177(23), 2007, pp. 5432--5440, Elsevier. <http://www.sciencedir= ect.com/science/article/pii/S0020025507002757 <http://www.sciencedirect.= com/science/article/pii/S0020025507002757>>

That sounds really= useful.  Do you have a quick description for those of us who aren?t a= t a university?

Thanks,
? Mike

Sure. Here you= go (I presume you want to know the algorithmic differences, not the securi= ty reduction right now).

Let <G> be the underlying group (in a= dditive notation) of order q. Key pairs are (s, V) where s is sampled unifo= rmly from Z/qZ, and V =3D s*G. Let H: {0,1}^* x <G> -> Z/qZ and F:= {0,1}^* -> <G> be random oracles.

To sign a message m, sam= ple k uniformly from Z/qZ; then, while Schnorr would compute R =3D k*G, Sha= o computes R =3D k*G + F(m), and after that both compute h =3D H(m, R), z = =3D k - h*s (mod q), and the signature is (h, z).

To verify a signat= ure (h, z) for m, while Schnorr would compute R =3D z*G + h*V, Shao compute= s R =3D z*G + h*V + F(m), and after that both check whether H(m, R) =3D h.<= br>
There are a few practical considerations here. The computation of F(= m) and H(m, .) might involve a single underlying hash whose internal state = (assumed to be large enough) is divided in two pieces right after m has bee= n processed; one piece is finalized to yield F(m), the other is extended to= process R (a modern sponge could do it more easily). So the overhead is es= sentially one group mapping and one addition; the cost is less than two sca= lar multiplications, and it does not require additional randomness.

= Besides, the security reduction only requires H to be preimage-resistant, n= ot collision-resistant, so that its size could in principle be half that of= the ECDSA hash size for the same security level; the shorter h may also re= duce a bit the verification time.

P.

------=_Part_11598303_897858279.1414717947332-- From nobody Thu Oct 30 21:33:15 2014 Return-Path: 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 082FB1A8AA5 for ; Thu, 30 Oct 2014 21:33:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.456 X-Spam-Level: **** X-Spam-Status: No, score=4.456 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, J_CHICKENPOX_41=0.6, MANGLED_OFF=2.3, RDNS_DYNAMIC=0.982, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no 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 8TyhvxnYAzC5 for ; Thu, 30 Oct 2014 21:33:10 -0700 (PDT) Received: from aspartame.shiftleft.org (199-116-74-168-v301.PUBLIC.monkeybrains.net [199.116.74.168]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 051FF1A8A9F for ; Thu, 30 Oct 2014 21:33:09 -0700 (PDT) Received: from [192.168.1.124] (unknown [192.168.1.1]) by aspartame.shiftleft.org (Postfix) with ESMTPSA id 899113A9C1; Thu, 30 Oct 2014 21:30:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=shiftleft.org; s=sldo; t=1414729815; bh=LGaaAtmvzFTZq1oPWZH+e+pBrhaa3i16oPFimJBcoTQ=; h=Date:From:To:Subject:References:In-Reply-To:From; b=OPGr1gP4VHPyHBPjeCQ6qmk6kR41XzYAOQfjP0ngsgzsppf1F4On70TaCl7hq8n+E wM+0pVopbXQdjWTKV+xEK7yv/lxYVE9iIrCrekeOCzJuciNDzEs2fQNLuajXFJi10/ FoY8QS3Mii6o6iPxMxO9l4R6sGBmU9O0te408mOc= Message-ID: <54531103.6070201@shiftleft.org> Date: Thu, 30 Oct 2014 21:33:07 -0700 From: Mike Hamburg User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Paulo Sergio Licciardi Messeder Barreto , cfrg@irtf.org References: <2083991331.11598304.1414717947333.JavaMail.root@larc.usp.br> In-Reply-To: <2083991331.11598304.1414717947333.JavaMail.root@larc.usp.br> Content-Type: multipart/alternative; boundary="------------060303070903070105010403" Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/teozd2dYEk-OFtJpVtmJMvIIRQ0 Subject: Re: [Cfrg] Signature question ... [RE: Actual security levels for IETF crypto] X-BeenThere: cfrg@irtf.org 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, 31 Oct 2014 04:33:13 -0000 This is a multi-part message in MIME format. --------------060303070903070105010403 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 10/30/2014 6:12 PM, Paulo Sergio Licciardi Messeder Barreto wrote: > > > Message: 5 > Date: Thu, 30 Oct 2014 17:16:35 -0700 > From: Michael Hamburg > To: Paulo Sergio Licciardi Messeder Barreto > Cc: cfrg@irtf.org > Subject: Re: [Cfrg] Signature question ... [RE: Actual security levels > for IETF crypto] > Message-ID: <32FC2030-4423-44BD-83F8-A4D6305A4FA7@shiftleft.org> > Content-Type: text/plain; charset="utf-8" > > > > On Oct 30, 2014, at 1:17 PM, Paulo Sergio Licciardi Messeder > Barreto wrote: > > > > > > Date: Thu, 30 Oct 2014 13:55:12 -0400 > > From: David Leon Gil > > > To: Watson Ladd > > > Cc: Dan Brown >, "cfrg@irtf.org > " > > > Subject: Re: [Cfrg] Signature question ... [RE: Actual security > levels > > for IETF crypto] > > Message-ID: > > > > > > Content-Type: text/plain; charset=UTF-8 > > > > On Thu, Oct 30, 2014 at 10:54 AM, Watson Ladd > > wrote: > > > While the above is certainly interesting theoretically, I doubt it > > > matters practically. Schnorr signatures have been intensively > studied > > > for many years, with no attacks, as have ECDSA. > > > > Agreed: But I prefer security reductions to the absence of attacks, > > where at all possible. The former proves security; the latter only > > proves a lack of cleverness. > > > > > The question is one over how annoyed you want the implementor > to be, > > > when they have to try to make a constant time inversion modulo > an ugly > > > prime. > > > > Well, doing arithmetic modulo an ugly prime is already necessary > for Schnorr. > > > > And if you read the Katz et al. paper, you will see that signing > does > > not require performing an inversion mod #K. > > > > The Katz et al. scheme is a direct variant of Schnorr, *not* of > ECDSA. It also requires *two* exponentiations for signing, which > is worse than doing an inversion. It is also inferior on all > accounts to Shao's variant of Schnorr [Shao], whose security > reduction is as tight as it can be (and it requires a single > exponentiation and no modular inversion, just an extra hash, with > negligible computational overhead). > > > > P. > > > > -- > > > > [Shao] Z. Shao, A provably secure short signature scheme based > on discrete logarithms, Information Sciences 177(23), 2007, pp. > 5432--5440, Elsevier. > > > > That sounds really useful. Do you have a quick description for > those of us who aren?t at a university? > > Thanks, > ? Mike > > > Sure. Here you go (I presume you want to know the algorithmic > differences, not the security reduction right now). > > Let be the underlying group (in additive notation) of order q. Key > pairs are (s, V) where s is sampled uniformly from Z/qZ, and V = s*G. > Let H: {0,1}^* x -> Z/qZ and F: {0,1}^* -> be random oracles. > > To sign a message m, sample k uniformly from Z/qZ; then, while Schnorr > would compute R = k*G, Shao computes R = k*G + F(m), and after that > both compute h = H(m, R), z = k - h*s (mod q), and the signature is > (h, z). > > To verify a signature (h, z) for m, while Schnorr would compute R = > z*G + h*V, Shao computes R = z*G + h*V + F(m), and after that both > check whether H(m, R) = h. This is the same thing as Schnorr with H'(m,R) := H(m, R+F(m)), which is indifferentiable from a random oracle anyway. So, it's exactly as secure as Schnorr, but slower. "Ah, but it's provably secure with a tight reduction!", you might say. No it isn't. A colleague of mine has kindly provided me with a copy of the paper. The argument presented at the bottom of the 7th and the top of the 8th page in favor of the tight reduction is, to use a technical term, bullshit. It's not merely wrong: the author knew it was wrong, and wrote it anyway. Essentially, the author says that with some probability delta, the attacker forges a message by calling H first and F second (unlike a real signer, who always calls F first); this leads to a tight reduction. With probability 1-delta, the adversary calls F first. The author admits that if delta = 0, the reduction is loose. Intuitively, we would expect an adversary to call F(m) before H(m,R), since R is supposed to depend on F(m) and m is known anyway when calling H(m,R). So delta ought to be 0. But the author "eclectically" assumes that, since the adversary is randomized, you can just let delta = 1/2, in which case the reduction is still tight. In fact, the author knows that the reduction isn't tight, which is why the claims throughout the paper are that the signature scheme is "closely, if not tightly, related to the difficulty of solving discrete logarithms"; that "epsilon' \approx [tight reduction]" instead of "epsilon' >= [tight reduction]"; and that the reduction might be called "between loose and tight". Thanks anyway though, -- Mike > There are a few practical considerations here. The computation of F(m) > and H(m, .) might involve a single underlying hash whose internal > state (assumed to be large enough) is divided in two pieces right > after m has been processed; one piece is finalized to yield F(m), the > other is extended to process R (a modern sponge could do it more > easily). So the overhead is essentially one group mapping and one > addition; the cost is less than two scalar multiplications, and it > does not require additional randomness. > > Besides, the security reduction only requires H to be > preimage-resistant, not collision-resistant, so that its size could in > principle be half that of the ECDSA hash size for the same security > level; the shorter h may also reduce a bit the verification time. > > P. --------------060303070903070105010403 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 10/30/2014 6:12 PM, Paulo Sergio Licciardi Messeder Barreto wrote:


Message: 5
Date: Thu, 30 Oct 2014 17:16:35 -0700
From: Michael Hamburg <mike@shiftleft.org>
To: Paulo Sergio Licciardi Messeder Barreto <pbarreto@larc.usp.br>
Cc: cfrg@irtf.org
Subject: Re: [Cfrg] Signature question ... [RE: Actual security levels
        for IETF crypto]
Message-ID: <32FC2030-4423-44BD-83F8-A4D6305A4FA7@shiftleft.org>
Content-Type: text/plain; charset="utf-8"


> On Oct 30, 2014, at 1:17 PM, Paulo Sergio Licciardi Messeder Barreto <pbarreto@larc.usp.br> wrote:
>
>
> Date: Thu, 30 Oct 2014 13:55:12 -0400
> From: David Leon Gil <coruus@gmail.com <mailto:coruus@gmail.com>>
> To: Watson Ladd <watsonbladd@gmail.com <mailto:watsonbladd@gmail.com>>
> Cc: Dan Brown <dbrown@certicom.com <mailto:dbrown@certicom.com>>, "cfrg@irtf.org <mailto:cfrg@irtf.org>" <cfrg@irtf.org <mailto:cfrg@irtf.org>>
> Subject: Re: [Cfrg] Signature question ... [RE: Actual security levels
>         for IETF crypto]
> Message-ID:
>         <CAA7UWsU2wgDdEt+KJB13c_DCL+_sHZNOwEJDb0cZ6YbKHuReTQ@mail.gmail.com <mailto:CAA7UWsU2wgDdEt+KJB13c_DCL+_sHZNOwEJDb0cZ6YbKHuReTQ@mail.gmail.com>>
> Content-Type: text/plain; charset=UTF-8
>
> On Thu, Oct 30, 2014 at 10:54 AM, Watson Ladd <watsonbladd@gmail.com <mailto:watsonbladd@gmail.com>> wrote:
> > While the above is certainly interesting theoretically, I doubt it
> > matters practically. Schnorr signatures have been intensively studied
> > for many years, with no attacks, as have ECDSA.
>
> Agreed: But I prefer security reductions to the absence of attacks,
> where at all possible. The former proves security; the latter only
> proves a lack of cleverness.
>
> > The question is one over how annoyed you want the implementor to be,
> > when they have to try to make a constant time inversion modulo an ugly
> > prime.
>
> Well, doing arithmetic modulo an ugly prime is already necessary for Schnorr.
>
> And if you read the Katz et al. paper, you will see that signing does
> not require performing an inversion mod #K.
>
> The Katz et al. scheme is a direct variant of Schnorr, *not* of ECDSA. It also requires *two* exponentiations for signing, which is worse than doing an inversion. It is also inferior on all accounts to Shao's variant of Schnorr [Shao], whose security reduction is as tight as it can be (and it requires a single exponentiation and no modular inversion, just an extra hash, with negligible computational overhead).
>
> P.
>
> --
>
> [Shao] Z. Shao, A provably secure short signature scheme based on discrete logarithms, Information Sciences 177(23), 2007, pp. 5432--5440, Elsevier. <http://www.sciencedirect.com/science/article/pii/S0020025507002757 <http://www.sciencedirect.com/science/article/pii/S0020025507002757>>

That sounds really useful.  Do you have a quick description for those of us who aren?t at a university?

Thanks,
? Mike

Sure. Here you go (I presume you want to know the algorithmic differences, not the security reduction right now).

Let <G> be the underlying group (in additive notation) of order q. Key pairs are (s, V) where s is sampled uniformly from Z/qZ, and V = s*G. Let H: {0,1}^* x <G> -> Z/qZ and F: {0,1}^* -> <G> be random oracles.

To sign a message m, sample k uniformly from Z/qZ; then, while Schnorr would compute R = k*G, Shao computes R = k*G + F(m), and after that both compute h = H(m, R), z = k - h*s (mod q), and the signature is (h, z).

To verify a signature (h, z) for m, while Schnorr would compute R = z*G + h*V, Shao computes R = z*G + h*V + F(m), and after that both check whether H(m, R) = h.
This is the same thing as Schnorr with H'(m,R) := H(m, R+F(m)), which is indifferentiable from a random oracle anyway.  So, it's exactly as secure as Schnorr, but slower.

"Ah, but it's provably secure with a tight reduction!", you might say.  No it isn't.  A colleague of mine has kindly provided me with a copy of the paper.  The argument presented at the bottom of the 7th and the top of the 8th page in favor of the tight reduction is, to use a technical term, bullshit.  It's not merely wrong: the author knew it was wrong, and wrote it anyway.

Essentially, the author says that with some probability delta, the attacker forges a message by calling H first and F second (unlike a real signer, who always calls F first); this leads to a tight reduction.  With probability 1-delta, the adversary calls F first.  The author admits that if delta = 0, the reduction is loose.  Intuitively, we would expect an adversary to call F(m) before H(m,R), since R is supposed to depend on F(m) and m is known anyway when calling H(m,R).  So delta ought to be 0.  But the author "eclectically" assumes that, since the adversary is randomized, you can just let delta = 1/2, in which case the reduction is still tight.

In fact, the author knows that the reduction isn't tight, which is why the claims throughout the paper are that the signature scheme is "closely, if not tightly, related to the difficulty of solving discrete logarithms"; that "epsilon' \approx [tight reduction]" instead of "epsilon' >= [tight reduction]"; and that the reduction might be called "between loose and tight".

Thanks anyway though,
-- Mike
There are a few practical considerations here. The computation of F(m) and H(m, .) might involve a single underlying hash whose internal state (assumed to be large enough) is divided in two pieces right after m has been processed; one piece is finalized to yield F(m), the other is extended to process R (a modern sponge could do it more easily). So the overhead is essentially one group mapping and one addition; the cost is less than two scalar multiplications, and it does not require additional randomness.

Besides, the security reduction only requires H to be preimage-resistant, not collision-resistant, so that its size could in principle be half that of the ECDSA hash size for the same security level; the shorter h may also reduce a bit the verification time.

P.

--------------060303070903070105010403-- From nobody Fri Oct 31 00:37:08 2014 Return-Path: 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 980E81A8AEC for ; Fri, 31 Oct 2014 00:37:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 TqBqV2pDNIUd for ; Fri, 31 Oct 2014 00:37:04 -0700 (PDT) Received: from mail-vc0-f174.google.com (mail-vc0-f174.google.com [209.85.220.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51DC91A8AE7 for ; Fri, 31 Oct 2014 00:37:04 -0700 (PDT) Received: by mail-vc0-f174.google.com with SMTP id im17so1063867vcb.33 for ; Fri, 31 Oct 2014 00:37:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=K03xIiM5tm2Stt6YI+91WNVY70BXY/AWMbLPFnA6h5Q=; b=St6eH8yh6fVuaxAXG6P9jk1ny+1uUWCR9FceulzRVIrlmYat5pH9kQGuoQwbVax23Q 0wwoZMsPArEe4aRkMLsocuPRzKMVt4hawdi9pG65SAEea6veUKZA6hIkstomj3P73WO1 SiIZc+bmAEJiuuIEK8lSnCliS7j7cPzQ5bRcVj2Snf+2mXN0xTqdHCFfQfCNgqlPP0oF cOIOgMDjBu4npb97tTHs22zCneaS4pBzx5Y8NSbH8RGKaJTOKXBPv03egbVkZFs9SGJk rf28p1X0VVuhT8UejnFK+ONcq9EqkGTsXXlQnFt+T84yPamqHh27iaj1tYMjLU4kGNm+ kvJA== X-Gm-Message-State: ALoCoQmBRHi/JtspUcAwr1DtHgDPYX4gGdmy5FlOfQPEjIJiFoIsiP9xd+0Mk7M6BWbWCAP1hyOL MIME-Version: 1.0 X-Received: by 10.221.5.65 with SMTP id of1mr16098490vcb.6.1414740013448; Fri, 31 Oct 2014 00:20:13 -0700 (PDT) Received: by 10.31.149.205 with HTTP; Fri, 31 Oct 2014 00:20:13 -0700 (PDT) In-Reply-To: References: <810FD859-5CE9-4163-9749-973ED4F810CA@gmail.com> <20141029194708.5993.qmail@cr.yp.to> Date: Fri, 31 Oct 2014 00:20:13 -0700 Message-ID: From: Richard Barnes To: Benjamin Black Content-Type: multipart/alternative; boundary=089e013cb9bef399470506b2d3b8 Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/DDu-VWRBwZtX93Y7w5_LtOVe21w Cc: IRTF CFRG , "D. J. Bernstein" Subject: Re: [Cfrg] Actual security levels for IETF crypto X-BeenThere: cfrg@irtf.org 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, 31 Oct 2014 07:37:06 -0000 --089e013cb9bef399470506b2d3b8 Content-Type: text/plain; charset=UTF-8 Those percentages actually seem rather low. While the IIJ data show roughly 5:1 ratio of 80 to 443, Firefox telemetry shows roughly 2:1. So substantially more HTTPS. http://telemetry.mozilla.org/#filter=release%2F32%2FHTTP_TRANSACTION_IS_SSL&aggregates=multiselect-all!Submissions&evoOver=Builds&locked=true&sanitize=true&renderhistogram=Graph --Richard On Thu, Oct 30, 2014 at 2:23 PM, Benjamin Black wrote: > Thanks, Randy. 200% YoY increase in port 443 attributed to Snowden leaks, > with anticipation of that trend continuing, matches my anecdotal evidence > and expectation. > > On Thu, Oct 30, 2014 at 2:06 PM, Randy Bush wrote: > >> for an actual measurement of port use of broadband users, see page 31 of >> >> http://www.iij.ad.jp/en/company/development/iir/pdf/iir_vol24_report_EN.pdf >> note that iij is more enterprise than consumer. >> >> randy >> >> _______________________________________________ >> Cfrg mailing list >> Cfrg@irtf.org >> http://www.irtf.org/mailman/listinfo/cfrg >> > > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg > > --089e013cb9bef399470506b2d3b8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Those percentages actually seem rather low.=C2= =A0 While the IIJ data show roughly 5:1 ratio of 80 to 443, Firefox telemet= ry shows roughly 2:1.=C2=A0 So substantially more HTTPS.

http://telemet= ry.mozilla.org/#filter=3Drelease%2F32%2FHTTP_TRANSACTION_IS_SSL&aggrega= tes=3Dmultiselect-all!Submissions&evoOver=3DBuilds&locked=3Dtrue&am= p;sanitize=3Dtrue&renderhistogram=3DGraph

--Ric= hard

On = Thu, Oct 30, 2014 at 2:23 PM, Benjamin Black <b@b3k.us> wrote:
Thanks, Randy. 200% YoY incre= ase in port 443 attributed to Snowden leaks, with anticipation of that tren= d continuing, matches my anecdotal evidence and expectation.

On Thu, Oct 30, 2014 at 2:06 PM, Randy Bush <randy@psg.com&g= t; wrote:
for an actual measuremen= t of port use of broadband users, see page 31 of
http://www.iij.ad.jp/en/company/development/= iir/pdf/iir_vol24_report_EN.pdf
note that iij is more enterprise than consumer.

randy

_______________________________________________
Cfrg mailing list
Cfrg@irtf.org
htt= p://www.irtf.org/mailman/listinfo/cfrg


_______________________________________________
Cfrg mailing list
Cfrg@irtf.org
htt= p://www.irtf.org/mailman/listinfo/cfrg


--089e013cb9bef399470506b2d3b8-- From nobody Fri Oct 31 00:51:18 2014 Return-Path: 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 979F21A8AF0 for ; Fri, 31 Oct 2014 00:51:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 lYcj4n9OYtmj for ; Fri, 31 Oct 2014 00:51:15 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 394A01A8AEE for ; Fri, 31 Oct 2014 00:51:15 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1Xk6zI-0005ta-Oy; Fri, 31 Oct 2014 07:51:13 +0000 Date: Fri, 31 Oct 2014 16:51:11 +0900 Message-ID: From: Randy Bush To: Richard Barnes In-Reply-To: References: <810FD859-5CE9-4163-9749-973ED4F810CA@gmail.com> <20141029194708.5993.qmail@cr.yp.to> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/y9zSOO35_p9FRjPiWZvpavwa9Rs Cc: IRTF CFRG Subject: Re: [Cfrg] Actual security levels for IETF crypto X-BeenThere: cfrg@irtf.org 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, 31 Oct 2014 07:51:16 -0000 > Those percentages actually seem rather low. While the IIJ data show > roughly 5:1 ratio of 80 to 443, Firefox telemetry shows roughly 2:1. > So substantially more HTTPS. that would be cheering. very different measurements, of course. as cho san said, we have elephants who file share and other biases. and, of course, sampling from a browser has its biases, a lot happens over http* which is not in a browser. but numbers are good. and i sure am cheered by yours. randy From nobody Fri Oct 31 01:05:34 2014 Return-Path: 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 B0E2D1A8BAF for ; Fri, 31 Oct 2014 01:05:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-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 dulsow7MiXqL for ; Fri, 31 Oct 2014 01:05:29 -0700 (PDT) Received: from entima.net (entima.net [78.129.143.175]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DB091A8BB0 for ; Fri, 31 Oct 2014 01:05:29 -0700 (PDT) Message-ID: <545342CF.4090503@akr.io> Date: Fri, 31 Oct 2014 08:05:35 +0000 From: Alyssa Rowan MIME-Version: 1.0 To: "cfrg@irtf.org" References: <810FD859-5CE9-4163-9749-973ED4F810CA@gmail.com> <20141029194708.5993.qmail@cr.yp.to> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/l7ZiozMGCoGp1t89T4wkqqug9-M Subject: Re: [Cfrg] Actual security levels for IETF crypto X-BeenThere: cfrg@irtf.org 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, 31 Oct 2014 08:05:32 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 31/10/2014 07:51, Randy Bush wrote: >> Those percentages actually seem rather low. While the IIJ data >> show roughly 5:1 ratio of 80 to 443, Firefox telemetry shows >> roughly 2:1. So substantially more HTTPS. > but numbers are good. and i sure am cheered by yours. Of course, what is needed is to get it to ≈100%. I think we recognise that high-performance strong crypto is needed by the TLS WG to do that. (Otherwise they could just use DHE-3072, etc.) - -- /akr -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJUU0LPAAoJEOyEjtkWi2t6YfQP/iWewuT64HuqD60S3yywZ15A JBrM4k4SyG6sh1a3FfpaYa6p8SvBYOaVDWkVXxs/ptZmSN3oizrRIdoa8RRc/bkE BKHuS2XQvgVHkq42V8ObN+kdZAAEsBJWwYvpohGKZMEGOS6D08IHwIZp9M+rCk9t 4jPVVOVc7tXlV7ynbw7Vu1JQSiUJ96faIQZ3PNo+Rwqxr7pLKh9KeshF9CD/Y+de FdfNqzTdB/fUtfWaOUHHN+GpsoadEF5cjEdr2fOk+XxzGdddeuX8ssIpmZfYgUeL Jri/SlYmdTfN77mxlyzICy94g6ebFnAXqG9VWXgm/wApWPXdEjQ58YLvVHM9Xj/+ kOsZQCAkCv9ajHNVYsvlhGxMMR06Xm4dUtOIjG09NMauyqpkWkSKx9e2BfMuhcwt NshPtu6VSJlOeQ/B+NuG3qFiVu63lmLV+sk90YVPQL1ejKnVQ2wPLoxVM5o2voHE ebm41QjZPcNWV9z7/7zq/Qf1UFJ8l9qX3lYPDUeKDs3yDU/0ca6s7IIbKmYBRTsq BV/QTDbtizuLWZN/+6pSG1RyKZ0tH3BlQklb31Zv9kov/Ftg5Bc1q+1FMY1c0S4K JdkBVw6F6QsJElkgo3sYeXzF3+iwcusRdQXkOPhdHGOWwejOvDGMo06VPI+ET+QW Ekxep7A73BpE0IZrOKfc =UAgK -----END PGP SIGNATURE----- From nobody Fri Oct 31 02:23:58 2014 Return-Path: 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 168D91A6F99 for ; Fri, 31 Oct 2014 02:23:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 hlw_Us6yrIJw for ; Fri, 31 Oct 2014 02:23:53 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73BD71A802E for ; Fri, 31 Oct 2014 02:23:53 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1Xk8Qw-0006ZG-Ry; Fri, 31 Oct 2014 09:23:51 +0000 Date: Fri, 31 Oct 2014 18:23:48 +0900 Message-ID: From: Randy Bush To: Alyssa Rowan In-Reply-To: <545342CF.4090503@akr.io> References: <810FD859-5CE9-4163-9749-973ED4F810CA@gmail.com> <20141029194708.5993.qmail@cr.yp.to> <545342CF.4090503@akr.io> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/M9aIJUyG6uK7J-_KLp68rzhzIuk Cc: IRTF CFRG Subject: Re: [Cfrg] Actual security levels for IETF crypto X-BeenThere: cfrg@irtf.org 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, 31 Oct 2014 09:23:55 -0000 > Of course, what is needed is to get it to =E2=89=88100%. > I think we recognise that high-performance strong crypto is needed by > the TLS WG to do that. (Otherwise they could just use DHE-3072, etc.) agree. but, as has been a bit overdiscussed, we would like the servers and clients not to be biased against strength. maybe this is na=C3=AFve, b= ut one step in that direction is to get the performance numbers that have been published in recent days and in supercop into marketing form. and then strongly encourage tls and dnssec to *default* to strong crypto. i would appreciate help trying to get ed25519 into bgpsec, which is in draft. randy From nobody Fri Oct 31 03:18:32 2014 Return-Path: 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 7B8F21A0461 for ; Fri, 31 Oct 2014 03:18:30 -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 qjVjryMuQVxw for ; Fri, 31 Oct 2014 03:18:27 -0700 (PDT) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 206E61A19E4 for ; Fri, 31 Oct 2014 03:18:26 -0700 (PDT) Received: by mail-wi0-f170.google.com with SMTP id q5so885941wiv.5 for ; Fri, 31 Oct 2014 03:18:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:mime-version:to:from:subject:date:in-reply-to:references :content-type; bh=EZycoGW7Qs+y7WL0RDJhXsSvgBHWBrNgfNk+92aZlwE=; b=wxReKmNY0VsdLtgAsozrGAIJmtD71UsPHwcJdMfEvtqMT3eWo2redx0DcIPXYTNaT3 8O/9C1wsfo4PykPKmyBwRJ8i2KQWmrgR/FG7eZeuwYpMfIGKTvI4VrU/d1CBiC8eyy6R h7x1G3vyq441wYflFBXah+3WMdBLEBLY99MIwWRfJWvNexSiocQ+S/MnAFejH1h4q5N8 XczfSb+LpxjTWfowYj50LhPxhFqMM5egCpCdiyl+paSa/1TTURDO5C/HjHFVKmZZTbMk 5PamyrRv2wkAOGpxvEcA9ifkZFN/gDMXTtqrdz/snimFt+mPb4UhmYwq8YGox7ZyX3Kd ZS4w== X-Received: by 10.194.100.98 with SMTP id ex2mr25923275wjb.48.1414750705572; Fri, 31 Oct 2014 03:18:25 -0700 (PDT) Received: from [10.234.94.114] ([109.253.136.199]) by mx.google.com with ESMTPSA id p3sm11531667wjf.49.2014.10.31.03.18.23 for (version=SSLv3 cipher=RC4-SHA bits=128/128); Fri, 31 Oct 2014 03:18:24 -0700 (PDT) Message-ID: <545361f0.e317c20a.3875.47cf@mx.google.com> MIME-Version: 1.0 To: Alyssa Rowan , "cfrg@irtf.org" From: Yoav Nir Date: Fri, 31 Oct 2014 12:18:08 +0200 In-Reply-To: <545342CF.4090503@akr.io> References: <810FD859-5CE9-4163-9749-973ED4F810CA@gmail.com> <20141029194708.5993.qmail@cr.yp.to> <545342CF.4090503@akr.io> Content-Type: multipart/alternative; boundary="_7ADADC29-C7C2-4F72-ABE0-4792DA9ECE31_" Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/EEJXaQk45EpdDUm9oE9t6xEubHQ Subject: Re: [Cfrg] Actual security levels for IETF crypto X-BeenThere: cfrg@irtf.org 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, 31 Oct 2014 10:18:30 -0000 --_7ADADC29-C7C2-4F72-ABE0-4792DA9ECE31_ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Well all of that TLS needs to check OCSP or CRLs, so we'll always get some = HTTP, and there's captive portals. But if we can get real browser traffic t= o nearly all encrypted, then we've made some progress. -----Original Message----- From: "Alyssa Rowan" Sent: =E2=80=8E10/=E2=80=8E31/=E2=80=8E2014 10:05 To: "cfrg@irtf.org" Subject: Re: [Cfrg] Actual security levels for IETF crypto -----BEGIN PGP SIGNED MESSAGE-----=0A= Hash: SHA512=0A= =0A= On 31/10/2014 07:51, Randy Bush wrote:=0A= >> Those percentages actually seem rather low. While the IIJ data=0A= >> show roughly 5:1 ratio of 80 to 443, Firefox telemetry shows=0A= >> roughly 2:1. So substantially more HTTPS.=0A= > but numbers are good. and i sure am cheered by yours.=0A= =0A= Of course, what is needed is to get it to =E2=89=88100%.=0A= =0A= I think we recognise that high-performance strong crypto is needed by=0A= the TLS WG to do that. (Otherwise they could just use DHE-3072, etc.)=0A= =0A= - -- =0A= /akr=0A= -----BEGIN PGP SIGNATURE-----=0A= =0A= iQIcBAEBCgAGBQJUU0LPAAoJEOyEjtkWi2t6YfQP/iWewuT64HuqD60S3yywZ15A=0A= JBrM4k4SyG6sh1a3FfpaYa6p8SvBYOaVDWkVXxs/ptZmSN3oizrRIdoa8RRc/bkE=0A= BKHuS2XQvgVHkq42V8ObN+kdZAAEsBJWwYvpohGKZMEGOS6D08IHwIZp9M+rCk9t=0A= 4jPVVOVc7tXlV7ynbw7Vu1JQSiUJ96faIQZ3PNo+Rwqxr7pLKh9KeshF9CD/Y+de=0A= FdfNqzTdB/fUtfWaOUHHN+GpsoadEF5cjEdr2fOk+XxzGdddeuX8ssIpmZfYgUeL=0A= Jri/SlYmdTfN77mxlyzICy94g6ebFnAXqG9VWXgm/wApWPXdEjQ58YLvVHM9Xj/+=0A= kOsZQCAkCv9ajHNVYsvlhGxMMR06Xm4dUtOIjG09NMauyqpkWkSKx9e2BfMuhcwt=0A= NshPtu6VSJlOeQ/B+NuG3qFiVu63lmLV+sk90YVPQL1ejKnVQ2wPLoxVM5o2voHE=0A= ebm41QjZPcNWV9z7/7zq/Qf1UFJ8l9qX3lYPDUeKDs3yDU/0ca6s7IIbKmYBRTsq=0A= BV/QTDbtizuLWZN/+6pSG1RyKZ0tH3BlQklb31Zv9kov/Ftg5Bc1q+1FMY1c0S4K=0A= JdkBVw6F6QsJElkgo3sYeXzF3+iwcusRdQXkOPhdHGOWwejOvDGMo06VPI+ET+QW=0A= Ekxep7A73BpE0IZrOKfc=0A= =3DUAgK=0A= -----END PGP SIGNATURE-----=0A= =0A= _______________________________________________=0A= Cfrg mailing list=0A= Cfrg@irtf.org=0A= http://www.irtf.org/mailman/listinfo/cfrg=0A= --_7ADADC29-C7C2-4F72-ABE0-4792DA9ECE31_ Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"
Well all of that TLS needs to check OCSP or CRLs, so we'l= l always get some HTTP, and there's captive portals. But if we can get real= browser traffic to nearly all encrypted, then we've made some progress.
From: A= lyssa Rowan
Sent: =E2=80=8E10/=E2=80=8E31/=E2=80=8E20= 14 10:05
To: cfrg@irtf.o= rg
Subject: Re: [Cfrg] Actual security levels for IET= F crypto

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SH= A512

On 31/10/2014 07:51, Randy Bush wrote:
>> Those percen= tages actually seem rather low.  While the IIJ data
>> show r= oughly 5:1 ratio of 80 to 443, Firefox telemetry shows
>> roughly = 2:1. So substantially more HTTPS.
> but numbers are good.  and i= sure am cheered by yours.

Of course, what is needed is to get it to= =E2=89=88100%.

I think we recognise that high-performance strong cr= ypto is needed by
the TLS WG to do that. (Otherwise they could just use = DHE-3072, etc.)

- --
/akr
-----BEGIN PGP SIGNATURE-----
iQIcBAEBCgAGBQJUU0LPAAoJEOyEjtkWi2t6YfQP/iWewuT64HuqD60S3yywZ15A
JBrM4= k4SyG6sh1a3FfpaYa6p8SvBYOaVDWkVXxs/ptZmSN3oizrRIdoa8RRc/bkE
BKHuS2XQvgVH= kq42V8ObN+kdZAAEsBJWwYvpohGKZMEGOS6D08IHwIZp9M+rCk9t
4jPVVOVc7tXlV7ynbw7= Vu1JQSiUJ96faIQZ3PNo+Rwqxr7pLKh9KeshF9CD/Y+de
FdfNqzTdB/fUtfWaOUHHN+Gpso= adEF5cjEdr2fOk+XxzGdddeuX8ssIpmZfYgUeL
Jri/SlYmdTfN77mxlyzICy94g6ebFnAXq= G9VWXgm/wApWPXdEjQ58YLvVHM9Xj/+
kOsZQCAkCv9ajHNVYsvlhGxMMR06Xm4dUtOIjG09= NMauyqpkWkSKx9e2BfMuhcwt
NshPtu6VSJlOeQ/B+NuG3qFiVu63lmLV+sk90YVPQL1ejKn= VQ2wPLoxVM5o2voHE
ebm41QjZPcNWV9z7/7zq/Qf1UFJ8l9qX3lYPDUeKDs3yDU/0ca6s7I= IbKmYBRTsq
BV/QTDbtizuLWZN/+6pSG1RyKZ0tH3BlQklb31Zv9kov/Ftg5Bc1q+1FMY1c0= S4K
JdkBVw6F6QsJElkgo3sYeXzF3+iwcusRdQXkOPhdHGOWwejOvDGMo06VPI+ET+QW
= Ekxep7A73BpE0IZrOKfc
=3DUAgK
-----END PGP SIGNATURE-----

_____= __________________________________________
Cfrg mailing list
Cfrg@irt= f.org
http://www.irtf.org/mailman/listinfo/cfrg
= --_7ADADC29-C7C2-4F72-ABE0-4792DA9ECE31_-- From nobody Fri Oct 31 03:29:26 2014 Return-Path: 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 40A6F1A19E2 for ; Fri, 31 Oct 2014 03:29:24 -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 JiMGxVrtuhEC for ; Fri, 31 Oct 2014 03:29:22 -0700 (PDT) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAA331A19E4 for ; Fri, 31 Oct 2014 03:28:05 -0700 (PDT) Received: by mail-wi0-f170.google.com with SMTP id q5so908022wiv.1 for ; Fri, 31 Oct 2014 03:28:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:mime-version:to:cc:from:subject:date:in-reply-to :references:content-type; bh=3ZZngidZherzYEkTLJfrngWx+r090qJ6S+60Vw4JtAk=; b=TpNytnSdY46KHXmMWgThgqOYK065azFKmtJBXJIAdBYqn/4hy4cNpELu5LEL+cK30h tkPjQPljG0ElSdkF2R2GNgHbVHdC6nnySTjDYnUb3oYGkIAO7Tv5H3oAKjFLoTIK1OE3 6+fWJpRCmUGIbiuVoxLBe4JxivtqNOJnhSE6f4evxZ61EQBWZC4louft1s1sJM0FZXeQ PSe6qdHOBejEcT1ZUdcKWy4EocfwRPxc4icppueDt0z3qHPuhcjI6fSOgbl2hj45jcwt ZvBgkMSTtNwAsMtIO7MAAvPl4nVqTOYd14zLteyijELS5B67eEU385DcXUU0pe3BWa8g IUUw== X-Received: by 10.194.206.72 with SMTP id lm8mr27504776wjc.70.1414751283416; Fri, 31 Oct 2014 03:28:03 -0700 (PDT) Received: from [10.234.94.114] ([109.253.136.199]) by mx.google.com with ESMTPSA id t16sm11562823wjr.44.2014.10.31.03.28.01 for (version=SSLv3 cipher=RC4-SHA bits=128/128); Fri, 31 Oct 2014 03:28:02 -0700 (PDT) Message-ID: <54536432.f03dc20a.1c7a.5605@mx.google.com> MIME-Version: 1.0 To: Randy Bush , Alyssa Rowan From: Yoav Nir Date: Fri, 31 Oct 2014 12:27:46 +0200 In-Reply-To: References: <810FD859-5CE9-4163-9749-973ED4F810CA@gmail.com> <20141029194708.5993.qmail@cr.yp.to> <545342CF.4090503@akr.io> Content-Type: multipart/alternative; boundary="_965F32B2-C788-4A28-9978-6F1E6A31F43C_" Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/cgBwsMnzG5b6vvlhFhL5eaFrYrs Cc: IRTF CFRG Subject: Re: [Cfrg] Actual security levels for IETF crypto X-BeenThere: cfrg@irtf.org 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, 31 Oct 2014 10:29:24 -0000 --_965F32B2-C788-4A28-9978-6F1E6A31F43C_ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Marketing is interested in exactly two numbers: Session setup rate and conc= urrent session rate. For the first we have to estimate how many cycles a TLS handshake takes in = addition to the signature and ECDHE, then add that number to the numbers fr= om supercop and divide the result into the cycles a 'typical' server can do= in a second. Naively that's clock speed multiplied by core count, but in p= ractice some cycles go to other things. The second is more tricky because you have to define a profile for usage th= at mixes TLS handshakes with data traffic. Come to think of it, there is an IETF group that deals with benchmarking me= thodology. Having a standard test and showing new algorithms getting better= scores than current algorithms can go a long way.=20 -----Original Message----- From: "Randy Bush" Sent: =E2=80=8E10/=E2=80=8E31/=E2=80=8E2014 11:24 To: "Alyssa Rowan" Cc: "IRTF CFRG" Subject: Re: [Cfrg] Actual security levels for IETF crypto > Of course, what is needed is to get it to =E2=89=88100%.=0A= > I think we recognise that high-performance strong crypto is needed by=0A= > the TLS WG to do that. (Otherwise they could just use DHE-3072, etc.)=0A= =0A= agree. but, as has been a bit overdiscussed, we would like the servers=0A= and clients not to be biased against strength. maybe this is na=C3=AFve, b= ut=0A= one step in that direction is to get the performance numbers that have=0A= been published in recent days and in supercop into marketing form.=0A= and then strongly encourage tls and dnssec to *default* to strong=0A= crypto. i would appreciate help trying to get ed25519 into bgpsec,=0A= which is in draft.=0A= =0A= randy=0A= =0A= _______________________________________________=0A= Cfrg mailing list=0A= Cfrg@irtf.org=0A= http://www.irtf.org/mailman/listinfo/cfrg=0A= --_965F32B2-C788-4A28-9978-6F1E6A31F43C_ Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"
Marketing is interested in exactly two numbers: Session s= etup rate and concurrent session rate.

For the first we have to esti= mate how many cycles a TLS handshake takes in addition to the signature and= ECDHE, then add that number to the numbers from supercop and divide the re= sult into the cycles a 'typical' server can do in a second. Naively that's = clock speed multiplied by core count, but in practice some cycles go to oth= er things.

The second is more tricky because you have to define a pr= ofile for usage that mixes TLS handshakes with data traffic.

Come to= think of it, there is an IETF group that deals with benchmarking methodolo= gy. Having a standard test and showing new algorithms getting better scores= than current algorithms can go a long way.
From: Randy Bush
<= span style=3D"font-family: Calibri,sans-serif; font-size: 11pt; font-weight= : bold;">Sent: =E2=80=8E10/=E2=80=8E31/=E2=80=8E2014 11:24
Alyssa Rowan
Cc: = IRTF CFRG
Subject: <= /span>Re:= [Cfrg] Actual security levels for IETF crypto

> Of = course, what is needed is to get it to =E2=89=88100%.
> I think we re= cognise that high-performance strong crypto is needed by
> the TLS WG= to do that. (Otherwise they could just use DHE-3072, etc.)

agree.&n= bsp; but, as has been a bit overdiscussed, we would like the servers
and= clients not to be biased against strength.  maybe this is na=C3=AFve,= but
one step in that direction is to get the performance numbers that h= ave
been published in recent days and in supercop into <ugh> marke= ting form.
and then strongly encourage tls and dnssec to *default* to st= rong
crypto.  i would appreciate help trying to get ed25519 into bg= psec,
which is in draft.

randy

___________________________= ____________________
Cfrg mailing list
Cfrg@irtf.org
http://www.ir= tf.org/mailman/listinfo/cfrg
= --_965F32B2-C788-4A28-9978-6F1E6A31F43C_-- From nobody Fri Oct 31 06:19:59 2014 Return-Path: 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 AB6291A0022 for ; Fri, 31 Oct 2014 06:19:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no 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 I47SVOR63RhY for ; Fri, 31 Oct 2014 06:19:55 -0700 (PDT) Received: from mail-la0-x22a.google.com (mail-la0-x22a.google.com [IPv6:2a00:1450:4010:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EFFA1A0008 for ; Fri, 31 Oct 2014 06:19:54 -0700 (PDT) Received: by mail-la0-f42.google.com with SMTP id gq15so6226024lab.29 for ; Fri, 31 Oct 2014 06:19:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=S9kzuvcZoM2STI2cuqi224YklMizG4RZsgmI0aPDfdk=; b=ccVewlDdsShJDaWBtPjSNPG2QiiaZxd9CBmCGrjhbfuTbXcanOAaXN8PxovD8QGkc7 BC49rP9GNrE6y0HourphitKd1z2cSip5IjxESyNGUDmJa5XcC7LzF9BgvR4fG17/r0dB 26NXdCT8gD83Z8tO1OtI3S+2dM1Tcct7nLgV8LoTSRlCE8RIYVZofQOHo+WunT1u1stJ Mc7gd8JM33GRa8EqEG6hI/Nz3JnM2OuRK6x65H3SPeAsWx5dZHZLzunUcDlpU5H4T2EL 3AuhrVh/T8k4D4ZMH8d0MbScdtAGaDFo3lxUPxcZtJ5STN36JHl6eNjvZnyqNil350Jf 7yRQ== MIME-Version: 1.0 X-Received: by 10.112.134.39 with SMTP id ph7mr26247778lbb.45.1414761592369; Fri, 31 Oct 2014 06:19:52 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.214.163 with HTTP; Fri, 31 Oct 2014 06:19:52 -0700 (PDT) In-Reply-To: References: <810FD859-5CE9-4163-9749-973ED4F810CA@gmail.com> <20141029194708.5993.qmail@cr.yp.to> <545342CF.4090503@akr.io> Date: Fri, 31 Oct 2014 09:19:52 -0400 X-Google-Sender-Auth: H6blZXq9mgblHRABb9oRi1k9pC0 Message-ID: From: Phillip Hallam-Baker To: Randy Bush Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/7PhWn5V5a_Xkz9Oyct_1mWRVGSI Cc: IRTF CFRG Subject: Re: [Cfrg] Actual security levels for IETF crypto X-BeenThere: cfrg@irtf.org 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, 31 Oct 2014 13:19:56 -0000 On Fri, Oct 31, 2014 at 5:23 AM, Randy Bush wrote: >> Of course, what is needed is to get it to =E2=89=88100%. >> I think we recognise that high-performance strong crypto is needed by >> the TLS WG to do that. (Otherwise they could just use DHE-3072, etc.) > > agree. but, as has been a bit overdiscussed, we would like the servers > and clients not to be biased against strength. maybe this is na=C3=AFve,= but > one step in that direction is to get the performance numbers that have > been published in recent days and in supercop into marketing form. > and then strongly encourage tls and dnssec to *default* to strong > crypto. i would appreciate help trying to get ed25519 into bgpsec, > which is in draft. I would much rather we have one algorithm/curve for ~256 and we use that across all IETF crypto. If BGP is using something different from TLS then there is a real chance that it does not get the attention it should. Which is a way of saying that I think the original premise of this exercise is bogus. We are not really choosing algorithms for TLS alone, whatever we choose is going to be the defacto industry standard for everything. The only choice we have is whether to recognize that or not. Which in my view argues for ed25518 as the 'performance' curve. I think I am correct in saying that DJB has picked up more actual use of his curve than exists for any of the NIST curves in TLS. I don't think there is a solid argument for NUMS256 over ed25519. If people care so much about the additional rigidity of one extra bit then they are not going to be using ~256 anyway. The only strong reasons for going to ECC over RSA2048 are better performance and shorter keys/signatures. And only the performance reason is a really good one because DSA would give the short signatures. The security improvement is real but not the reason to change. So at ~256 I see two factors that should drive the decision, performance and backwards compatibility. Insecurity being a disqualification factor rather than a distinguishing factor. Which is a way of saying that maybe what we should do is to split the process and decide on the performance curve first and then decide on the ultra-confidence curve as a separate matter. I think we could probably come to a decision on the performance curve pretty quickly because it can be reduced to a set of disqualification factors and one ranking factor. The ultra-curve worries me because people keep proposing that we have two ranking factors and attempt a tradeoff. Which is nonsense when we don't know what the security differences really mean or what the impact of the performance differences are. The reason I want an ultra curve is simple, I need to have one algorithm that is beyond question so that I can use it to establish ground truths. Performance does not matter very much to me because I don't expect to be using it in latency sensitive situations except for validating proof chains. Since that is almost exclusively a client operation and clients rarely have to check more than one at once, it is not a major concern. From nobody Fri Oct 31 07:05:12 2014 Return-Path: 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 8928D1A9035 for ; Fri, 31 Oct 2014 07:05:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 GT_UtbCMEfBL for ; Fri, 31 Oct 2014 07:05:01 -0700 (PDT) Received: from mail-vc0-f178.google.com (mail-vc0-f178.google.com [209.85.220.178]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88D341A9025 for ; Fri, 31 Oct 2014 07:05:01 -0700 (PDT) Received: by mail-vc0-f178.google.com with SMTP id la4so1389926vcb.9 for ; Fri, 31 Oct 2014 07:05:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=STNxIizapifgrlDFG/JkB+XC5Y3lXxb8q4082dmZjdY=; b=KczIic1T7csrfgZbQ2hrGy2KQmUbI3r0qoxE/dsNnrC16YuAxEDB7vDZMAuARb+GM5 nEq8l9R9OPWMbXI/8L1Rsl4KizIh2qNuJY2bvU+5bSZzyjtjzXP7a5y3uR5ghy4IIlzp jFVVdZLrHQjk5gjYJ++a97Qu8b8W+V9JuzqMakcwl5Z+NywvHBYoZhwXTfY8K9IAHDBL NeixzO3MC28MS8OcXuBb33VS5mvEEIenpwOWBHJeg7OwAfvwg+lv0r8TY05Bgo+M8xYd 0IhArfC/s3y60fxS2cP2ze5r0jUHvOByLyZ7J+bIA8oHEGtZdgit90xbL2N63yPO9lzs Mxig== X-Gm-Message-State: ALoCoQkSj4Ci5a8DyjhoZO5hPdkJWN2fPXyuPhmGT0o3SRQot25/a482cS9O5QdKC12PIqMdcjbC MIME-Version: 1.0 X-Received: by 10.52.190.68 with SMTP id go4mr185497vdc.60.1414764300391; Fri, 31 Oct 2014 07:05:00 -0700 (PDT) Received: by 10.31.149.205 with HTTP; Fri, 31 Oct 2014 07:05:00 -0700 (PDT) In-Reply-To: <545342CF.4090503@akr.io> References: <810FD859-5CE9-4163-9749-973ED4F810CA@gmail.com> <20141029194708.5993.qmail@cr.yp.to> <545342CF.4090503@akr.io> Date: Fri, 31 Oct 2014 07:05:00 -0700 Message-ID: From: Richard Barnes To: Alyssa Rowan Content-Type: multipart/alternative; boundary=001a1133e56c911b7e0506b87b1a Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/28s-X7eHAyiAR8MQ74C5b3oCPvc Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] Actual security levels for IETF crypto X-BeenThere: cfrg@irtf.org 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, 31 Oct 2014 14:05:09 -0000 --001a1133e56c911b7e0506b87b1a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Oct 31, 2014 at 1:05 AM, Alyssa Rowan wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > On 31/10/2014 07:51, Randy Bush wrote: > >> Those percentages actually seem rather low. While the IIJ data > >> show roughly 5:1 ratio of 80 to 443, Firefox telemetry shows > >> roughly 2:1. So substantially more HTTPS. > > but numbers are good. and i sure am cheered by yours. > > Of course, what is needed is to get it to =E2=89=88100%. > > I think we recognise that high-performance strong crypto is needed by > the TLS WG to do that. (Otherwise they could just use DHE-3072, etc.) > The idea that whiz-bang new crypto is the main barrier to 100% HTTPS adoption seems rather na=C3=AFve. It helps, but there are several other, h= igher barriers, like having to manage certs. Or upgrade gear that only supports SSLv3. https://istlsfastyet.com/ http://poodle.io > > - -- > /akr > -----BEGIN PGP SIGNATURE----- > > iQIcBAEBCgAGBQJUU0LPAAoJEOyEjtkWi2t6YfQP/iWewuT64HuqD60S3yywZ15A > JBrM4k4SyG6sh1a3FfpaYa6p8SvBYOaVDWkVXxs/ptZmSN3oizrRIdoa8RRc/bkE > BKHuS2XQvgVHkq42V8ObN+kdZAAEsBJWwYvpohGKZMEGOS6D08IHwIZp9M+rCk9t > 4jPVVOVc7tXlV7ynbw7Vu1JQSiUJ96faIQZ3PNo+Rwqxr7pLKh9KeshF9CD/Y+de > FdfNqzTdB/fUtfWaOUHHN+GpsoadEF5cjEdr2fOk+XxzGdddeuX8ssIpmZfYgUeL > Jri/SlYmdTfN77mxlyzICy94g6ebFnAXqG9VWXgm/wApWPXdEjQ58YLvVHM9Xj/+ > kOsZQCAkCv9ajHNVYsvlhGxMMR06Xm4dUtOIjG09NMauyqpkWkSKx9e2BfMuhcwt > NshPtu6VSJlOeQ/B+NuG3qFiVu63lmLV+sk90YVPQL1ejKnVQ2wPLoxVM5o2voHE > ebm41QjZPcNWV9z7/7zq/Qf1UFJ8l9qX3lYPDUeKDs3yDU/0ca6s7IIbKmYBRTsq > BV/QTDbtizuLWZN/+6pSG1RyKZ0tH3BlQklb31Zv9kov/Ftg5Bc1q+1FMY1c0S4K > JdkBVw6F6QsJElkgo3sYeXzF3+iwcusRdQXkOPhdHGOWwejOvDGMo06VPI+ET+QW > Ekxep7A73BpE0IZrOKfc > =3DUAgK > -----END PGP SIGNATURE----- > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg > --001a1133e56c911b7e0506b87b1a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, Oct 31, 2014 at 1:05 AM, Alyssa Rowan <akr@akr.io>= ; wrote:
-----BEGIN= PGP SIGNED MESSAGE-----
Hash: SHA512

On 31/10/2014 07:51, Randy Bush wrote:
>> Those percentages actually seem rather low.=C2=A0 While the IIJ da= ta
>> show roughly 5:1 ratio of 80 to 443, Firefox telemetry shows
>> roughly 2:1. So substantially more HTTPS.
> but numbers are good.=C2=A0 and i sure am chee= red by yours.

Of course, what is needed is to get it to =E2=89=88100%.

I think we recognise that high-performance strong crypto is needed by
the TLS WG to do that. (Otherwise they could just use DHE-3072, etc.)

The idea that whiz-bang new crypto is the ma= in barrier to 100% HTTPS adoption seems rather na=C3=AFve.=C2=A0 It helps, = but there are several other, higher barriers, like having to manage certs.= =C2=A0 Or upgrade gear that only supports SSLv3.

https://istlsfastyet.com/

=C2=A0

- --
/akr
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJUU0LPAAoJEOyEjtkWi2t6YfQP/iWewuT64HuqD60S3yywZ15A
JBrM4k4SyG6sh1a3FfpaYa6p8SvBYOaVDWkVXxs/ptZmSN3oizrRIdoa8RRc/bkE
BKHuS2XQvgVHkq42V8ObN+kdZAAEsBJWwYvpohGKZMEGOS6D08IHwIZp9M+rCk9t
4jPVVOVc7tXlV7ynbw7Vu1JQSiUJ96faIQZ3PNo+Rwqxr7pLKh9KeshF9CD/Y+de
FdfNqzTdB/fUtfWaOUHHN+GpsoadEF5cjEdr2fOk+XxzGdddeuX8ssIpmZfYgUeL
Jri/SlYmdTfN77mxlyzICy94g6ebFnAXqG9VWXgm/wApWPXdEjQ58YLvVHM9Xj/+
kOsZQCAkCv9ajHNVYsvlhGxMMR06Xm4dUtOIjG09NMauyqpkWkSKx9e2BfMuhcwt
NshPtu6VSJlOeQ/B+NuG3qFiVu63lmLV+sk90YVPQL1ejKnVQ2wPLoxVM5o2voHE
ebm41QjZPcNWV9z7/7zq/Qf1UFJ8l9qX3lYPDUeKDs3yDU/0ca6s7IIbKmYBRTsq
BV/QTDbtizuLWZN/+6pSG1RyKZ0tH3BlQklb31Zv9kov/Ftg5Bc1q+1FMY1c0S4K
JdkBVw6F6QsJElkgo3sYeXzF3+iwcusRdQXkOPhdHGOWwejOvDGMo06VPI+ET+QW
Ekxep7A73BpE0IZrOKfc
=3DUAgK
-----END PGP SIGNATURE-----

_______________________________________________
Cfrg mailing list
Cfrg@irtf.org
htt= p://www.irtf.org/mailman/listinfo/cfrg

--001a1133e56c911b7e0506b87b1a-- From nobody Fri Oct 31 07:11:01 2014 Return-Path: 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 268261A0083 for ; Fri, 31 Oct 2014 07:10:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 lzloqZvvWm00 for ; Fri, 31 Oct 2014 07:10:57 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id EDD6E1A0055 for ; Fri, 31 Oct 2014 07:10:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 638B6BE0F; Fri, 31 Oct 2014 14:10:56 +0000 (GMT) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0nAJPHGy9TTG; Fri, 31 Oct 2014 14:10:56 +0000 (GMT) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 42E33BE0D; Fri, 31 Oct 2014 14:10:56 +0000 (GMT) Message-ID: <54539870.2050003@cs.tcd.ie> Date: Fri, 31 Oct 2014 14:10:56 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Richard Barnes , Alyssa Rowan References: <810FD859-5CE9-4163-9749-973ED4F810CA@gmail.com> <20141029194708.5993.qmail@cr.yp.to> <545342CF.4090503@akr.io> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/ym5EAA4JSRaFFvLGBB6Dh4pgl8Q Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] Actual security levels for IETF crypto X-BeenThere: cfrg@irtf.org 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, 31 Oct 2014 14:10:59 -0000 On 31/10/14 14:05, Richard Barnes wrote: > The idea that whiz-bang new crypto is the main barrier to 100% HTTPS > adoption seems rather naïve. It helps, I agree. Of course, having CFRG decide on precisely which whiz-bang new crypto would be a good next step:-) S. From nobody Fri Oct 31 07:14:35 2014 Return-Path: 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 5E7031A902C for ; Fri, 31 Oct 2014 07:14:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 FKJUJNFRFpn9 for ; Fri, 31 Oct 2014 07:14:20 -0700 (PDT) Received: from mail-yk0-x233.google.com (mail-yk0-x233.google.com [IPv6:2607:f8b0:4002:c07::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 559A21A9025 for ; Fri, 31 Oct 2014 07:14:20 -0700 (PDT) Received: by mail-yk0-f179.google.com with SMTP id 131so3342745ykp.10 for ; Fri, 31 Oct 2014 07:14:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=YZbSBoyhZ6pFJxTaQ3HC7gF3d5RRmQxLxYBdirt1IkY=; b=mfhB9MPjTEN1AXV5kcF4amFjtZ2/MBTa+Hmxi7Ux5PmV4j9Ncfi7TYBiIxJ7XY5QP3 U32RHSthb4GvBqheQUBHkmxYhYKfw2+6XSPPoM+R7W1nLHHSfjf+sUULOSKuiT9turPy K6CrIQe7hIJmexXJTUS6vdU0y/2rmILmv/cETWah54WTpKl6RnJda+aFxQEWPUp8T8x9 pALZJE38TmO5Q2x3JlGyfqymIh1N/KYzX7j1vp3Z5+eGkrVV1Hffk1ZYQjTkkmnUQkJ3 BtuseIWJ5j8Q+YPHlEiJTr0vPsJFqXPK3Wom7/k5flCYwHsThjpivlzim/C+VGj5YS5y OWzw== MIME-Version: 1.0 X-Received: by 10.236.7.52 with SMTP id 40mr9260507yho.172.1414764859611; Fri, 31 Oct 2014 07:14:19 -0700 (PDT) Received: by 10.170.195.149 with HTTP; Fri, 31 Oct 2014 07:14:19 -0700 (PDT) In-Reply-To: <54539870.2050003@cs.tcd.ie> References: <810FD859-5CE9-4163-9749-973ED4F810CA@gmail.com> <20141029194708.5993.qmail@cr.yp.to> <545342CF.4090503@akr.io> <54539870.2050003@cs.tcd.ie> Date: Fri, 31 Oct 2014 07:14:19 -0700 Message-ID: From: Watson Ladd To: Stephen Farrell Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/Ck0BkJy0qPvTyP0V9Gv1MxZk3TA Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] Actual security levels for IETF crypto X-BeenThere: cfrg@irtf.org 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, 31 Oct 2014 14:14:25 -0000 On Fri, Oct 31, 2014 at 7:10 AM, Stephen Farrell wrote: > > > On 31/10/14 14:05, Richard Barnes wrote: >> The idea that whiz-bang new crypto is the main barrier to 100% HTTPS >> adoption seems rather na=C3=AFve. It helps, > > I agree. Of course, having CFRG decide on precisely > which whiz-bang new crypto would be a good next step:-) But our choices are not the fastest ones! We've decided to have genus 1 prime, no CM, which is a very conservative choice, but not necessarily the fastest. Anyway, since Benjamin Black has said he doesn't actually think we should pick NUMS, but do our own picking, I think the answer is clear... > > S. > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg --=20 "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Fri Oct 31 07:32:07 2014 Return-Path: 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 E22701A9029 for ; Fri, 31 Oct 2014 07:32:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 Ev4xHEcoii8q for ; Fri, 31 Oct 2014 07:32:03 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D3F01A8AB7 for ; Fri, 31 Oct 2014 07:32:02 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id q5so1468187wiv.5 for ; Fri, 31 Oct 2014 07:32:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=tlSKkA/WE+rG2mgY7EjQIWFsnbsAmggMQLjEdggcudE=; b=LGPQNckfuMiJ13hT6TZXRdOvsRViw1IfRv7xDpbTed5QL5CVANfChROKDJnH6vJYZN Sj5B79Nl2B3z0GMhkge4NIz9mxFJ8FWiUjsIlG4yUkkbRDyJ+/tOauunat1WMAz9gl2T ifcSMwTD5rdohFvW/aaLoes91JS9jr+TLLtkwGExeWAcyHyyDLWMLe0S+ovrb/R3GMOb vKHFqmE5inwnvKUMLVACmiG2DIQ453hi2MyJ2V9fi4XcshIYRmqblKw1hY/stCuwKGun QCa01mVnfUyUTa7Bq3jjSPsh4NPflRDS77pybR3mDJUMCgDOU7+S/zfvvwKqH7s6hif0 mnLg== X-Gm-Message-State: ALoCoQlkmxIJzhnssTPkCiACfB9BfJiuc4aDBglmTVH8HB6wHWfeugCLgllKI/ZIcC0U+KefRY3w X-Received: by 10.194.242.4 with SMTP id wm4mr27563557wjc.61.1414765921349; Fri, 31 Oct 2014 07:32:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.217.14.70 with HTTP; Fri, 31 Oct 2014 07:31:41 -0700 (PDT) In-Reply-To: References: <810FD859-5CE9-4163-9749-973ED4F810CA@gmail.com> <20141029194708.5993.qmail@cr.yp.to> <545342CF.4090503@akr.io> <54539870.2050003@cs.tcd.ie> From: Benjamin Black Date: Fri, 31 Oct 2014 07:31:41 -0700 Message-ID: To: Watson Ladd Content-Type: multipart/alternative; boundary=089e01419af62ec7670506b8dc00 Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/HxlcvIxMiQSRocZZI_aIjCPgPPI Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] Actual security levels for IETF crypto X-BeenThere: cfrg@irtf.org 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, 31 Oct 2014 14:32:06 -0000 --089e01419af62ec7670506b8dc00 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Watson, Where exactly did I say "don't pick NUMS"? b On Fri, Oct 31, 2014 at 7:14 AM, Watson Ladd wrote: > On Fri, Oct 31, 2014 at 7:10 AM, Stephen Farrell > wrote: > > > > > > On 31/10/14 14:05, Richard Barnes wrote: > >> The idea that whiz-bang new crypto is the main barrier to 100% HTTPS > >> adoption seems rather na=C3=AFve. It helps, > > > > I agree. Of course, having CFRG decide on precisely > > which whiz-bang new crypto would be a good next step:-) > > But our choices are not the fastest ones! We've decided to have genus > 1 prime, no CM, which is a very conservative choice, but not > necessarily the fastest. > > Anyway, since Benjamin Black has said he doesn't actually think we > should pick NUMS, but do our own picking, I think the answer is > clear... > > > > S. > > > > _______________________________________________ > > Cfrg mailing list > > Cfrg@irtf.org > > http://www.irtf.org/mailman/listinfo/cfrg > > > > -- > "Those who would give up Essential Liberty to purchase a little > Temporary Safety deserve neither Liberty nor Safety." > -- Benjamin Franklin > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg > --089e01419af62ec7670506b8dc00 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Watson,

Where exactly did I say "d= on't pick NUMS"?


b

On Fri, Oct 3= 1, 2014 at 7:14 AM, Watson Ladd <watsonbladd@gmail.com> = wrote:
On Fri, Oct 31, 2= 014 at 7:10 AM, Stephen Farrell
<stephen.farrell@cs.tcd.ie<= /a>> wrote:
>
>
> On 31/10/14 14:05, Richard Barnes wrote:
>> The idea that whiz-bang new crypto is the main barrier to 100% HTT= PS
>> adoption seems rather na=C3=AFve.=C2=A0 It helps,
>
> I agree. Of course, having CFRG decide on precisely
> which whiz-bang new crypto would be a good next step:-)

But our choices are not the fastest ones! We've decided to have = genus
1 prime, no CM, which is a very conservative choice, but not
necessarily the fastest.

Anyway, since Benjamin Black has said he doesn't actually think we
should pick NUMS, but do our own picking, I think the answer is
clear...
>
> S.
>
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> http://www.irtf.org/mailman/listinfo/cfrg



--
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither=C2=A0 Liberty nor Safety."
-- Benjamin Franklin

____________________________= ___________________
Cfrg mailing list
Cfrg@irtf.org
htt= p://www.irtf.org/mailman/listinfo/cfrg

--089e01419af62ec7670506b8dc00-- From nobody Fri Oct 31 07:35:42 2014 Return-Path: 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 6D4111A000E for ; Fri, 31 Oct 2014 07:35:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 xESh2tJeJ43M for ; Fri, 31 Oct 2014 07:35:38 -0700 (PDT) Received: from mail-yk0-x233.google.com (mail-yk0-x233.google.com [IPv6:2607:f8b0:4002:c07::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 829131A0079 for ; Fri, 31 Oct 2014 07:35:38 -0700 (PDT) Received: by mail-yk0-f179.google.com with SMTP id 131so3362121ykp.10 for ; Fri, 31 Oct 2014 07:35:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=RJ4kMUpGjsN33JjcpbpnG5bfBidpDKOHgApmiadzHJ4=; b=i7to/T6L2+Ad5qGGhb9lJd6gTzYbU7cy519bf3KfyMdBdg6vRTBbEXAZ3zRg2e3hHt bNK9MmmY+etWqZNXTesaIxgr34lbS/pDPqF8tVWY++MEsMbJTLyPbUDtIq0ICrRK26GT 401dGBRDfErTIdR7iyitvMPJ5a6wrrD/5K30Zz9gblG8lJyqh/4SMMb9Z7hE0RfUDeyA MyyOGhXkm28dnVhDv6U7LI/pGzRbJ8a9R6dGHNM2o2Q4d7QXwnfl2KTJjO4QXa1ZvV+p eSDLiHZerjVzfodApG6CA0jOf03QFEdMvJ3l96E+afAkjjwl5s92qmyUnIex+Un1gpTu SfSQ== MIME-Version: 1.0 X-Received: by 10.236.53.69 with SMTP id f45mr14123682yhc.65.1414766137832; Fri, 31 Oct 2014 07:35:37 -0700 (PDT) Received: by 10.170.195.149 with HTTP; Fri, 31 Oct 2014 07:35:37 -0700 (PDT) In-Reply-To: References: <810FD859-5CE9-4163-9749-973ED4F810CA@gmail.com> <20141029194708.5993.qmail@cr.yp.to> <545342CF.4090503@akr.io> <54539870.2050003@cs.tcd.ie> Date: Fri, 31 Oct 2014 07:35:37 -0700 Message-ID: From: Watson Ladd To: Benjamin Black Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/ZmkG5xZkjmx_00PuhVSxFfauaoE Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] Actual security levels for IETF crypto X-BeenThere: cfrg@irtf.org 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, 31 Oct 2014 14:35:40 -0000 On Fri, Oct 31, 2014 at 7:31 AM, Benjamin Black wrote: > Watson, > > Where exactly did I say "don't pick NUMS"? On October 29 "I've also said repeatedly that we should be starting from requirements and then consider _generating_ curves to meet them, rather than limiting ourselves to the curves at hand or trying to contort the requirements to match an existing favorite." That seems to suggest that we don't pick any curves, but instead generate new ones. > > > b > > On Fri, Oct 31, 2014 at 7:14 AM, Watson Ladd wrot= e: >> >> On Fri, Oct 31, 2014 at 7:10 AM, Stephen Farrell >> wrote: >> > >> > >> > On 31/10/14 14:05, Richard Barnes wrote: >> >> The idea that whiz-bang new crypto is the main barrier to 100% HTTPS >> >> adoption seems rather na=C3=AFve. It helps, >> > >> > I agree. Of course, having CFRG decide on precisely >> > which whiz-bang new crypto would be a good next step:-) >> >> But our choices are not the fastest ones! We've decided to have genus >> 1 prime, no CM, which is a very conservative choice, but not >> necessarily the fastest. >> >> Anyway, since Benjamin Black has said he doesn't actually think we >> should pick NUMS, but do our own picking, I think the answer is >> clear... >> > >> > S. >> > >> > _______________________________________________ >> > Cfrg mailing list >> > Cfrg@irtf.org >> > http://www.irtf.org/mailman/listinfo/cfrg >> >> >> >> -- >> "Those who would give up Essential Liberty to purchase a little >> Temporary Safety deserve neither Liberty nor Safety." >> -- Benjamin Franklin >> >> _______________________________________________ >> Cfrg mailing list >> Cfrg@irtf.org >> http://www.irtf.org/mailman/listinfo/cfrg > > --=20 "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Fri Oct 31 07:37:31 2014 Return-Path: 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 CB0B41A904E for ; Fri, 31 Oct 2014 07:37:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 NsS5rT8BVPmj for ; Fri, 31 Oct 2014 07:37:19 -0700 (PDT) Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E0CF1A9045 for ; Fri, 31 Oct 2014 07:37:17 -0700 (PDT) Received: by mail-wi0-f180.google.com with SMTP id hi2so1492343wib.1 for ; Fri, 31 Oct 2014 07:37:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=2HRggsKa+39aQu4E6eYCI1KbHkU2NJ/EmozBT0pQkz4=; b=FSwwHvyJjI1kVaJg6Xk3f42hZt4Qz948A2AKFkVkvpMGoObOaJlU/IVl+jdYjw032C uDrBNvI/AFzjLe1mrEt8qF7lAicKcxcnjUuKrcbg0wYkV61wpm7k5yBPktsAinyIe/cK 3aYXafxxXP17YLsxWYZZp1DCtuaKhpiAblBiV7Q56B0S9MP0ryk6PL5eIlfJE2BhB9sY xFGFAk4BWNfxY9pb2X77yM+6Ka+m5wWudn3PbzQvt99YTDopk8pLtIf7yaI5zrwa/SPV citPNF9q+k7jFe4mwQbX9D6lEo+mBR1qaRnYRzMl0Umws1V7JYR8OYJyEHCuLEirwuOL MzPA== X-Gm-Message-State: ALoCoQnA1EM0pFBv13Q34oT+bX5VxwqUK0xcqgpAt9IJh1ShtyCDXhN6KuLRjBsHWbYnL7kOwdqN X-Received: by 10.194.209.230 with SMTP id mp6mr28482639wjc.2.1414766236260; Fri, 31 Oct 2014 07:37:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.217.14.70 with HTTP; Fri, 31 Oct 2014 07:36:56 -0700 (PDT) In-Reply-To: <545342CF.4090503@akr.io> References: <810FD859-5CE9-4163-9749-973ED4F810CA@gmail.com> <20141029194708.5993.qmail@cr.yp.to> <545342CF.4090503@akr.io> From: Benjamin Black Date: Fri, 31 Oct 2014 07:36:56 -0700 Message-ID: To: Alyssa Rowan Content-Type: multipart/alternative; boundary=047d7b3a8c08f3f3fa0506b8ee77 Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/xwccZbJe83SIfoKAO8PZCDDCA8k Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] Actual security levels for IETF crypto X-BeenThere: cfrg@irtf.org 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, 31 Oct 2014 14:37:26 -0000 --047d7b3a8c08f3f3fa0506b8ee77 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Oct 31, 2014 at 1:05 AM, Alyssa Rowan wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > On 31/10/2014 07:51, Randy Bush wrote: > >> Those percentages actually seem rather low. While the IIJ data > >> show roughly 5:1 ratio of 80 to 443, Firefox telemetry shows > >> roughly 2:1. So substantially more HTTPS. > > but numbers are good. and i sure am cheered by yours. > > Of course, what is needed is to get it to =E2=89=88100%. > > I think we recognise that high-performance strong crypto is needed by > the TLS WG to do that. (Otherwise they could just use DHE-3072, etc.) > > Implicit in this argument is that TLS doesn't already have crypto with sufficient performance and strength and that a meaningful percentage of sites will refuse to move to TLS until a certain performance threshold is achieved. I have seen no data supporting these claims. I want faster crypto, too, to reduce costs and shave milliseconds. In the mean time, I'm moving sites to HTTPS as fast as I can. b --047d7b3a8c08f3f3fa0506b8ee77 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Oct 31, 2014 at 1:05 AM, Alyssa Rowan <akr@akr.io> wrote:
-----BEGIN PGP SIGNED MESSAGE= -----
Hash: SHA512

On 31/10/2014 07:51, Randy Bush wrote:
>> Those percentages actually seem rather low.=C2=A0 While the IIJ da= ta
>> show roughly 5:1 ratio of 80 to 443, Firefox telemetry shows
>> roughly 2:1. So substantially more HTTPS.
> but numbers are good.=C2=A0 and i sure am chee= red by yours.

Of course, what is needed is to get it to =E2=89=88100%.

I think we recognise that high-performance strong crypto is needed by
the TLS WG to do that. (Otherwise they could just use DHE-3072, etc.)


Implicit in th= is argument is that TLS doesn't already have crypto with sufficient per= formance and strength and that a meaningful percentage of sites will refuse= to move to TLS until a certain performance threshold is achieved. I have s= een no data supporting these claims.

I want faster= crypto, too, to reduce costs and shave milliseconds. In the mean time, I&#= 39;m moving sites to HTTPS as fast as I can.


<= /div>
b

--047d7b3a8c08f3f3fa0506b8ee77-- From nobody Fri Oct 31 07:39:59 2014 Return-Path: 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 D17FE1A9049 for ; Fri, 31 Oct 2014 07:39:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 4iRgUe_p2w0V for ; Fri, 31 Oct 2014 07:39:54 -0700 (PDT) Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB6651A9042 for ; Fri, 31 Oct 2014 07:39:51 -0700 (PDT) Received: by mail-wi0-f176.google.com with SMTP id h11so1506614wiw.3 for ; Fri, 31 Oct 2014 07:39:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=ymLFxOLr6r94s1IGktSylbNJ2Q4iuPA7LmZWLUG5DT0=; b=SCpS2oZg6XTgp8SdH2JjUBV8MelpgrBbo1Qki+Xq+vuNL01z/zGk7B0sR4b4zb4HFL JhdfEvZsl2Y7nbvW7F3gSo1RRWP2IPeJKaGuM/gzDwdtz54gX6JDrRH/GvaQ3e7kJg7j G3RciLM7+TORpe52KbcOFpi3Ja1OBSS6MIx/GGFwoaEI5PTiOZLUeHKtAFtdmYbmh5iG 2/W1ADgq7KnRC1WZEmFl4chKF6sSWLmlOvexwAYE7hQtFSUYXXHSlvq18fvHz9Q3VyIA IXnypQpfnAvqf7OFuxWIg0Du6VaiiVB45DdCB1etRm4XD81PEj6dFya0aQdMQVcWs63Q NKTQ== X-Gm-Message-State: ALoCoQkODMskZQKAQEzW/fwWbOZXbZqbqYj+lz5IR+0zpX4GnyRyovXdpXIwMXt6GBSfXukJ4lid X-Received: by 10.194.81.70 with SMTP id y6mr3129233wjx.113.1414766390408; Fri, 31 Oct 2014 07:39:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.217.14.70 with HTTP; Fri, 31 Oct 2014 07:39:30 -0700 (PDT) In-Reply-To: References: <810FD859-5CE9-4163-9749-973ED4F810CA@gmail.com> <20141029194708.5993.qmail@cr.yp.to> <545342CF.4090503@akr.io> <54539870.2050003@cs.tcd.ie> From: Benjamin Black Date: Fri, 31 Oct 2014 07:39:30 -0700 Message-ID: To: Watson Ladd Content-Type: multipart/alternative; boundary=047d7bf0ca4a240bfb0506b8f8f5 Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/7730H1oPoorBPqUlqmZmdyfza3Y Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] Actual security levels for IETF crypto X-BeenThere: cfrg@irtf.org 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, 31 Oct 2014 14:39:57 -0000 --047d7bf0ca4a240bfb0506b8f8f5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Right, I didn't say don't pick NUMS. I said I believe the process should've gone a direction it did not, which would've rejected _ALL_ current candidates in favor of CFRG generating new ones. That is no more my saying "don't pick NUMS" than your saying you want genus 2 on the table is the same as your saying "don't pick Curve25519". On Fri, Oct 31, 2014 at 7:35 AM, Watson Ladd wrote: > On Fri, Oct 31, 2014 at 7:31 AM, Benjamin Black wrote: > > Watson, > > > > Where exactly did I say "don't pick NUMS"? > > On October 29 > "I've also said repeatedly that we should be starting from > requirements and then consider _generating_ curves to meet them, > rather than limiting ourselves to the curves at hand or trying to > contort the requirements to match an existing favorite." > > That seems to suggest that we don't pick any curves, but instead > generate new ones. > > > > > > > b > > > > On Fri, Oct 31, 2014 at 7:14 AM, Watson Ladd > wrote: > >> > >> On Fri, Oct 31, 2014 at 7:10 AM, Stephen Farrell > >> wrote: > >> > > >> > > >> > On 31/10/14 14:05, Richard Barnes wrote: > >> >> The idea that whiz-bang new crypto is the main barrier to 100% HTTP= S > >> >> adoption seems rather na=C3=AFve. It helps, > >> > > >> > I agree. Of course, having CFRG decide on precisely > >> > which whiz-bang new crypto would be a good next step:-) > >> > >> But our choices are not the fastest ones! We've decided to have genus > >> 1 prime, no CM, which is a very conservative choice, but not > >> necessarily the fastest. > >> > >> Anyway, since Benjamin Black has said he doesn't actually think we > >> should pick NUMS, but do our own picking, I think the answer is > >> clear... > >> > > >> > S. > >> > > >> > _______________________________________________ > >> > Cfrg mailing list > >> > Cfrg@irtf.org > >> > http://www.irtf.org/mailman/listinfo/cfrg > >> > >> > >> > >> -- > >> "Those who would give up Essential Liberty to purchase a little > >> Temporary Safety deserve neither Liberty nor Safety." > >> -- Benjamin Franklin > >> > >> _______________________________________________ > >> Cfrg mailing list > >> Cfrg@irtf.org > >> http://www.irtf.org/mailman/listinfo/cfrg > > > > > > > > -- > "Those who would give up Essential Liberty to purchase a little > Temporary Safety deserve neither Liberty nor Safety." > -- Benjamin Franklin > --047d7bf0ca4a240bfb0506b8f8f5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Right, I didn't say don't pick NUMS. I said I beli= eve the process should've gone a direction it did not, which would'= ve rejected _ALL_ current candidates in favor of CFRG generating new ones. = That is no more my saying "don't pick NUMS" than your saying = you want genus 2 on the table is the same as your saying "don't pi= ck Curve25519".

On Fri, Oct 31, 2014 at 7:35 AM, Watson Ladd <= ;watsonbladd@gma= il.com> wrote:
On Fri, Oct 31, 2014 at 7:31 AM, Benjamin Black <b@b3k.us> wrote:
> Watson,
>
> Where exactly did I say "don't pick NUMS"?

On October 29
"I've also said repeatedly that we should b= e starting from
requirements and then consider _generating_ curves to meet them,
rather than limiting ourselves to the curves at hand or trying to
contort the requirements to match an existing favorite."

That seems to suggest that we don't pick any curves, but in= stead
generate new ones.

>
>
> b
>
> On Fri, Oct 31, 2014 at 7:14 AM, Watson Ladd <watsonbladd@gmail.com> wrote:
>>
>> On Fri, Oct 31, 2014 at 7:10 AM, Stephen Farrell
>> <stephen.farrell@c= s.tcd.ie> wrote:
>> >
>> >
>> > On 31/10/14 14:05, Richard Barnes wrote:
>> >> The idea that whiz-bang new crypto is the main barrier to= 100% HTTPS
>> >> adoption seems rather na=C3=AFve.=C2=A0 It helps,
>> >
>> > I agree. Of course, having CFRG decide on precisely
>> > which whiz-bang new crypto would be a good next step:-)
>>
>> But our choices are not the fastest ones! We've decided to hav= e genus
>> 1 prime, no CM, which is a very conservative choice, but not
>> necessarily the fastest.
>>
>> Anyway, since Benjamin Black has said he doesn't actually thin= k we
>> should pick NUMS, but do our own picking, I think the answer is >> clear...
>> >
>> > S.
>> >
>> > _______________________________________________
>> > Cfrg mailing list
>> > Cfrg@irtf.org
>> > http://www.irtf.org/mailman/listinfo/cfrg
>>
>>
>>
>> --
>> "Those who would give up Essential Liberty to purchase a litt= le
>> Temporary Safety deserve neither=C2=A0 Liberty nor Safety." >> -- Benjamin Franklin
>>
>> _______________________________________________
>> Cfrg mailing list
>> Cfrg@irtf.org
>> http://www.irtf.org/mailman/listinfo/cfrg
>
>



--
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither=C2=A0 Liberty nor Safety."
-- Benjamin Franklin

--047d7bf0ca4a240bfb0506b8f8f5-- From nobody Fri Oct 31 07:43:11 2014 Return-Path: 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 1CC4E1A9040 for ; Fri, 31 Oct 2014 07:43:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 mASx3eo7L4Ys for ; Fri, 31 Oct 2014 07:43:07 -0700 (PDT) Received: from mail-yh0-x231.google.com (mail-yh0-x231.google.com [IPv6:2607:f8b0:4002:c01::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE8841A9028 for ; Fri, 31 Oct 2014 07:43:06 -0700 (PDT) Received: by mail-yh0-f49.google.com with SMTP id t59so2692804yho.8 for ; Fri, 31 Oct 2014 07:43:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Bbr0mdfULXu/43jPoEDnyW9vE/GlU0/q5KNPJrgXpyg=; b=vCK9SJATptwRfmR2fuZ0r+FhQr34vaDhVfgPcEoEZC2Q4Gw29xLqtrEWgMRmqgK2jj 1qNC23ms5t7egvznG0zpNaV7n4W6VXJdKK1mNrdgZYHk1CeAQ+uA7UgPFPKdmYeF7/jT /9L9kawrJgp1nGgLdxfRBpru0QsZ8ig3xMro40dc4ioTLVn4YN73deZR+r3y7UQ8BBzd fsNpx7tbPhn/qMealYwyRhTl598YZAF+wEyOFCn/7hVrlN9kVbYU09ShykaT1n5NCfQq xQISLFKXfugEP1urFXZaNSbgHod3KDZZMZY/9AuhabgASgKDQ0p7oE7J/R6vWlS88ube JZVA== MIME-Version: 1.0 X-Received: by 10.170.207.141 with SMTP id y135mr24755286yke.28.1414766586037; Fri, 31 Oct 2014 07:43:06 -0700 (PDT) Received: by 10.170.195.149 with HTTP; Fri, 31 Oct 2014 07:43:05 -0700 (PDT) In-Reply-To: References: <810FD859-5CE9-4163-9749-973ED4F810CA@gmail.com> <20141029194708.5993.qmail@cr.yp.to> <545342CF.4090503@akr.io> <54539870.2050003@cs.tcd.ie> Date: Fri, 31 Oct 2014 07:43:05 -0700 Message-ID: From: Watson Ladd To: Benjamin Black Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/tTfgQ8dzEh6GIfbSaQ4_SVxfuvU Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] Actual security levels for IETF crypto X-BeenThere: cfrg@irtf.org 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, 31 Oct 2014 14:43:09 -0000 On Fri, Oct 31, 2014 at 7:39 AM, Benjamin Black wrote: > Right, I didn't say don't pick NUMS. I said I believe the process should'= ve > gone a direction it did not, which would've rejected _ALL_ current > candidates in favor of CFRG generating new ones. That is no more my sayin= g > "don't pick NUMS" than your saying you want genus 2 on the table is the s= ame > as your saying "don't pick Curve25519". The unimportant question is why would we reject candidates for existing? The important question is: What's the case for NUMS vs. the other curves? Or do I have to go write this email myself? > > On Fri, Oct 31, 2014 at 7:35 AM, Watson Ladd wrot= e: >> >> On Fri, Oct 31, 2014 at 7:31 AM, Benjamin Black wrote: >> > Watson, >> > >> > Where exactly did I say "don't pick NUMS"? >> >> On October 29 >> "I've also said repeatedly that we should be starting from >> requirements and then consider _generating_ curves to meet them, >> rather than limiting ourselves to the curves at hand or trying to >> contort the requirements to match an existing favorite." >> >> That seems to suggest that we don't pick any curves, but instead >> generate new ones. >> >> > >> > >> > b >> > >> > On Fri, Oct 31, 2014 at 7:14 AM, Watson Ladd >> > wrote: >> >> >> >> On Fri, Oct 31, 2014 at 7:10 AM, Stephen Farrell >> >> wrote: >> >> > >> >> > >> >> > On 31/10/14 14:05, Richard Barnes wrote: >> >> >> The idea that whiz-bang new crypto is the main barrier to 100% HTT= PS >> >> >> adoption seems rather na=C3=AFve. It helps, >> >> > >> >> > I agree. Of course, having CFRG decide on precisely >> >> > which whiz-bang new crypto would be a good next step:-) >> >> >> >> But our choices are not the fastest ones! We've decided to have genus >> >> 1 prime, no CM, which is a very conservative choice, but not >> >> necessarily the fastest. >> >> >> >> Anyway, since Benjamin Black has said he doesn't actually think we >> >> should pick NUMS, but do our own picking, I think the answer is >> >> clear... >> >> > >> >> > S. >> >> > >> >> > _______________________________________________ >> >> > Cfrg mailing list >> >> > Cfrg@irtf.org >> >> > http://www.irtf.org/mailman/listinfo/cfrg >> >> >> >> >> >> >> >> -- >> >> "Those who would give up Essential Liberty to purchase a little >> >> Temporary Safety deserve neither Liberty nor Safety." >> >> -- Benjamin Franklin >> >> >> >> _______________________________________________ >> >> Cfrg mailing list >> >> Cfrg@irtf.org >> >> http://www.irtf.org/mailman/listinfo/cfrg >> > >> > >> >> >> >> -- >> "Those who would give up Essential Liberty to purchase a little >> Temporary Safety deserve neither Liberty nor Safety." >> -- Benjamin Franklin > > --=20 "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Fri Oct 31 07:56:26 2014 Return-Path: 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 365031A908A for ; Fri, 31 Oct 2014 07:56:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.208 X-Spam-Level: X-Spam-Status: No, score=-4.208 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=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 KczL7tsNaatQ for ; Fri, 31 Oct 2014 07:56:13 -0700 (PDT) Received: from mx1.ll.mit.edu (MX1.LL.MIT.EDU [129.55.12.45]) by ietfa.amsl.com (Postfix) with ESMTP id A37181A907D for ; Fri, 31 Oct 2014 07:56:13 -0700 (PDT) Received: from LLE2K10-HUB02.mitll.ad.local (LLE2K10-HUB02.mitll.ad.local) by mx1.ll.mit.edu (unknown) with ESMTP id s9VEu9H8021798; Fri, 31 Oct 2014 10:56:10 -0400 From: "Blumenthal, Uri - 0558 - MITLL" To: Watson Ladd , Benjamin Black Thread-Topic: [Cfrg] Actual security levels for IETF crypto Thread-Index: AQHP87EfyBJktumKTkOlVDCBDIGoOpxJZl4AgAAE4ICAAKamgIAACKeAgAAEBoCAAGRsAIAAAagAgAAA8oCAAATagIAAARqAgAABFQCAAAEBgP//wIOA Date: Fri, 31 Oct 2014 14:56:09 +0000 Message-ID: References: <810FD859-5CE9-4163-9749-973ED4F810CA@gmail.com> <20141029194708.5993.qmail@cr.yp.to> <545342CF.4090503@akr.io> <54539870.2050003@cs.tcd.ie> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-originating-ip: [172.25.177.187] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3497597751_15913479" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.28, 0.0.0000 definitions=2014-10-31_05:2014-10-31,2014-10-31,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1410310146 Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/7IEu_7M52X1CWI2KkVqTfNDPkTg Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] Actual security levels for IETF crypto X-BeenThere: cfrg@irtf.org 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, 31 Oct 2014 14:56:22 -0000 --B_3497597751_15913479 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable On 10/31/14, 10:43 , "Watson Ladd" wrote: >The unimportant question is why would we reject candidates for existing? IF we were to reject the existing candidates - the reason for that would be group=E2=80=99s desire to come up with *verifiably random-generated* curves so that Nothing-Up-My-Sleeve argument would hold. I personally am in favor of randomly generated curves, because I think that performance penalty they are likely to incur would be justified by public confidence in their security. It is more difficult to prove that you did not =E2=80=9Ccook=E2=80=9D your curve if it = is generated in other ways. >The important question is: >What's the case for NUMS vs. the other curves? Or do I have to go >write this email myself? :-) --B_3497597751_15913479 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIUOAYJKoZIhvcNAQcCoIIUKTCCFCUCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGgghIHMIIE6jCCA9KgAwIBAgIKH0XZoAAAAAABzTANBgkqhkiG9w0BAQsFADBRMQswCQYD VQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJ MRMwEQYDVQQDEwpNSVRMTCBDQS0zMB4XDTE0MDQxNjIxNTMwMloXDTE1MDQxNjIxNTMwMlow YTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNV BAsTBlBlb3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQCx/gK75UYos2g8JavX0BVfe3TCGsmjQY34z9ZVeucP 8dGtqRA8T5i1OKdf++Jd81a0/qQA6mIGyzTW6lOtY+77qKUJtEeLM5URd+iv2EejAwxsa2B5 pMq9L9qWuVokR1rTEfEcuUeKR1Kko6xmRE/y6AzBnUhTvHx2X9F6JSVdR36Lx3R62CNeQqFi ZDeHuTI8AhRY4UdPkri1FTDxV6gLYaLKxsGIurrL/6EzdlkX8ImTcxKzEmxX1VjTPy9ZRNYj akDGcJF9clCfcwbq3DI3gAUkVxXf+UbHEjzOCVNQcoga7bYbBUuDpN25Lc86P9RaOiiICtyu ZZP2P/2kkKYRAgMBAAGjggGyMIIBrjAdBgNVHQ4EFgQUEN9QHIi9GvlGjs9Th46jrfPir+Uw DgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1Ud HwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYB BQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExD QTMwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3 FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+KcwIBZAIBBTAi BgNVHSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAYBgNVHSAEETAPMA0GCyqGSIb3 EgIBAwEIMBkGA1UdEQQSMBCBDnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABM AFUAcwBlAHIAUwBpAGcALQBTAFcwDQYJKoZIhvcNAQELBQADggEBAL2kCh9ovO8AbHgAVU6T eH5qRmKnOrfTUfn9JnHzkspdWMQA1IdtftSpiZZ7C3lCmblSDCgPqbQl4zMZxXeTgxnQsB6m 1LA6uDHM/0G27RcOJH4OTN9sQ0/2CKb4JPIXXIps1z+s8XjSRzPJZuD8fPC8R8QWvOH3owL2 BLzZebZTOMa5yws3kohY02vP/Clv0KQXYVzUZUYXoYmhUSYmQ1UZZZSFJ2rNdgNn0z8fPrUQ NIYlVaJV0kKQYjlHWTfomVapLEfIY7xRHZy9g997IjYReD0t9IZd6tTwcJES+2ijFM8l/fxk u/cQ4WCYyI+58DaBaV9p68/AC147b0HhvLUwggS8MIIDpKADAgECAgEpMA0GCSqGSIb3DQEB BQUAMFQxCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQww CgYDVQQLEwNQS0kxFjAUBgNVBAMTDU1JVExMIFJvb3QgQ0EwHhcNMTMxMjE3MDAwMDAwWhcN MjAxMjMxMjM1OTU5WjBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFi b3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2jBSdW18tuW1tNxG6h8B0kqckFZQAAtoHCkvUpUEX6jF vBd8mQI53GyLYRuAo4HWJpe7/izFXOfSJDs6UM5ovvCOfXg2bJgDYlBC9JDcLBFIn0nppOu9 RvpjWSixtC56crwJ5Us5QPdtxtKdek5LJXl2oKw3w8lihUixePbxWad1m7ZMKKagvm9zTybP 6FumKRxeYJjSpB2+cAYjoGGEbSVHyx8uzHm6xAoBMHxa8by+yDz8Jzk6sP9iilgP3iXSGoCA mhyBzvlQQ5QNNWP+Emo9jz/ukKhYVB/VwdxtoquPAqn4ifDAIaM9dtb05cy1gXAFSP3Z/iUk xyBZZUORfwIDAQABo4IBmjCCAZYwEgYDVR0TAQH/BAgwBgEB/wIBADAdBgNVHQ4EFgQU12Bm DntJjXVMDf3PRt7IxxKHyr8wHwYDVR0jBBgwFoAUZ6p6z/QKprlytYqg0p3yEMND7SkwDgYD VR0PAQH/BAQDAgGGMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0cDovL2NybC5s bC5taXQuZWR1L2dldHRvP0xMUkNBMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5sbC5taXQu ZWR1L29jc3AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNy bD9MTFJDQTCBkgYDVR0gBIGKMIGHMA0GCyqGSIb3EgIBAwEGMA0GCyqGSIb3EgIBAwEIMA0G CyqGSIb3EgIBAwEHMA0GCyqGSIb3EgIBAwEJMA0GCyqGSIb3EgIBAwEKMA0GCyqGSIb3EgIB AwELMA0GCyqGSIb3EgIBAwEOMA0GCyqGSIb3EgIBAwEPMA0GCyqGSIb3EgIBAwEQMA0GCSqG SIb3DQEBBQUAA4IBAQAsf9HBn72qU7UTgkxarjAc7iynhcDEgWwezYKtd/SLGSQ0DhtzIV/L TCxqULjOd+H+HTqMJXB8+nHnzhyqQ43RsnGZOFT5RfzPh94db/ZJ3ql244DwlJI7yXBA2DkZ cEEgOWC9bHcrElzU6NnigahSW5odVJrhmH/XhQAcMS77E5H62yyxK1WPPgcBipGVnu1xSHbT iHe7DqfWQ2tVMLUf23XYhIua94kJsQd4jSh71NVD0e7F4snAoqQMI98MzDYeLOkjlzKRs77r /aMsPAKx6nMaOvRL7Cy0Pjp51i2qFkbGmX8ofnh2kerjTTvRJ/g22r1MV8RR1PktjMsNOsPf MIIDgzCCAmugAwIBAgIBATANBgkqhkiG9w0BAQUFADBUMQswCQYDVQQGEwJVUzEfMB0GA1UE ChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRYwFAYDVQQDEw1NSVRM TCBSb290IENBMB4XDTA4MDkyMzEyMDAwMFoXDTI5MTIzMTIzNTk1OVowVDELMAkGA1UEBhMC VVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTEWMBQG A1UEAxMNTUlUTEwgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMVO KRdYsiay+a2Kv1wQCoPd5AkwExuwcNDRhaRCdQN17K+lCCKvf9VSQToAsA6q1bACtZUcMv5Z Kx8z5KG4jK9cM40NvEkf/bIOZAHJqzKgWG3N9NqrcAhimcXTXYQIdp1DgjtdADKVLAjXaYpD 2PbpE/JbAPnqKzOENa3Py9CegB0abTlOyLgwXWY/rXTW+4L/hipJ6+sI/ZtrFRmsKGhuwAKo bFr0FDP6uIfx+RaWJcJ1QBIdgM4aohvW8JeriSSMyf/LlFpXTZFcM9SOX0f7wmsYi1yFuKFM nQbkSkxvnpBKMRxrg+98seSbbEnIkvB0C9qBDPLb/lQAvmpW6oMCAwEAAaNgMF4wDwYDVR0T AQH/BAUwAwEB/zAdBgNVHQ4EFgQUZ6p6z/QKprlytYqg0p3yEMND7SkwHwYDVR0jBBgwFoAU Z6p6z/QKprlytYqg0p3yEMND7SkwCwYDVR0PBAQDAgGGMA0GCSqGSIb3DQEBBQUAA4IBAQA+ G20FYNB4eNhKWF+PyT5DUtzlABFkf2IM2VGNUBova0GeKX3I1Nf02qDU/GO2H9ETvnvTYhvf gQ4UB/5EImTkKPa7/TVG/MQ7SgmAmne8xELVbGLFrrytly8PyYtZtngb6DgeEUv+SwFnzcLO 1vg1rdmss3kwsqy0q8e2VYAY8zTptEzyJG36aXcIMbqOxWS/LbPjNuPdgJfO3d1WrHr1Etaa a0QRLqQoZj07dYY7Wo5EDqU+AUAMz9ZVRGK1s5b/jv5Wz/YroyqWFnH2KkNxRn9+2Ar7g3rn rOMZvp6psq2jbDXiPBod1wyMKn8x5y4cuGPNFcqjfyY/HX90ivQAMIIEzjCCA7agAwIBAgIK PVEvPAAAAACTsDANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlU IExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0y MB4XDTE0MDIxMjE4NTMwMVoXDTE1MDIxMjE4NTMwMVowYTELMAkGA1UEBhMCVVMxHzAdBgNV BAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsTBlBlb3BsZTEgMB4GA1UEAxMX Qmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCKHhhu75bRiOvWhbZ//TxS76yI2d+rHN2s8bp8wxW8oMjmsaplLeGQusUFRyRNSkfYtdB4 YApjnV6TCxS0Mqzly5BaoeZWoP+CbbMDNGYMszus9iFj22SSlTzGRo+gaL6rqsDKdwDOzs3C PYqh4Uu8sLzEq+QD9rhqAuMJ76635JKWELxK0uDehpNBMCGqVeAY8ht5u2h4ojPdwiuDQDW2 QxWRJjPDL8n1JczuEHY71jHldER3b2+UhpDDYRQ9aVOiGCjW8BwJOruVsBfLNxyDxgffNQ1D 1konuneMpL9H2S8ciHOdy5+Gi7snCQJ+7w30rIJ2NTldWaY6avZAaCa3AgMBAAGjggGWMIIB kjAdBgNVHQ4EFgQUZ7oGjnu6gWRmom/4UswgdVBW/3wwDgYDVR0PAQH/BAQDAgUgMB8GA1Ud IwQYMBaAFI5KfYmhYxccgYg0VzcmRV4Zin4kMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9j cmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTIwYgYIKwYBBQUHAQEEVjBUMC0GCCsGAQUFBzAC hiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTIwIwYIKwYBBQUHMAGGF2h0dHA6 Ly9vY3NwLmxsLm1pdC5lZHUvMAwGA1UdEwEB/wQCMAAwPQYJKwYBBAGCNxUHBDAwLgYmKwYB BAGCNxUIg4PlHYfsp2aGrYcVg+rwRYW2oR8dhevQcIPr7SACAWQCAQQwJQYDVR0lBB4wHAYE VR0lAAYIKwYBBQUHAwQGCisGAQQBgjcKAwQwGAYDVR0gBBEwDzANBgsqhkiG9xICAQMBCDAZ BgNVHREEEjAQgQ51cmlAbGwubWl0LmVkdTANBgkqhkiG9w0BAQsFAAOCAQEAJiU3WfJ9GvGJ iDNPClLazyh252wxxOc/TmClMKtyqHnbFObDEoXAMaoHGxrvs+lU8fU2F2ELpV8q8eYgqLLw 7PG09z5s/GkajlxVZ/FHj/9hNHTfwlicrCRY3zrna1GbOMZgWFz8R6akAoLKpqGulNrvjvU8 c63U+JVmgJmBPCMv5JlH10m87+WPJ+ToK0m4XfZjl7n5OKDJ/hOyBwbBntc+W2gDppfR1BCt DNfEG0+zHjFqF+Of1Q5NI5abhgvw5IEuVA1M4SV/utwmmdreBEv/YuLnDd/PhVgQwp3LHGCX X1dANyiKso2aACl9jrkylq39cA/WgvAlS21w9vxVpDGCAfUwggHxAgEBMF8wUTELMAkGA1UE BhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTET MBEGA1UEAxMKTUlUTEwgQ0EtMwIKH0XZoAAAAAABzTANBglghkgBZQMEAgEFAKBpMC8GCSqG SIb3DQEJBDEiBCBzs/ilT5rjoi4glKFmXJTaBqIAL55VRlpgEajEW0iV5zAYBgkqhkiG9w0B CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNDEwMzExNDU1NTFaMA0GCSqGSIb3 DQEBAQUABIIBAFl6RGS0fgWMnxUl6oP03k8kNThlYAnn6NZ8jcfrvx609vsKF/V98k2HKiqV aRCdyeoaBtCUWZGxeqRkxgz47I/kui9q1KzLTZsgKyBtebzIRmRq+I8I0WQStB5LQjOYLhwG gIqVHsUBSa+gr7WfVOT4CMQJCcmO8XLgJU7ZyKRhlbY82ntniXSVzLjJvd7KuZjZPWo3ojFq hP+tmkyoRq/bCQ3cx0TJ8fHqS4Mi8H9YUQGcCi9HXuBsPE0Pl1lCZ0oXtbQJlGRpWRixE6IR CfbbCFXq1WiZQjsaGILXosFHWV5X5NeIkH16BzJyj/iqXNhCfGCMSlj5shdrx/U2t2A= --B_3497597751_15913479-- From nobody Fri Oct 31 10:43:52 2014 Return-Path: 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 89B0B1A001E for ; Fri, 31 Oct 2014 10:43:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-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 04vL7Benrthd for ; Fri, 31 Oct 2014 10:43:43 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0640.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::640]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83AB01A010C for ; Fri, 31 Oct 2014 10:43:33 -0700 (PDT) Received: from DBXPR03MB383.eurprd03.prod.outlook.com (10.141.10.15) by DBXPR03MB384.eurprd03.prod.outlook.com (10.141.10.20) with Microsoft SMTP Server (TLS) id 15.1.6.9; Fri, 31 Oct 2014 17:14:36 +0000 Received: from DBXPR03MB383.eurprd03.prod.outlook.com ([10.141.10.15]) by DBXPR03MB383.eurprd03.prod.outlook.com ([10.141.10.15]) with mapi id 15.01.0011.000; Fri, 31 Oct 2014 17:14:35 +0000 From: "Paterson, Kenny" To: Watson Ladd , Stephen Farrell Thread-Topic: [Cfrg] Actual security levels for IETF crypto Thread-Index: AQHP87EfpcATo+d+GUO7EuDRvuoy0JxJI08AgAAE4YCAAKamgIAACKeAgAAEBoCAAGRsAIAAAagAgAAA8oCAACGTgA== Date: Fri, 31 Oct 2014 17:14:35 +0000 Message-ID: References: <810FD859-5CE9-4163-9749-973ED4F810CA@gmail.com> <20141029194708.5993.qmail@cr.yp.to> <545342CF.4090503@akr.io> <54539870.2050003@cs.tcd.ie> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [134.219.148.47] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:DBXPR03MB384; x-exchange-antispam-report-test: UriScan:; x-forefront-prvs: 03818C953D x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(51704005)(24454002)(199003)(189002)(479174003)(105586002)(106116001)(4396001)(106356001)(97736003)(120916001)(20776003)(21056001)(74482002)(122556002)(92726001)(86362001)(19580405001)(46102003)(66066001)(77156002)(40100003)(54356999)(107046002)(64706001)(83506001)(87936001)(93886004)(36756003)(31966008)(50986999)(101416001)(76176999)(95666004)(92566001)(19580395003)(99396003)(2656002)(62966003); DIR:OUT; SFP:1101; SCL:1; SRVR:DBXPR03MB384; H:DBXPR03MB383.eurprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: rhul.ac.uk Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/lFgOPr54ttSGqOTi5wgutN1eJNQ Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] Actual security levels for IETF crypto X-BeenThere: cfrg@irtf.org 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, 31 Oct 2014 17:43:45 -0000 Watson, On 31/10/2014 14:14, "Watson Ladd" wrote: > >But our choices are not the fastest ones! We've decided to have genus >1 prime, no CM, which is a very conservative choice, but not >necessarily the fastest. I believe that a conservative approach is merited, given the potential impact of getting it wrong. I don't think the world is ready for anything too bleeding-edge right now - in which category I include genus 2 curves. Thanks Kenny=20 From nobody Fri Oct 31 10:47:12 2014 Return-Path: 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 803661A0191 for ; Fri, 31 Oct 2014 10:47:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 PcjBgDWz-qFg for ; Fri, 31 Oct 2014 10:47:06 -0700 (PDT) Received: from mail-wg0-f51.google.com (mail-wg0-f51.google.com [74.125.82.51]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AF7B1A0169 for ; Fri, 31 Oct 2014 10:47:04 -0700 (PDT) Received: by mail-wg0-f51.google.com with SMTP id l18so6996653wgh.24 for ; Fri, 31 Oct 2014 10:47:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=cVzMr9n8H5FbBjbNLQIsk1xy+Bwi7nlgvqelunW3sF8=; b=e+orI+PRplXEPlC1VJfrXSkIJBEtSvLZvCTLmQA5C4OUz9UekthbA2oEYRoFTjESwB YoTOuIqXq5zjySYCKYvBucXzYeNbodQrnr3U491kgP7Dz6TnjQHOnpyMqCWEexu1RiZ/ a2q43r04Dz9lpyKbQOkupNAAP7B7HeV51AEO2WnjQalP7LE4/0xEyb/Urs/JNo5bqeld WzyO1bo40IikCzGN8PnkHZ0jwJ39RN7ta9h8O8u61kflzlbpLZLBOGIYqTty01EiWvV4 6OwszDd6fSFqcChwPIxteb59PgEscRieGLujHr0/sXLjAe41iSLILTnb47loTe1j2mnb Na5Q== X-Gm-Message-State: ALoCoQn33noYWB/CnlFdGT2W7mlI37Byk3lLqNHrChxHWyfjUmLr3zvZtbH/r1xvJnwgxWcPx5ha X-Received: by 10.194.209.230 with SMTP id mp6mr29706271wjc.2.1414777623264; Fri, 31 Oct 2014 10:47:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.217.14.70 with HTTP; Fri, 31 Oct 2014 10:46:43 -0700 (PDT) In-Reply-To: References: From: Benjamin Black Date: Fri, 31 Oct 2014 10:46:43 -0700 Message-ID: To: "Paterson, Kenny" Content-Type: multipart/alternative; boundary=047d7b3a8c08abd90c0506bb95fc Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/EUId8ji2BlnVT48GcN0XEmNpTD8 Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] new curves or old (was: Actual security levels for IETF crypto) X-BeenThere: cfrg@irtf.org 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, 31 Oct 2014 17:47:09 -0000 --047d7b3a8c08abd90c0506bb95fc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Yes. "Keeping in mind that this may induce negative performance impacts, but could increase confidence in the outcome of our deliberations." The process should allow both random and selected primes, even if CFRG decides to only use one or the other to meet the TLS-WG request. Agreeing on the process allows us to avoid this lengthy debate in future should other curves be needed to meet specific requirements. On Fri, Oct 31, 2014 at 10:34 AM, Paterson, Kenny wrote: > Hi > > We could still go down the route of generating fresh curves if there's > consensus for it on the list. > > So let's do a quick poll: > > - Who on the list would be in favour of using a to-be-agreed procedure to > generate new curves, instead of selecting from amongst the curves that ar= e > currently on the table? > > (Keeping in mind that this may induce negative performance impacts, but > could increase confidence in the outcome of our deliberations.) > > Replies should being with a one-word answer - "yes" or "no". > Justifications for positions can be included if you wish, but right now > I'm more interested in the raw, 1-bit answer. > > Thanks, > > Kenny > > > On 31/10/2014 14:39, "Benjamin Black" wrote: > > >Right, I didn't say don't pick NUMS. I said I believe the process > >should've gone a direction it did not, which would've rejected _ALL_ > >current candidates in favor of CFRG generating new ones. That is no more > >my saying "don't pick NUMS" than your > > saying you want genus 2 on the table is the same as your saying "don't > >pick Curve25519". > > > >On Fri, Oct 31, 2014 at 7:35 AM, Watson Ladd > > wrote: > > > >On Fri, Oct 31, 2014 at 7:31 AM, Benjamin Black wrote: > >> Watson, > >> > >> Where exactly did I say "don't pick NUMS"? > > > >On October 29 > >"I've also said repeatedly that we should be starting from > >requirements and then consider _generating_ curves to meet them, > >rather than limiting ourselves to the curves at hand or trying to > >contort the requirements to match an existing favorite." > > > > > > > >That seems to suggest that we don't pick any curves, but instead > >generate new ones. > > > >> > >> > >> b > >> > >> On Fri, Oct 31, 2014 at 7:14 AM, Watson Ladd > >>wrote: > >>> > >>> On Fri, Oct 31, 2014 at 7:10 AM, Stephen Farrell > >>> wrote: > >>> > > >>> > > >>> > On 31/10/14 14:05, Richard Barnes wrote: > >>> >> The idea that whiz-bang new crypto is the main barrier to 100% HTT= PS > >>> >> adoption seems rather na=C3=AFve. It helps, > >>> > > >>> > I agree. Of course, having CFRG decide on precisely > >>> > which whiz-bang new crypto would be a good next step:-) > >>> > >>> But our choices are not the fastest ones! We've decided to have genus > >>> 1 prime, no CM, which is a very conservative choice, but not > >>> necessarily the fastest. > >>> > >>> Anyway, since Benjamin Black has said he doesn't actually think we > >>> should pick NUMS, but do our own picking, I think the answer is > >>> clear... > >>> > > >>> > S. > >>> > > >>> > _______________________________________________ > >>> > Cfrg mailing list > >>> > Cfrg@irtf.org > >>> > http://www.irtf.org/mailman/listinfo/cfrg > >>> > >>> > >>> > >>> -- > >>> "Those who would give up Essential Liberty to purchase a little > >>> Temporary Safety deserve neither Liberty nor Safety." > >>> -- Benjamin Franklin > >>> > >>> _______________________________________________ > >>> Cfrg mailing list > >>> Cfrg@irtf.org > >>> http://www.irtf.org/mailman/listinfo/cfrg > >> > >> > > > > > > > >-- > >"Those who would give up Essential Liberty to purchase a little > >Temporary Safety deserve neither Liberty nor Safety." > >-- Benjamin Franklin > > > > > > > > > > > > > > > > --047d7b3a8c08abd90c0506bb95fc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Yes.

"Keeping in mind that this may induce negati= ve performance impacts, but
could increase confidence in the outcome of our de= liberations."

<= div>The process should allow both random and selected primes, even if CFRG = decides to only use one or the other to meet the TLS-WG request. Agreeing o= n the process allows us to avoid this lengthy debate in future should other= curves be needed to meet specific requirements.

On Fri, Oct 31, 2014 at 10= :34 AM, Paterson, Kenny <Kenny.Paterson@rhul.ac.uk> = wrote:
Hi

We could still go down the route of generating fresh curves if there's<= br> consensus for it on the list.

So let's do a quick poll:

- Who on the list would be in favour of using a to-be-agreed procedure to generate new curves, instead of selecting from amongst the curves that are<= br> currently on the table?

(Keeping in mind that this may induce negative performance impacts, but
could increase confidence in the outcome of our deliberations.)

Replies should being with a one-word answer - "yes" or "no&q= uot;.
Justifications for positions can be included if you wish, but right now
I'm more interested in the raw, 1-bit answer.

Thanks,

Kenny


On 31/10/2014 14:39, "Benjamin Black" <b@b3k.us> wrote:

>Right, I didn't say don't pick NUMS. I said I believe the proce= ss
>should've gone a direction it did not, which would've rejected = _ALL_
>current candidates in favor of CFRG generating new ones. That is no mor= e
>my saying "don't pick NUMS" than your
> saying you want genus 2 on the table is the same as your saying "= don't
>pick Curve25519".
>
>On Fri, Oct 31, 2014 at 7:35 AM, Watson Ladd
><watsonbladd@gmail.com&= gt; wrote:
>
>On Fri, Oct 31, 2014 at 7:31 AM, Benjamin Black <b@b3k.us> wrote:
>> Watson,
>>
>> Where exactly did I say "don't pick NUMS"?
>
>On October 29
>"I've also said repeatedly that we should be starting from
>requirements and then consider _generating_ curves to meet them,
>rather than limiting ourselves to the curves at hand or trying to
>contort the requirements to match an existing favorite."
>
>
>
>That seems to suggest that we don't pick any curves, but instead >generate new ones.
>
>>
>>
>> b
>>
>> On Fri, Oct 31, 2014 at 7:14 AM, Watson Ladd <watsonbladd@gmail.com>
>>wrote:
>>>
>>> On Fri, Oct 31, 2014 at 7:10 AM, Stephen Farrell
>>> <stephen.farre= ll@cs.tcd.ie> wrote:
>>> >
>>> >
>>> > On 31/10/14 14:05, Richard Barnes wrote:
>>> >> The idea that whiz-bang new crypto is the main barrie= r to 100% HTTPS
>>> >> adoption seems rather na=C3=AFve.=C2=A0 It helps,
>>> >
>>> > I agree. Of course, having CFRG decide on precisely
>>> > which whiz-bang new crypto would be a good next step:-) >>>
>>> But our choices are not the fastest ones! We've decided to= have genus
>>> 1 prime, no CM, which is a very conservative choice, but not >>> necessarily the fastest.
>>>
>>> Anyway, since Benjamin Black has said he doesn't actually = think we
>>> should pick NUMS, but do our own picking, I think the answer i= s
>>> clear...
>>> >
>>> > S.
>>> >
>>> > _______________________________________________
>>> > Cfrg mailing list
>>> > Cfrg@irtf.org
>>> > http://www.irtf.org/mailman/listinfo/cfrg
>>>
>>>
>>>
>>> --
>>> "Those who would give up Essential Liberty to purchase a = little
>>> Temporary Safety deserve neither=C2=A0 Liberty nor Safety.&quo= t;
>>> -- Benjamin Franklin
>>>
>>> _______________________________________________
>>> Cfrg mailing list
>>> Cfrg@irtf.org
>>> http://www.irtf.org/mailman/listinfo/cfrg
>>
>>
>
>
>
>--
>"Those who would give up Essential Liberty to purchase a little >Temporary Safety deserve neither=C2=A0 Liberty nor Safety."
>-- Benjamin Franklin
>
>
>
>
>
>
>


--047d7b3a8c08abd90c0506bb95fc-- From nobody Fri Oct 31 10:53:34 2014 Return-Path: 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 4F95B1A001E for ; Fri, 31 Oct 2014 10:53:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.207 X-Spam-Level: X-Spam-Status: No, score=-4.207 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=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 7viXm_dj55Zf for ; Fri, 31 Oct 2014 10:53:27 -0700 (PDT) Received: from mx1.ll.mit.edu (MX1.LL.MIT.EDU [129.55.12.45]) by ietfa.amsl.com (Postfix) with ESMTP id C164E1A0012 for ; Fri, 31 Oct 2014 10:53:26 -0700 (PDT) Received: from LLE2K10-HUB02.mitll.ad.local (LLE2K10-HUB02.mitll.ad.local) by mx1.ll.mit.edu (unknown) with ESMTP id s9VHrOWu032041; Fri, 31 Oct 2014 13:53:24 -0400 From: "Blumenthal, Uri - 0558 - MITLL" To: Benjamin Black , "Paterson, Kenny" , "cfrg@irtf.org" Thread-Topic: [Cfrg] new curves or old (was: Actual security levels for IETF crypto) Thread-Index: AQHP9TOQw2SN02Hv2kOqA1VdWTRJXw== Date: Fri, 31 Oct 2014 17:53:23 +0000 Message-ID: References: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-originating-ip: [172.25.177.187] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3497608391_16546108" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.28, 0.0.0000 definitions=2014-10-31_08:2014-10-31,2014-10-31,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1410310167 Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/dF-w0qm6RJZuTbG5fwr8VxzV1aE Subject: Re: [Cfrg] new curves or old (was: Actual security levels for IETF crypto) X-BeenThere: cfrg@irtf.org 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, 31 Oct 2014 17:53:32 -0000 --B_3497608391_16546108 Content-type: multipart/alternative; boundary="B_3497608390_16506599" --B_3497608390_16506599 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Yes. I concur with Benjamin=E2=80=99s reasoning. --=20 Regards, Uri Blumenthal Voice: (781) 981-1638 From: Benjamin Black > Yes.=20 >=20 > "Keeping in mind that this may induce negative performance impacts, but > could increase confidence in the outcome of our deliberations." >=20 > The process should allow both random and selected primes, even if CFRG de= cides > to only use one or the other to meet the TLS-WG request. Agreeing on the > process allows us to avoid this lengthy debate in future should other cur= ves > be needed to meet specific requirements. >=20 > On Fri, Oct 31, 2014 at 10:34 AM, Paterson, Kenny > wrote: >> Hi >>=20 >> We could still go down the route of generating fresh curves if there's >> consensus for it on the list. >>=20 >> So let's do a quick poll: >>=20 >> - Who on the list would be in favour of using a to-be-agreed procedure t= o >> generate new curves, instead of selecting from amongst the curves that a= re >> currently on the table? >>=20 >> (Keeping in mind that this may induce negative performance impacts, but >> could increase confidence in the outcome of our deliberations.) >>=20 >> Replies should being with a one-word answer - "yes" or "no". >> Justifications for positions can be included if you wish, but right now >> I'm more interested in the raw, 1-bit answer. >>=20 >> Thanks, >>=20 >> Kenny >>=20 >>=20 >> On 31/10/2014 14:39, "Benjamin Black" wrote: >>=20 >>> >Right, I didn't say don't pick NUMS. I said I believe the process >>> >should've gone a direction it did not, which would've rejected _ALL_ >>> >current candidates in favor of CFRG generating new ones. That is no mo= re >>> >my saying "don't pick NUMS" than your >>> > saying you want genus 2 on the table is the same as your saying "don'= t >>> >pick Curve25519". >>> > >>> >On Fri, Oct 31, 2014 at 7:35 AM, Watson Ladd >>> > wrote: >>> > >>> >On Fri, Oct 31, 2014 at 7:31 AM, Benjamin Black wrote: >>>> >> Watson, >>>> >> >>>> >> Where exactly did I say "don't pick NUMS"? >>> > >>> >On October 29 >>> >"I've also said repeatedly that we should be starting from >>> >requirements and then consider _generating_ curves to meet them, >>> >rather than limiting ourselves to the curves at hand or trying to >>> >contort the requirements to match an existing favorite." >>> > >>> > >>> > >>> >That seems to suggest that we don't pick any curves, but instead >>> >generate new ones. >>> > >>>> >> >>>> >> >>>> >> b >>>> >> >>>> >> On Fri, Oct 31, 2014 at 7:14 AM, Watson Ladd >>>> >>wrote: >>>>> >>> >>>>> >>> On Fri, Oct 31, 2014 at 7:10 AM, Stephen Farrell >>>>> >>> wrote: >>>>>> >>> > >>>>>> >>> > >>>>>> >>> > On 31/10/14 14:05, Richard Barnes wrote: >>>>>>> >>> >> The idea that whiz-bang new crypto is the main barrier to 10= 0% HTTPS >>>>>>> >>> >> adoption seems rather na=C3=AFve. It helps, >>>>>> >>> > >>>>>> >>> > I agree. Of course, having CFRG decide on precisely >>>>>> >>> > which whiz-bang new crypto would be a good next step:-) >>>>> >>> >>>>> >>> But our choices are not the fastest ones! We've decided to have g= enus >>>>> >>> 1 prime, no CM, which is a very conservative choice, but not >>>>> >>> necessarily the fastest. >>>>> >>> >>>>> >>> Anyway, since Benjamin Black has said he doesn't actually think w= e >>>>> >>> should pick NUMS, but do our own picking, I think the answer is >>>>> >>> clear... >>>>>> >>> > >>>>>> >>> > S. >>>>>> >>> > >>>>>> >>> > _______________________________________________ >>>>>> >>> > Cfrg mailing list >>>>>> >>> > Cfrg@irtf.org >>>>>> >>> > http://www.irtf.org/mailman/listinfo/cfrg >>>>> >>> >>>>> >>> >>>>> >>> >>>>> >>> -- >>>>> >>> "Those who would give up Essential Liberty to purchase a little >>>>> >>> Temporary Safety deserve neither Liberty nor Safety." >>>>> >>> -- Benjamin Franklin >>>>> >>> >>>>> >>> _______________________________________________ >>>>> >>> Cfrg mailing list >>>>> >>> Cfrg@irtf.org >>>>> >>> http://www.irtf.org/mailman/listinfo/cfrg >>>> >> >>>> >> >>> > >>> > >>> > >>> >-- >>> >"Those who would give up Essential Liberty to purchase a little >>> >Temporary Safety deserve neither Liberty nor Safety." >>> >-- Benjamin Franklin >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>=20 >=20 --B_3497608390_16506599 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable
Yes.

=
I concur with Benjamin’s reasoning.
-- =
Regards,
Uri Blumenthal             &nbs= p;                 Voice: (781) 981-= 1638

From: Benjamin Black <b@b3k.us>
Yes.

"Keeping in mind that this may induce negative performance impacts, = but
could increase confidence in the outcome of our deliberations."
The process should allow bot= h random and selected primes, even if CFRG decides to only use one or the ot= her to meet the TLS-WG request. Agreeing on the process allows us to avoid t= his lengthy debate in future should other curves be needed to meet specific requirements.

On Fri, Oct 31, 2014 at 10:34 AM, Paterson, Kenny <Kenny.Paters= on@rhul.ac.uk> wrote:
Hi

We could still go down the route of generating fresh curves if there's
consensus for it on the list.

So let's do a quick poll:

- Who on the list would be in favour of using a to-be-agreed procedure to generate new curves, instead of selecting from amongst the curves that are<= br> currently on the table?

(Keeping in mind that this may induce negative performance impacts, but
= could increase confidence in the outcome of our deliberations.)

Replies should being with a one-word answer - "yes" or "no".
Justifications for positions can be included if you wish, but right now
= I'm more interested in the raw, 1-bit answer.

Thanks,

Kenny


On 31/10/2014 14:39, "Benjamin Black" <b@b3k.u= s> wrote:

>Right, I didn't say don't pick NUMS. I said I believe the process
>should've gone a direction it did not, which would've rejected _ALL_ >current candidates in favor of CFRG generating new ones. That is no mor= e
>my saying "don't pick NUMS" than your
> saying you want genus 2 on the table is the same as your saying "don't=
>pick Curve25519".
>
>On Fri, Oct 31, 2014 at 7:35 AM, Watson Ladd
><watsonbladd@gmail.com>= ; wrote:
>
>On Fri, Oct 31, 2014 at 7:31 AM, Benjamin Black <b@b3k.us> wrote:
>> Watson,
>>
>> Where exactly did I say "don't pick NUMS"?
>
>On October 29
>"I've also said repeatedly that we should be starting from
>requirements and then consider _generating_ curves to meet them,
>rather than limiting ourselves to the curves at hand or trying to
>contort the requirements to match an existing favorite."
>
>
>
>That seems to suggest that we don't pick any curves, but instead
>generate new ones.
>
>>
>>
>> b
>>
>> On Fri, Oct 31, 2014 at 7:14 AM, Watson Ladd <watsonbladd@gmail.com>
>>wrote:
>>>
>>> On Fri, Oct 31, 2014 at 7:10 AM, Stephen Farrell
>>> <stephen.farrell= @cs.tcd.ie> wrote:
>>> >
>>> >
>>> > On 31/10/14 14:05, Richard Barnes wrote:
>>> >> The idea that whiz-bang new crypto is the main barrie= r to 100% HTTPS
>>> >> adoption seems rather na=C3=AFve.  It helps,
>>> >
>>> > I agree. Of course, having CFRG decide on precisely
>>> > which whiz-bang new crypto would be a good next step:-) >>>
>>> But our choices are not the fastest ones! We've decided to hav= e genus
>>> 1 prime, no CM, which is a very conservative choice, but not >>> necessarily the fastest.
>>>
>>> Anyway, since Benjamin Black has said he doesn't actually thin= k we
>>> should pick NUMS, but do our own picking, I think the answer i= s
>>> clear...
>>> >
>>> > S.
>>> >
>>> > _______________________________________________
>>> > Cfrg mailing list
>>> > Cfrg@irtf.org
>>> > http://www.irtf.org/mailman/listinfo/cfrg
>>>
>>>
>>>
>>> --
>>> "Those who would give up Essential Liberty to purchase a littl= e
>>> Temporary Safety deserve neither  Liberty nor Safety." >>> -- Benjamin Franklin
>>>
>>> _______________________________________________
>>> Cfrg mailing list
>>> Cfrg@irtf.org
>>> http://www.irtf.org/mailman/listinfo/cfrg
>>
>>
>
>
>
>--
>"Those who would give up Essential Liberty to purchase a little
>Temporary Safety deserve neither  Liberty nor Safety."
>-- Benjamin Franklin
>
>
>
>
>
>
>


--B_3497608390_16506599-- --B_3497608391_16546108 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIUOAYJKoZIhvcNAQcCoIIUKTCCFCUCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGgghIHMIIE6jCCA9KgAwIBAgIKH0XZoAAAAAABzTANBgkqhkiG9w0BAQsFADBRMQswCQYD VQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJ MRMwEQYDVQQDEwpNSVRMTCBDQS0zMB4XDTE0MDQxNjIxNTMwMloXDTE1MDQxNjIxNTMwMlow YTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNV BAsTBlBlb3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQCx/gK75UYos2g8JavX0BVfe3TCGsmjQY34z9ZVeucP 8dGtqRA8T5i1OKdf++Jd81a0/qQA6mIGyzTW6lOtY+77qKUJtEeLM5URd+iv2EejAwxsa2B5 pMq9L9qWuVokR1rTEfEcuUeKR1Kko6xmRE/y6AzBnUhTvHx2X9F6JSVdR36Lx3R62CNeQqFi ZDeHuTI8AhRY4UdPkri1FTDxV6gLYaLKxsGIurrL/6EzdlkX8ImTcxKzEmxX1VjTPy9ZRNYj akDGcJF9clCfcwbq3DI3gAUkVxXf+UbHEjzOCVNQcoga7bYbBUuDpN25Lc86P9RaOiiICtyu ZZP2P/2kkKYRAgMBAAGjggGyMIIBrjAdBgNVHQ4EFgQUEN9QHIi9GvlGjs9Th46jrfPir+Uw DgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1Ud HwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYB BQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExD QTMwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3 FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+KcwIBZAIBBTAi BgNVHSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAYBgNVHSAEETAPMA0GCyqGSIb3 EgIBAwEIMBkGA1UdEQQSMBCBDnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABM AFUAcwBlAHIAUwBpAGcALQBTAFcwDQYJKoZIhvcNAQELBQADggEBAL2kCh9ovO8AbHgAVU6T eH5qRmKnOrfTUfn9JnHzkspdWMQA1IdtftSpiZZ7C3lCmblSDCgPqbQl4zMZxXeTgxnQsB6m 1LA6uDHM/0G27RcOJH4OTN9sQ0/2CKb4JPIXXIps1z+s8XjSRzPJZuD8fPC8R8QWvOH3owL2 BLzZebZTOMa5yws3kohY02vP/Clv0KQXYVzUZUYXoYmhUSYmQ1UZZZSFJ2rNdgNn0z8fPrUQ NIYlVaJV0kKQYjlHWTfomVapLEfIY7xRHZy9g997IjYReD0t9IZd6tTwcJES+2ijFM8l/fxk u/cQ4WCYyI+58DaBaV9p68/AC147b0HhvLUwggS8MIIDpKADAgECAgEpMA0GCSqGSIb3DQEB BQUAMFQxCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQww CgYDVQQLEwNQS0kxFjAUBgNVBAMTDU1JVExMIFJvb3QgQ0EwHhcNMTMxMjE3MDAwMDAwWhcN MjAxMjMxMjM1OTU5WjBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFi b3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2jBSdW18tuW1tNxG6h8B0kqckFZQAAtoHCkvUpUEX6jF vBd8mQI53GyLYRuAo4HWJpe7/izFXOfSJDs6UM5ovvCOfXg2bJgDYlBC9JDcLBFIn0nppOu9 RvpjWSixtC56crwJ5Us5QPdtxtKdek5LJXl2oKw3w8lihUixePbxWad1m7ZMKKagvm9zTybP 6FumKRxeYJjSpB2+cAYjoGGEbSVHyx8uzHm6xAoBMHxa8by+yDz8Jzk6sP9iilgP3iXSGoCA mhyBzvlQQ5QNNWP+Emo9jz/ukKhYVB/VwdxtoquPAqn4ifDAIaM9dtb05cy1gXAFSP3Z/iUk xyBZZUORfwIDAQABo4IBmjCCAZYwEgYDVR0TAQH/BAgwBgEB/wIBADAdBgNVHQ4EFgQU12Bm DntJjXVMDf3PRt7IxxKHyr8wHwYDVR0jBBgwFoAUZ6p6z/QKprlytYqg0p3yEMND7SkwDgYD VR0PAQH/BAQDAgGGMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0cDovL2NybC5s bC5taXQuZWR1L2dldHRvP0xMUkNBMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5sbC5taXQu ZWR1L29jc3AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNy bD9MTFJDQTCBkgYDVR0gBIGKMIGHMA0GCyqGSIb3EgIBAwEGMA0GCyqGSIb3EgIBAwEIMA0G CyqGSIb3EgIBAwEHMA0GCyqGSIb3EgIBAwEJMA0GCyqGSIb3EgIBAwEKMA0GCyqGSIb3EgIB AwELMA0GCyqGSIb3EgIBAwEOMA0GCyqGSIb3EgIBAwEPMA0GCyqGSIb3EgIBAwEQMA0GCSqG SIb3DQEBBQUAA4IBAQAsf9HBn72qU7UTgkxarjAc7iynhcDEgWwezYKtd/SLGSQ0DhtzIV/L TCxqULjOd+H+HTqMJXB8+nHnzhyqQ43RsnGZOFT5RfzPh94db/ZJ3ql244DwlJI7yXBA2DkZ cEEgOWC9bHcrElzU6NnigahSW5odVJrhmH/XhQAcMS77E5H62yyxK1WPPgcBipGVnu1xSHbT iHe7DqfWQ2tVMLUf23XYhIua94kJsQd4jSh71NVD0e7F4snAoqQMI98MzDYeLOkjlzKRs77r /aMsPAKx6nMaOvRL7Cy0Pjp51i2qFkbGmX8ofnh2kerjTTvRJ/g22r1MV8RR1PktjMsNOsPf MIIDgzCCAmugAwIBAgIBATANBgkqhkiG9w0BAQUFADBUMQswCQYDVQQGEwJVUzEfMB0GA1UE ChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRYwFAYDVQQDEw1NSVRM TCBSb290IENBMB4XDTA4MDkyMzEyMDAwMFoXDTI5MTIzMTIzNTk1OVowVDELMAkGA1UEBhMC VVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTEWMBQG A1UEAxMNTUlUTEwgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMVO KRdYsiay+a2Kv1wQCoPd5AkwExuwcNDRhaRCdQN17K+lCCKvf9VSQToAsA6q1bACtZUcMv5Z Kx8z5KG4jK9cM40NvEkf/bIOZAHJqzKgWG3N9NqrcAhimcXTXYQIdp1DgjtdADKVLAjXaYpD 2PbpE/JbAPnqKzOENa3Py9CegB0abTlOyLgwXWY/rXTW+4L/hipJ6+sI/ZtrFRmsKGhuwAKo bFr0FDP6uIfx+RaWJcJ1QBIdgM4aohvW8JeriSSMyf/LlFpXTZFcM9SOX0f7wmsYi1yFuKFM nQbkSkxvnpBKMRxrg+98seSbbEnIkvB0C9qBDPLb/lQAvmpW6oMCAwEAAaNgMF4wDwYDVR0T AQH/BAUwAwEB/zAdBgNVHQ4EFgQUZ6p6z/QKprlytYqg0p3yEMND7SkwHwYDVR0jBBgwFoAU Z6p6z/QKprlytYqg0p3yEMND7SkwCwYDVR0PBAQDAgGGMA0GCSqGSIb3DQEBBQUAA4IBAQA+ G20FYNB4eNhKWF+PyT5DUtzlABFkf2IM2VGNUBova0GeKX3I1Nf02qDU/GO2H9ETvnvTYhvf gQ4UB/5EImTkKPa7/TVG/MQ7SgmAmne8xELVbGLFrrytly8PyYtZtngb6DgeEUv+SwFnzcLO 1vg1rdmss3kwsqy0q8e2VYAY8zTptEzyJG36aXcIMbqOxWS/LbPjNuPdgJfO3d1WrHr1Etaa a0QRLqQoZj07dYY7Wo5EDqU+AUAMz9ZVRGK1s5b/jv5Wz/YroyqWFnH2KkNxRn9+2Ar7g3rn rOMZvp6psq2jbDXiPBod1wyMKn8x5y4cuGPNFcqjfyY/HX90ivQAMIIEzjCCA7agAwIBAgIK PVEvPAAAAACTsDANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlU IExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0y MB4XDTE0MDIxMjE4NTMwMVoXDTE1MDIxMjE4NTMwMVowYTELMAkGA1UEBhMCVVMxHzAdBgNV BAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsTBlBlb3BsZTEgMB4GA1UEAxMX Qmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCKHhhu75bRiOvWhbZ//TxS76yI2d+rHN2s8bp8wxW8oMjmsaplLeGQusUFRyRNSkfYtdB4 YApjnV6TCxS0Mqzly5BaoeZWoP+CbbMDNGYMszus9iFj22SSlTzGRo+gaL6rqsDKdwDOzs3C PYqh4Uu8sLzEq+QD9rhqAuMJ76635JKWELxK0uDehpNBMCGqVeAY8ht5u2h4ojPdwiuDQDW2 QxWRJjPDL8n1JczuEHY71jHldER3b2+UhpDDYRQ9aVOiGCjW8BwJOruVsBfLNxyDxgffNQ1D 1konuneMpL9H2S8ciHOdy5+Gi7snCQJ+7w30rIJ2NTldWaY6avZAaCa3AgMBAAGjggGWMIIB kjAdBgNVHQ4EFgQUZ7oGjnu6gWRmom/4UswgdVBW/3wwDgYDVR0PAQH/BAQDAgUgMB8GA1Ud IwQYMBaAFI5KfYmhYxccgYg0VzcmRV4Zin4kMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9j cmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTIwYgYIKwYBBQUHAQEEVjBUMC0GCCsGAQUFBzAC hiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTIwIwYIKwYBBQUHMAGGF2h0dHA6 Ly9vY3NwLmxsLm1pdC5lZHUvMAwGA1UdEwEB/wQCMAAwPQYJKwYBBAGCNxUHBDAwLgYmKwYB BAGCNxUIg4PlHYfsp2aGrYcVg+rwRYW2oR8dhevQcIPr7SACAWQCAQQwJQYDVR0lBB4wHAYE VR0lAAYIKwYBBQUHAwQGCisGAQQBgjcKAwQwGAYDVR0gBBEwDzANBgsqhkiG9xICAQMBCDAZ BgNVHREEEjAQgQ51cmlAbGwubWl0LmVkdTANBgkqhkiG9w0BAQsFAAOCAQEAJiU3WfJ9GvGJ iDNPClLazyh252wxxOc/TmClMKtyqHnbFObDEoXAMaoHGxrvs+lU8fU2F2ELpV8q8eYgqLLw 7PG09z5s/GkajlxVZ/FHj/9hNHTfwlicrCRY3zrna1GbOMZgWFz8R6akAoLKpqGulNrvjvU8 c63U+JVmgJmBPCMv5JlH10m87+WPJ+ToK0m4XfZjl7n5OKDJ/hOyBwbBntc+W2gDppfR1BCt DNfEG0+zHjFqF+Of1Q5NI5abhgvw5IEuVA1M4SV/utwmmdreBEv/YuLnDd/PhVgQwp3LHGCX X1dANyiKso2aACl9jrkylq39cA/WgvAlS21w9vxVpDGCAfUwggHxAgEBMF8wUTELMAkGA1UE BhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTET MBEGA1UEAxMKTUlUTEwgQ0EtMwIKH0XZoAAAAAABzTANBglghkgBZQMEAgEFAKBpMC8GCSqG SIb3DQEJBDEiBCAjxzPhIHI5+1OdY2GpPQUa4j0trjrIpksYYBHZZoTBvjAYBgkqhkiG9w0B CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNDEwMzExNzUzMTBaMA0GCSqGSIb3 DQEBAQUABIIBADWmL5kVxE/S6m1dOEBpSQYWfCYBDbmVym1dKQE9IP8jim4XDrYD14jL95R/ VgT9MRoJBz7XE6grvQ3RqegO6YJLyzAAuRN25/4107FnroO2OKxnQCv/Ql8UsyAGIfiklOHN 8g1C/M//BJrGJIKf79ERU4wziEDoSPHh4K04+spvJrvjV04D1fEiJ8cvncIBfZpgITwHzdJk J+ImBMa/K+/mYQjmTjCRqDCBt4x9vRObZzHooynNVhLf24+Reil81fy7vyobVUDQy66NY4H6 eXHEMpMXRLzjQ7ra5RCvtOyAkMaHg4q1GQUvcolDA9p+mGg/fcTX6z7Jvn50jxpnYH8= --B_3497608391_16546108-- From nobody Fri Oct 31 10:57:30 2014 Return-Path: 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 E76841A0360 for ; Fri, 31 Oct 2014 10:57:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.266 X-Spam-Level: X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, 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 j0Z6y2zRTa4h for ; Fri, 31 Oct 2014 10:57:24 -0700 (PDT) Received: from mx0a-0016f401.pphosted.com (mx0a-0016f401.pphosted.com [67.231.148.174]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 006981A00F6 for ; Fri, 31 Oct 2014 10:57:23 -0700 (PDT) Received: from pps.filterd (m0045849.ppops.net [127.0.0.1]) by mx0a-0016f401.pphosted.com (8.14.5/8.14.5) with SMTP id s9VHsJOD016197; Fri, 31 Oct 2014 10:57:22 -0700 Received: from sc-owa.marvell.com ([199.233.58.135]) by mx0a-0016f401.pphosted.com with ESMTP id 1qb8365tft-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 31 Oct 2014 10:57:22 -0700 Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by SC-OWA.marvell.com ([::1]) with mapi; Fri, 31 Oct 2014 10:57:21 -0700 From: Paul Lambert To: "Paterson, Kenny" Date: Fri, 31 Oct 2014 10:57:20 -0700 Thread-Topic: [Cfrg] new curves or old (was: Actual security levels for IETF crypto) Thread-Index: Ac/1NB6NdLs4ji5wQUWjB9jkEiD7Ww== Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.5.141003 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_D0791AFC52433paulmarvellcom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.28, 0.0.0000 definitions=2014-10-31_08:2014-10-31,2014-10-31,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=2 spamscore=2 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1410310168 Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/C82xUCivTzU00JZrMs29rmIESi0 Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] new curves or old (was: Actual security levels for IETF crypto) X-BeenThere: cfrg@irtf.org 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, 31 Oct 2014 17:57:28 -0000 --_000_D0791AFC52433paulmarvellcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Yes. Good options for optimized and random primes is valuable. We should not be so focused on =91the=92 ultimate curve, but also ensure th= at there are well documented options for a variety of market applications. Paul From: Benjamin Black > Date: Friday, October 31, 2014 at 10:46 AM To: "Paterson, Kenny" > Cc: "cfrg@irtf.org" > Subject: Re: [Cfrg] new curves or old (was: Actual security levels for IETF= crypto) Yes. "Keeping in mind that this may induce negative performance impacts, but could increase confidence in the outcome of our deliberations." The process should allow both random and selected primes, even if CFRG deci= des to only use one or the other to meet the TLS-WG request. Agreeing on th= e process allows us to avoid this lengthy debate in future should other cur= ves be needed to meet specific requirements. On Fri, Oct 31, 2014 at 10:34 AM, Paterson, Kenny > wrote: Hi We could still go down the route of generating fresh curves if there's consensus for it on the list. So let's do a quick poll: - Who on the list would be in favour of using a to-be-agreed procedure to generate new curves, instead of selecting from amongst the curves that are currently on the table? (Keeping in mind that this may induce negative performance impacts, but could increase confidence in the outcome of our deliberations.) Replies should being with a one-word answer - "yes" or "no". Justifications for positions can be included if you wish, but right now I'm more interested in the raw, 1-bit answer. Thanks, Kenny On 31/10/2014 14:39, "Benjamin Black" > wrote: >Right, I didn't say don't pick NUMS. I said I believe the process >should've gone a direction it did not, which would've rejected _ALL_ >current candidates in favor of CFRG generating new ones. That is no more >my saying "don't pick NUMS" than your > saying you want genus 2 on the table is the same as your saying "don't >pick Curve25519". > >On Fri, Oct 31, 2014 at 7:35 AM, Watson Ladd >> wrote: > >On Fri, Oct 31, 2014 at 7:31 AM, Benjamin Black = > wrote: >> Watson, >> >> Where exactly did I say "don't pick NUMS"? > >On October 29 >"I've also said repeatedly that we should be starting from >requirements and then consider _generating_ curves to meet them, >rather than limiting ourselves to the curves at hand or trying to >contort the requirements to match an existing favorite." > > > >That seems to suggest that we don't pick any curves, but instead >generate new ones. > >> >> >> b >> >> On Fri, Oct 31, 2014 at 7:14 AM, Watson Ladd > >>wrote: >>> >>> On Fri, Oct 31, 2014 at 7:10 AM, Stephen Farrell >>> > wrote: >>> > >>> > >>> > On 31/10/14 14:05, Richard Barnes wrote: >>> >> The idea that whiz-bang new crypto is the main barrier to 100% HTTPS >>> >> adoption seems rather na=EFve. It helps, >>> > >>> > I agree. Of course, having CFRG decide on precisely >>> > which whiz-bang new crypto would be a good next step:-) >>> >>> But our choices are not the fastest ones! We've decided to have genus >>> 1 prime, no CM, which is a very conservative choice, but not >>> necessarily the fastest. >>> >>> Anyway, since Benjamin Black has said he doesn't actually think we >>> should pick NUMS, but do our own picking, I think the answer is >>> clear... >>> > >>> > S. >>> > >>> > _______________________________________________ >>> > Cfrg mailing list >>> > Cfrg@irtf.org >>> > http://www.irtf.org/mailman/listinfo/cfrg >>> >>> >>> >>> -- >>> "Those who would give up Essential Liberty to purchase a little >>> Temporary Safety deserve neither Liberty nor Safety." >>> -- Benjamin Franklin >>> >>> _______________________________________________ >>> Cfrg mailing list >>> Cfrg@irtf.org >>> http://www.irtf.org/mailman/listinfo/cfrg >> >> > > > >-- >"Those who would give up Essential Liberty to purchase a little >Temporary Safety deserve neither Liberty nor Safety." >-- Benjamin Franklin > > > > > > > --_000_D0791AFC52433paulmarvellcom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Yes.
Good options for optimized and random primes is valuable.
We should not be so focused on =91the=92 ultimate curve, but also ens= ure that there are well documented options for a variety of market applicat= ions.

Paul


From: Benjamin Black <b@b3k.us>
D= ate: Friday, October 31, 2014 at 10:46 AM
To: "Paterson, Kenny" <Kenny.Paterson@rhul.ac.uk>
Cc: "cf= rg@irtf.org" <cfrg@irtf.org>
Subject: Re: [Cfrg] new c= urves or old (was: Actual security levels for IETF crypto)

On Fri, Oct 31, 2014 at 10:34 AM= , Paterson, Kenny <Kenny.Paterson@rhul.ac.uk> wrote:=
Hi

We could still go down the route of generating fresh curves if there's
consensus for it on the list.

So let's do a quick poll:

- Who on the list would be in favour of using a to-be-agreed procedure to generate new curves, instead of selecting from amongst the curves that are<= br> currently on the table?

(Keeping in mind that this may induce negative performance impacts, but
could increase confidence in the outcome of our deliberations.)

Replies should being with a one-word answer - "yes" or "no&q= uot;.
Justifications for positions can be included if you wish, but right now
I'm more interested in the raw, 1-bit answer.

Thanks,

Kenny


On 31/10/2014 14:39, "Benjamin Black" <b@b3k.us> wrote:

>Right, I didn't say don't pick NUMS. I said I believe the process
>should've gone a direction it did not, which would've rejected _ALL_ >current candidates in favor of CFRG generating new ones. That is no mor= e
>my saying "don't pick NUMS" than your
> saying you want genus 2 on the table is the same as your saying "= don't
>pick Curve25519".
>
>On Fri, Oct 31, 2014 at 7:35 AM, Watson Ladd
><watsonbladd@gmail.com&= gt; wrote:
>
>On Fri, Oct 31, 2014 at 7:31 AM, Benjamin Black <b@b3k.us> wrote:
>> Watson,
>>
>> Where exactly did I say "don't pick NUMS"?
>
>On October 29
>"I've also said repeatedly that we should be starting from
>requirements and then consider _generating_ curves to meet them,
>rather than limiting ourselves to the curves at hand or trying to
>contort the requirements to match an existing favorite."
>
>
>
>That seems to suggest that we don't pick any curves, but instead
>generate new ones.
>
>>
>>
>> b
>>
>> On Fri, Oct 31, 2014 at 7:14 AM, Watson Ladd <watsonbladd@gmail.com>
>>wrote:
>>>
>>> On Fri, Oct 31, 2014 at 7:10 AM, Stephen Farrell
>>> <stephen.farre= ll@cs.tcd.ie> wrote:
>>> >
>>> >
>>> > On 31/10/14 14:05, Richard Barnes wrote:
>>> >> The idea that whiz-bang new crypto is the main barrie= r to 100% HTTPS
>>> >> adoption seems rather na=EFve.  It helps,
>>> >
>>> > I agree. Of course, having CFRG decide on precisely
>>> > which whiz-bang new crypto would be a good next step:-) >>>
>>> But our choices are not the fastest ones! We've decided to hav= e genus
>>> 1 prime, no CM, which is a very conservative choice, but not >>> necessarily the fastest.
>>>
>>> Anyway, since Benjamin Black has said he doesn't actually thin= k we
>>> should pick NUMS, but do our own picking, I think the answer i= s
>>> clear...
>>> >
>>> > S.
>>> >
>>> > _______________________________________________
>>> > Cfrg mailing list
>>> > Cfrg@irtf.org
>>> > http://www.irtf.org/mailman/listinfo/cfrg
>>>
>>>
>>>
>>> --
>>> "Those who would give up Essential Liberty to purchase a = little
>>> Temporary Safety deserve neither  Liberty nor Safety.&quo= t;
>>> -- Benjamin Franklin
>>>
>>> _______________________________________________
>>> Cfrg mailing list
>>> Cfrg@irtf.org
>>> http://www.irtf.org/mailman/listinfo/cfrg
>>
>>
>
>
>
>--
>"Those who would give up Essential Liberty to purchase a little >Temporary Safety deserve neither  Liberty nor Safety."
>-- Benjamin Franklin
>
>
>
>
>
>
>




--_000_D0791AFC52433paulmarvellcom_-- From nobody Fri Oct 31 10:58:44 2014 Return-Path: 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 2C42B1A0155 for ; Fri, 31 Oct 2014 10:58:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-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 VC9SmSP3bXR3 for ; Fri, 31 Oct 2014 10:58:32 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0625.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::625]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68A2A1A028A for ; Fri, 31 Oct 2014 10:58:32 -0700 (PDT) Received: from DBXPR03MB383.eurprd03.prod.outlook.com (10.141.10.15) by DBXPR03MB383.eurprd03.prod.outlook.com (10.141.10.15) with Microsoft SMTP Server (TLS) id 15.1.11.14; Fri, 31 Oct 2014 17:34:13 +0000 Received: from DBXPR03MB383.eurprd03.prod.outlook.com ([10.141.10.15]) by DBXPR03MB383.eurprd03.prod.outlook.com ([10.141.10.15]) with mapi id 15.01.0011.000; Fri, 31 Oct 2014 17:34:13 +0000 From: "Paterson, Kenny" To: Benjamin Black , Watson Ladd Thread-Topic: new curves or old (was: Actual security levels for IETF crypto) Thread-Index: AQHP9TDjNOV6k7Uea0qq/hyZGzgxWw== Date: Fri, 31 Oct 2014 17:34:13 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [134.219.148.47] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:DBXPR03MB383; x-forefront-prvs: 03818C953D x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(199003)(51704005)(24454002)(377454003)(479174003)(189002)(52314003)(164054003)(86362001)(4396001)(40100003)(19273905006)(120916001)(46102003)(99396003)(62966003)(122556002)(87936001)(31966008)(15975445006)(83506001)(92726001)(2656002)(50986999)(92566001)(74482002)(101416001)(54356999)(95666004)(15202345003)(97736003)(107046002)(66066001)(21056001)(105586002)(36756003)(64706001)(20776003)(19580395003)(106116001)(19580405001)(106356001)(77156002)(563064011); DIR:OUT; SFP:1101; SCL:1; SRVR:DBXPR03MB383; H:DBXPR03MB383.eurprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="iso-8859-1" Content-ID: <1B55E2E18DE3724586806A81F79BEA35@eurprd03.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: rhul.ac.uk Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/hwAXnC2HnpjL5G45jeBPuqvReYQ Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] new curves or old (was: Actual security levels for IETF crypto) X-BeenThere: cfrg@irtf.org 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, 31 Oct 2014 17:58:38 -0000 Hi We could still go down the route of generating fresh curves if there's consensus for it on the list. So let's do a quick poll: - Who on the list would be in favour of using a to-be-agreed procedure to generate new curves, instead of selecting from amongst the curves that are currently on the table? (Keeping in mind that this may induce negative performance impacts, but could increase confidence in the outcome of our deliberations.) Replies should being with a one-word answer - "yes" or "no". Justifications for positions can be included if you wish, but right now I'm more interested in the raw, 1-bit answer. Thanks, Kenny=20 On 31/10/2014 14:39, "Benjamin Black" wrote: >Right, I didn't say don't pick NUMS. I said I believe the process >should've gone a direction it did not, which would've rejected _ALL_ >current candidates in favor of CFRG generating new ones. That is no more >my saying "don't pick NUMS" than your > saying you want genus 2 on the table is the same as your saying "don't >pick Curve25519". > >On Fri, Oct 31, 2014 at 7:35 AM, Watson Ladd > wrote: > >On Fri, Oct 31, 2014 at 7:31 AM, Benjamin Black wrote: >> Watson, >> >> Where exactly did I say "don't pick NUMS"? > >On October 29 >"I've also said repeatedly that we should be starting from >requirements and then consider _generating_ curves to meet them, >rather than limiting ourselves to the curves at hand or trying to >contort the requirements to match an existing favorite." > > > >That seems to suggest that we don't pick any curves, but instead >generate new ones. > >> >> >> b >> >> On Fri, Oct 31, 2014 at 7:14 AM, Watson Ladd >>wrote: >>> >>> On Fri, Oct 31, 2014 at 7:10 AM, Stephen Farrell >>> wrote: >>> > >>> > >>> > On 31/10/14 14:05, Richard Barnes wrote: >>> >> The idea that whiz-bang new crypto is the main barrier to 100% HTTPS >>> >> adoption seems rather na=EFve. It helps, >>> > >>> > I agree. Of course, having CFRG decide on precisely >>> > which whiz-bang new crypto would be a good next step:-) >>> >>> But our choices are not the fastest ones! We've decided to have genus >>> 1 prime, no CM, which is a very conservative choice, but not >>> necessarily the fastest. >>> >>> Anyway, since Benjamin Black has said he doesn't actually think we >>> should pick NUMS, but do our own picking, I think the answer is >>> clear... >>> > >>> > S. >>> > >>> > _______________________________________________ >>> > Cfrg mailing list >>> > Cfrg@irtf.org >>> > http://www.irtf.org/mailman/listinfo/cfrg >>> >>> >>> >>> -- >>> "Those who would give up Essential Liberty to purchase a little >>> Temporary Safety deserve neither Liberty nor Safety." >>> -- Benjamin Franklin >>> >>> _______________________________________________ >>> Cfrg mailing list >>> Cfrg@irtf.org >>> http://www.irtf.org/mailman/listinfo/cfrg >> >> > > > >-- >"Those who would give up Essential Liberty to purchase a little >Temporary Safety deserve neither Liberty nor Safety." >-- Benjamin Franklin > > > > > > > From nobody Fri Oct 31 11:15:47 2014 Return-Path: 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 D1C451A03B3 for ; Fri, 31 Oct 2014 11:15:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.555 X-Spam-Level: * X-Spam-Status: No, score=1.555 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.982, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no 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 t43rVgqOXgpI for ; Fri, 31 Oct 2014 11:15:37 -0700 (PDT) Received: from aspartame.shiftleft.org (199-116-74-168-v301.PUBLIC.monkeybrains.net [199.116.74.168]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDF241A039B for ; Fri, 31 Oct 2014 11:15:36 -0700 (PDT) Received: from [10.184.148.249] (unknown [209.36.6.242]) by aspartame.shiftleft.org (Postfix) with ESMTPSA id 676B63A9C1; Fri, 31 Oct 2014 11:12:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=shiftleft.org; s=sldo; t=1414779159; bh=XPpgC8PPGoCs/hQgGQCod3txBJyeMA8kaOvY3/c7xSo=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=MfQxu/0DMBMdJlrpG6doTP9wjAnkaZUS2olcrjFoktBb6eWGzlLBKZqPJLE3wJ/vp 4dRjNVk+5QtcotWNimBkbM9H+Rsw7Q1Ij/v7uzaBI5qGYBxmHiYCiuwDmhYZbjf4TK fgTGA4SEzbO+uMAswa/mavxHSwe09JcEITEqqXa4= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Michael Hamburg In-Reply-To: Date: Fri, 31 Oct 2014 11:15:34 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Paterson, Kenny" X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/Lhu32ry1jX6eO7_bKaJCEmI31B8 Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] new curves or old (was: Actual security levels for IETF crypto) X-BeenThere: cfrg@irtf.org 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, 31 Oct 2014 18:15:41 -0000 No. I=92m OK with this in principle, but if there aren=92t new curves by = Christmas, there will be mutiny. Seriously, industry is just going to = give up on CFRG and roll out new curves of their choice. And anyway, will we actually get different curves this way? We=92ve got = curves from pretty much the convex hull of the proposed strategy space, = except for VPR curves and a performance-at-all-costs WF128 curve. =97 Mike > On Oct 31, 2014, at 10:34 AM, Paterson, Kenny = wrote: >=20 > Hi >=20 > We could still go down the route of generating fresh curves if there's > consensus for it on the list. >=20 > So let's do a quick poll: >=20 > - Who on the list would be in favour of using a to-be-agreed procedure = to > generate new curves, instead of selecting from amongst the curves that = are > currently on the table? >=20 > (Keeping in mind that this may induce negative performance impacts, = but > could increase confidence in the outcome of our deliberations.) >=20 > Replies should being with a one-word answer - "yes" or "no". > Justifications for positions can be included if you wish, but right = now > I'm more interested in the raw, 1-bit answer. >=20 > Thanks, >=20 > Kenny=20 >=20 >=20 > On 31/10/2014 14:39, "Benjamin Black" wrote: >=20 >> Right, I didn't say don't pick NUMS. I said I believe the process >> should've gone a direction it did not, which would've rejected _ALL_ >> current candidates in favor of CFRG generating new ones. That is no = more >> my saying "don't pick NUMS" than your >> saying you want genus 2 on the table is the same as your saying = "don't >> pick Curve25519". >>=20 >> On Fri, Oct 31, 2014 at 7:35 AM, Watson Ladd >> wrote: >>=20 >> On Fri, Oct 31, 2014 at 7:31 AM, Benjamin Black wrote: >>> Watson, >>>=20 >>> Where exactly did I say "don't pick NUMS"? >>=20 >> On October 29 >> "I've also said repeatedly that we should be starting from >> requirements and then consider _generating_ curves to meet them, >> rather than limiting ourselves to the curves at hand or trying to >> contort the requirements to match an existing favorite." >>=20 >>=20 >>=20 >> That seems to suggest that we don't pick any curves, but instead >> generate new ones. >>=20 >>>=20 >>>=20 >>> b >>>=20 >>> On Fri, Oct 31, 2014 at 7:14 AM, Watson Ladd >>> wrote: >>>>=20 >>>> On Fri, Oct 31, 2014 at 7:10 AM, Stephen Farrell >>>> wrote: >>>>>=20 >>>>>=20 >>>>> On 31/10/14 14:05, Richard Barnes wrote: >>>>>> The idea that whiz-bang new crypto is the main barrier to 100% = HTTPS >>>>>> adoption seems rather na=EFve. It helps, >>>>>=20 >>>>> I agree. Of course, having CFRG decide on precisely >>>>> which whiz-bang new crypto would be a good next step:-) >>>>=20 >>>> But our choices are not the fastest ones! We've decided to have = genus >>>> 1 prime, no CM, which is a very conservative choice, but not >>>> necessarily the fastest. >>>>=20 >>>> Anyway, since Benjamin Black has said he doesn't actually think we >>>> should pick NUMS, but do our own picking, I think the answer is >>>> clear... >>>>>=20 >>>>> S. >>>>>=20 >>>>> _______________________________________________ >>>>> Cfrg mailing list >>>>> Cfrg@irtf.org >>>>> http://www.irtf.org/mailman/listinfo/cfrg >>>>=20 >>>>=20 >>>>=20 >>>> -- >>>> "Those who would give up Essential Liberty to purchase a little >>>> Temporary Safety deserve neither Liberty nor Safety." >>>> -- Benjamin Franklin >>>>=20 >>>> _______________________________________________ >>>> Cfrg mailing list >>>> Cfrg@irtf.org >>>> http://www.irtf.org/mailman/listinfo/cfrg >>>=20 >>>=20 >>=20 >>=20 >>=20 >> -- >> "Those who would give up Essential Liberty to purchase a little >> Temporary Safety deserve neither Liberty nor Safety." >> -- Benjamin Franklin >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >=20 > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg From nobody Fri Oct 31 11:18:57 2014 Return-Path: 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 87D7D1A03B3 for ; Fri, 31 Oct 2014 11:18:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-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 TIYadG70L8sW for ; Fri, 31 Oct 2014 11:18:47 -0700 (PDT) Received: from entima.net (entima.net [78.129.143.175]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CED181A0187 for ; Fri, 31 Oct 2014 11:18:44 -0700 (PDT) In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 From: Alyssa Rowan Date: Fri, 31 Oct 2014 18:18:40 +0000 To: "Paterson, Kenny" Message-ID: Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/egcdDalMh7OHaFe0cLV5DHz7ywY Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] new curves or old (was: Actual security levels for IETF crypto) X-BeenThere: cfrg@irtf.org 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, 31 Oct 2014 18:18:48 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 >- Who on the list would be in favour of using a to-be-agreed procedure to generate new curves, instead of selecting from amongst the curves that are currently on the table? No. • If we generated new curves with rigid processes and constraints, they'd likely match one of the contenders. (That's the point. See what happened with E-521.) • I think the already-existing Brainpool curves match random curve criteria fine. • Concerns about delay. There's nothing stopping us (or Brainpool) doing new random curves later, but I don't think this satisfies the TLS WG request on the table now. - -- /akr -----BEGIN PGP SIGNATURE----- Version: APG v1.1.1 iQI3BAEBCgAhBQJUU9KAGhxBbHlzc2EgUm93YW4gPGFrckBha3IuaW8+AAoJEOyE jtkWi2t6+mgP/3I4onpIh3kUpV5L6r58cQfFXXBELDm3NcxnZ24HfFvY1dJrGcgS H7n8PgmCFOn1LrAgjI+fTdnV9tZTiDbIea+WEJ/sB34QLys9Uh3HF3qHC44yGemV 1VkTYs+GNpSE4abwgJWtQZkdieL3zzOUbzuBV0Kp43Y6N6+F7+P6ck3Al2YRlsKs rVFclrYQSy0MMLNtLZXaAUcmjIwyl26wcp8qeUlloB3NVnK1M5kygAjUGA/cHKZz f8c+RfHlbDD1/8DUKbOJ04tvfbQ59ewy8u2xl1KtiCTKPi0jMrLlfTAMHnse+8c+ ogDTUuXcLBBI/2V8ZbWMH39ZpK5OwMKI8fZ5n9foPWLhS5K7t56TZRORi3QFuWZz 6bFzNWkKsOL4pHWcCEXu96UKG8LEDSiM4LihJQBhm9LufKQD/YnNb9qvZOVfrUa+ i/JyZLkI9YGqbAtcxrqhouPTNiO10ySexLFxyNUs3ryReVCKr2Ht5L+9nsutjN6p Mu2hiwPlS/ePBBlFAUl29QQ3fAGuCnkngsUBaWxtDstXN2RgKVbi2IhJbf1p5gZt Qa2G+foAO3E/rwdvrWGWnh+aB71wPeZEVkKslbb79IN7YcO+IrFwHAHu/waSo0ff w5N5vKW/0aOb8nN8tszQn/mm7RdbW/QxB6jDjmQklyor98L+k4ZEcf7W =ACO5 -----END PGP SIGNATURE----- From nobody Fri Oct 31 11:31:27 2014 Return-Path: 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 A5D0A1A19F9 for ; Fri, 31 Oct 2014 11:31:24 -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 Vywbnw5CVrMk for ; Fri, 31 Oct 2014 11:31:21 -0700 (PDT) Received: from mail-yh0-x231.google.com (mail-yh0-x231.google.com [IPv6:2607:f8b0:4002:c01::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EDB51A0252 for ; Fri, 31 Oct 2014 11:31:21 -0700 (PDT) Received: by mail-yh0-f49.google.com with SMTP id t59so2927546yho.22 for ; Fri, 31 Oct 2014 11:31:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=DA0sRspZv3JULrk/1GoKgJkB8G/G8IH/M8OjGy0qL0s=; b=n4sGBJP59KZv5M/qYquE5DYo5Z8KmD7Tk2aTeFuWYsP8CNZ62GE0zMfpeCB3E93ulk aii+iuTkEvmecO73r8FxRE/DgHd8uS3u8m9yaeCOuC0aN55ow5os11L2KORSJMKKf/+w 3ovV+jQNt5qwhJVKt007jUc9BWr5YkzfDeUo4z6SNbYQUrR1G3TE+H3/8y1iJMlOmdKI fT6YPAd4aJks+jq9HpidqD7Kd2g4NvzFefMb2+HExDcLYv4Q4Hh4DRmA9H1iTxLZ7u9A t2nzHEJTSAYXVXqV2TM2ew5N3tLotKz6+FyQSTovaZxdCdrf6bat0GND3Kvl0Z+GJkaQ Ccug== MIME-Version: 1.0 X-Received: by 10.236.53.69 with SMTP id f45mr15583800yhc.65.1414780280633; Fri, 31 Oct 2014 11:31:20 -0700 (PDT) Received: by 10.170.195.149 with HTTP; Fri, 31 Oct 2014 11:31:20 -0700 (PDT) Received: by 10.170.195.149 with HTTP; Fri, 31 Oct 2014 11:31:20 -0700 (PDT) In-Reply-To: References: Date: Fri, 31 Oct 2014 11:31:20 -0700 Message-ID: From: Watson Ladd To: Uri - 0558 - MITLL Blumenthal Content-Type: multipart/alternative; boundary=089e0122971c10018a0506bc3453 Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/E6fcV6Q-q2FpdLw2JGjDPcu-wiw Cc: cfrg@irtf.org Subject: Re: [Cfrg] new curves or old (was: Actual security levels for IETF crypto) X-BeenThere: cfrg@irtf.org 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, 31 Oct 2014 18:31:25 -0000 --089e0122971c10018a0506bc3453 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I feel we are being asked to buy a pig in a poke. Given that the three yes votes have wanted random primes, or "a range of market" applications, and have left the door open to later having to pick for TLS, I'm not sure the people voting yes actually agree with the proposal, which as I read it would involve constructing a procedure that would output the curves, that would then go to TLS, without regard to other uses of said procedure or picking out some curves from the output. I'm going to vote "no". I don't see how this speeds up the process, or is different from the results of picking NUMS, or E-521+other junk. I'll mail a quarter to you if I have to for use in making the decision: but let's decide already. On Oct 31, 2014 10:53 AM, "Blumenthal, Uri - 0558 - MITLL" wrote: > > Yes. > > I concur with Benjamin=E2=80=99s reasoning. > -- > Regards, > Uri Blumenthal Voice:(781) 981-1638 > > From: Benjamin Black >> >> Yes. >> >> "Keeping in mind that this may induce negative performance impacts, but >> could increase confidence in the outcome of our deliberations." >> >> The process should allow both random and selected primes, even if CFRG decides to only use one or the other to meet the TLS-WG request. Agreeing on the process allows us to avoid this lengthy debate in future should other curves be needed to meet specific requirements. >> >> On Fri, Oct 31, 2014 at 10:34 AM, Paterson, Kenny < Kenny.Paterson@rhul.ac.uk> wrote: >>> >>> Hi >>> >>> We could still go down the route of generating fresh curves if there's >>> consensus for it on the list. >>> >>> So let's do a quick poll: >>> >>> - Who on the list would be in favour of using a to-be-agreed procedure to >>> generate new curves, instead of selecting from amongst the curves that are >>> currently on the table? >>> >>> (Keeping in mind that this may induce negative performance impacts, but >>> could increase confidence in the outcome of our deliberations.) >>> >>> Replies should being with a one-word answer - "yes" or "no". >>> Justifications for positions can be included if you wish, but right now >>> I'm more interested in the raw, 1-bit answer. >>> >>> Thanks, >>> >>> Kenny >>> >>> >>> On 31/10/2014 14:39, "Benjamin Black" wrote: >>> >>> >Right, I didn't say don't pick NUMS. I said I believe the process >>> >should've gone a direction it did not, which would've rejected _ALL_ >>> >current candidates in favor of CFRG generating new ones. That is no more >>> >my saying "don't pick NUMS" than your >>> > saying you want genus 2 on the table is the same as your saying "don'= t >>> >pick Curve25519". >>> > >>> >On Fri, Oct 31, 2014 at 7:35 AM, Watson Ladd >>> > wrote: >>> > >>> >On Fri, Oct 31, 2014 at 7:31 AM, Benjamin Black wrote: >>> >> Watson, >>> >> >>> >> Where exactly did I say "don't pick NUMS"? >>> > >>> >On October 29 >>> >"I've also said repeatedly that we should be starting from >>> >requirements and then consider _generating_ curves to meet them, >>> >rather than limiting ourselves to the curves at hand or trying to >>> >contort the requirements to match an existing favorite." >>> > >>> > >>> > >>> >That seems to suggest that we don't pick any curves, but instead >>> >generate new ones. >>> > >>> >> >>> >> >>> >> b >>> >> >>> >> On Fri, Oct 31, 2014 at 7:14 AM, Watson Ladd >>> >>wrote: >>> >>> >>> >>> On Fri, Oct 31, 2014 at 7:10 AM, Stephen Farrell >>> >>> wrote: >>> >>> > >>> >>> > >>> >>> > On 31/10/14 14:05, Richard Barnes wrote: >>> >>> >> The idea that whiz-bang new crypto is the main barrier to 100% HTTPS >>> >>> >> adoption seems rather na=C3=AFve. It helps, >>> >>> > >>> >>> > I agree. Of course, having CFRG decide on precisely >>> >>> > which whiz-bang new crypto would be a good next step:-) >>> >>> >>> >>> But our choices are not the fastest ones! We've decided to have genus >>> >>> 1 prime, no CM, which is a very conservative choice, but not >>> >>> necessarily the fastest. >>> >>> >>> >>> Anyway, since Benjamin Black has said he doesn't actually think we >>> >>> should pick NUMS, but do our own picking, I think the answer is >>> >>> clear... >>> >>> > >>> >>> > S. >>> >>> > >>> >>> > _______________________________________________ >>> >>> > Cfrg mailing list >>> >>> >Cfrg@irtf.org >>> >>> >http://www.irtf.org/mailman/listinfo/cfrg >>> >>> >>> >>> >>> >>> >>> >>> -- >>> >>> "Those who would give up Essential Liberty to purchase a little >>> >>> Temporary Safety deserve neither Liberty nor Safety." >>> >>> -- Benjamin Franklin >>> >>> >>> >>> _______________________________________________ >>> >>> Cfrg mailing list >>> >>>Cfrg@irtf.org >>> >>>http://www.irtf.org/mailman/listinfo/cfrg >>> >> >>> >> >>> > >>> > >>> > >>> >-- >>> >"Those who would give up Essential Liberty to purchase a little >>> >Temporary Safety deserve neither Liberty nor Safety." >>> >-- Benjamin Franklin >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> >> > > _______________________________________________ > Cfrg mailing list >Cfrg@irtf.org >http://www.irtf.org/mailman/listinfo/cfrg > --089e0122971c10018a0506bc3453 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I feel we are being asked to buy a pig in a poke. Given that= the three yes votes have wanted random primes, or "a range of market&= quot; applications, and have left the door open to later having to pick for= TLS, I'm not sure the people voting yes actually agree with the propos= al, which as I read it would involve constructing a procedure that would ou= tput the curves, that would then go to TLS, without regard to other uses of= said procedure or picking out some curves from the output.

I'm going to vote "no". I don't see how th= is speeds up the process, or is different from the results of picking NUMS,= or E-521+other junk.

I'll mail a quarter to you if I have to for use in makin= g the decision: but let's decide already.

On Oct 31, 2014 10:53 AM, "Blumenthal, Uri - 0558 - MIT= LL" <uri@ll.mit.edu> wrote= :
>
> Yes.
>
> I concur with Benjamin=E2=80=99s reasoning.
> --=C2=A0
> Regards,
> Uri Blumenthal =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Voice:(781) 981-1638
>
> From: Benjamin Black <b@b3k.us><= br> >>
>> Yes.
>>
>> "Keeping in mind that this may induce negative performance im= pacts, but
>> could increase confidence in the outcome of our deliberations.&quo= t;
>>
>> The process should allow both random and selected primes, even if = CFRG decides to only use one or the other to meet the TLS-WG request. Agree= ing on the process allows us to avoid this lengthy debate in future should = other curves be needed to meet specific requirements.
>>
>> On Fri, Oct 31, 2014 at 10:34 AM, Paterson, Kenny <Kenny.Paterson@rhul.ac.uk> wrote: >>>
>>> Hi
>>>
>>> We could still go down the route of generating fresh curves if= there's
>>> consensus for it on the list.
>>>
>>> So let's do a quick poll:
>>>
>>> - Who on the list would be in favour of using a to-be-agreed p= rocedure to
>>> generate new curves, instead of selecting from amongst the cur= ves that are
>>> currently on the table?
>>>
>>> (Keeping in mind that this may induce negative performance imp= acts, but
>>> could increase confidence in the outcome of our deliberations.= )
>>>
>>> Replies should being with a one-word answer - "yes" = or "no".
>>> Justifications for positions can be included if you wish, but = right now
>>> I'm more interested in the raw, 1-bit answer.
>>>
>>> Thanks,
>>>
>>> Kenny
>>>
>>>
>>> On 31/10/2014 14:39, "Benjamin Black" <b@b3k.us> wrote:
>>>
>>> >Right, I didn't say don't pick NUMS. I said I beli= eve the process
>>> >should've gone a direction it did not, which would'= ;ve rejected _ALL_
>>> >current candidates in favor of CFRG generating new ones. T= hat is no more
>>> >my saying "don't pick NUMS" than your
>>> > saying you want genus 2 on the table is the same as your = saying "don't
>>> >pick Curve25519".
>>> >
>>> >On Fri, Oct 31, 2014 at 7:35 AM, Watson Ladd
>>> ><watsonbladd@g= mail.com> wrote:
>>> >
>>> >On Fri, Oct 31, 2014 at 7:31 AM, Benjamin Black <b@b3k.us> wrote:
>>> >> Watson,
>>> >>
>>> >> Where exactly did I say "don't pick NUMS&quo= t;?
>>> >
>>> >On October 29
>>> >"I've also said repeatedly that we should be star= ting from
>>> >requirements and then consider _generating_ curves to meet= them,
>>> >rather than limiting ourselves to the curves at hand or tr= ying to
>>> >contort the requirements to match an existing favorite.&qu= ot;
>>> >
>>> >
>>> >
>>> >That seems to suggest that we don't pick any curves, b= ut instead
>>> >generate new ones.
>>> >
>>> >>
>>> >>
>>> >> b
>>> >>
>>> >> On Fri, Oct 31, 2014 at 7:14 AM, Watson Ladd <watsonbladd@gmail.com>
>>> >>wrote:
>>> >>>
>>> >>> On Fri, Oct 31, 2014 at 7:10 AM, Stephen Farrell<= br> >>> >>> <= stephen.farrell@cs.tcd.ie> wrote:
>>> >>> >
>>> >>> >
>>> >>> > On 31/10/14 14:05, Richard Barnes wrote:
>>> >>> >> The idea that whiz-bang new crypto is th= e main barrier to 100% HTTPS
>>> >>> >> adoption seems rather na=C3=AFve.=C2=A0 = It helps,
>>> >>> >
>>> >>> > I agree. Of course, having CFRG decide on pr= ecisely
>>> >>> > which whiz-bang new crypto would be a good n= ext step:-)
>>> >>>
>>> >>> But our choices are not the fastest ones! We'= ve decided to have genus
>>> >>> 1 prime, no CM, which is a very conservative choi= ce, but not
>>> >>> necessarily the fastest.
>>> >>>
>>> >>> Anyway, since Benjamin Black has said he doesn= 9;t actually think we
>>> >>> should pick NUMS, but do our own picking, I think= the answer is
>>> >>> clear...
>>> >>> >
>>> >>> > S.
>>> >>> >
>>> >>> > ____________________________________________= ___
>>> >>> > Cfrg mailing list
>>> >>> >Cfrg@irtf.or= g
>>> >>> >http://www.irtf.org/mailman/listinfo/cfrg
>>> >>>
>>> >>>
>>> >>>
>>> >>> --
>>> >>> "Those who would give up Essential Liberty t= o purchase a little
>>> >>> Temporary Safety deserve neither=C2=A0 Liberty no= r Safety."
>>> >>> -- Benjamin Franklin
>>> >>>
>>> >>> _______________________________________________ >>> >>> Cfrg mailing list
>>> >>>Cfrg@irtf.org=
>>> >>>http://www.irtf.org/mailman/listinfo/cfrg
>>> >>
>>> >>
>>> >
>>> >
>>> >
>>> >--
>>> >"Those who would give up Essential Liberty to purchas= e a little
>>> >Temporary Safety deserve neither=C2=A0 Liberty nor Safety.= "
>>> >-- Benjamin Franklin
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>>
>>
>
> _______________________________________________
> Cfrg mailing list
>Cfrg@irtf.org
>http://www.irtf.o= rg/mailman/listinfo/cfrg
>

--089e0122971c10018a0506bc3453-- From nobody Fri Oct 31 11:50:21 2014 Return-Path: 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 472351A1A37 for ; Fri, 31 Oct 2014 11:50:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.61 X-Spam-Level: X-Spam-Status: No, score=-1.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 yZ2OiT71AkkE for ; Fri, 31 Oct 2014 11:50:17 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C7531A1A31 for ; Fri, 31 Oct 2014 11:50:17 -0700 (PDT) Received: from [91.53.243.71] by 3capp-gmx-bs25.server.lan (via HTTP); Fri, 31 Oct 2014 19:50:14 +0100 MIME-Version: 1.0 Message-ID: From: =?UTF-8?Q?=22Torsten_Sch=C3=BCtze=22?= To: "Paterson, Kenny" Content-Type: text/plain; charset=UTF-8 Date: Fri, 31 Oct 2014 19:50:14 +0100 Importance: normal Sensitivity: Normal In-Reply-To: References: Content-Transfer-Encoding: quoted-printable X-UI-Message-Type: mail X-Priority: 3 X-Provags-ID: V03:K0:EkT88X5Ujt7a5sdTskBe8bgR1Cj+Ka6Q6Alac/uLSJC VUltipBj4MapRAHEO4dpgjw7/EUiQmUKCdjFC2Bs5FsXFVZaBc jyA1UcycVw6lwUR2q2E/ajNkr6KqTeUGqbBaG1QTx0EDFec6GP d/ZKIbx8zxdBeXLl4Dr2Ll9Vz/EwrbIGimVWBBBTBoZATWJNYw rLQ/cgD3Ji1hqJdlIic6Qrsi0A9mkE+1I2J2Qk03e/9/bawBvR UlNa6dyiAYNdXzypsPP/PadaDOh7KdAzdESkGzcZH2Vs6b94Yi 3RKm7s= X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/KUvNAKJv4HPdq_oU_XMMvEUC00U Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] new curves or old (was: Actual security levels for IETF crypto) X-BeenThere: cfrg@irtf.org 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, 31 Oct 2014 18:50:19 -0000 Yes. Brainpool always stated that it could/would generate new VPR curves from t= ime to time.=20 In my personal opinion (not checked with BP members) one could at that occ= asion change some of the "critics", e.g., usage of SHA-1, twist security (n= ot unanimously agreed within BP). Quality goes before speed. The world will= not break down if TLS WG or other IETF WGs have to wait a little bit longe= r, but have TRUST in the selection procedure / the selected curves.=20 Torsten > Gesendet: Freitag, 31. Oktober 2014 um 18:34 Uhr > Von: "Paterson, Kenny" > An: "Benjamin Black" , "Watson Ladd" > Cc: "cfrg@irtf.org" > Betreff: Re: [Cfrg] new curves or old (was: Actual security levels for I= ETF crypto) > > Hi >=20 > We could still go down the route of generating fresh curves if there's > consensus for it on the list. >=20 > So let's do a quick poll: >=20 > - Who on the list would be in favour of using a to-be-agreed procedure t= o > generate new curves, instead of selecting from amongst the curves that a= re > currently on the table? >=20 > (Keeping in mind that this may induce negative performance impacts, but > could increase confidence in the outcome of our deliberations.) >=20 > Replies should being with a one-word answer - "yes" or "no". > Justifications for positions can be included if you wish, but right now > I'm more interested in the raw, 1-bit answer. >=20 > Thanks, >=20 > Kenny=20 >=20 >=20 > On 31/10/2014 14:39, "Benjamin Black" wrote: >=20 > >Right, I didn't say don't pick NUMS. I said I believe the process > >should've gone a direction it did not, which would've rejected _ALL_ > >current candidates in favor of CFRG generating new ones. That is no mor= e > >my saying "don't pick NUMS" than your > > saying you want genus 2 on the table is the same as your saying "don't > >pick Curve25519". > > > >On Fri, Oct 31, 2014 at 7:35 AM, Watson Ladd > > wrote: > > > >On Fri, Oct 31, 2014 at 7:31 AM, Benjamin Black wrote: > >> Watson, > >> > >> Where exactly did I say "don't pick NUMS"? > > > >On October 29 > >"I've also said repeatedly that we should be starting from > >requirements and then consider _generating_ curves to meet them, > >rather than limiting ourselves to the curves at hand or trying to > >contort the requirements to match an existing favorite." > > > > > > > >That seems to suggest that we don't pick any curves, but instead > >generate new ones. > > > >> > >> > >> b > >> > >> On Fri, Oct 31, 2014 at 7:14 AM, Watson Ladd > >>wrote: > >>> > >>> On Fri, Oct 31, 2014 at 7:10 AM, Stephen Farrell > >>> wrote: > >>> > > >>> > > >>> > On 31/10/14 14:05, Richard Barnes wrote: > >>> >> The idea that whiz-bang new crypto is the main barrier to 100% HT= TPS > >>> >> adoption seems rather na=C3=AFve. It helps, > >>> > > >>> > I agree. Of course, having CFRG decide on precisely > >>> > which whiz-bang new crypto would be a good next step:-) > >>> > >>> But our choices are not the fastest ones! We've decided to have genu= s > >>> 1 prime, no CM, which is a very conservative choice, but not > >>> necessarily the fastest. > >>> > >>> Anyway, since Benjamin Black has said he doesn't actually think we > >>> should pick NUMS, but do our own picking, I think the answer is > >>> clear... > >>> > > >>> > S. > >>> > > >>> > _______________________________________________ > >>> > Cfrg mailing list > >>> > Cfrg@irtf.org > >>> > http://www.irtf.org/mailman/listinfo/cfrg > >>> > >>> > >>> > >>> -- > >>> "Those who would give up Essential Liberty to purchase a little > >>> Temporary Safety deserve neither Liberty nor Safety." > >>> -- Benjamin Franklin > >>> > >>> _______________________________________________ > >>> Cfrg mailing list > >>> Cfrg@irtf.org > >>> http://www.irtf.org/mailman/listinfo/cfrg > >> > >> > > > > > > > >-- > >"Those who would give up Essential Liberty to purchase a little > >Temporary Safety deserve neither Liberty nor Safety." > >-- Benjamin Franklin > > > > > > > > > > > > > > >=20 > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg > From nobody Fri Oct 31 11:56:54 2014 Return-Path: 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 A392F1A0AFE for ; Fri, 31 Oct 2014 11:56:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 m8K1vmSXcrTO for ; Fri, 31 Oct 2014 11:56:50 -0700 (PDT) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29F001A0072 for ; Fri, 31 Oct 2014 11:56:50 -0700 (PDT) Received: by mail-wi0-f174.google.com with SMTP id d1so2115717wiv.13 for ; Fri, 31 Oct 2014 11:56: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 :content-transfer-encoding:message-id:references:to; bh=qCFPEp5Uhiymi79shDlR7T4wvX+2iRy9YkdyGoYaxyA=; b=ndYp0j4bzr1spuJ4wGNspYHgc3diXgz/w1a2MQAUazPrQ0uMH0M2hcFLmdT1Kc8bKR m5M/+AwkwApGZ56qPS6fGabpl94j6SqMbIK+NaNwckGN6Zh9YYuZrThSu2POmYYVUrzy XHrVXcH2QU813ksJUWLVe0/q6tLrZm0d2vVxY7vuPvlmnjIp0Ycmh48OxwPhrnsWdu7d 996417/F2w2Lm3P9L0CVyEgVM4Bv8bAm0YzgYk42bm8RxlWlzzO+08psFhasr0QHsa0r 9xmOb+j3fW7FQIsEZ5bi1u3mjnOQdBri17sSFNyOse9FtNcJLXZBbe9eGUVT9UydXP5G /olw== X-Received: by 10.194.23.10 with SMTP id i10mr29563329wjf.11.1414781808704; Fri, 31 Oct 2014 11:56:48 -0700 (PDT) Received: from [192.168.1.104] (IGLD-84-228-87-161.inter.net.il. [84.228.87.161]) by mx.google.com with ESMTPSA id td9sm13320425wic.15.2014.10.31.11.56.47 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 31 Oct 2014 11:56:48 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Yoav Nir In-Reply-To: Date: Fri, 31 Oct 2014 20:56:46 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <635F495D-D39D-4F1F-9D22-96D7B14D51CF@gmail.com> References: To: "cfrg@irtf.org" X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/WJ4JM6LbPeA8Qn-MPgo8_2q3wII Subject: Re: [Cfrg] new curves or old (was: Actual security levels for IETF crypto) X-BeenThere: cfrg@irtf.org 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, 31 Oct 2014 18:56:52 -0000 > On Oct 31, 2014, at 8:18 PM, Alyssa Rowan wrote: >=20 >> - Who on the list would be in favour of using a to-be-agreed = procedure to generate new curves, instead of selecting from amongst the = curves that are currently on the table? >=20 > No. >=20 > =E2=80=A2 If we generated new curves with rigid processes and = constraints, they'd likely match one of the contenders. (That's the = point. See what happened with E-521.) >=20 > =E2=80=A2 I think the already-existing Brainpool curves match random = curve criteria fine. >=20 > =E2=80=A2 Concerns about delay. >=20 > There's nothing stopping us (or Brainpool) doing new random curves = later, but I don't think this satisfies the TLS WG request on the table = now. +1. No. I totally trust the Brainpool people to have picked the curves correctly = and randomly. No reason to do it again. The NUMS people have (I=E2=80=99m sure) done a fine job of doing the = rigid process, and I don=E2=80=99t think we=E2=80=99ll come up with = better rigid criteria unless we tailor the criteria to get a particular = curve. It=E2=80=99s time to do what IETF and IRTF usually do poorly - decide = among several options, each with advantages and disadvantages. Yoav From nobody Fri Oct 31 12:02:52 2014 Return-Path: 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 A82AA1A1A43 for ; Fri, 31 Oct 2014 12:02:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 qWXuFQzzRI6t for ; Fri, 31 Oct 2014 12:02:48 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43A771A1A37 for ; Fri, 31 Oct 2014 12:02:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4025; q=dns/txt; s=iport; t=1414782168; x=1415991768; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=68JZXRLtu/UBi0SpFHLIkjuN2wbO/DX2Nliv6KTOWmc=; b=jiQUL8NlW7aChN0yty+zu4fy1JWtlcRghkaYN0UFAxvZiMZSZIeZ6U7W HVQnsiMegxn98/3DBI93DaQz1Qn898LgkRyxXUcAn9ZsVi83ZBqAOrBxD s2GXOrhm8ZcTlVvxMN6bfyjNHZQsSpQ6inlUcwUV7Gfg8d14luGkI4n1O Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiIFAIXbU1StJA2H/2dsb2JhbABcDoMAVFgEzSAKh00CgRkWAQEBAQF9hAIBAQEEAQEBawsMBAIBCBEEAQEBCh0HIQYLFAkIAgQBDQUIAYgjAxINxD4NhkABAQEBAQEBAQEBAQEBAQEBAQEBAQEXjkYQHYFsMQcGgyeBHgWLM4ZiiVKDQo4qgmSECYM4QGyBBiQegQMBAQE X-IronPort-AV: E=Sophos;i="5.07,295,1413244800"; d="scan'208";a="368560514" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-2.cisco.com with ESMTP; 31 Oct 2014 19:02:48 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s9VJ2lhF026136 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 31 Oct 2014 19:02:47 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.20]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0195.001; Fri, 31 Oct 2014 14:02:47 -0500 From: "Scott Fluhrer (sfluhrer)" To: "Paterson, Kenny" , Benjamin Black , Watson Ladd Thread-Topic: [Cfrg] new curves or old (was: Actual security levels for IETF crypto) Thread-Index: AQHP9TDjfPP/w4GML0GGs4Ff+mhqFpxKj8tw Date: Fri, 31 Oct 2014 19:02:46 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.196.27] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/EWeASY0F6GO5h5vSMZTkWo4SDtQ Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] new curves or old (was: Actual security levels for IETF crypto) X-BeenThere: cfrg@irtf.org 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, 31 Oct 2014 19:02:50 -0000 No. We have plenty of proposals for curves that are quite reasonable. We don't= need to go inventing Yet More curves... > -----Original Message----- > From: Cfrg [mailto:cfrg-bounces@irtf.org] On Behalf Of Paterson, Kenny > Sent: Friday, October 31, 2014 1:34 PM > To: Benjamin Black; Watson Ladd > Cc: cfrg@irtf.org > Subject: Re: [Cfrg] new curves or old (was: Actual security levels for IE= TF > crypto) >=20 > Hi >=20 > We could still go down the route of generating fresh curves if there's > consensus for it on the list. >=20 > So let's do a quick poll: >=20 > - Who on the list would be in favour of using a to-be-agreed procedure to > generate new curves, instead of selecting from amongst the curves that ar= e > currently on the table? >=20 > (Keeping in mind that this may induce negative performance impacts, but > could increase confidence in the outcome of our deliberations.) >=20 > Replies should being with a one-word answer - "yes" or "no". > Justifications for positions can be included if you wish, but right now I= 'm more > interested in the raw, 1-bit answer. >=20 > Thanks, >=20 > Kenny >=20 >=20 > On 31/10/2014 14:39, "Benjamin Black" wrote: >=20 > >Right, I didn't say don't pick NUMS. I said I believe the process > >should've gone a direction it did not, which would've rejected _ALL_ > >current candidates in favor of CFRG generating new ones. That is no > >more my saying "don't pick NUMS" than your saying you want genus 2 on > >the table is the same as your saying "don't pick Curve25519". > > > >On Fri, Oct 31, 2014 at 7:35 AM, Watson Ladd > >wrote: > > > >On Fri, Oct 31, 2014 at 7:31 AM, Benjamin Black wrote: > >> Watson, > >> > >> Where exactly did I say "don't pick NUMS"? > > > >On October 29 > >"I've also said repeatedly that we should be starting from requirements > >and then consider _generating_ curves to meet them, rather than > >limiting ourselves to the curves at hand or trying to contort the > >requirements to match an existing favorite." > > > > > > > >That seems to suggest that we don't pick any curves, but instead > >generate new ones. > > > >> > >> > >> b > >> > >> On Fri, Oct 31, 2014 at 7:14 AM, Watson Ladd > >>wrote: > >>> > >>> On Fri, Oct 31, 2014 at 7:10 AM, Stephen Farrell > >>> wrote: > >>> > > >>> > > >>> > On 31/10/14 14:05, Richard Barnes wrote: > >>> >> The idea that whiz-bang new crypto is the main barrier to 100% > >>> >> HTTPS adoption seems rather na=EFve. It helps, > >>> > > >>> > I agree. Of course, having CFRG decide on precisely which > >>> > whiz-bang new crypto would be a good next step:-) > >>> > >>> But our choices are not the fastest ones! We've decided to have > >>> genus > >>> 1 prime, no CM, which is a very conservative choice, but not > >>> necessarily the fastest. > >>> > >>> Anyway, since Benjamin Black has said he doesn't actually think we > >>> should pick NUMS, but do our own picking, I think the answer is > >>> clear... > >>> > > >>> > S. > >>> > > >>> > _______________________________________________ > >>> > Cfrg mailing list > >>> > Cfrg@irtf.org > >>> > http://www.irtf.org/mailman/listinfo/cfrg > >>> > >>> > >>> > >>> -- > >>> "Those who would give up Essential Liberty to purchase a little > >>> Temporary Safety deserve neither Liberty nor Safety." > >>> -- Benjamin Franklin > >>> > >>> _______________________________________________ > >>> Cfrg mailing list > >>> Cfrg@irtf.org > >>> http://www.irtf.org/mailman/listinfo/cfrg > >> > >> > > > > > > > >-- > >"Those who would give up Essential Liberty to purchase a little > >Temporary Safety deserve neither Liberty nor Safety." > >-- Benjamin Franklin > > > > > > > > > > > > > > >=20 > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg From nobody Fri Oct 31 12:51:53 2014 Return-Path: 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 BE40E1A020B for ; Fri, 31 Oct 2014 12:51:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 cG2Kat5WYnAS for ; Fri, 31 Oct 2014 12:51:48 -0700 (PDT) Received: from smtp-p01.blackberry.com (smtp-p01.blackberry.com [208.65.78.88]) by ietfa.amsl.com (Postfix) with ESMTP id 4A3C51A0199 for ; Fri, 31 Oct 2014 12:51:47 -0700 (PDT) Received: from smtp-pop.rim.net (HELO XCT103CNC.rim.net) ([10.65.161.203]) by mhs211cnc.rim.net with ESMTP/TLS/AES128-SHA; 31 Oct 2014 15:51:43 -0400 Received: from XMB116CNC.rim.net ([fe80::45d:f4fe:6277:5d1b]) by XCT103CNC.rim.net ([fe80::b8:d5e:26a5:f4d6%17]) with mapi id 14.03.0174.001; Fri, 31 Oct 2014 15:51:42 -0400 From: Dan Brown To: "'Kenny.Paterson@rhul.ac.uk'" Thread-Topic: [Cfrg] new curves or old (was: Actual security levels for IETF crypto) Thread-Index: AQHP9TDjsjzpu3pf3E2CfS5RocicHpxKmEKQ Date: Fri, 31 Oct 2014 19:51:41 +0000 Message-ID: <810C31990B57ED40B2062BA10D43FBF5CF9A77@XMB116CNC.rim.net> References: In-Reply-To: Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.250] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0077_01CFF522.905C8770" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/rfuuf_gpXI6G6rKewnXRoMO-r8Q Cc: "'cfrg@irtf.org'" Subject: Re: [Cfrg] new curves or old (was: Actual security levels for IETF crypto) X-BeenThere: cfrg@irtf.org 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, 31 Oct 2014 19:51:50 -0000 ------=_NextPart_000_0077_01CFF522.905C8770 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Cfrg [mailto:cfrg-bounces@irtf.org] On Behalf Of Paterson, Kenny > > So let's do a quick poll: > > - Who on the list would be in favour of using a to-be-agreed procedure to > generate new curves, instead of selecting from amongst the curves that are > currently on the table? > Yes, I'm in favor. I'd like a special prime with random j-invariant (as usual, subject to some reasonable cofactor and other to-be-agreed constraints). This would only slightly impact efficiency (by 1% IIRC), but would help resist *sparse* secret attacks (which I think there's <<1% chance of existing). Also, existing implementations of the special prime field can be quite easily adapted, just by switching over the coefficients. Although weak fields are a concern in binary-field elliptic curves, it seems unlikely to carry over to prime-field curves. If it does carry over, then the Brainpool curves should prevent that problem, and they are ready to go. That's why I think special primes would be okay. ------=_NextPart_000_0077_01CFF522.905C8770 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUoDCCBo8w ggV3oAMCAQICCm2p3UcABAAABWowDQYJKoZIhvcNAQEFBQAwUDETMBEGCgmSJomT8ixkARkWA25l dDETMBEGCgmSJomT8ixkARkWA3JpbTEkMCIGA1UEAxMbUklNIFN1Ym9yZGluYXRlIENBIE1DQTAy WUtGMB4XDTE0MDUxNDE0MzYzOFoXDTE1MDUxNDE0MzYzOFowgaQxEzARBgoJkiaJk/IsZAEZFgNu ZXQxEzARBgoJkiaJk/IsZAEZFgNyaW0xDTALBgNVBAsTBEFNRVIxCzAJBgNVBAsTAkNBMRQwEgYD VQQLEwtNaXNzaXNzYXVnYTEOMAwGA1UECxMFVXNlcnMxEjAQBgNVBAMTCURhbiBCcm93bjEiMCAG CSqGSIb3DQEJARYTZGJyb3duQGNlcnRpY29tLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEA54YaBOai2UDS89LoHMbDcC4+c8dEl5TpkJWz0muqjnXP6xpSYqBzotsw9SpPD3/0wF8Dz77Z hkYN8BDSF0RAdtmfXKXe40tQkHoplN4pos9jnBZW5e8HuTZUkEVC/q7bf399cskpxMt9MA934gvB rSk1QNbR3D7Hq34t4bOHXSUCAwEAAaOCA5gwggOUMAsGA1UdDwQEAwIFoDBEBgkqhkiG9w0BCQ8E NzA1MA4GCCqGSIb3DQMCAgIAgDAOBggqhkiG9w0DBAICAIAwBwYFKw4DAgcwCgYIKoZIhvcNAwcw FwYJKwYBBAGCNxQCBAoeCABVAHMAZQByMCkGA1UdJQQiMCAGCisGAQQBgjcKAwQGCCsGAQUFBwME BggrBgEFBQcDAjBBBgNVHREEOjA4oCEGCisGAQQBgjcUAgOgEwwRZGFuaWJyb3duQHJpbS5uZXSB E2Ricm93bkBjZXJ0aWNvbS5jb20wHQYDVR0OBBYEFFdFrujr5LyMGa3Hl1U4MTjlEtfvMB8GA1Ud IwQYMBaAFObbryVSYEL0jYI1VF2A64ahrO/cMIIBMQYDVR0fBIIBKDCCASQwggEgoIIBHKCCARiG gctsZGFwOi8vL0NOPVJJTSUyMFN1Ym9yZGluYXRlJTIwQ0ElMjBNQ0EwMllLRixDTj1NQ0EwMllL RixDTj1DRFAsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmln dXJhdGlvbixEQz13aW5kb3dzLERDPWxvY2FsP2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFz ZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2ludIZIaHR0cDovL21jYTAyeWtmLnJpbS5u ZXQvQ2VydEVucm9sbC9SSU0lMjBTdWJvcmRpbmF0ZSUyMENBJTIwTUNBMDJZS0YuY3JsMIIBQQYI KwYBBQUHAQEEggEzMIIBLzCBwgYIKwYBBQUHMAKGgbVsZGFwOi8vL0NOPVJJTSUyMFN1Ym9yZGlu YXRlJTIwQ0ElMjBNQ0EwMllLRixDTj1BSUEsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049 U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz13aW5kb3dzLERDPWxvY2FsP2NBQ2VydGlmaWNh dGU/YmFzZT9vYmplY3RDbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MGgGCCsGAQUFBzAChlxo dHRwOi8vbWNhMDJ5a2YucmltLm5ldC9DZXJ0RW5yb2xsL01DQTAyWUtGLnJpbS5uZXRfUklNJTIw U3Vib3JkaW5hdGUlMjBDQSUyME1DQTAyWUtGKDQpLmNydDANBgkqhkiG9w0BAQUFAAOCAQEActBk hryrMh5+C+8YiOrR8xi+G1NkUycfNLuz4fYdQzFNB9yWxyRs2K0ydl0X5PZXejhbIif0dFoyaxnh g/D5hYfeGIhXfAOFG22EpMJWXVOavqYLxslnc2enihWAYcWkjPfE6tf3XMXkodFkMYvEd+qFj8eU vxbbcR1dBqiBFNNDcKlAKn/oElp/iI/LjUGMEb+tJdHttsGExvQzSd1zwk1U6cOinYD82Y08zA5b z38l5bE2+plmfX3EQ8vCKYA95psgGg3hsffn150smpY7HeEPGRZh9vglGfi2wnMqY/QgO+qs78dq O/C1be3quQU3WHQ6YcZr3JP1Rc7yj76K7jCCBr8wggSnoAMCAQICEDIa85KxFFmUTU0vlRGze+Ew DQYJKoZIhvcNAQEFBQAwTzEVMBMGCgmSJomT8ixkARkWBWxvY2FsMRcwFQYKCZImiZPyLGQBGRYH d2luZG93czEdMBsGA1UEAxMUUklNIFJvb3QgQ0EgTUNBMDFZS0YwHhcNMDYxMDEzMDEyNDU1WhcN MTYxMDEzMDEzMDQxWjBPMRUwEwYKCZImiZPyLGQBGRYFbG9jYWwxFzAVBgoJkiaJk/IsZAEZFgd3 aW5kb3dzMR0wGwYDVQQDExRSSU0gUm9vdCBDQSBNQ0EwMVlLRjCCAiIwDQYJKoZIhvcNAQEBBQAD ggIPADCCAgoCggIBAMbous78rVQBLT87+jYSuzmZ2osP40BMhFbJA3+cs3BZC0//uT87SG7/nhZi 9Qj9hYby7/HkGSQyheGL/lLIzxDdZV+AwxiirdDT6ck/acEMxWolLdK5xEYEmm6OxLaUuEvg7i/B vXPpZlsA6m9FFrTzHVX2693w8IoMs9cofr1TAB3YYDnvZTwupz7YifSF02pu1eZiZg09Jjaav9Hy aNyRGjbwyqFwTpCr+iHW7SsSszyJxulWGgnYCQgE95loK/ZMYhEBFCSq7yNn1yNM0WJ5S+uPILyv OKXbE9sWSxba+DnWQJuEZCvFPnILq5Ugq+jVap326uv9zejBpsnPUgdgMoZNlUuuu+e1eJwc3mng /rK6ZOCF1NzUzP/mIEdc1UuNV8L2WqvVH+fY9EyYTfcRlWTvO9XlVa9lXzca9MTqlKcHMYeSWWJF nJlCRZWIkIdAjNj632g0U06kWUHeBd8VJXFxQFzhob2lyr4pHiOv7rZ1+rwpw8DFMZnp85b/HqTW rcQ7LiIDljuKX6oBjMs1qNobnUPe/ucp1Kgy19+J61M7MxniBNyqKmLJLMTBd7aiIGnbfYTVl2j/ xJJ2aUQJmj9LNFeWb4Isl8PVK6p1sJkWy0JOx52HNIR0AY16AcikojsoYEkvci+mvuwANq4QT6bE lSPS2AbNnDSpT7GXAgMBAAGjggGVMIIBkTATBgkrBgEEAYI3FAIEBh4EAEMAQTALBgNVHQ8EBAMC AUYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQU1mmCZCQWwcwk2/EUfUcSfNzJTe4wggEpBgNV HR8EggEgMIIBHDCCARigggEUoIIBEIaBxGxkYXA6Ly8vQ049UklNJTIwUm9vdCUyMENBJTIwTUNB MDFZS0YsQ049TUNBMDFZS0YsQ049Q0RQLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNl cnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9d2luZG93cyxEQz1sb2NhbD9jZXJ0aWZpY2F0ZVJl dm9jYXRpb25MaXN0P2Jhc2U/b2JqZWN0Q2xhc3M9Y1JMRGlzdHJpYnV0aW9uUG9pbnSGR2h0dHA6 Ly9tY2EwMXlrZi53aW5kb3dzLmxvY2FsL0NlcnRFbnJvbGwvUklNJTIwUm9vdCUyMENBJTIwTUNB MDFZS0YuY3JsMBAGCSsGAQQBgjcVAQQDAgEAMA0GCSqGSIb3DQEBBQUAA4ICAQBDnlhbuDlU58ff o2JPdog62tn9QXOY9VnrBBiDZeFQmPVicup9e2/4dnw5o4/SnyLaNyxNlno++5Uiar/y0ne8J300 FWVW9cAXtmbfi7jwKour1kgwEFTn3TjGFbuYps553/mTTC3bk6l2f2xUCk1rINqoQVsGomH8RGO5 1YN/mX0rasHPUd7/7Rx/m/ZF9xbii6FUOikq6lMgYn4SEY+e3jsOvyYzwPkiHf6dshGfsZgDUN9b xNwRxUZttJGRx6gH3Qpk7dUuyw0ixwY9xmVyBVIHvWjyqswF3ntgwmEz92GHIKz/xWxRdkahkSIT zPjHYya2jI3sfpzU/tigvxCFrG1PQ4BSCNMByqUcfK5STTfJJm/x/ahqnDWlvUP6cFE6V9W10nW8 72BbNzWOypmGIouENEUAhq/ejrw09P0uvyK51vr6mY5z1djF6hLskNC+R11Tpwou+vbhmHEZBKOc cxCfxDL49O7wlpxu4fcpDYSxBDHMoFZgXVz/ajqqIHcjyQdAM8QGBqgkjE/Dq7NTP7K2Ul1An0nx DR+YgXe28R+7l5he5GzhIIaJuwHHAtgpbeA1NLY/bBciFoOR+s8ujS3rZtv5M3Q95hmN7trVrYo1 Z3dglmNmLM2KNZWwwHxH4xi//bhaR+/WbfXpEUg+WW0p9Uja9Z443hqVd48MrjCCB0YwggUuoAMC AQICChJuoPAAAAAAAiswDQYJKoZIhvcNAQEFBQAwTzEVMBMGCgmSJomT8ixkARkWBWxvY2FsMRcw FQYKCZImiZPyLGQBGRYHd2luZG93czEdMBsGA1UEAxMUUklNIFJvb3QgQ0EgTUNBMDFZS0YwHhcN MTQwNDAyMDA1MTEyWhcNMTYwNDAyMDEwMTEyWjBQMRMwEQYKCZImiZPyLGQBGRYDbmV0MRMwEQYK CZImiZPyLGQBGRYDcmltMSQwIgYDVQQDExtSSU0gU3Vib3JkaW5hdGUgQ0EgTUNBMDJZS0YwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCzrn3UT996pLvUIVlnExxcXGmYftIOq1qMwitW RCBe2j32VmDvzlJseIkfQuXDqjWnoqoE4sxQjxD5QNwhyBw9eXMCvLjHBW+HM4+HcmGIdan2w17E 4rR+RHVK6NzvkE1Gm4ziBTDr2jzSliZJpowLM+M/+cY2pyym074TQx+QCZQOKIqLnEgZ2uYw4kSj nCcE7eJ+WmJFq9bX6Cv9SONQfgN5Z3O1N/36lgavm/G6Amt/ePNE0AhcJwxin7Fahkx6/SjRbf0r Oa8uhCMxK8ebqTqD0+0VpViARFterasW5FTU2rcRFLHwwWV67yoFc2fbozkj5iseBXctM8NmqKt5 AgMBAAGjggMhMIIDHTAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBTm268lUmBC9I2CNVRdgOuG oazv3DALBgNVHQ8EBAMCAYYwEAYJKwYBBAGCNxUBBAMCAQQwIwYJKwYBBAGCNxUCBBYEFCLdxB/L akuvuaYdTyqIgHmfibLUMBkGCSsGAQQBgjcUAgQMHgoAUwB1AGIAQwBBMB8GA1UdIwQYMBaAFNZp gmQkFsHMJNvxFH1HEnzcyU3uMIIBKQYDVR0fBIIBIDCCARwwggEYoIIBFKCCARCGgcRsZGFwOi8v L0NOPVJJTSUyMFJvb3QlMjBDQSUyME1DQTAxWUtGLENOPU1DQTAxWUtGLENOPUNEUCxDTj1QdWJs aWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPXdpbmRv d3MsREM9bG9jYWw/Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdD9iYXNlP29iamVjdENsYXNzPWNS TERpc3RyaWJ1dGlvblBvaW50hkdodHRwOi8vbWNhMDF5a2Yud2luZG93cy5sb2NhbC9DZXJ0RW5y b2xsL1JJTSUyMFJvb3QlMjBDQSUyME1DQTAxWUtGLmNybDCCATwGCCsGAQUFBwEBBIIBLjCCASow gbsGCCsGAQUFBzAChoGubGRhcDovLy9DTj1SSU0lMjBSb290JTIwQ0ElMjBNQ0EwMVlLRixDTj1B SUEsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlv bixEQz13aW5kb3dzLERDPWxvY2FsP2NBQ2VydGlmaWNhdGU/YmFzZT9vYmplY3RDbGFzcz1jZXJ0 aWZpY2F0aW9uQXV0aG9yaXR5MGoGCCsGAQUFBzAChl5odHRwOi8vbWNhMDF5a2Yud2luZG93cy5s b2NhbC9DZXJ0RW5yb2xsL01DQTAxWUtGLndpbmRvd3MubG9jYWxfUklNJTIwUm9vdCUyMENBJTIw TUNBMDFZS0YuY3J0MA0GCSqGSIb3DQEBBQUAA4ICAQCUe8BMuuw2GW4AUAag80hqgwOQyezrSatL SIadEDvzg3LgXMJcN7onC+1B7vHsMxVMbFz3V+85WSKtzCtaBe5rhUCXLBZEGbM+WPavYgYMnUsD TpJwSXiDaM9Ym/ZLFsgfo3Qv7rfglydpqPCBfHUEQys2KeBVsDGd7HDK5Nk5fNaSmK0KgIBIvbXR bJKzhTsuctYGlOf/2nFtuoxWcdhu7t6UR7DbSTerjug7rvCZH4bie5cphsu4lZDXdNRp2IKWVEF6 0VcEK8dXK1hZXEGgjuen7R03uaA+7VsSr7eUZSLiouG7XnvXWik11aNCgBiQcIGsHVRIccHphmfS sFaZ0Bc+4/c/+K/v7X7RvdE29J9b1DqB2iV2SGZp58M0JLscohJ9uY0SJj8Hwl9YeuznijFBIC2y Psb1V9CgoRtBl+Ek37tPp1Wm4XSS+as2kcdcsZwiM/LywbFvYDEBa71b0mquxjisPyPvmVccA0e6 WW6RDNYKUqBJsZDpjTbRZkQA7CmzrOK6YHip2F/92ZYmpqM84BsEkLuf6kzzk+r0OVsWaFP+plU3 MfqtAeKtBgJu6yd4SYbA9eFX9ePeIzBaCjTzIcd+CclwA8SeoAgP07Ut2WcB3QnD7fcU6CBegHSd 7504Ty34G+FymbG6ZBBUU0exF44VAplxv4rWFA7mPTGCAvMwggLvAgEBMF4wUDETMBEGCgmSJomT 8ixkARkWA25ldDETMBEGCgmSJomT8ixkARkWA3JpbTEkMCIGA1UEAxMbUklNIFN1Ym9yZGluYXRl IENBIE1DQTAyWUtGAgptqd1HAAQAAAVqMAkGBSsOAwIaBQCgggHrMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE0MTAzMTE5NTE0MVowIwYJKoZIhvcNAQkEMRYEFIid bxZbU+m/0QPkaAXDAZbJe/eRMG0GCSsGAQQBgjcQBDFgMF4wUDETMBEGCgmSJomT8ixkARkWA25l dDETMBEGCgmSJomT8ixkARkWA3JpbTEkMCIGA1UEAxMbUklNIFN1Ym9yZGluYXRlIENBIE1DQTAy WUtGAgptqd1HAAQAAAVqMG8GCyqGSIb3DQEJEAILMWCgXjBQMRMwEQYKCZImiZPyLGQBGRYDbmV0 MRMwEQYKCZImiZPyLGQBGRYDcmltMSQwIgYDVQQDExtSSU0gU3Vib3JkaW5hdGUgQ0EgTUNBMDJZ S0YCCm2p3UcABAAABWowgasGCSqGSIb3DQEJDzGBnTCBmjALBglghkgBZQMEASowCwYJYIZIAWUD BAEWMAoGCCqGSIb3DQMHMAsGCWCGSAFlAwQBAjAOBggqhkiG9w0DAgICAIAwBwYFKw4DAgcwDQYI KoZIhvcNAwICAUAwDQYIKoZIhvcNAwICASgwBwYFKw4DAhowCwYJYIZIAWUDBAIDMAsGCWCGSAFl AwQCAjALBglghkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEgYBJV2IqazzRgvDFA61r88qqVakTdk2D euePlccHI1fbQgFxT1li2CXKIbF4k8RsgfIKFR/KzKFuD+zknz9FXjskQiHmsLpdS7nP2zZtzEwR HtZdugGkcU/mA2n1EtIJUOhBSJMG7GBbd+fgw0ZWqcQu6arbpb0M69BuofTVuijO1AAAAAAAAA== ------=_NextPart_000_0077_01CFF522.905C8770-- From nobody Fri Oct 31 14:46:54 2014 Return-Path: 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 00A031A6F12 for ; Fri, 31 Oct 2014 14:46:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 E4_ZFBuM1dAh for ; Fri, 31 Oct 2014 14:46:49 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 9D1551A6F05 for ; Fri, 31 Oct 2014 14:46:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 2B7AABE09; Fri, 31 Oct 2014 21:46:46 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XQmG1ME1_FRD; Fri, 31 Oct 2014 21:46:45 +0000 (GMT) Received: from [10.87.48.12] (unknown [86.41.50.206]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 1116CBE08; Fri, 31 Oct 2014 21:46:45 +0000 (GMT) Message-ID: <54540344.6010809@cs.tcd.ie> Date: Fri, 31 Oct 2014 21:46:44 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Yoav Nir , "cfrg@irtf.org" References: <635F495D-D39D-4F1F-9D22-96D7B14D51CF@gmail.com> In-Reply-To: <635F495D-D39D-4F1F-9D22-96D7B14D51CF@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/9jOEAybnlDvlCiuVgfkGTdrX-Jc Subject: Re: [Cfrg] new curves or old (was: Actual security levels for IETF crypto) X-BeenThere: cfrg@irtf.org 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, 31 Oct 2014 21:46:52 -0000 On 31/10/14 18:56, Yoav Nir wrote: > It’s time to do what IETF and IRTF usually do poorly - decide among > several options, each with advantages and disadvantages. +1, and count me as a no-hats no, on the basis that yes == more delay and more not particularly fruitful discussion. (Though I do find a good bit of the non-fruitful discussion educational;-) S. From nobody Fri Oct 31 16:51:01 2014 Return-Path: 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 307A21A8745 for ; Fri, 31 Oct 2014 16:50:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 JkzZhKnNf-sm for ; Fri, 31 Oct 2014 16:50:56 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E1921A8741 for ; Fri, 31 Oct 2014 16:50:56 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1XkLy2-0004is-TX; Fri, 31 Oct 2014 23:50:55 +0000 Date: Sat, 01 Nov 2014 08:50:53 +0900 Message-ID: From: Randy Bush To: Yoav Nir In-Reply-To: <635F495D-D39D-4F1F-9D22-96D7B14D51CF@gmail.com> References: <635F495D-D39D-4F1F-9D22-96D7B14D51CF@gmail.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/3cWur-CTKY_tiXDRR_RSrxCi6as Cc: IRTF CFRG Subject: Re: [Cfrg] new curves or old (was: Actual security levels for IETF crypto) X-BeenThere: cfrg@irtf.org 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, 31 Oct 2014 23:50:58 -0000 > It=E2=80=99s time to do what IETF and IRTF usually do poorly - decide amo= ng > several options, each with advantages and disadvantages. bingo. i.e. no.