4 ms·

You probably shouldn't even entertain the notion of RSA or finite field Diffie Hellman anymore. In general... Public key encryption: Use X25519 (RFC 7748) then

You probably shouldn't even entertain the notion of RSA or finite field Diffie Hellman anymore. In general... Public key encryption: Use X25519 (RFC 7748) then 256-bit symmetric-key encryption in an AEAD mode. (When in doubt, ChaCha20-Poly1305 is a great choice with ephemeral keys.) Public key signatures: Use Ed25519 (RFC 7748) or deterministic ECDSA (RFC 6979) over a 256-bit curve. And obviously, the key sizes on that page have no applicability to post-quantum cryptography key sizes.

geofft 10y ago
A lot of us have to interoperate with systems that don't easily support Curve25519 or ChaCha20-Poly1305, let alone post-quantum algorithms. As RSA and finite-field DH aren't broken, I'd rather use a well-tested implementation of one of those with sufficient key length than try to backport a newer algorithm. (For new protocols and new code, sure.) What I find this page useful for is pointing out lower bounds on security levels. If you're building a system that, eventually, outputs a file format with 256-bit hashes of files, there isn't a point in using any stronger crypto than a 128-bit security level to sign and transmit the hashes. If you want to make the system more secure, first figure out how to make the hashes longer.
- CiPHPerCoder 10y ago
  > As RSA and finite-field DH aren't broken No, but their implementations often are. For a recent example (Zend Framework, just at the end of 2015): http://framework.zend.com/security/advisory/ZF2015-10 http://framework.zend.com/security/advisory/ZF2015-10 More famously: http://www.cryptofails.com/post/70059600123/saltstack-rsa-e-d-1 http://www.cryptofails.com/post/70059600123/saltstack-rsa-e-... RSA has more knobs to turn than EdDSA, and leads greater room for implementor error.
  - Someone1234 10y ago
    I'm confused. Above you're arguing for the use of newer schemes which are available with newer code which has not been as time-tested, here you're suggesting that the reason to avoid older well-tested schemes is poor implementation? Aren't these two points contradictory. Unless you have a reason why the new scheme's implementation is more likely to be flawless than older implementations which may have received bug fixes or reviews. Seems to me that implementation bugs are a good reason to stick to older heavily used code, rather than jumping to the latest new thing.
    - marcosdumay 10y ago
      Curve25519 is very well tested too. Not as well tested as RSA, granted, but it has actually survived the testing, while RSA has several known problems. Overall, creating an RSA implementation is a minefield. There is a big number of issues you must avoid, while Curve25519 doesn't suffer from most of them.
      - geofft 10y ago
        I have no intention of creating an RSA implementation or a Curve25519 implementation. I'm going to use a high-level library that doesn't let me choose things like public exponent or padding style. If the high-level libraries out there for X25519 are better-tested and less likely to get things wrong than those for RSA, sure, but that would be pretty surprising.
        CiPHPerCoder 10y ago
        Here's a high-level library: https://github.com/paragonie/halite https://github.com/paragonie/halite It uses libsodium, which only offers X25519/Ed25519 for public key crypto.
        marcosdumay 10y ago
        So, be surprised. They are. Implementing RSA has many, many pitfalls. People are finding vulnerabilities on those libraries all the time. Now, take a look at libsodim source code - it's simple and direct, no special cases anywhere, no tests for validity. The only concern is with stuff like if the compiler will optimize out things like zeroing the memory and the platform has constant time opcodes.
    - tptacek 10y ago
      You're confused because you're unfamiliar with the concepts being discussed. That's not the same thing as being confused because the parent comment's argument is flawed. RSA is dangerous for a bunch of reasons: * It has selectable key sizes and performance parameters that beg people to deploy it insecurely. That's the concept you're probably roughly familiar with. * It is subject to a far greater diversity of implementation faults (for instance: because of its padding requirements, or because of its relatively complicated key generation process) than alternative algorithms. * It offers one primitive operation you actually want (signatures) along with one you almost never want (encryption), which results in cryptosystems like classical TLS or, worse, every system that ever directly encrypted a credit card number with RSA. Alternative algorithms don't offer this foot-gun. * The underlying mathematics of RSA are weakening(/improving) faster than those of elliptic curve; we could lose RSA entirely within our lifetimes even if quantum doesn't come to pass. You don't have to take my word for it. Survey modern cryptosystems. Note which ones depend on curves and which depend on RSA, and then investigate the reputations of each of those systems.
