Re: [Cfrg] 40 bit loop and DragonFly
Stephen Farrell <stephen.farrell@cs.tcd.ie> Sun, 05 January 2014 10:34 UTC
Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 155881ADF8C for <cfrg@ietfa.amsl.com>; Sun, 5 Jan 2014 02:34:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.438
X-Spam-Level:
X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6t15opfbGohy for <cfrg@ietfa.amsl.com>; Sun, 5 Jan 2014 02:34:03 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id ECEA21ADF89 for <cfrg@irtf.org>; Sun, 5 Jan 2014 02:34:02 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 70613BE74; Sun, 5 Jan 2014 10:33:54 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2nyxPWyGxegc; Sun, 5 Jan 2014 10:33:53 +0000 (GMT)
Received: from [10.87.48.14] (unknown [86.44.71.9]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 03B8ABE6E; Sun, 5 Jan 2014 10:33:52 +0000 (GMT)
Message-ID: <52C93506.5070100@cs.tcd.ie>
Date: Sun, 05 Jan 2014 10:33:42 +0000
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: "Igoe, Kevin M." <kmigoe@nsa.gov>, "'cfrg@irtf.org'" <cfrg@irtf.org>
References: <3C4AAD4B5304AB44A6BA85173B4675CABA99F80C@MSMR-GH1-UEA03.corp.nsa.gov>
In-Reply-To: <3C4AAD4B5304AB44A6BA85173B4675CABA99F80C@MSMR-GH1-UEA03.corp.nsa.gov>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Subject: Re: [Cfrg] 40 bit loop and DragonFly
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Sun, 05 Jan 2014 10:34:07 -0000
Kevin, On 01/05/2014 01:41 AM, Igoe, Kevin M. wrote: > Potential IPR issues: > Certicom has granted permission to the IETF to use the NIST curves, > and at least two of these, P256 and P384, have p = 3 mod 4. I'm not sure what exactly you mean there. From my POV, Certicom have declared [1] that they consider that some of their IPR is somehow required in order to implement the most excellent RFC 6090 [2] which only references things published at least a year before Certicom's first filing. I also seem to recall that some of their IPR declarations do include restrictions on things like CAs issuing certs. So "granted permission" is not quite so clear. At least not without either being a lawyer, or having whatever time machine Certicom's lawyers seem to possess. I doubt we'll clarify the IPR situation around ECC here, nor around PAKEs unfortunately. But I think we can conclude that the Dragonfly goal of designing around existing IPR remains a valid design goal. Whether or not Dan has succeeded in that is another matter, participants who care about IPR need to evaluate that for themselves. S. [1] https://datatracker.ietf.org/ipr/search/?option=rfc_search&rfc_search=6090 [2] http://tools.ietf.org/html/rfc6090 > Not > being a patent lawyer, I have no idea what impact the Certicom patents > have on the use of newer families of curves, such as Edwards curves. > RFC 6090 outlines elliptic curve technology which predates the Certicom > patents.
- [Cfrg] 40 bit loop and DragonFly Igoe, Kevin M.
- [Cfrg] 40 long loop, not 40 bit loop Igoe, Kevin M.
- Re: [Cfrg] 40 bit loop and DragonFly Stephen Farrell
- [Cfrg] On interpreting IPR in the IETF Paul Hoffman
- Re: [Cfrg] 40 bit loop and DragonFly Scott Fluhrer (sfluhrer)
- Re: [Cfrg] 40 bit loop and DragonFly Igoe, Kevin M.
- Re: [Cfrg] 40 bit loop and DragonFly Watson Ladd
- Re: [Cfrg] 40 bit loop and DragonFly Trevor Perrin
- Re: [Cfrg] 40 bit loop and DragonFly David Jacobson
- Re: [Cfrg] 40 bit loop and DragonFly Dan Harkins
- Re: [Cfrg] 40 bit loop and DragonFly Watson Ladd
- Re: [Cfrg] 40 bit loop and DragonFly Dan Harkins
- Re: [Cfrg] 40 bit loop and DragonFly Feng Hao
- Re: [Cfrg] 40 bit loop and DragonFly Watson Ladd