Subject: [Cfrg] When in doubt, err on the side of security

From: "Igoe, Kevin M." <[email-masked]>
Date: Mon, 20 Oct 2014 18:37:19 +0000

Once a security primitive has been selected, Moore's law will naturally improve its
performance with the passage of time.   But Moore's law and advances in
cryptanalysis will only erode its security (measured in the money needed to run
the attack).  Bottom line: err on the side of security.

----------------+--------------------------------------------------
Kevin M. Igoe   | "We can't solve problems by using the same kind
[email-masked]  | of thinking we used when we created them."
                |              - Albert Einstein -
----------------+--------------------------------------------------

---

From: Watson Ladd <[email-masked]>
Date: Mon, 20 Oct 2014 12:22:46 -0700

On Oct 20, 2014 11:37 AM, "Igoe, Kevin M." <[email-masked]> wrote:
>
> Once a security primitive has been selected, Moore’s law will naturally
improve its
>
> performance with the passage of time.   But Moore’s law and advances in
>

Truisms like that are rarely helpful, and this is no exception. First,
Moores law amplifies, not erases, performance issuses: users want to do
more with cheaper crypto. How much this matters is an economic question.
Sadly we've already ruled out the fastest options for somewhat decent
reasons, as a glance at eBATS will show.

The second issue is that the choice between performance and security is
made worse by the absence of intermediate options. An organization that
strained and strained to get adequate performance out of ed448goldilocks
isn't made more secure by a standard only offering a 521 bit and 256 bit
curve, as they will reduce security to get adequate performance. The
tradeoff doesn't need to be that extreme for this to happen.

I haven't seen good arguments for approving two curves at the far ends of
the performance scale, instead of picking inflection points where a small
increase in time yields a large increase in security. What I've seen is
arguments that ignore the revealed preferences of users.

Thirdly, I recall more Z80 processors are produced today then in the days
of the microcomputer. Moore's law can be used to increase performance or
reduce price.

Interestingly, the NSA is no stranger to this issue. Suite B did not use
the highest security for everything, presumably for performance reasons. In
some cases the US Army uses very breakable ciphers, because the alternative
is no cipher and the material isn't that sensitive.  (If the message is
"Attack at dawn", decrypting at 9 am isn't terribly helpful to the enemy)

In conclusion performance still matters.

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

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 20 Oct 2014 16:01:44 -0400

> arguments that ignore the revealed preferences of users.

We didn't. We picked one point that was comfortably above being broken
using any current or future computer or network of computers built using
conventional computing gates using known algorithms. Then we picked another
point that gave roughly the square of the work factor of the first.

There is no security/performance tradeoff above the ~256 bit level. The
point of going for those extra bits is to put the question beyond any
feasible doubt.

So this argument would make sense if we were talking about something faster
than Curve25519. But I don't think anyone is.

---

From: David Leon Gil <[email-masked]>
Date: Mon, 20 Oct 2014 16:32:56 -0400

On Mon, Oct 20, 2014 at 3:22 PM, Watson Ladd <[email-masked]> wrote:
> The second issue is that the choice between performance and security is made
> worse by the absence of intermediate options. An organization that strained
> and strained to get adequate performance out of ed448goldilocks

What organization has strained and strained to get more performance out
of Ed448? Or Curve25519, for that matter?

On Mon, Oct 20, 2014 at 2:37 PM, Igoe, Kevin M. <[email-masked]> wrote:
> Once a security primitive has been selected, Moore’s law will naturally improve
> its performance with the passage of time.   But Moore’s law and advances in
> cryptanalysis will only erode its security [ . . . ]

Proposal: Pick curve bit-length based on a fixed latency budget; say, 1 ms.
Each semiconductor node, increase bit-length as much as necessary to
keep latency the same.

Security is asymptotically guaranteed.

The CFRG could start by recommending a curve over Fq(2^4062-17), rather than
any of this nonsense about Fq(2^414-17) etc.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 20 Oct 2014 16:38:14 -0400

I don't understand the constraint suggested.

In practice the performance of public key is not particularly critical. If
you want really fast then use symmetric key. The only time that you ever
need public key is to establish a trust relationship. Other than the Web,
which is a far outlier, what synchronous protocol do we have where
negotiating keys synchronously is a hard requirement?

Certainly not email, nor chat. And if we get into money then we can solve
problems by spending our way out.

On Mon, Oct 20, 2014 at 4:32 PM, David Leon Gil <[email-masked]> wrote:

> made
> improve