Re: [Cfrg] Rerun: Elliptic Curves - preferred curves around 256bit work factor (ends on March 3rd)

[Dan Brown <[e-mail]>]

My votes in this poll:

521: preferred
512: acceptable
480: acceptable
448: acceptable

Earlier, I voted NO on pursuing 192-bit and 256-bit security in the
short term.  Perhaps that disqualifies me to vote on this poll about
the short term choice for higher security curves, but I still have
some preferences on the outcome of the short term recommendation, so
I'll submit my vote in the current poll.  Feel free to ignore for the
short-term activity, especially if it helps to achieve CFRG to
consensus, thereby progressing with a recommendation.

Long-term, I strongly support higher-level security, including what
might be labelled as 192-bit security, and perhaps even other
intermediate values.

Though I voted above on 448 and 480 as acceptable, just to be clear,
we should not label them as providing "256-bit security" and not use
them with AES-256, until we solidify accounting arguments such
compatibility, such as:

- the for the EC operations per bit size being slower than say AES
operations per bit size,

- the stronger per-user security of ECC compared to AES,

- the more secure quadratic trade-off of success rate for time in ECC
compared to linear trade-off for AES.

These arguments are subtle, but perhaps within reach.

Alternatively, I wouldn't mind recommending the 448 and 480 field
sizes, and then using symmetric key sizes that are appropriate for the
field sizes. In other words, with public-key taking a more leading
role in security decisions, with symmetric-key just following suit.

An additional reservation I have with 480 and 448 is that they arise
from more recent, and lower profile proposals, compared to NIST P521.
Generally, I have a strong belief in the security in the security of
ECC, including the hardness of the ECDLP and other things needed for
security of ECC.  But for making recommendations of higher security,
I'd want something stronger than mere belief.

For low-characteristic fields, Menezes, Diem and others have published
attacks on weak fields, in the strongest sense of having an easier
ECDLP.  Also, some have argued here that in some prime-field are more
vulnerable to side channels than others [ref?].  Based on these two
existing threats, we might reasonably speculate that there remains a
remote risk of new weaknesses in ECC that depend on the field choice.
If we want to rationally reduce that remote risk, then we can use the
evidence of the 521-bit field size has remained unbroken since 1999.
This is a reason to deem 521 as less risky the newer 448 and 480.

Finally, others have commented that 128-bit security is so strong that
anything beyond that is pointless.  Well, I disagree, for several
reasons, albeit perhaps theoretical reasons.  For example, many
security proofs [*], especially for signature schemes, have loose
reductions, which suggest larger key sizes are needed for the provable
security results to be concretely applicable.  Of course, real-world
security can be better than what the proofs suggests, but occasionally
the bounds in the proof turn out to be right after all.  Luckily, for
many signature applications, perhaps even those of CAs and signed
ECDH, that looseness is irrelevant, either because the number of
signatures is low, or the signing oracle is more limited than the
threat model of the security proofs.  For another example, consider
known reductions between ECDHP and ECDLP, whose tightness depend on
not just on the field size, but also the group size.


[*] I'm using the conventional terms "security proof", though a more
modest label like "reductionist security argument", or "conditional
security analysis" might be better.

> -----Original Message-----
> From: Cfrg [mailto:[e-mail]] On Behalf Of Alexey Melnikov
> Sent: Wednesday, February 25, 2015 9:28 AM
> To: [e-mail]
> Subject: [Cfrg] Rerun: Elliptic Curves - preferred curves around 256bit work
> factor (ends on March 3rd)
> 
> CFRG chairs are starting another poll:
> 
> Q3: This is a Quaker poll (please answer one of "preferred", "acceptable" or
> "no") for each curve specified below:
> 
> 1) 448 (Goldilocks)
> 2) 480
> 3) 521
> 4) other curve (please name another curve that you "prefer" or "accept", or
> state "no")
> 
> If you stated your curve preferences in the poll that ended on February 23rd
> (see the attachment), you don't need to reply to this poll, your opinion is
> already recorded. But please double check what chairs recorded (see the
> attachment).
> 
> If you changed your mind or only answered the question about performance
> versa memory usage for curves 512 and 521, feel free to reply.
> 
> Once this issues is settled, we will be discussing (in no particular order. Chairs
> reserve the right to add additional questions) implementation specifics and
> coordinate systems for Diffie-Hellman. We will then make decisions on
> signature schemes. Please don't discuss any of these future topics at this time.