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 ciphertex