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

From: Alexey Melnikov <[email-masked]>
Date: Wed, 18 Feb 2015 10:51:16 +0000

CFRG chairs are starting another poll:

Q3: (For people who want CFRG to recommend a curve at 256bit level) Is 
bandwidth cost of going to p521 worth the speed win over primes closer 
to 512 bits?

Once this issues is settled, we will be discussing 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.

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 18 Feb 2015 14:32:43 +0200

On Wed, Feb 18, 2015 at 10:51:16AM +0000, Alexey Melnikov wrote:
> bandwidth cost of going to p521 worth the speed win over primes closer to
> 512 bits?

Yes, it is a win.

- The cost is ~3% (~1.5% for some cases). Any application where that
  is a concern sure will not be using 256-level curves. Probably not
  even 128-level curves.
- The small speed penalty for "breaking a stride" is more than
  compensated by the faster arithmetic due to smaller constant.
- 2^512-569 looks quite nasty to implement (large constant causing
  overflows more easily, irregular structure)
- Both primes cause issues with signatures as required hash output
  length exceeds what is commonly available (the ECC signature
  schemes blow up with even the smallest nonuniformity, so you need
  the extra bits).
- 2^521-1 is already very slow (~5-6x slower than 128-level curves,
  which was one of the main reasons I think that 256-level is too
  high), 2^512-569 is even worse.

BTW: In NIST P-x curves, the 256-bit one is the only one that isn't
some nasty-looking trinomial or pentanomial. ECC people really
beeline for nearby Mersennes.

-Ilari

---

From: Alyssa Rowan <[email-masked]>
Date: Wed, 18 Feb 2015 13:31:35 +0000

On 18 February 2015 12:32:43 GMT+00:00, Ilari Liusvaara <[email-masked]> wrote:

>> Q3: (For people who want CFRG to recommend a curve at 256bit level)
>> Is bandwidth cost of going to p521 worth the speed win over primes closer to 512 bits?
>Yes, it is a win.

+1 yes from me, too.

If we're going to be doing a ≈WF256 curve, then on balance I'd far rather have the one which is 2 bytes longer but is a Mersenne prime with ≈42% faster muls and ≈27% faster sqrs than the weaker 2^512-569¹.

We'd be fools not to, really.

___
[1] From Mike Hamburg's data comparing an optimised E-521, I think it was - which I think this would end up as? - to the MSR NUMS curve over 2^512-569.

- --
/akr

---

From: Aaron Zauner <[email-masked]>
Date: Wed, 18 Feb 2015 14:52:07 +0100

> bandwidth cost of going to p521 worth the speed win over primes closer

Yes.

Aaron

---

From: "Dan Harkins" <[email-masked]>
Date: Wed, 18 Feb 2015 11:02:36 -0800 (PST)

> bandwidth cost of going to p521 worth the speed win over primes closer

  Yes it is; I prefer p521.

  Dan.

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

---

From: Tony Arcieri <[email-masked]>
Date: Wed, 18 Feb 2015 11:06:23 -0800

> bandwidth cost of going to p521 worth the speed win over primes closer to

Yes, although I would still consider it unusably slow for practical
purposes. Primes closer to 512-bits are even worse.

-- 
Tony Arcieri

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 18 Feb 2015 22:44:27 +0000

> bandwidth cost of going to p521 worth the speed win over primes closer

