Re: [Cfrg] Elliptic Curves - poll on specific curve around 256bit work factor (ends on February 23rd)

[Michael Scott <[e-mail]>]

I know I am a bit late to this party, so apologies if some-one has made
this point already.

First off as I voted I see absolutely no point in going beyond 256-bit
curves, unless the asymptotics are broken in which case all bets are off.

However there is an undoubted demand for bigger curves, often driven by
emotions and instincts which seem impervious to logic. Its all about what
Schneier called getting that "warm fuzzy feeling". And I guess imbuing
users with that feeling of confidence may have some value.

In the world of RSA, when RSA-1024 was threatened, the warm fuzzies were
restored by moving to RSA-2048. There is something about doubling the bit
length that appeals. Of course this is not even close to the equivalent of
going from 256-bit curves to 521-bit curves, and indeed RSA-2048 is not
even close to the same security as that provided by even a 256-bit curve.

The equivalent to a 256-bit curve would be 3072-bit RSA approximately. If
the latter were threatened a comfortable response would be a move to 6144
bit RSA, which is the equivalent of a 320-bit curve (roughly).

So anyone for 2^321-9 ? 2^342-65?


Mike


On Sat, Feb 21, 2015 at 4:24 AM, Phillip Hallam-Baker <[e-mail]
> wrote:

> June 2005 is nine and a half years ago. Go to the 2014 top 500 and the top
> spot is 33 TFlop. And I am not using those $3000 cards, the
> price/performance is better at $500.
>
> Looks like my machine is actually only beating the number 5 machine at
> around 10TFlop at present.
>
>
> On Fri, Feb 20, 2015 at 10:59 PM, Watson Ladd <[e-mail]>
> wrote:
>
>> On Feb 20, 2015 11:50 AM, "Phillip Hallam-Baker" <[e-mail]>
>> wrote:
>> >
>> >
>> >
>> > On Fri, Feb 20, 2015 at 1:17 PM, Watson Ladd <[e-mail]>
>> wrote:
>> >>
>> >>
>> >> On Feb 20, 2015 9:21 AM, "Phillip Hallam-Baker" <[e-mail]>
>> wrote:
>> >>
>> >> > Well maybe if we had discussed it first. As it is your poll
>> completely mis-states the reasons people prefer 512 over 521. Which rather
>> undercuts the whole process.
>> >>
>> >> We've been discussing these issues for nearly a full year. You've had
>> and taken ample opportunity to explain why you don't like E-521, and the
>> fact that no one else is convinced has a lot to do with the strength of
>> your arguments.
>> >
>> > You are entitled to your opinion but it is far from the case that
>> everyone here sees things as you do.
>> >
>> > Even if my opinion was wrong, the chairs should not misrepresent them.
>> >
>> >> > The way I would do this is as a Quaker poll asking people what their
>> preferred outcome is and what they can live with on 448, 480, 512 and 521.
>> >> >
>> >> > 448 - No
>> >> > 480 - Acceptable
>> >> > 512 - Preferred
>> >> > 521 - No
>> >> >
>> >> > This is meant to be a consensus process and we should be using
>> consensus seeking tools wherever possible. Votes for the best outcome are
>> not the best way to come to consensus.
>> >>
>> >> No, it's about using our expertise to make the right decision. If your
>> arguments are wrong, don't expect us to pay attention.
>> >
>> > If the issue was expertise in mathematics then it would be a simple
>> choice. The question is not down to that type expertise, it is which set of
>> criteria are considered to be important. And there experience is rather
>> more relevant than expertise in the specific branch of math.
>> >
>> > You think that performance should be the criteria. In the twenty years
>> since I was a grad student the performance of computers has doubled every
>> 18 months or so. I am writing this on a computer that has more computing
>> power than the fastest supercomputer available only ten years ago, cost
>> less than $10,000 and plugs into a regular wall socket.
>>
>> Nope: Top500 list from June 2005 gives 183 teraflops peak. That's 45
>> Telsa K10 GPUs, which will run you $90,000. Each card consumes 225W,
>> leading to 10,125 watts. At US voltage of 120 RMS, that's an 84 amp
>> circuit. You can plug something drawing 84 amps into an ordinary wall
>> socket: the fuse will blow.
>>
>> Of course, performance has never been the sole criterion: as DJB
>> stated in http://www.ietf.org/mail-archive/web/cfrg/current/msg04894.html
>> there are a number of criteria which Curve25519 was designed to meet.
>> But none of them argue against primes with 2^s-c, c as small as
>> possible, and there are very few primes achieving maximal performance.
>> The supposed conflict between rigidity and performance doesn't
>> actually exist.
>>
>> These aren't the only possible criteria: someone with hardware that
>> implements the special reduction for the NSA primes probably won't be
>> happy having to adapt that hardware or work around its absence for
>> other primes. Someone who implements generic Montgomery reduction
>> won't see any speed gains from special primes. But the criteria that
>> these curves and primes meet apply to the vast majority of
>> implementations.
>>
>> It's also not clear what criteria you are actually applying to get the
>> list above: it's not "power of 2 in the name at all costs", nor is it
>> strictly sized based. It's not performance based after a certain size
>> either.
>>
>> >
>> > I don't actually care very much about the specific outcome here. What
>> is important to me is whether the outcome is backed by 10%, 50% or 90% of
>> the industry. And that in turn depends first and foremost on the litigation
>> cost associated with the new algorithm and next to that the ease with which
>> we can convince people that there is nothing odd about the choice.
>> >
>> > So I am far more concerned about process than outcome here. How long we
>> spend arguing is much less important to me than the risk we have to do it
>> all again soon.
>> >
>> >
>> > The litigation risk has no bearing on 512 or 521 but it is going to
>> have a big bearing on the choice of curve. More than one of us is going to
>> have to eventually have to explain all of this stuff to lawyers at $400/hr
>> per person involved and up. The cost of moving to ECC is going to largely
>> depend on the length of time those conversations take.
>>
>> But we're not talking about the coordinates to be used yet, only the
>> prime.
>>
>> Sincerely,
>> Watson Ladd
>>
>
>
> _______________________________________________
> Cfrg mailing list
> [e-mail]
> http://www.irtf.org/mailman/listinfo/cfrg
>
>