Subject: [Cfrg] General question about ECC encryption

From: N6 Ghost <[email-masked]>
Date: Thu, 29 Mar 2018 22:31:06 -0700

Hi all,

I recently, go into a “talk” with one of the security engineers at work. he was trying to tell me how he refuses to use ECC encryption because it has weakness it there basic functionality.  something about curves being able to be predicted.  and the NSA and other “big brother” orgs, have tools
the break ECC because of these weaknesses….

whats the real skinny?

N6Ghost

---

From: Travis Finkenauer <[email-masked]>
Date: Fri, 30 Mar 2018 17:47:17 +0000

Is your coworker conflating any ECC and the Dual_EC_DRBG?
Dual_EC_DRBG is theorized have been designed to have a back door, as shown by Checkoway et. al:

    http://dualec.org/

By the same logic:
"A cryptographic algorithm with a back door used numbers. Therefore, any cryptographic algorithm that uses numbers has a backdoor."

-Travis

On 3/30/18, 1:31 AM, "Cfrg on behalf of N6 Ghost" <[email-masked] on behalf of [email-masked]> wrote:

    Hi all,

    whats the real skinny?
    
    N6Ghost

---

From: Tony Arcieri <[email-masked]>
Date: Fri, 30 Mar 2018 11:18:21 -0700

> Is your coworker conflating any ECC and the Dual_EC_DRBG?

There are also concerns about the domain parameters of the NIST curves,
most notably the choice of "b" (in short Weierstrass form) as the SHA-1
digest of a seed value, whose origins are not stated or justified. (Note:
my personal opinion is it is unlikely that these values have been chosen in
such a way that they have any material impact on the security of the NIST
curves)

The elliptic curves selected by the CFRG, on the other hand, do not have
mystery constants of unknown origin, but instead deterministically generate
all relevant domain parameters according to a set of rigid curve selection
guidelines. You can read about these guidelines in Appendix A of RFC 7748:

https://tools.ietf.org/html/rfc7748#appendix-A

-- 
Tony Arcieri

---

From: Dan Brown <[email-masked]>
Date: Sat, 31 Mar 2018 13:56:37 +0000

Many things are possible, see ‎https://ia.cr/2015/1018
by Koblitz and Menezes, where they examine some speculations about secret attacks on ECC, RSA, etc.

There was considerable discussion in CFRG, and else where on _which_ ECC is best, but that does not seem to be your question.

Personal views: based on published info: ECC was in 1985, last attacks on ECDLP in prime fields were from 1999, and affected very special curves, ECC standard since around 2000, ECC now deployed very widely. Of course, one must also be careful how one uses ECC, because there’s many pitfalls.

It's okay to worry about ECC, but the solution is to use ECC + 2nd algorithm.‎ Refusing ECC passes the buck to another algorithm , e.g RSA, which might also have a secret attack, and has some published deficiencies.

Sent from my BlackBerry 10 smartphone on the Rogers network.
  Original Message
From: N6 Ghost
Sent: Friday, March 30, 2018 1:31 AM
To: [email-masked]
Subject: [Cfrg] General question about ECC encryption

Hi all,

whats the real skinny?

N6Ghost

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

---

From: N6 Ghost <[email-masked]>
Date: Sat, 31 Mar 2018 21:36:42 -0700

good points, i don’t know but he seemed to have problems with ECC in general… I was always ok With ECC..  the subject came up as part of a larger “signal” talk. 

-N6Ghost

> On Mar 30, 2018, at 10:47 AM, Travis Finkenauer <[email-masked]> wrote:
>

---

From: N6 Ghost <[email-masked]>
Date: Sat, 31 Mar 2018 21:42:20 -0700

good stuff, below.. sort reminds of OpenBSD the pump there random generators thru a second pass, amongst other things. so modern crypto
standards, more or less 2 different algorithms seem to be the best as any weakness in one is offset by the other. likewise with random generators?

> On Mar 31, 2018, at 6:56 AM, Dan Brown <[email-masked]> wrote:
>

---

From: Nex6 <[email-masked]>
Date: Sat, 31 Mar 2018 21:38:44 -0700

very good points below, another link for me to digest. thanks

> On Mar 30, 2018, at 11:18 AM, Tony Arcieri <[email-masked]> wrote:
> 
> On Fri, Mar 30, 2018 at 10:47 AM, Travis Finkenauer <[email-masked] <mailto:[email-masked]>> wrote:
> There are also concerns about the domain parameters of the NIST curves, most notably the choice of "b" (in short Weierstrass form) as the SHA-1 digest of a seed value, whose origins are not stated or justified. (Note: my personal opinion is it is unlikely that these values have been chosen in such a way that they have any material impact on the security of the NIST curves)
> 
> The elliptic curves selected by the CFRG, on the other hand, do not have mystery constants of unknown origin, but instead deterministically generate all relevant domain parameters according to a set of rigid curve selection guidelines. You can read about these guidelines in Appendix A of RFC 7748:
> 
> https://tools.ietf.org/html/rfc7748#appendix-A <https://tools.ietf.org/html/rfc7748#appendix-A>
> 
> -- 
> Tony Arcieri