I'd be fine with anything significantly stronger than the 128-bit work
factor so would definitely not be arguing that precisely 512 bit long
primes are needed. (I'd actually be fine with any of the "more than
192 bit WF" curves, including the 4xx bit long prime options.)

I don't think the bandwidth cost in terms of bits-sent-over-the-wire is
at all significant if it came to considering 521 vs. 512 bit primes.

S.

---

From: James Cloos <[email-masked]>
Date: Wed, 18 Feb 2015 19:21:38 -0500

>>>>> "AM" == Alexey Melnikov <[email-masked]> writes:

AM> CFRG chairs are starting another poll:
AM> Q3: (For people who want CFRG to recommend a curve at 256bit level) Is
AM> bandwidth cost of going to p521 worth the speed win over primes closer
AM> to 512 bits?

Something on a prime which is between 400 and 500 bits is preferred.

Eg, things like Curve41417 or Ed448-Goldilocks are in the reasonable range.

-JimC
-- 
James Cloos <[email-masked]>         OpenPGP: 0x997A9F17ED7DAEA6

---

From: Jon Callas <[email-masked]>
Date: Thu, 19 Feb 2015 08:07:45 -0800

I'm using Curve 41417 because it was designed for more-than 128 bits of strength, and has really good performance.

There was a paper at CHES last summer, "Curve41417: Karatsuba revisited"

http://eprint.iacr.org/2014/526.pdf

The implementation they did on ARM with NEON is faster than the OpenSSL implementation of P-160, and runs at around 12% (yes, about eight times faster) of the speed of P-384.

For me, it really hits the sweet spot. It's fast enough that I don't worry and secure enough that I don't worry.

	Jon

---

From: Mike Hamburg <[email-masked]>
Date: Thu, 19 Feb 2015 09:22:26 -0800

Jon, if you're using Curve41417, do you have benchmarks for Curve41417 
on x86 or amd64?  I've only ever seen their NEON benchmarks.

-- Mike

On 02/19/2015 08:07 AM, Jon Callas wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> -----BEGIN PGP SIGNATURE-----
> Version: PGP Universal 3.3.0 (Build 9060)
> Charset: us-ascii
>
> wsBVAwUBVOYKUvD9H+HfsTZWAQjykwf/fNoWAg7Z00EJSRRoAptN8uKIOpibL/5i
> NaxWIeLDqnB25K1H5MVQ9I93vIZdW+MlUu4L9cASmCmIWTv0HTyA3ps1/rfH/wh2
> oGHzfAzdRugSMJLL0MAj2AzQX4Qi4ax6/jRz6UdlYm5y0AeHr8sQhQyrkzQgNUCe
> AilGvr5thli2pRfS+bGL/FpwZ/MlG7cuo91O7M25JaKZwJj2DAoDgvZgAuHmPPZO
> HkyfNBGQ/BenywYsW9y6j0f998983IMOICyeuk2/8SIloae9bsdjRCKiFnK/mMpl
> aj+0i94uwk/GdYcIz5mlRChzamBySEuAP8pf4Kh4GXZiTzMBRjl5BQ==
> =Lf3T
> -----END PGP SIGNATURE-----
>

---

From: Adam Langley <[email-masked]>
Date: Thu, 19 Feb 2015 10:56:21 -0800

Yes.

Cheers

AGL

-- 
Adam Langley [email-masked] https://www.imperialviolet.org

---

From: Jon Callas <[email-masked]>
Date: Thu, 19 Feb 2015 11:04:54 -0800

On Feb 19, 2015, at 9:22 AM, Mike Hamburg <[email-masked]> wrote:

> Jon, if you're using Curve41417, do you have benchmarks for Curve41417 on x86 or amd64?  I've only ever seen their NEON benchmarks.

No, I only do it on ARM, and I'm using it as an alternative to P-384.

The decision we made in looking for ciphers was to reduce options. Our original plan was to have a 128-bit cipher suite and a 256-bit cipher suite, and have the default be 256, with fallback to 128 when performance wasn't good enough. That original decision was to have only one public key parameter, and that was P-384.

Even before the Snowden revelations, Dan Bernstein and Tanja Lange talked to me about elliptic curves, and in specific asking why we didn't use 25519, and my answer on 25519 was that I wanted greater than 128-bit security, and even at 128 bits, 25519 isn't *quite* 128. There's no *technical* reason to care about the difference, but it's good to be able to say, "I do at least 128 bits of security" and not have someone in the room point out that well, technically 25519 is some fraction of a bit lower in security.

They offered to design me a curve as a replacement for P-384. The result is 41417. It's a really nice curve, both intellectually and from a performance standpoint. Our naive implementations of 41417 performed just fine. Public key performance isn't a real problem for me -- good enough is good enough. P-384 was good enough.

The NEON implementation of 41417 is amazing. I'm sure getting an equivalent done for Intel is completely doable -- just pick what generation of vector instructions you want to support.

	Jon

---

From: Russ Housley <[email-masked]>
Date: Thu, 19 Feb 2015 14:05:43 -0500

Yes.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 20 Feb 2015 01:09:56 -0500

> bandwidth cost of going to p521 worth the speed win over primes closer to

No, and I rather object to the phrasing.

The issue has never been the bandwidth of 9 extra bits. Its that it is an
odd size. Going down a bit from 256 to 255 is much easier than going up a
step.

Speed isn't much of a concern as this is going to be used for the long term
trust framework and as a backup algorithm.

---

From: Watson Ladd <[email-masked]>
Date: Thu, 19 Feb 2015 22:30:49 -0800

> bandwidth cost of going to p521 worth the speed win over primes closer to

Yes. The arguments for 2^512-whatever are specious, and the
performance advantage of 2^521-1 is the only thing that makes it a
plausible alternative to Goldilocks. (I don't understand why we aren't
voting on Goldilocks)

>
>
> Once this issues is settled, we will be discussing 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.
>

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

---

From: Tony Arcieri <[email-masked]>
Date: Thu, 19 Feb 2015 22:53:07 -0800

> bandwidth cost of going to p521 worth the speed win over primes closer to

Have you considered doing a poll of what specific curves people actually
want to use?

-- 
Tony Arcieri

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 20 Feb 2015 10:34:03 +0200

> odd size. Going down a bit from 256 to 255 is much easier than going up a

Well, cachelines are 512 bits on (semi-)modern Intel CPUs. Breaking that
means a couple more L1 promotions (the calculations itself should produce
very few Data-L1 misses).

However, 2^512-569 in practice _breaks_ 512 bits. The issue is that working
on full 64-bit (or whatever) units in software leads to excessive carry
propagation.

This carry propagation is an issue for threee reasons:
1) Pretty much nothing above assembly has good support for carry
   propagation (pick your favorite compiled language).
2) SIMD vector units often have no carry propagation support
   (smartphones).
3) Carry propagation interacts badly with tricks modern CPUs use for
   fast code execution (Intel CPUs).

Then there is the 569 constant, which due to its size tends to cause
lots of carrying without at least two extra words (M_521 needs none).

AFAIK, the largest prime that properly fits into 8 words of 64 bits
each (512 bits) when doing arithmetic is 480-bits in size
("Ridinghood"). For 16 of 32, it is 450 bits (the second largest is
448 ("Goldilocks")).

On dedicated hardware, one can make all sorts of odd sizes. And
there doesn't seem to be any significant scalability problems
(512x512 parallel multiplier is already too big to be practical).

Mike Hamburg posted a mail about this earlier.

> trust framework and as a backup algorithm.

