Subject: Re: [Cfrg] revised requirements for new curves

From: "Paterson, Kenny" <[email-masked]>
Date: Mon, 8 Sep 2014 10:23:14 +0000

Dear All,

After much deliberation, I've developed a set of requirements that I
believe fairly reflect the discussions we've had as a community on the
CFRG list, and at IETF 89, during the CFRG interim meeting and at IETF 90.
I'm including them below, in two formats:

1. A clean list of requirements, with no rationale.

2. A list of requirements, interspersed with rationale and explanation of
how I got to them from David McGrew's original list of requirements (which
can be found here: 
http://www.ietf.org/mail-archive/web/cfrg/current/msg04655.html).

Please read and reflect before posting (note that there is no prize for
being the first to post). You may disagree with one, many, or maybe even
all (!) the requirements I've listed. However, I believe they *do*
represent a consensus view or rough consensus view (in all but one case,
SE6), and it is a consensus-seeking approach that we are engaged in here.

So to be explicit: please do not simply post "I do not agree with X or Y"
- we've already had that debate. Instead, you are encouraged to post
things like "I do not believe X was the majority view" or "I think we
should modify X to say Y because that reflects better the consensus view".

I would now propose that we discuss these requirements for a short period
of time, to give everyone time to comment. We can then refine or change
them as necessary. 

Regards,

Kenny (for the CFRG chairs)

Short version:
--------------
Key to labelling of requirements:

[C] - we've achieved consensus on this requirement (put another way,
there's no serious disagreement on this point).
[RC] - we've achieved rough consensus on this requirement (put another
way, there's significant opposition to this requirement, but the majority
view supports it).
[NC] - the debate is fairly balanced, but we need to continue to make
progress, and the chairs are recommending this requirement be adopted.

Performance

PE1. Required: amenable to both compact and fast implementations of curve
operations in software, across a wide range of processor types. [C]

PE2. Desired: amenable to both compact and fast implementations of curve
operations in hardware. [RC]

Security

SE1. Required: the selected curves should be secure against reasonable and
well-understood threats, including (but not necessarily limited to)
Pollard rho attack, MOV/FR attacks, Smart-ASS attack, invalid-curve
attacks, and twist attacks. [C]

SE2. Required: curve operations (incorporating underlying field
arithmetic) should be amenable to efficient, implementation in software
whilst avoiding all data flow from secret values to timing. [C]

SE3. Desired: curve operations (incorporating underlying field arithmetic)
should be amenable to efficient implementation in hardware whilst avoiding
all data flow from secret values to timing. [C]

SE4. Desired: curve operations (incorporating underlying field arithmetic)
should be amenable to efficient implementation in software and hardware
whilst avoiding other known forms of side channel attack. [C]

SE5. Required: each set of curve parameters should be generated by a
well-defined procedure that allows only a limited and quantified amount of
flexibility. If the selected procedure involves the choice of an initial
seed, then the seed will be selected by multiple independent parties using
a procedure having the property that no collusion of all but one or fewer
of the parties can exert any control over the chosen seed. [RC]

SE6. Required: the selected curves should provide levels of security that
match to a good approximation 128-bit, 192-bit and 256-bit security
levels, as these levels are currently commonly understood in the wider
security community. [NC]

Intellectual Property

IP1. Required: securely, simply and efficiently implementable world-wide
under royalty-free licensing terms. [C]

IP2. Desired: securely, simply and efficiently implementable world-wide in
a patent-free manner. [RC]

Interoperability

IN1. Required: compatible with current and forthcoming IETF RFCs for TLS.
[C]

IN2. Required: minimise work needed to generate suitable OBJECT
IDENTIFIERs for Subject Public Key Information Fields, as defined in RFC
5480 (PKIX). [C]

IN2. Desired: usable with minimal changes to existing IETF RFCs for CMS,
SSH, IKE, IKEv2, Kerberos PKINIT. [RC]

Longer version (with rationale):
--------------------------------

Key to labelling of requirements:

[C] -  we've achieved consensus on this requirement (put another way,
there's no serious disagreement on this point).
[RC] - we've achieved rough consensus on this requirement (put another
way, there's significant opposition to this requirement, but the majority
view supports it).
[NC] - the debate is fairly balanced, but we need to continue to make
progress, and the chairs are recommending this requirement be adopted.

Performance

PE1.  Required: amenable to both compact and fast implementations of curve
operations in software, across a wide range of processor types. [C]

PE2. Desired: amenable to both compact and fast implementations of curve
operations in hardware. [RC]

[Hardware speed is secondary to software speed for this exercise; also do
not demand reuse of code or hardware, as it handicaps performance. The
main curve operations of interest are:
- Scalar multiplication, fixed base, variable base and double-base
(important in ECDHE and ECDSA);
- Point addition (needed in ECDSA).]

[Removed: "R3:  Desired: re-use components between signatures and key
exchange algorithms"; this seems likely to happen naturally to some
extent, by picking a single curve at a given security level or by
selecting curves at a given security level that share a prime p and
reusing code for field arithmetic. Moreover, the original request from the
TLS WG signalled that different curves would be acceptable for different
cryptographic functions. There's been a lot of discussion on the list
related to this point; the lack of a hard requirement for a single curve
at each security level seems to represent a majority view of list
participants.]

Security

SE1. Required: the selected curves should be secure against reasonable and
well-understood threats, including (but not necessarily limited to)
Pollard rho attack, MOV/FR attacks, Smart-ASS attack, invalid-curve
attacks, and twist attacks. [C]

SE2. Required: curve operations (incorporating underlying field
arithmetic) should be amenable to efficient, implementation in software
whilst avoiding all data flow from secret values to timing. [C]

SE3. Desired: curve operations (incorporating underlying field arithmetic)
should be amenable to efficient implementation in hardware whilst avoiding
all data flow from secret values to timing. [C]

[SE2 and SE3: aka constant time implementation. These requirements reflect
the view that timing attacks are the most important class of side channel
for TLS environments. A harder requirement for software is notwithstanding
the wide range of hardware-focussed environments in which TLS is currently
being used or will in future be used.]

SE4. Desired: curve operations (incorporating underlying field arithmetic)
should be amenable to efficient implementation in software and hardware
whilst avoiding other known forms of side channel attack. [C]

[Removed:
   R8.  Required: amenable to constant-time implementations, to avoid
   side channel attacks.

   R9.  Required: resist twist attacks.
  
as these are now incorporated under SE1 and SE2, SE3, SE4.]

SE5. Required: each set of curve parameters should be generated by a
well-defined procedure that allows only a limited and quantified amount of
flexibility. If the selected procedure involves the choice of an initial
seed, then the seed will be selected by multiple independent parties using
a procedure having the property that no collusion of all but one or fewer
of the parties can exert any control over the chosen seed.  [RC]

[This requirement refines a previous requirement:

R10.  Required: curve parameters should have good provenance;
   random curves should be provably pseudorandom.
   
The amount of flexibility can be used as a criterion for selecting between
different proposals; it does not seem helpful to put a hard bound on it at
this stage.]

SE6. Required: the selected curves should provide levels of security that
match to a good approximation 128-bit, 192-bit and 256-bit security
levels, as these levels are currently commonly understood in the wider
security community. [NC]

