6 ms·

> RSA is obsolete. Stop using it. The problem is, the ONLY curves that are supported in practice are NIST P-256 (prime256v1) and P-384 (secp384r1), which aren'

> RSA is obsolete. Stop using it. The problem is, the ONLY curves that are supported in practice are NIST P-256 (prime256v1) and P-384 (secp384r1), which aren't considered safe. So, I guess, many are reluctant to switch (because we're non-experts and don't know real implications, but we heard that there's something not right there - and shouldn't one be wary?). Neither Curve25519 nor Curve448 - which are said to be safe - are usable with X.509 and TLS, yet. Still waiting for that RFC to get past the draft status. So, what should we do?

microcolonel 11y ago
Frankly I don't do security critical things on TLS anymore. I'm tired of having to wait in limbo for months to fix known vulnerabilities.
- _yy 11y ago
  Other protocols are probably just as broken, we just haven't found the vulnerabilities yet. Few protocols (if any) get as much scrutiny as SSL/TLS.
- wolf550e 11y ago
  What do you use instead? SSH? IPSec?
  - sandworm101 11y ago
    Go to datacenter. Open cage. Plug in keyboard. Oldschool.
    - Someone1234 11y ago
      Are you shielding the keyboard from EM leakage? I don't open a cage, I get in one and do my work in there... No more EM eavesdropping.
      - sandworm101 11y ago
        Unless there is an enemy antenna with you inside the cage. A real security pro uses a pneumatic keyboard.
        IgorPartola 11y ago
        No magnetized needle and a steady hand?
  - deleted 11y ago
    [deleted]
- chflags 11y ago
  This seems like what a sensible person would do. On the other hand, placing evergreen confidence in "TLS", believing that it is "good enough" or concluding "it's all we've got" are lines of thinking that not make sense to me. The vulnerabilities just keep coming, one after another. High speed crypto not part of TLS that, as another commenter put it, is "considered safe". Does it exist? Useful software that is written from the start with such care that it does not need to be continously patched ad inifitum. Nonexistant? (No need to answer. I know the truth.) Getting something added to TLS seems difficult enough, but getting something removed seems impossible. Like all bad software, TLS has numerous "features" I do not need and will never use. OpenSSL is like a museum of cryptography, preserving the obsolete for posterity. Long live TLS. May it forever waste my time and energy.
CiPHPerCoder 11y ago
You have two choices then: - Use RSA until 25519/448 land in TLS - Switch to ECDSA in the interim Personally, I would switch even though ECDSA isn't great. The concerns over P-256 and P-384 are more academic than anything: They're hard to implement safely and without side-channels. Read: hard, not impossible. You shouldn't be writing your own ECDSA implementation, however. That'd be foolhardy. EDIT: I use secp384r1 for signing random_compat, so if anyone gets bit by this recommendation, I will too: https://github.com/paragonie/random_compat/blob/master/dist/random_compat.phar.pubkey https://github.com/paragonie/random_compat/blob/master/dist/...
- _yy 11y ago
  The NIST curves also have constants which may or may not be manipulated. Bruce Schneier recommends against using them.
  - CiPHPerCoder 11y ago
    I would recommend against using them if your adversary is the NSA and your threat model comes wrapped in tin foil (and if I didn't, I'd get ignored anyway). If so, use NaCl/libsodium at the application layer and don't rely on ECDSA alone. If your threat model is "criminals", ECDSA is less insane than RSA (provided, once again, you're not implementing it yourself, you're relying on developed by a team of cryptographers and security engineers).
    - Dylan16807 11y ago
      Threat model wrapped in tin foil? I don't understand what you mean, are you suggesting paranoia? My threat model includes NSA dragnets but not being specifically targeted by the NSA.
      - CiPHPerCoder 11y ago
        In that case, active attacks against Weierstrass field arithmetic isn't part of your threat model and ECDSA/ECDH over the NIST curves is fine.
DCKing 11y ago
> The problem is, the ONLY curves that are supported in practice are NIST P-256 (prime256v1) and P-384 (secp384r1), which aren't considered safe. I don't believe this is accurate. It is true that there are complaints about the curves' design in parameter transparency and their difficulty to implement them securely. But I don't think people are actually suggesting the curves are not safe to use conceptually. P-256 facilitated ECDSA should be good to use until the new curves are adopted (which will take a while) as long as you're not writing implementations yourself. It is true that the new curves will be a better alternative once they are available given that they are designed for transparency and ease of implementation.
tptacek 11y ago
Use Curve25519.
- AnimalMuppet 11y ago
  drdaeman says that Curve25519 isn't usable with X.509 and TLS. Your reply is "Use Curve25519". What are you saying? That drdaeman is wrong, and Curve25519 can be used with TLS? Or are you saying, "don't use TLS"? Or... what?
  - wolf550e 11y ago
    The spec for Ed25519 signatures in TLS is not yet ready: https://tools.ietf.org/html/draft-irtf-cfrg-eddsa-02 https://tools.ietf.org/html/draft-irtf-cfrg-eddsa-02 X25519 for key exchange in TLS is ready and is in openssl master (and in boringSSL). I don't know the status of NSS support, or plans for SChannel and CoreCrypto support. X25519 key exchange and Ed25519 signatures have been deployed in nacl, libsodium, ssh, etc. for a while. EDIT: NSS ticket for X25519 Key Exchange: https://bugzilla.mozilla.org/show_bug.cgi?id=957105 https://bugzilla.mozilla.org/show_bug.cgi?id=957105