That's not what I have heard. I have heard actual use being
planned (and that's a major reason I found 256-level curves so
distasteful).

-Ilari

---

From: "Paterson, Kenny" <[email-masked]>
Date: Fri, 20 Feb 2015 09:32:26 +0000

Hi Tony,

>Have you considered doing a poll of what specific curves people actually

Yes, we considered a number of different ways of narrowing down our
choices. However, we settled on doing it this way. Please stick with us.

Cheers,

Kenny

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 20 Feb 2015 12:21:00 -0500

> choices. However, we settled on doing it this way. Please stick with us.
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.

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.

---

From: Watson Ladd <[email-masked]>
Date: Fri, 20 Feb 2015 10:17:45 -0800

On Feb 20, 2015 9:21 AM, "Phillip Hallam-Baker" <[email-masked]>
wrote:
>
>
>
> On Fri, Feb 20, 2015 at 4:32 AM, Paterson, Kenny <
>> >bandwidth cost of going to p521 worth the speed win over primes closer
to

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.

No, it's about using our expertise to make the right decision. If your
arguments are wrong, don't expect us to pay attention.

---

From: Michael Hamburg <[email-masked]>
Date: Fri, 20 Feb 2015 10:55:56 -0800

I agree that more and better polling would have been a good idea, and to some degree is still a good idea.  If we had used these consensus tools starting several months ago it would have been good for progress.  Using them now is also fine, but we’d have to make sure to be really brief with the “why no?”, which would otherwise be an important part of the consensus process.

For the record:

379: Acceptable, but prefer 1 mod 4.
384: No, unless benchmarks turn out fine on multiple platforms (eg ARM +- NEON).
389: Preferred.
414: Acceptable
448: Preferred
480: Acceptable
512: No, unless benchmarks turn out fine on multiple platforms.
521: Preferred

Cheers,
— Mike

> On Feb 20, 2015, at 10:17 AM, Watson Ladd <[email-masked]> wrote:
> 
> 
> On Feb 20, 2015 9:21 AM, "Phillip Hallam-Baker" <[email-masked] <mailto:[email-masked]>> wrote:
> >
> >
> >
> > On Fri, Feb 20, 2015 at 4:32 AM, Paterson, Kenny <[email-masked] <mailto:[email-masked]>> wrote:
> >>
> >> Hi Tony,
> >>
> >> On 20/02/2015 06:53, "Tony Arcieri" <[email-masked] <mailto:[email-masked]>> wrote:
> >>
> >> ><[email-masked] <mailto:[email-masked]>> 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.
> 
> >
> > 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.
> 
> >
> > [email-masked] <mailto:[email-masked]>
> > http://www.irtf.org/mailman/listinfo/cfrg <http://www.irtf.org/mailman/listinfo/cfrg>
> >
>

---

From: "Blumenthal, Uri - 0558 - MITLL" <[email-masked]>
Date: Fri, 20 Feb 2015 19:09:01 +0000

For the record:

384: Acceptable
480: Acceptable
521: Preferred
--
Regards,
Uri
<Disclaimer>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 20 Feb 2015 14:50:48 -0500

> that no one else is convinced has a lot to do with the strength of your
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.

> 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.

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.

---

From: Michael Hamburg <[email-masked]>
Date: Fri, 20 Feb 2015 11:53:33 -0800

> On Feb 20, 2015, at 10:55 AM, Michael Hamburg <[email-masked]> wrote:
> 

By this I mean 3 mod 4.  Sorry for the spam.

---

From: Alyssa Rowan <[email-masked]>
Date: Fri, 20 Feb 2015 20:15:22 +0000

> [TA] Have you considered doing a poll of what specific curves
> people actually want to use?

> [PHB] […] your poll […] rather undercuts the whole process.

Strongly agreed.

> [KP] Yes, we considered a number of different ways of narrowing
> down our choices. However, we settled on doing it this way. Please
> stick with us.

With the greatest respect, if upstream and external parties were
willing to tolerate undocumented decisions by editor/chair fiat,
they'd stick with the NIST curves, wouldn't they?

We were asked because publicly-documented technical consensus, not
guided by any one party, is very highly desirable.

We need that if our efforts are to be meaningful.

> [PHB] 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.

I agree - that process will probably work much better than these
forced-choice yes/no polls!

So: my preference votes on prime consensus for the record:

Just 2^255-19: Acceptable [no concerns; but CAs want extra-strength]
     2^379-19: No         [one 1 mod 4 is probably enough]
    2^384-317: No         [slow and awkward]
     2^389-21: Acceptable [seems fast, but not very well-explored]
     2^414-17: Acceptable [fast, but a slightly awkward size]
