4 ms·

The logical click bait on this one. I could not resist thinking it’s like saying there is no circle other than a round circle, but I had no idea if it’s equival

by cgio 1y ago

The logical click bait on this one. I could not resist thinking it’s like saying there is no circle other than a round circle, but I had no idea if it’s equivalent and fair comment given my limited cryptography knowledge (as in non existent). So I had to read it, and while I got little, by osmosis, I feel falling for the bait was worth it.

techNoob123 1y ago
lol same - but i needed this comment to take the bait
bawolff 1y ago
For historical context, TLS only really started to use the eliptic curve version of diffie-helman in the mid 2010s. Prior to that, plain diffie helman was more popular. (E.g. here is a thread from a decade ago complaining about lack of support https://security.stackexchange.com/questions/59459/how-widely-deployed-is-tls-with-cipher-ecdhe https://security.stackexchange.com/questions/59459/how-widel... ). ECC also used to have patents which restricted adoption back in the day. There also used to be a lot of conspiracy theories that NSA backdoored nist curved ( e.g. https://m.slashdot.org/story/191445 https://m.slashdot.org/story/191445 ). Probably fud, but it slowed down adoption of eliptic curves.
- tgma 1y ago
  I believe the patent issue was by far the dominant friction for adoption in 2000s. On the NIST curve problem, well, maybe FUD, but evidently, they indeed backdoored the elliptic curve-based random number generator, so I would say some distrust is warranted. Irrespective of the curve issue, ed25519/x25519 is superior and has other nice properties like not catastrophically breaking if you can't generate a unique random "k" for ECDSA as PlayStation discovered the hard way[1]. [1]: https://youtu.be/DUGGJpn2_zY?t=2142 https://youtu.be/DUGGJpn2_zY?t=2142
  - xyzzyz 1y ago
    > like not catastrophically breaking if you can't generate a unique random "k" for ECDSA How does that work? I thought that this vulnerability was independent of the curve that is used. Ed25519 has a bunch of other nice properties related to resistance to programming errors, but I never heard of this one.
    - cesarb 1y ago
      > How does that work? I thought that this vulnerability was independent of the curve that is used. The trick is that this value in Ed25519 is a deterministic hash of the private key and the message, which means that for the same message, the same value will always be chosen, and since the private key is part of the hash, for different messages the value is basically random unless you already know the private key. Yes, the same trick can be used with any curve, and it will avoid the vulnerability; but for Ed25519, it's always been part of the specification so everyone does it that way, while for ECDSA it's a later addition (RFC 6979) and many implementations still do it the old way.
- phkahler 1y ago
  >> Probably fud, but it slowed down adoption of eliptic curves. Not FUD at all. NIST revoked their recommendation to use those curves because of it. The facts are that a "backdoor" exists whether anyone knows what it is or not, and NSA could not explain how those particular numbers were chosen so out of caution we must assume they know the backdoor and not use those curves.
  - tgma 1y ago
    I believe you are mixing up NIST ECC curves with Dual_EC_DRBG[1] which is a random number generator based on elliptic curves which is widely considered to be backdoored and they revoked its recommendation (there are much better ways to construct an RNG so it was stupid to use in practice for reasons other than backdoor too.) The P-series curves are still a NIST recommendation and widely deployed in TLS. The B-series fell out of fashion due to practical reasons. [1]: https://en.wikipedia.org/wiki/Dual_EC_DRBG https://en.wikipedia.org/wiki/Dual_EC_DRBG

by cgio 1y ago

techNoob123 1y ago

lol same - but i needed this comment to take the bait

bawolff 1y ago

For historical context, TLS only really started to use the eliptic curve version of diffie-helman in the mid 2010s. Prior to that, plain diffie helman was more popular. (E.g. here is a thread from a decade ago complaining about lack of support https://security.stackexchange.com/questions/59459/how-widely-deployed-is-tls-with-cipher-ecdhe https://security.stackexchange.com/questions/59459/how-widel... ). ECC also used to have patents which restricted adoption back in the day. There also used to be a lot of conspiracy theories that NSA backdoored nist curved ( e.g. https://m.slashdot.org/story/191445 https://m.slashdot.org/story/191445 ). Probably fud, but it slowed down adoption of eliptic curves.

tgma 1y ago
I believe the patent issue was by far the dominant friction for adoption in 2000s. On the NIST curve problem, well, maybe FUD, but evidently, they indeed backdoored the elliptic curve-based random number generator, so I would say some distrust is warranted. Irrespective of the curve issue, ed25519/x25519 is superior and has other nice properties like not catastrophically breaking if you can't generate a unique random "k" for ECDSA as PlayStation discovered the hard way[1]. [1]: https://youtu.be/DUGGJpn2_zY?t=2142 https://youtu.be/DUGGJpn2_zY?t=2142
- xyzzyz 1y ago
  > like not catastrophically breaking if you can't generate a unique random "k" for ECDSA How does that work? I thought that this vulnerability was independent of the curve that is used. Ed25519 has a bunch of other nice properties related to resistance to programming errors, but I never heard of this one.
  - cesarb 1y ago
    > How does that work? I thought that this vulnerability was independent of the curve that is used. The trick is that this value in Ed25519 is a deterministic hash of the private key and the message, which means that for the same message, the same value will always be chosen, and since the private key is part of the hash, for different messages the value is basically random unless you already know the private key. Yes, the same trick can be used with any curve, and it will avoid the vulnerability; but for Ed25519, it's always been part of the specification so everyone does it that way, while for ECDSA it's a later addition (RFC 6979) and many implementations still do it the old way.
phkahler 1y ago
>> Probably fud, but it slowed down adoption of eliptic curves. Not FUD at all. NIST revoked their recommendation to use those curves because of it. The facts are that a "backdoor" exists whether anyone knows what it is or not, and NSA could not explain how those particular numbers were chosen so out of caution we must assume they know the backdoor and not use those curves.
- tgma 1y ago
  I believe you are mixing up NIST ECC curves with Dual_EC_DRBG[1] which is a random number generator based on elliptic curves which is widely considered to be backdoored and they revoked its recommendation (there are much better ways to construct an RNG so it was stupid to use in practice for reasons other than backdoor too.) The P-series curves are still a NIST recommendation and widely deployed in TLS. The B-series fell out of fashion due to practical reasons. [1]: https://en.wikipedia.org/wiki/Dual_EC_DRBG https://en.wikipedia.org/wiki/Dual_EC_DRBG