5 ms·

"ecdh. which all the standard curves appear to be backdoored" This is a pretty serious assertion to make as a throwaway comment. You're talking about the NIST

"ecdh. which all the standard curves appear to be backdoored" This is a pretty serious assertion to make as a throwaway comment. You're talking about the NIST sponsored constants suspected of being backdoored. ( https://en.wikipedia.org/wiki/Dual_EC_DRBG https://en.wikipedia.org/wiki/Dual_EC_DRBG https://safecurves.cr.yp.to/ https://safecurves.cr.yp.to/ ) That's the reason Curve22519 (defined by djb, completely independent of any NIST involvement) has become popular and is being widely used as default in major ECDH implementations (https://en.wikipedia.org/wiki/Curve25519 https://en.wikipedia.org/wiki/Curve25519 ). As close to a "standard" as you'd find today that nobody believes to have known weaknesses or backdoors.

mSparks 10y ago
im mobile and traveling. tried to find my links to research but not in my mobile bookmarks. there is a great page somewhere that lists each curve --- edit you found it: https://safecurves.cr.yp.to https://safecurves.cr.yp.to for reference google (pdfs so cant get links from google mobile): security dangers of nist curves and also the reasoning behind the curve chosen for bitcoin. so edit 2: just, yes. but note the safecurves quote " The core problem is that if you implement the standard curves, chances are you're doing it wrong:"
- chetanahuja 10y ago
  Please stop spreading FUD. The quote from safecurves you posted is actually describing the very reason safecurves exists in the first place. And it lists the curves that are safe to use. "Most of these attacks would have been ruled out by better choices of curves that allow simple implementations to be secure implementations. This is the primary motivation for SafeCurves. The SafeCurves criteria are designed to ensure ECC security, not just ECDLP security." Also you completely ignored them main part of my earlier comment. The actually widely adapted, curve25519 by djb (who's also the author of that safecurves page) with no currently known weaknesses (and needless to say, no backdoors either).
  - mSparks 10y ago
    Confused.. Safecurves exists because all the standard curves appear to be backdoored. Curve25519 is not a standard curve. How is this FUD? Curve25519 was first released by Daniel J. Bernstein in 2005,[7] but interest increased considerably after 2013 when it was discovered that the NSA had implemented a backdoor into Dual EC DRBG. While not directly related,[8] suspicious aspects of the NIST's P curve constants[9] led to concerns[10] that the NSA had chosen values that gave them an advantage in factoring[11] public keys.[12]
    - chetanahuja 10y ago
      "Safecurves exists because all the standard curves appear to be backdoored. Curve25519 is not a standard curve. This was your original stanza that I objected to: "The problems are all in establishing keys. For that there are currently only two choices in use. ecdh. which all the standard curves appear to be backdoored. and rsa, which the russians reckon they have broken." You were insinuating that basically there's no safe way to establish secrets (using some form of ecdh). While there absolutely is. Here's the list of open source packages using (safe) Curve25519 : https://en.wikipedia.org/wiki/Curve25519 https://en.wikipedia.org/wiki/Curve25519 In 2014 OpenSSH[14] defaults to Curve25519-based ECDH. Libraries[edit] Libgcrypt[15] libssh[14][16] NaCl[17] GnuTLS[18] mbed TLS (formerly PolarSSL)[19] wolfSSL[20] Botan[21] Libsodium[22] OpenSSL since version 1.1.0[23] What else do you want from a "standard"?
      - mSparks 10y ago
        ->You were insinuating that basically there's no safe way to establish secrets (using some form of ecdh). While there absolutely is. I'm complaining there is no STANDARD & SECURE way to establish secrets (unlike say AES or Rabbit). That's not quite the same thing. Nearly everything has been designed to fail from the very beginning. Or are you saying you still trust "the experts" after everything that's happened? Curve 25519 does not meet the ECRYPT recommendations of a min keylength of 512bits for Ellyptic Curves https://www.keylength.com/en/3/ https://www.keylength.com/en/3/ Curve 25519 at 128bit provides:Very short-term protection against small organizations Should not be used for confidentiality in new systems ->OpenSSL since version 1.1.0 Probably the very worst example of an implementation you could give. OpenSSL version 1.1.0... Really????

mSparks 10y ago

im mobile and traveling. tried to find my links to research but not in my mobile bookmarks. there is a great page somewhere that lists each curve --- edit you found it: https://safecurves.cr.yp.to https://safecurves.cr.yp.to for reference google (pdfs so cant get links from google mobile): security dangers of nist curves and also the reasoning behind the curve chosen for bitcoin. so edit 2: just, yes. but note the safecurves quote " The core problem is that if you implement the standard curves, chances are you're doing it wrong:"

chetanahuja 10y ago
Please stop spreading FUD. The quote from safecurves you posted is actually describing the very reason safecurves exists in the first place. And it lists the curves that are safe to use. "Most of these attacks would have been ruled out by better choices of curves that allow simple implementations to be secure implementations. This is the primary motivation for SafeCurves. The SafeCurves criteria are designed to ensure ECC security, not just ECDLP security." Also you completely ignored them main part of my earlier comment. The actually widely adapted, curve25519 by djb (who's also the author of that safecurves page) with no currently known weaknesses (and needless to say, no backdoors either).
- mSparks 10y ago
  Confused.. Safecurves exists because all the standard curves appear to be backdoored. Curve25519 is not a standard curve. How is this FUD? Curve25519 was first released by Daniel J. Bernstein in 2005,[7] but interest increased considerably after 2013 when it was discovered that the NSA had implemented a backdoor into Dual EC DRBG. While not directly related,[8] suspicious aspects of the NIST's P curve constants[9] led to concerns[10] that the NSA had chosen values that gave them an advantage in factoring[11] public keys.[12]
  - chetanahuja 10y ago
    "Safecurves exists because all the standard curves appear to be backdoored. Curve25519 is not a standard curve. This was your original stanza that I objected to: "The problems are all in establishing keys. For that there are currently only two choices in use. ecdh. which all the standard curves appear to be backdoored. and rsa, which the russians reckon they have broken." You were insinuating that basically there's no safe way to establish secrets (using some form of ecdh). While there absolutely is. Here's the list of open source packages using (safe) Curve25519 : https://en.wikipedia.org/wiki/Curve25519 https://en.wikipedia.org/wiki/Curve25519 In 2014 OpenSSH[14] defaults to Curve25519-based ECDH. Libraries[edit] Libgcrypt[15] libssh[14][16] NaCl[17] GnuTLS[18] mbed TLS (formerly PolarSSL)[19] wolfSSL[20] Botan[21] Libsodium[22] OpenSSL since version 1.1.0[23] What else do you want from a "standard"?
    - mSparks 10y ago
      ->You were insinuating that basically there's no safe way to establish secrets (using some form of ecdh). While there absolutely is. I'm complaining there is no STANDARD & SECURE way to establish secrets (unlike say AES or Rabbit). That's not quite the same thing. Nearly everything has been designed to fail from the very beginning. Or are you saying you still trust "the experts" after everything that's happened? Curve 25519 does not meet the ECRYPT recommendations of a min keylength of 512bits for Ellyptic Curves https://www.keylength.com/en/3/ https://www.keylength.com/en/3/ Curve 25519 at 128bit provides:Very short-term protection against small organizations Should not be used for confidentiality in new systems ->OpenSSL since version 1.1.0 Probably the very worst example of an implementation you could give. OpenSSL version 1.1.0... Really????