2^448-2^224-1: Preferred  [fast, strong, good size, plenty of margin]
2^480-2^240-1: Acceptable [fast, but only with 64-bit]
    2^512-569: No         [way too slow; awkward; would not implement]
      2^521-1: Acceptable [could live with it; slower than I'd like]

- -- 
/akr

---

From: Tony Arcieri <[email-masked]>
Date: Fri, 20 Feb 2015 14:23:58 -0800

> less than $10,000 and plugs into a regular wall socket.

Let's imagine we want to use E-521 as a digital signature on a TLS
certificate. Now let's imagine we have intermediates. And we're on a mobile
phone, which is slow.

This is an interactive user experience... someone is just trying to access
a web site over HTTPS, and to ensure we have the correct certificate, we
have to verify two E-521 signatures.

How long is that going to take?

What's the argument for a curve that's closer to 512? Surely it's not that
the field arithmetic is easier. It's going to be slower and harder to
implement.

Can you say what exactly what the beneficial properties of 512 over 521
actually are?

-- 
Tony Arcieri

---

From: Tony Arcieri <[email-masked]>
Date: Fri, 20 Feb 2015 15:07:51 -0800

> 512: No, unless benchmarks turn out fine on multiple platforms.

+1

-- 
Tony Arcieri

---

From: Jon Callas <[email-masked]>
Date: Fri, 20 Feb 2015 15:32:21 -0800

The actual question as it appears to be in the poll is, I believe:

Q3: (For people who want CFRG to recommend a curve at 256bit level) Is bandwidth cost of going to p521 worth the speed win over primes closer to 512 bits?

No.

Explanation:

I have a great need for over 128 bits of security. The specific security level is not exact. Until recently, P-384 was my compromise and chosen because it was what was available. 521 is inherently slow because it's greater than 512 and that has issues into the hardware. 414 is good enough security with ~205 bits of security and fast enough, even in naive implementations.

Alternate sizes -- 389, 448, 480, 512, etc. even 379 are all good enough from a security standpoint. At this point, we're looking at considerations of code speed, code size, etc.

I've explained why I've picked 414 as secure enough and fast enough.

	Jon

---

From: Damien Miller <[email-masked]>
Date: Sat, 21 Feb 2015 11:00:25 +1100 (AEDT)

On Wed, 18 Feb 2015, Alexey Melnikov wrote:

> bandwidth cost of going to p521 worth the speed win over primes closer to 512
> bits?

yes

---

From: Damien Miller <[email-masked]>
Date: Sat, 21 Feb 2015 11:01:02 +1100 (AEDT)

On Thu, 19 Feb 2015, Tony Arcieri wrote:

>       Q3: (For people who want CFRG to recommend a curve at 256bit
>       level) Is bandwidth cost of going to p521 worth the speed win
>       over primes closer to 512 bits?
> 
> 

+1

---

From: Tony Arcieri <[email-masked]>
Date: Fri, 20 Feb 2015 16:22:06 -0800

On Fri, Feb 20, 2015 at 3:32 PM, Jon Callas <[email-masked]> wrote:

> 521 is inherently slow because it's greater than 512
>

No. The benchmarks say otherwise.

-- 
Tony Arcieri

---

From: Watson Ladd <[email-masked]>
Date: Fri, 20 Feb 2015 19:59:56 -0800

On Feb 20, 2015 11:50 AM, "Phillip Hallam-Baker" <[email-masked]> wrote:
>> On Feb 20, 2015 9:21 AM, "Phillip Hallam-Baker" <[email-masked]> wrote:
>>
> You are entitled to your opinion but it is far from the case that everyone here sees things as you do.
>
> 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

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 20 Feb 2015 23:24:16 -0500

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 <[email-masked]> 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.
> >
> >> > 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.
> >>
> > 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
> > 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

---

From: Michael Scott <[email-masked]>
Date: Sat, 21 Feb 2015 11:00:54 +0000

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 <[email-masked]

>> > 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
>> > 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

---

From: "Paterson, Kenny" <[email-masked]>
Date: Sat, 21 Feb 2015 13:43:55 +0000

Hi Phillip,

On 20/02/2015 19:50, "Phillip Hallam-Baker" <[email-masked]> wrote:

>>mis-states the reasons people prefer 512 over 521. Which rather

We didn't either present or misrepresent your views. Other people
attributed that to us. We simply asked a question, which I'll repeat here
for your and everyone else's benefit:

No mention of Phillip Hallam-Baker there, as far as I can see.

Let's all try to stay calm, please.

Thanks

Kenny

>>consensus seeking tools wherever possible. Votes for the best outcome
>>are not the best way to come to consensus.
>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.
>
>
>power than the fastest supercomputer
> available only ten years ago, cost less than $10,000 and plugs into a
>regular wall socket.
>
>
>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.
>
>
>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.
>
>
>

---

From: "Paterson, Kenny" <[email-masked]>
Date: Sat, 21 Feb 2015 13:40:53 +0000

Hi Alyssa,
 
On 20/02/2015 20:15, "Alyssa Rowan" <[email-masked]> wrote:

>Hash: SHA512
>> [PHB] [Š] your poll [Š] rather undercuts the whole process.
>
>Strongly agreed.
>

I think you have to give the chairs some room to make decisions in order
to help move things forward. We've been rightly criticised for not doing
that in recent months, and now we are trying to do better. So cut us some
slack, please.

Yes, we could have first run a "meta poll" to ask the group what kinds of
questions they wanted to be asked, or what the topics of the questions
should be, but I think that would only have led to dismayed comments from
other participants saying we were not providing enough direction or
leadership (but Alexey and I are by now well aware that chairs cannot
please all of the people any of the time, and some of the time we do not
please anyone; for us, it goes with the territory).

>guided by any one party, is very highly desirable.

But then what to do if there is no consensus? This appeared to be the case
on the specific question of whether we should stick to "traditional powers
of 2" security levels or not.

I explained this in an earlier response to one of your messages here:

http://www.ietf.org/mail-archive/web/cfrg/current/msg06183.html.

So now it seems to me that we are just rehashing. Let's try to avoid that,
please.

Now, all of this said: we can come back to other security levels later on,
if we have sufficient time and energy. But right now, we're focussing on a
question about the 256-bit security level.

Thanks,

Kenny

>iQIcBAEBCgAGBQJU55XaAAoJEOyEjtkWi2t6jH4P/1F6iBWEt8i7Y1aLXKQo8Efm
>FncsTL1Byh51vi0WHHjnrJ+9d8z/oNecFeklfjPVvu5+rdezpCR+m2MN/SwW8d25
>WmYjse75bBN9ilz7YohD7T632fUi4wcG1ffRnyNGw40ngiZIJopPAJMA0SZ4N5Wl
>OPaIUNssN/y+XoEcezFzAioIoUkO+C24r3589dc5Bozd7hZQfz4INmyajFHGhgBy
>ctpzMAoOqD+lgY6dbpeWrprV8Nnr3ZMm5Hnq9lb5rFgSSDUU8KsU5yIMX9yTwK/p
>JFPewlUyJK4nb6zdj3Wc42pPgJuezXfdfrif6I6YRwFxet0lRMN1QVFKANubdOtC
>hIKjQjBdMWYKcQkpFQJhoAiHSbMKSFafO+3KeMimyn3aKYotIUyuRZ9bf89cMuzl
>HjABTiPmZNU4hyXxOn/9eNd5vd5T+UIKRY+RfVxSPwo6S/dDphwJ7W/3dhiwCMWI
>AC6Ix5PFCia/y/TFP9R+edsHpmjzUwL+5MgJ+/oSUCgwFDuW8mpuncAtfPLujVQA
>dsDkzhcJZvlna1AiIh8bNiAj9TFnyiiWr3K33tNPmTaocuN6y7yC3BW2hMiGbzT+
>7u5TU8krsfiq1tG/yPzriZBXdlYmnMhTl9LmGvBw9gEMqxtmChJTXDdz0XnI7uy0
>4YgaokzGUjTwkn5PxI9X
>=FXwL

---

From: Torsten Schuetze <[email-masked]>
Date: Sat, 21 Feb 2015 15:19:57 +0100

> bandwidth cost of going to p521 worth the speed win over primes closer

I would rather prefer 2^512-c but could live with P521, too.

Torsten

---

From: Alyssa Rowan <[email-masked]>
Date: Sat, 21 Feb 2015 15:03:25 +0000

On 21/02/2015 13:40, Paterson, Kenny wrote:

> I think you have to give the chairs some room to make decisions in 
> order to help move things forward.

I truly appreciate the sentiment of avoiding delay, but I feel I may
have some trouble at the end of this process externally justifying
technical decisions made without rigidity or documented consensus.

>> We were asked because publicly-documented technical consensus, 
>> not guided by any one party, is very highly desirable.
> But then what to do if there is no consensus?

Such as a 50% result in a yes/no poll? Ask better questions.

> This appeared to be the case on the specific question of whether
> we should stick to "traditional powers of 2" security levels or
> not.

I don't seem to recall a consensus call on that: has there been one?

Philip's poll is much more neutral and IMHO more likely to converge
on agreement than your yes/no questions, which feel equivocative to me.

- -- 
/akr

---

From: Aaron Zauner <[email-masked]>
Date: Sun, 22 Feb 2015 15:06:35 +0100

Hi,

For the record:

255: Preferred.
414: Acceptable.
448: Preferred.
521: Acceptable.

Consider the remaining alternatives as a clear: No.

With regard to the short off-topic discussion on Moore's Law. Most
people seem to reference this paper but have never read it or long
forgotten what it states. Reduction in cost of production (thus consumer
products) is a big theme in the original work [0]; rarely mentioned when
this paper is referenced. In the HPC community there's been consensus
that "moore's law is coming to an end" for quite some time. The US DoE
has been working on an outline for "exascale computing" for quite some
time -- main concerns are actually green computing, IO bottlenecks,
alternative computing architectures (e.g. Harvard) and use of
specialized hardware over general purpose hardware. Might be interesting
to some [1] [2] [3].

Aaron

[0] http://www.cs.utexas.edu/~fussell/courses/cs352h/papers/moore.pdf
[1]
http://science.energy.gov/~/media/ascr/ascac/pdf/meetings/20140210/Top10reportFEB14.pdf
[2] http://science.energy.gov/ascr/news-and-resources/program-documents/
[3] http://exascale.org/

---

From: Kurt Roeckx <[email-masked]>
Date: Sun, 22 Feb 2015 17:37:17 +0100

> bandwidth cost of going to p521 worth the speed win over primes closer to

So if I understand the question, this is about speed versus
bandwidth?  I haven't seen anybody argue that bandwidth is a
concern.  Depending on who you ask you might get a different
answer, but I doubt many people here care about bandwidth.

I also have to wonder how much bandwidth difference there would
be.  If this is in the order of a few bytes per connection I doubt
you can get many people excited about this.

Kurt

---

From: Ilari Liusvaara <[email-masked]>
Date: Sun, 22 Feb 2015 19:28:30 +0200

> you can get many people excited about this.

AFAICT: +4 bytes for ECDHE, +5 for each certificate in chain.

So at most 24 bytes for all even remotely realistic-sounding
scenarios.

And for all applications where 256-level curves are even remotely
feasible, 24 bytes is insignificant.

-Ilari

---

From: Andrey Jivsov <[email-masked]>
Date: Sun, 22 Feb 2015 18:14:48 -0800

Yes.

A typical TLS handshake, no client authentication (3 X.509 certs in the 
server chain), is 4Kb.

There might be an issue in scenarios like sending an S/MIME message to N 
recipients, but RSA is common (very wasteful), otherwise, uncompressed 
points are common. There is typically additional per-recipient overhead 
for headers. Overall, for N recipients this translates to about ~5% 
overhead per recipient, whereas the lack of compression is about ~95%.

The key size is an issue when users need to enter keys manually. But 
with with base32 encoding this is 51 characters for P-256 (removing a 
bits with https://tools.ietf.org/html/draft-jivsov-ecc-compact-05 as 
needed), which is already annoyingly large. Beyond this, a few 
characters won't make the user experience friendly.

---

From: "D. J. Bernstein" <[email-masked]>
Date: 23 Feb 2015 03:21:02 -0000

Kurt Roeckx writes:
> Depending on who you ask you might get a different

I care very much about network traffic---although it has to be
quantified and put into context, just like CPU time.

As a concrete example, suppose your server resources are ten quad-core
3GHz CPUs and a 100Mbps network connection. Each microsecond the CPUs
will perform a total of 120000 cycles of computation while the network
connection will transmit 100 bits, i.e., 12.5 bytes.

Case study 1: Suppose you save 20000 cycles of computation by replacing
a compressed 32-byte point with an uncompressed 64-byte point. You're

   * saving 0.17 microseconds of computation but
   * costing 2.56 microseconds of network capacity.

Is this a worthwhile tradeoff? The factor 15 imbalance suggests an
answer of "no" (unless your ten servers cost fifteen times more than
your network connection, which I doubt). This isn't a guarantee---maybe
at this instant your CPUs are fully loaded while your network isn't---
but my experience is that if you need to reduce CPU time then there will
be many better ways to reduce CPU time in other parts of the system with
less cost to the network.

For me security and simplicity are ample reasons to require compression,
but this example still illustrates how to think about the performance
impact.

Case study 2: Suppose you save 200000 cycles of computation by switching
from 65-byte numsp512t1 points to 66-byte E-521 points. You're

   * saving 1.67 microseconds of computation but
   * costing 0.08 microseconds of network capacity.

Is this a worthwhile tradeoff? The factor 20 imbalance the other way
suggests an answer of "yes" (unless your network connection costs twenty
times more than your ten servers, which I doubt). This again isn't a
guarantee---maybe at this instant your network is fully loaded while
your CPUs aren't---but my experience is that there will be many better
ways to reduce network traffic in other parts of the system with less
cost to the CPUs.

I should note that a single numsp512t1 coordinate uses only 64 bytes,
but sending a compressed second coordinate spills over into another
byte. Of course, a single-coordinate ladder skips this compressed bit;
there are various cheap tricks to squeeze more bits out of keys; and one
can always squeeze out another bit by doubling the key-generation time.
Any method of saving 1 bit will squeeze numsp512t1 into 64 bytes; any
method of saving 4 bits will squeeze E-521 into 65 bytes; any method of
saving 9 bits will squeeze numsp512t1 into 63 bytes; etc.

---Dan

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 23 Feb 2015 11:17:04 +0100

> bandwidth cost of going to p521 worth the speed win over primes closer

Yes.  In this case, I believe the performance improvement would be
significant whereas the bandwidth cost is negligible.  I'm assuming
compressed code points.

/Simon

> decisions on signature schemes. Please don't discuss any of these
> future topics at this time.
>

---

From: RONDEPIERRE Franck <[email-masked]>
Date: Mon, 23 Feb 2015 11:12:54 +0000

I suggest another view for this study with same figures.

Let's say we are working at 128 bit of security, with uncompressed 64-byte points. Let's assume the key agreement requires 300k CPU cycles. 
Hence each 3GHz CPU can process 10k key agreements per second whereas the network can absorb 195k key agreements per second.
Besides, most websites do not have more than 10k connections per second, with the exception of google which processes roughly 65k researches per second in 2014 (less than in 2013).
In this context, which part benefits most from improvement? I'd rather say that saving computations would help to increase the capacity of websites.
How this still means nothing as long as we don't identify the bottleneck by taking into account the global network capacity, the cost to install wires, the cost of servers (internet providers or web sites)...

I personally doubt it has importance at our level, since big companies will adapt (or not) depending on their policy to fit customers needs and they would make us pay for it (with more commercials or money). I also reckon that cryptography has currently no impact on the internet bandwidth.

On the internet user side, I think we can agree that saving time is pointless since the whole cost of the key agreement (0.1 ms) is nothing compare to human times.

My current personal point of view is that internet industry doesn't really need performance improvements, but I'm ready to listen other argumentations.

Regards,

Franck Rondepierre

-----Message d'origine-----
De : Cfrg [mailto:[email-masked]] De la part de D. J. Bernstein
Envoyé : lundi 23 février 2015 04:21
À : [email-masked]
Objet : [Cfrg] network traffic

Kurt Roeckx writes:
> Depending on who you ask you might get a different answer, but I doubt 
> many people here care about bandwidth.

I care very much about network traffic---although it has to be quantified and put into context, just like CPU time.

As a concrete example, suppose your server resources are ten quad-core 3GHz CPUs and a 100Mbps network connection. Each microsecond the CPUs will perform a total of 120000 cycles of computation while the network connection will transmit 100 bits, i.e., 12.5 bytes.

Case study 1: Suppose you save 20000 cycles of computation by replacing a compressed 32-byte point with an uncompressed 64-byte point. You're

Is this a worthwhile tradeoff? The factor 15 imbalance suggests an answer of "no" (unless your ten servers cost fifteen times more than your network connection, which I doubt). This isn't a guarantee---maybe at this instant your CPUs are fully loaded while your network isn't--- but my experience is that if you need to reduce CPU time then there will be many better ways to reduce CPU time in other parts of the system with less cost to the network.

For me security and simplicity are ample reasons to require compression, but this example still illustrates how to think about the performance impact.

Case study 2: Suppose you save 200000 cycles of computation by switching from 65-byte numsp512t1 points to 66-byte E-521 points. You're

Is this a worthwhile tradeoff? The factor 20 imbalance the other way suggests an answer of "yes" (unless your network connection costs twenty times more than your ten servers, which I doubt). This again isn't a guarantee---maybe at this instant your network is fully loaded while your CPUs aren't---but my experience is that there will be many better ways to reduce network traffic in other parts of the system with less cost to the CPUs.

I should note that a single numsp512t1 coordinate uses only 64 bytes, but sending a compressed second coordinate spills over into another byte. Of course, a single-coordinate ladder skips this compressed bit; there are various cheap tricks to squeeze more bits out of keys; and one can always squeeze out another bit by doubling the key-generation time.
Any method of saving 1 bit will squeeze numsp512t1 into 64 bytes; any method of saving 4 bits will squeeze E-521 into 65 bytes; any method of saving 9 bits will squeeze numsp512t1 into 63 bytes; etc.

---Dan

---

From: David Jacobson <[email-masked]>
Date: Mon, 23 Feb 2015 08:47:56 -0800

Where computational efficiency does matter is code verification in 
embedded systems.  For automotive systems, they often want boot times on 
the order of half a second or less.  The code is running on a low-end 
ARM processor and has to validate the certificate chain and the 
executable image.  In some mobile systems, entire subsystems (say WiFi) 
are shut down when not being used, to save power.  They are powered back 
on, and have to boot and verify the code signature in a new 
milliseconds. Alas, in these systems there is no secure non-volatile 
memory available and thus the shortcut of just checking the hash of the 
image against the correct value won't work.

Now admittedly the CFRG serves the IETF, and thus is focused on network 
issues, not embedded systems. So my remarks are perhaps out of scope.  
But standards developed for networking are widely used for other things.

     --David Jacobson

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 23 Feb 2015 14:33:21 -0500

> significant whereas the bandwidth cost is negligible.  I'm assuming

I don't recall ever seeing a post suggesting bandwidth was the issue.

The actual issues are:

1) Performance (512 takes X% longer than 521)
2) Rigidity, 512 is a round number, 521 isn't
3) Regulation, (apparently Russia has legislation that effectively forces
512 or 511.)