[This requirement comes from the original TLS WG request, strengthened to
mandate the selection of curve(s) at the 192-bit security level. While we
did not achieve even rough consensus that the choices we make need to be
easily explainable by us and others to less sophisticated consumers of
cryptography, the emphasis on "as these levels are currently commonly
understood in the wider community" is deliberate on my part; in other
words, I recognise the lack of consensus on this point, but I am proposing
this wording in order to enable us to make progress. If SE6 were to be
adopted, we would need to reach a common view on what "to a good
approximation" means; I'd suggest "at most 4 bits either way for Pollard
rho" so as to reduce potential conflict with SE5.]

Intellectual Property

IP1. Required: securely, simply and efficiently implementable world-wide
under royalty-free licensing terms. [C]

IP2. Desired: securely, simply and efficiently implementable world-wide in
a patent-free manner. [RC]

[We quickly reached consensus (respectively, rough consensus) on these
points on the list.]

Interoperability

[What follows replaces:

"R6.  Desired: can be used with current software implementations
   (using different curve parameters) of TLS, PKIX, SSH, and IKE [4]

   R7.  Desired: can be used within current ECC standards of TLS,
   PKIX, SSH, and IKE [4]"

The rationale for replacing these is based on CFRG discussions pointing to
the fact that significant performance and security benefits may accrue by
using different curves, e.g. relative ease of protecting E/tE-form curve
operations against timing attacks as compared to W-form curves. However,
such choices are unlikely to allow for significant software reuse.
Moreover, adopting such curves will require extensions to existing PKIX
RFCs, notably RFC 5480, if we want to use ECDSA certs for new curves.]

IN1.  Required: compatible with current and forthcoming IETF RFCs for TLS.
[C]

[We've been asked by TLS WG to conduct this exercise; our primary goal is
to come up with curves that they can easily use in currently deployed and
anticipated future versions of TLS. In practice, this is a relatively easy
requirement to meet because of the flexibility that the TLS WG has
signalled is available to CFRG in terms of curves and wire formats.]

IN2. Required: minimise work needed to generate suitable OBJECT
IDENTIFIERs for Subject Public Key Information Fields, as defined in RFC
5480 (PKIX). [C]

[This requirement is more a reminder to us that this work will need to be
done in order to be able to issue ECDSA certificates using the new curves.
Discussion on list:
http://www.ietf.org/mail-archive/web/cfrg/current/msg04874.html.]

IN2.  Desired: usable with minimal changes to existing IETF RFCs for CMS,
SSH, IKE, IKEv2, Kerberos PKINIT. [RC]

["desired" rather than "required" because our main focus is TLS in this
exercise, rather than other protocols. Still, we should be aware that what
we recommend as alternatives to NIST curves in CFRG is likely to be picked
up by other groups. More discussion is needed to determine what the
implications of our selections would be for other IETF applications.]

On 31/08/2014 22:05, "Paterson, Kenny" <[email-masked]> wrote:

>Dear all,
>
>I've spent today reviewing all the messages to CFRG on new curves - those
>concerning requirements (our current phase of enquiry), and more
>generally. It's been interesting and informative. I want to thank everyone
>who has participated to date. It seems (to me at least) that almost
>everything that could be said about requirements has now been said. The
>traffic on the list on this topic has also slowed markedly, another sign
>that this phase is reaching a natural conclusion.
>
>In the next day or two, I will send to the list a proposal for a list of
>requirements that we will use for the second phase of our investigation:
>selecting curves to recommend to the TLS WG. I've made careful notes on
>all the contributions to the requirements discussion, and my sense it that
>we do have a rough consensus concerning what these requirements should be.
>
>NB: I use the word "rough" deliberately here - in looking over the
>messages to the list, of course I can see frequent disagreements about
>requirements, but in each case, sufficiently many independent views have
>been expressed one way or another that a *rough* consensus is clear on
>pretty much every issue of substance, even if a perfect harmony of views
>has not been expressed.
>
>So, more news from me soon...
>
>Best regards,
>
>Kenny 
>

---

From: William Whyte <[email-masked]>
Date: Mon, 8 Sep 2014 09:49:18 -0400

Hi Kenny,

Couple of comments on the interoperability requirements. I'm struggling to
see how they significantly distinguish between different candidates and
wonder if they're requirements as such, rather than simply things that we
should bear in mind. In more detail:

IN1: I don't understand how a curve could be incompatible with a TLS RFC. A
new curve would be a new ciphersuite: to support a new curve, you reserve a
ciphersuite identifier and define behavior for that ciphersuite identifier.
Any behavior that's well-defined seems like it should be compatible (and you
hint at this in the requirements-with-rationale version). Do you have a
concrete example of what would be ruled out by this requirement?

IN2: I don't like the word "minimize" here, because if strictly interpreted
it would bind us to using existing OIDs. And if this was rephrased as "keep
to a reasonable level the work needed to generate..." I think it loses any
meaning, because generating new OIDs as such is trivial. Is it possible to
rephrase this in terms of "not introducing significant numbers of new data
types" or something of the sort, which I think is the intent?

Cheers,

William

-----Original Message-----
From: Cfrg [mailto:[email-masked]] On Behalf Of Paterson, Kenny
Sent: Monday, September 08, 2014 6:23 AM
To: [email-masked]
Subject: Re: [Cfrg] revised requirements for new curves

Dear All,

Regards,

Short version:
--------------

Performance

Security

Intellectual Property

Interoperability

Performance

Security

[Removed:

Intellectual Property

Interoperability

[What follows replaces:

>So, more news from me soon...

_______________________________________________
Cfrg mailing list
[email-masked]
http://www.irtf.org/mailman/listinfo/cfrg

---

From: Manuel Pégourié-Gonnard <[email-masked]>
Date: Mon, 08 Sep 2014 16:30:21 +0200

> ciphersuite identifier and define behavior for that ciphersuite identifier.

I guess you mean a NamedCurve identifier (RFC 4492 sec. 5.1.1) rather than a
ciphersuite identifier. Currently, ciphersuites only specify the high-level
mechanism (ECDH(E), ECDSA), not the specific curve(s) used by this mechanism.
(There is a draft for including curve selection in the ciphersuite identifier,
but for now it's only a draft). And possibly some new ECPointFormat (sec 5.1.2)
in addition, if the new curves support other representations than short
Weierstrass, and the decision is made to allow those representations on the wire
(rather than to force conversion to short Weierstrass).

By the way, the TLS curve/point negotiation doesn't allow peers to negotiate the
use of different point formats for different curves. That's probably something
to bear in mind when discussing point formats.

Manuel.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 8 Sep 2014 10:42:50 -0400

I didn't see consensus that we needed 192 bit curves.

These seem superfluous to me If I want speed then I will go to 128
bits. If I want high assurance I will go to 256. 192 is neither fish
nor fowl.

In a perfect world folk can make fine tuned choices between speed and
security but I only have two security levels: paranoid and till the
sun goes supernova secure level paranoid.

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 08 Sep 2014 15:42:47 +0100

Hiya,

Good job and good to see this progressing towards completion.
Thanks for both.

> of the parties can exert any control over the chosen seed. [RC]

A clarification question: the above reads a bit like the result
has to be a curve that hasn't yet been documented. I assume that
its ok if e.g. 25519 and/or one of msft's are picked and that this
is not meant to rule those out. It might be worth stating that e.g.
along the lines of "Note that SE5 does not rule out selection of
an already documented curve or curves should there be consensus
that this requirement has been met sufficiently."

If you do mean to rule those out, then I think that really would
need to be crystal clear.

Other than that:

On IN1 and IN2 I agree with William's comment. And since that
is to the effect that those don't help or hinder selections
I'm ok with the text as-is.

On IP1, I do agree with the intent, but that might need to be
reworded to keep everyone happy - one can never know for sure
that royalty-free anything is possible. But I'm ok with the
wording as-is, since adding the equivalent of "as far as its
possible to know" doesn't matter so much given that CFRG cannot
afaik yet do the impossible;-)

Ta,
S.

---

From: "Paterson, Kenny" <[email-masked]>
Date: Mon, 8 Sep 2014 15:05:53 +0000

Hi William,

>should bear in mind. In more detail:

They are definitely of the latter flavour.

>concrete example of what would be ruled out by this requirement?

No, I don't have a concrete example. Rather, this was just meant to
contrast with the previous list of requirements from David.

>types" or something of the sort, which I think is the intent?

That's a good suggestion. The work is relatively light, but we don't want
to expand it more than is necessary, especially as someone will have to
write the Internet Draft and shepherd it through IETF.

Thanks for the inputs,

Kenny

---

From: "Paterson, Kenny" <[email-masked]>
Date: Mon, 8 Sep 2014 15:10:08 +0000

Hi Stephen,

On 08/09/2014 15:42, "Stephen Farrell" <[email-masked]> wrote:

>is not meant to rule those out.

That's correct - it's not meant to rule these out. The intention is that,
for a specific, existing curve like Curve25519 or one of the MSR curves,
this requirement would mean the publication of a clear selection rationale
and an evaluation of how much flexibility was exercised during the
selection. 

>It might be worth stating that e.g.

OK, this could certainly be added.

>I'm ok with the text as-is.

OK, good to know.

>afaik yet do the impossible;-)

Understood. So some fine-tuning might be merited here.

Cheers

Kenny

---

From: Watson Ladd <[email-masked]>
Date: Mon, 8 Sep 2014 08:12:03 -0700

> to bear in mind when discussing point formats.

I think that is more wrong than right. Currently all curves are short
Weierstrass. If we say "curveXYZ means you do this instead, and adjust
the point formats accordingly", is that really a problem? Certainly
the Curve25519 in TLS draft didn't think so.

Sincerely,
Watson Ladd

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

---

From: "Paterson, Kenny" <[email-masked]>
Date: Mon, 8 Sep 2014 15:14:51 +0000

Hi

You're correct, there was not consensus on this point. The whole
requirement is marked as [NC] on my list, meaning "no consensus". It's
true that I did not specifically call this aspect out as being "NC".

However, 192-bit security was in the initial request from TLS WG as an
option. I don't see why we can't also solve this problem too (but I'm
prepared to drop it if it looks like it will prevent us from making
progress).

Cheers

Kenny

---

From: David Jacobson <[email-masked]>
Date: Mon, 08 Sep 2014 08:46:02 -0700

> levels, as these levels are currently commonly understood in the wider
I think you need to make it clear that "good approximation" is rather 
loose.  The point is to make Curve 25519 be considered an approximately 
256 bit curve.

    --David Jacobson

---

From: Manuel Pégourié-Gonnard <[email-masked]>
Date: Mon, 08 Sep 2014 18:28:51 +0200

On 08/09/2014 17:12, Watson Ladd wrote:
> I think that is more wrong than right. 

Or maybe just not clear enough, sorry for that. Let me expand a little bit,
assuming Curve25519 (for the sake of the example) is standardised, the CFRG
and/or the TLS WG will have to choose between the following options:

1. Use only short-Weierstrass format for point transmission, for this curve as
well as the others, meaning that no new point format is added, but
implementations have to either convert between representations, or use the
classic code for short Weierstrass arithmetic.

2. Use only Mongtomery-x format with this curve (and maybe other new curves
supporting it, but obviously not with the NIST and Brainpool curves).

3. Allow both formats, with the idea that implementations are free to choose. My
point was, this is not as good an idea as it might seem, since currently an
implementation has no way of saying "I support the short Weierstrass point
format(s) with the NIST/brainpool curves, and Montgomery-x with Curve25519, but
not short Weierstrass with Curve25519 (since I want to use the Montgomery ladder
but didn't implement conversion between short-Weierstrass and Montgomery)".

I'm not saying this is a big issue, just something we might want to keep in
mind. Of course TLS could change its negotiation procedure to negotiate (curve,
point format) pairs instead, but I'm not sure it would be a good thing, esp. if
we want it to be usable before TLS 1.3.

I thought about this while reading djb's email about the fact that the new
curves allow more options, since they can be converted to short Weierstrass
representation. It's entirely correct of course, but it might be good to
restrict that flexibility (options 1 and 2 above).

> Currently all curves are short
That would be option 2 above, which is not a problem. I was trying to warn about
option 3.

Manuel.

---

From: "D. J. Bernstein" <[email-masked]>
Date: 8 Sep 2014 18:36:35 -0000

I have two clarification questions regarding SE6:

> SE6. Required: the selected curves should provide levels of security
> that match to a good approximation 128-bit, 192-bit and 256-bit
> security levels, as these levels are currently commonly understood in
> the wider security community. [NC]

Background for question 1: E-521 was proposed by three teams
independently. It appears to be faster on typical platforms than
Microsoft's 2^512-569, despite the higher security level. It's also
supported by various arguments from other people, such as "a lot of
effort has gone into optimization of modular reduction for the NIST
primes". E-521 reuses the NIST P-521 prime, the only NIST prime that's
immune to Adam Langley's "What a difference a prime makes" critique.

Question 1: Does SE6 formally exclude E-521 as being above the "commonly
understood" 256-bit security level?

Background for question 2: There are also proposals for faster 414-bit
and 448-bit curves. This intermediate range is backed by a variety of
arguments from a variety of people: e.g., clear improvements over the
larger option in Suite B (NIST P-384 with AES-256); deployment by Silent
Circle; and the argument "What benefit do you derive from including a
stronger algorithm in a chain made of weaker algorithms?" combined with
undisputed evaluations of the AES-256 security level.

Question 2: Does SE6 formally exclude Curve41417 etc. as being above the
"commonly understood" 192-bit security level but below the "commonly
understood" 256-bit security level?

---Dan

---

From: Michael Hamburg <[email-masked]>
Date: Mon, 8 Sep 2014 12:16:39 -0700

> On Sep 8, 2014, at 11:36 AM, D. J. Bernstein <[email-masked]> wrote:
> 
> —Dan

I believe that Kenny’s "at most 4 bits either way for Pollard rho” clarification is calculated to allow Curve25519, E-521 and shortened primes like ed-510-mont; but to formally exclude Curve41417, Ed448-Goldilocks and Ed480-Ridinghood.

Cheers,
— Mike

---

From: "Paterson, Kenny" <[email-masked]>
Date: Tue, 9 Sep 2014 18:54:06 +0000

Hi

In-line.

>understood" 256-bit security level?

Let me restate SE6 here and than answer your question.

"SE6. Required: the selected curves should provide levels of security that
match to a good approximation 128-bit, 192-bit and 256-bit security
levels, as these levels are currently commonly understood in the wider
security community. [NC]"

Answer to your first question: no. Because if we adopt this requirement
then we would still need to reach consensus on the exact meaning of "match
to a good approximation". I've made a suggestion for this in my covering
rationale, but, recognising the "[NC]" status of this requirement, I
consider it in need of further discussion.

>understood" 256-bit security level?

Again, no, not formally, but here I think it'd be harder to argue for
"match to a good approximation".

Cheers

Kenny

---

From: Damien Miller <[email-masked]>
Date: Thu, 11 Sep 2014 17:35:18 +1000 (EST)

> CFRG list, and at IETF 89, during the CFRG interim meeting and at IETF 90.

Thanks for compiling this and sorry for barging in late in the process.

> levels, as these levels are currently commonly understood in the wider

Speaking for OpenSSH, I don't see much point in a 192-bit "security level"
curve.

It's difficult to imagine a scenario where a 192-bit SL curve provides
something that the other don't. For the rest of the time, it's just code
and complexity that everyone has to carry that will be rarely used, and
therefore more likely to be wrong.

Perhaps consider splitting this into three requirements, one for each of
the "security levels"?

> SSH, IKE, IKEv2, Kerberos PKINIT. [RC]

It would help if you defined what you meant by existing RFCs here. Do you
mean the overarching transport protocol definitions (RFC4253 in the case
of SSH) or the RFCs that define DH methods specifically (RFC5656 for SSH)?
latter for better curves/encodings.

-d

---

From: Damien Miller <[email-masked]>
Date: Thu, 11 Sep 2014 17:46:50 +1000 (EST)

> latter for better curves/encodings.

Err, vim ate my last paragraph:

For SSH, I support certainly support the former interpretations but would
happily jettison the specific EC RFCs if that was the cost of
safer/faster/better curves and encodings.

---

From: Torsten Schuetze <[email-masked]>
Date: Thu, 11 Sep 2014 13:41:25 +0200

On Sep 08, 2014 10:23:14 +0000 "Paterson, Kenny" <Kenny.Paterson at

> operations in hardware. [RC]

Dear Kenny,

is this to be understood in the more general sense:

PE1.   software in a secure environment, e.g., on a secured server,
       i.e., where only the global timing as side-channel is relevant

PE2.   software on constrained devices or hardware in a hostile
       environment, i.e., where the full set of local and global
       side-channels applies.

? Or in the strict sense?

My point is, that most of the discussion for PE1 was on software with
a constant global timing, not on more specific local attacks, as CPA
or EMA.

For example, an ECC software implementation on a constrained
device/embedded device in a hostile environment or under an adversary
with high attack potential would fall into PE1 according to the
original classification and into PE2 according to the refined
classification. Surely, for such an implementation much more than
timing constant arithmetic would be necessary, e.g., all kinds of
blinding and fault attack countermeasures.

Regarding non-symmetry in refined PE1/2: I don't know of any sensible
hardware which is designed to be run only in a secured environment. In
those cases, often software would perform better.

One further question: At least in the "hardware thread" the issue of
flexibility came up. I could not find this completely covered by your
requirements. But perhaps this is the greatest disagreement in the
discussion (random primes vs. fixed, specific primes). Of course, a
selected curve has to be very specific, but I mean if the curve
encourages you to an high-performant, but inflexible arithmetic.

Cheers,
  Torsten
-- 
ROHDE & SCHWARZ SIT GmbH
Hemminger Str. 41
http://www.sit.rohde-schwarz.com
mailto:[email-masked]

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 12 Sep 2014 08:41:10 -0700

> prepared to drop it if it looks like it will prevent us from making

Kenny,

I suspect that this may have been a case of misplaced concreteness
on the part of the (former) chairs :)

As you say, we did ask for 128, 192 (optional), and 256-bits. In my
personal opinion
if the CFRG came back and said "we only see value in 128- and 256-bits"
that would be taken seriously.

Best,
-Ekr

---

From: Markulf Kohlweiss <[email-masked]>
Date: Sun, 14 Sep 2014 11:02:37 +0000

All of them are only "until someone develops quantum computers" security level anyway.
________________________________
From: Phillip Hallam-Baker<mailto:[email-masked]>
Sent: ‎08/‎09/‎2014 15:43
To: Paterson, Kenny<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Cfrg] revised requirements for new curves

---

From: Alyssa Rowan <[email-masked]>
Date: Sun, 14 Sep 2014 20:20:42 +0100

On 08/09/2014 11:23, Paterson, Kenny wrote:
> Intellectual Property
> 
> IP1. Required: securely, simply and efficiently implementable
> world-wide under royalty-free licensing terms. [C]
> 
> IP2. Desired: securely, simply and efficiently implementable
> world-wide in a patent-free manner. [RC]

I think it'd be invaluable for potential proposals to have a clear
statement about the patent status of a (secure, simple and efficient)
reference implementation, at least - otherwise, it's hard to know how
we can best evaluate these criteria, particularly alongside PE1 and PE2?

It'd be even more helpful for adoption downstream if those reference
implementations were suitable, and permissable, for wide practical use.

Would a patent search help? Someone recently said to me that elliptic
curve cryptography was a [patent] minefield (albeit less so as some
older patents, such as point-compression, expire) - and if we can
clear, or at the very least map, as much of that minefield as
possible, many potential barriers to adoption could be removed.

On 08/09/2014 15:42, Phillip Hallam-Baker wrote:
>  bits. If I want high assurance I will go to 256. 192 is neither 
> fish nor fowl.
> 
> In a perfect world folk can make fine tuned choices between speed 
> and security but I only have two security levels: paranoid and
> till the sun goes supernova secure level paranoid.

I concur entirely with this, agl's points, and Markulf's.

≈WF128 curves can I think deliver the strong, but very efficient
functions IETF protocols are going to want for cryptography everywhere.

≈WF256 curves can deliver about the best we can probably expect from
elliptic curves, until quantum computers eventually show up and crash
that party. If you want to be extra-careful, and some do, that's the
way to go.

≈WF192 is not a great compromise either way IMHO, especially as there
are no convenient 2^x-n primes with very small n in the immediate
vicinity of 384-bit.

Plus, 2 new curves are easier to specify and implement correctly than
3. (1 is of course easier still - as with agl, if we had to pick one,
I'd pick ≈WF128 - but I'd suggest keeping ≈WF256, too.)

If it's optional, I definitely say drop 192 from requirement SE6. You
don't exactly see people queuing up to use AES-192, do you (or even
SHA-384 for anything but NSA Suite B)?

- -- 
/akr