- tptacek 10y ago
  Implementation pitfalls for RSA are one problem, but not the only one. RSA systems also tend to intrinsically resist forward security (they beg for long-lived keys used directly to encrypt things) and have idiosyncratic padding requirements and message restrictions. These are design-level issues that libraries can't easily address for you. Look at the deployed base of RSA systems, including modern ones, and note how few of them use OAEP and how many use PKCS1v15. If you don't have a choice what algorithm you can use, I'm not so interested in what advice you're getting. Just do what everyone else tells you to do. But if you're in a place where you have real choices to make, the most important thing people can probably tell you is "don't use RSA, don't use conventional Diffie-Hellman".

geofft 10y ago

A lot of us have to interoperate with systems that don't easily support Curve25519 or ChaCha20-Poly1305, let alone post-quantum algorithms. As RSA and finite-field DH aren't broken, I'd rather use a well-tested implementation of one of those with sufficient key length than try to backport a newer algorithm. (For new protocols and new code, sure.) What I find this page useful for is pointing out lower bounds on security levels. If you're building a system that, eventually, outputs a file format with 256-bit hashes of files, there isn't a point in using any stronger crypto than a 128-bit security level to sign and transmit the hashes. If you want to make the system more secure, first figure out how to make the hashes longer.

CiPHPerCoder 10y ago
> As RSA and finite-field DH aren't broken No, but their implementations often are. For a recent example (Zend Framework, just at the end of 2015): http://framework.zend.com/security/advisory/ZF2015-10 http://framework.zend.com/security/advisory/ZF2015-10 More famously: http://www.cryptofails.com/post/70059600123/saltstack-rsa-e-d-1 http://www.cryptofails.com/post/70059600123/saltstack-rsa-e-... RSA has more knobs to turn than EdDSA, and leads greater room for implementor error.
- Someone1234 10y ago
  I'm confused. Above you're arguing for the use of newer schemes which are available with newer code which has not been as time-tested, here you're suggesting that the reason to avoid older well-tested schemes is poor implementation? Aren't these two points contradictory. Unless you have a reason why the new scheme's implementation is more likely to be flawless than older implementations which may have received bug fixes or reviews. Seems to me that implementation bugs are a good reason to stick to older heavily used code, rather than jumping to the latest new thing.
  - marcosdumay 10y ago
    Curve25519 is very well tested too. Not as well tested as RSA, granted, but it has actually survived the testing, while RSA has several known problems. Overall, creating an RSA implementation is a minefield. There is a big number of issues you must avoid, while Curve25519 doesn't suffer from most of them.
    - geofft 10y ago
      I have no intention of creating an RSA implementation or a Curve25519 implementation. I'm going to use a high-level library that doesn't let me choose things like public exponent or padding style. If the high-level libraries out there for X25519 are better-tested and less likely to get things wrong than those for RSA, sure, but that would be pretty surprising.
      - CiPHPerCoder 10y ago
        Here's a high-level library: https://github.com/paragonie/halite https://github.com/paragonie/halite It uses libsodium, which only offers X25519/Ed25519 for public key crypto.
      - marcosdumay 10y ago
        So, be surprised. They are. Implementing RSA has many, many pitfalls. People are finding vulnerabilities on those libraries all the time. Now, take a look at libsodim source code - it's simple and direct, no special cases anywhere, no tests for validity. The only concern is with stuff like if the compiler will optimize out things like zeroing the memory and the platform has constant time opcodes.
  - tptacek 10y ago
    You're confused because you're unfamiliar with the concepts being discussed. That's not the same thing as being confused because the parent comment's argument is flawed. RSA is dangerous for a bunch of reasons: * It has selectable key sizes and performance parameters that beg people to deploy it insecurely. That's the concept you're probably roughly familiar with. * It is subject to a far greater diversity of implementation faults (for instance: because of its padding requirements, or because of its relatively complicated key generation process) than alternative algorithms. * It offers one primitive operation you actually want (signatures) along with one you almost never want (encryption), which results in cryptosystems like classical TLS or, worse, every system that ever directly encrypted a credit card number with RSA. Alternative algorithms don't offer this foot-gun. * The underlying mathematics of RSA are weakening(/improving) faster than those of elliptic curve; we could lose RSA entirely within our lifetimes even if quantum doesn't come to pass. You don't have to take my word for it. Survey modern cryptosystems. Note which ones depend on curves and which depend on RSA, and then investigate the reputations of each of those systems.
tptacek 10y ago
Implementation pitfalls for RSA are one problem, but not the only one. RSA systems also tend to intrinsically resist forward security (they beg for long-lived keys used directly to encrypt things) and have idiosyncratic padding requirements and message restrictions. These are design-level issues that libraries can't easily address for you. Look at the deployed base of RSA systems, including modern ones, and note how few of them use OAEP and how many use PKCS1v15. If you don't have a choice what algorithm you can use, I'm not so interested in what advice you're getting. Just do what everyone else tells you to do. But if you're in a place where you have real choices to make, the most important thing people can probably tell you is "don't use RSA, don't use conventional Diffie-Hellman".