How you weight these issues depends very much on the value of X. So I am
rather surprised that we didn't agree on a figure for X first. We don't
have to have an exact value but we do need values based on code that has
been optimized to the same degree. I have been watching for those numbers
but have not seen them yet.

If the value of X is definitely less than 10% I think there would be no
debate, 10% isn't enough to justify a strange number.

If the value of X is definitely more than 100% then 521 is the clear winner.

Yes, I know there will be error bars on the numbers because the code will
run at different speeds on different platforms. But lets face it, modern
platforms don't actually vary a whole lot.

A 10% difference in speed might be enough to make an objective choice
between Edwards and Montgomery but only experts know the difference between
those.

In short, I want to see the end of this particuar thread:

http://www.ietf.org/mail-archive/web/cfrg/current/msg05349.html

At the time the code for E512-569 was actually 15% faster than for E521-1

If Microsoft care enough about this that they are willing to put in more
cycles optimizing open source code for their favored outcome than
supporters of E521-1, then I say let them have it.

---

From: Damien Miller <[email-masked]>
Date: Tue, 24 Feb 2015 06:49:30 +1100 (AEDT)

+1

---

From: Kurt Roeckx <[email-masked]>
Date: Mon, 23 Feb 2015 22:13:29 +0100

> connection will transmit 100 bits, i.e., 12.5 bytes.