microcolonel 11y ago

Frankly I don't do security critical things on TLS anymore. I'm tired of having to wait in limbo for months to fix known vulnerabilities.

_yy 11y ago
Other protocols are probably just as broken, we just haven't found the vulnerabilities yet. Few protocols (if any) get as much scrutiny as SSL/TLS.
wolf550e 11y ago
What do you use instead? SSH? IPSec?
- sandworm101 11y ago
  Go to datacenter. Open cage. Plug in keyboard. Oldschool.
  - Someone1234 11y ago
    Are you shielding the keyboard from EM leakage? I don't open a cage, I get in one and do my work in there... No more EM eavesdropping.
    - sandworm101 11y ago
      Unless there is an enemy antenna with you inside the cage. A real security pro uses a pneumatic keyboard.
      - IgorPartola 11y ago
        No magnetized needle and a steady hand?
- deleted 11y ago
  [deleted]
chflags 11y ago
This seems like what a sensible person would do. On the other hand, placing evergreen confidence in "TLS", believing that it is "good enough" or concluding "it's all we've got" are lines of thinking that not make sense to me. The vulnerabilities just keep coming, one after another. High speed crypto not part of TLS that, as another commenter put it, is "considered safe". Does it exist? Useful software that is written from the start with such care that it does not need to be continously patched ad inifitum. Nonexistant? (No need to answer. I know the truth.) Getting something added to TLS seems difficult enough, but getting something removed seems impossible. Like all bad software, TLS has numerous "features" I do not need and will never use. OpenSSL is like a museum of cryptography, preserving the obsolete for posterity. Long live TLS. May it forever waste my time and energy.

CiPHPerCoder 11y ago

You have two choices then: - Use RSA until 25519/448 land in TLS - Switch to ECDSA in the interim Personally, I would switch even though ECDSA isn't great. The concerns over P-256 and P-384 are more academic than anything: They're hard to implement safely and without side-channels. Read: hard, not impossible. You shouldn't be writing your own ECDSA implementation, however. That'd be foolhardy. EDIT: I use secp384r1 for signing random_compat, so if anyone gets bit by this recommendation, I will too: https://github.com/paragonie/random_compat/blob/master/dist/random_compat.phar.pubkey https://github.com/paragonie/random_compat/blob/master/dist/...

_yy 11y ago
The NIST curves also have constants which may or may not be manipulated. Bruce Schneier recommends against using them.
- CiPHPerCoder 11y ago
  I would recommend against using them if your adversary is the NSA and your threat model comes wrapped in tin foil (and if I didn't, I'd get ignored anyway). If so, use NaCl/libsodium at the application layer and don't rely on ECDSA alone. If your threat model is "criminals", ECDSA is less insane than RSA (provided, once again, you're not implementing it yourself, you're relying on developed by a team of cryptographers and security engineers).
  - Dylan16807 11y ago
    Threat model wrapped in tin foil? I don't understand what you mean, are you suggesting paranoia? My threat model includes NSA dragnets but not being specifically targeted by the NSA.
    - CiPHPerCoder 11y ago
      In that case, active attacks against Weierstrass field arithmetic isn't part of your threat model and ECDSA/ECDH over the NIST curves is fine.

DCKing 11y ago

> The problem is, the ONLY curves that are supported in practice are NIST P-256 (prime256v1) and P-384 (secp384r1), which aren't considered safe. I don't believe this is accurate. It is true that there are complaints about the curves' design in parameter transparency and their difficulty to implement them securely. But I don't think people are actually suggesting the curves are not safe to use conceptually. P-256 facilitated ECDSA should be good to use until the new curves are adopted (which will take a while) as long as you're not writing implementations yourself. It is true that the new curves will be a better alternative once they are available given that they are designed for transparency and ease of implementation.

tptacek 11y ago

Use Curve25519.

AnimalMuppet 11y ago
drdaeman says that Curve25519 isn't usable with X.509 and TLS. Your reply is "Use Curve25519". What are you saying? That drdaeman is wrong, and Curve25519 can be used with TLS? Or are you saying, "don't use TLS"? Or... what?
- wolf550e 11y ago
  The spec for Ed25519 signatures in TLS is not yet ready: https://tools.ietf.org/html/draft-irtf-cfrg-eddsa-02 https://tools.ietf.org/html/draft-irtf-cfrg-eddsa-02 X25519 for key exchange in TLS is ready and is in openssl master (and in boringSSL). I don't know the status of NSS support, or plans for SChannel and CoreCrypto support. X25519 key exchange and Ed25519 signatures have been deployed in nacl, libsodium, ssh, etc. for a while. EDIT: NSS ticket for X25519 Key Exchange: https://bugzilla.mozilla.org/show_bug.cgi?id=957105 https://bugzilla.mozilla.org/show_bug.cgi?id=957105