I'm just going adjust your example a little.

>    * saving 0.17 microseconds of computation but

If we assume it took 1 microseconds, it would then take 0.83.

>    * costing 2.56 microseconds of network capacity.

If we take the average connection to be 10.000 bytes, it would now
increase to 10.032.

If we start from assuming we're bandwidth limited, I was able to
do 10000 connections per second transfering 10 kB, but now
I can only do 9968.1.  That would also mean that I now spend 5.32
microseconds / s less CPU time on ECC.

So I would reduce the user visible performance by 0.32% and
reduce my cpu time by 0.00053%.  (That's a factor of 600.)

On the other hand if I assume I'm CPU limited I was spending 100
microseconds of CPU time per connection and had that reduced by
0.17.  I would then be able to do 10017 connections per second,
and bandwidth would increase to 100.49 mbit.  So a 0.17% increase
in user visible performance but also 0.49% increase in bandwidth.

(This all assumes no other overhead.)

As you can probably see, there are a lot of factors.

Kurt

---

From: Michael Hamburg <[email-masked]>
Date: Mon, 23 Feb 2015 14:26:51 -0800

Hi Phillip.

> On Feb 23, 2015, at 11:33 AM, Phillip Hallam-Baker <[email-masked]> wrote:
> 
> Yes, I know there will be error bars on the numbers because the code will run at different speeds on different platforms. But lets face it, modern platforms don't actually vary a whole lot.

This assertion may be true for Sandy Bridge vs Haswell, or even for other 64-bit platforms like Bulldozer, MIPS64, AArch64 etc.  I believe it’s worth noting that there is a large difference between 64-bit, 32-bit with no bignum acceleration, 32-bit with UMAAL but no vector unit, 32-bit with a NEON vector unit, etc.

For this difference, we mostly have conjecture.  As far as I’m aware, Ed448-Goldilocks is the only one of the proposed stronger curves which has been implemented and benchmarked on both ARM32 and AMD64, so we can’t measure how much the architecture influences rankings of curve speed.  This curve was also designed explicitly with 32-bit performance in mind, and it performs very well on NEON.

> A 10% difference in speed might be enough to make an objective choice between Edwards and Montgomery but only experts know the difference between those.
> 
> 
> http://www.ietf.org/mail-archive/web/cfrg/current/msg05349.html <http://www.ietf.org/mail-archive/web/cfrg/current/msg05349.html>
> 

I believe that the most recent discussion of the performance of strong curves is in this thread:

https://www.ietf.org/mail-archive/web/cfrg/current/msg05733.html <https://www.ietf.org/mail-archive/web/cfrg/current/msg05733.html>

This is for field arithmetic on Haswell, and there are several caveats mentioned in that thread.  Some approximation of relative performance of the whole curve (across implementation tradeoffs, Montgomery vs Edwards, comb size etc) can be obtained by multiplying the M and S times by the number of bits in the field.  See

http://www.ietf.org/mail-archive/web/cfrg/current/msg06084.html <http://www.ietf.org/mail-archive/web/cfrg/current/msg06084.html>

So for EG a 60:40 M:S ratio, normalized to MS NUMS P384, the rough curve timing ratios would be:

384: 1.00
389: 0.93
448: 1.17
480: 1.25
512: 2.21
521: 1.68

Note that the inflection point in performance is likely to occur lower on 32-bit.  In particular, I expect that the 480:448 cycle cost ratio is likely to be in the neighborhood of 1.5:1 on ARM32+NEON instead of 1.07:1.

> If Microsoft care enough about this that they are willing to put in more cycles optimizing open source code for their favored outcome than supporters of E521-1, then I say let them have it.

I don’t think that effort should be the main factor in standards.  But if you think so, would you also support the converse?

Cheers,
— Mike

---

From: Michael Hamburg <[email-masked]>
Date: Mon, 23 Feb 2015 14:29:20 -0800

> On Feb 23, 2015, at 2:26 PM, Michael Hamburg <[email-masked]> wrote:
> 
Err, s/discussion/measurement/, since there is discussion in the more recent thread I cited below.

> http://www.ietf.org/mail-archive/web/cfrg/current/msg06084.html <http://www.ietf.org/mail-archive/web/cfrg/current/msg06084.html>
D’oh, — Mike

---

From: Kurt Roeckx <[email-masked]>
Date: Tue, 24 Feb 2015 00:18:06 +0100

> As you can probably see, there are a lot of factors.

I think 5 gbps is actually more realistic for you example, so I'm
just going to give that as an alternative.

bandwidth limited: start with 500k connections/s of 10kB.  That
drops to 498.4k connections/s, spend .027% less cpu. (factor
of 12.)

cpu limited: go from 2 microseconds to 1.83 microseconds per
connection, or go to 545.4k connections/s.  Performances increases
with 9.1%, bandwith goes to 5.47 gbit/s increasing 9.4%.

Kurt

---

From: _MiW <[email-masked]>
Date: Tue, 24 Feb 2015 21:43:06 +1030

Q3: Yes.

A little extra uncompressed/compressed prime curve slight above 512
(1024b public key) is negligible cost difference to store and send in
the grand scheme of things.
It is after the end date but I wanted to contribute, at least because
there was no post interpreting the question as a monetary cost for data.
djb's answer in Subject: [Cfrg] network traffic
<[email-masked]> was awesome and inspired me to
post these scratchings.
The poll form is cool and I have been enjoying peoples responses.

These are fuzzy Fermi Equations :-) The total number of keys is going to
increase as humans engage in more cryptosystems. 10k xchg wtf? also
machines.

Early 2015.
Yearly key rotation, so cost are per annum and will decrease over time
as rest and transit costs decrease per GB.
Only raw key material considered, not cert or key meta (which is in the
order of kilobytes per key) but is mostly constant between key sizes.

Data at Rest cost per GB SSD:    0.40    $/GB
Data at Rest cost per GB HDD:    0.03    $/GB
Data in Transit cost per GB:    0.04    $/GB
Earth humans:    7000000000    persons
x keys per person    50   
key size    512 bits   
Total keys for people    350000000000   
Bytes to store every humans 50 private keys @ key size EC:   
22400000000000   
Bytes to store every humans 50 public keys (x2) @ key size EC:   
44800000000000   
GB of public keys    41723.25   
GB of private keys    20861.63   
Lifetime Key transfers    10000   
Cost to store on SSD    $16,689.30   
Cost to store on HDD    $1,251.70   
Cost to transmit every key lifetime_transfer_n times    $16,689,300.54   

Now we consume 66 bytes for our private key in secp521r1, but log2(521)
= 65.125 so we are wasting 7 bits we could use
for no additional cost at the data layer.
So our range of primes is for same cost as secp521r1 is 2^528 but I
don’t know of any at this size.

Even a modest 5% key size increase over 512b is going to cost us
something like $800 extra to store on SSD's and
$800,000 to transfer over the life of all the keys per year somewhat
divided up among all players.
Totally worth it in my opinion.

Thanks for reading,
_MiW