Hacker News new | past | comments | ask | show | jobs | submit login

I presume what you're saying is that there is a whole set of missing verification additions, but if not, what are you referring to for textbook RSA being insecure?



You need to "pad" the number that will be signed so that it's the right size and shape to fit, or else bad guys can choose for you to sign a number that makes it very easy to find your private key by looking at the signature which is clearly a terrible outcome.

Remember RSA is just very simple maths, done with huge numbers. If you pick the right "huge" numbers things that look hard become very easy indeed. So we need to ensure we never pick them.

The correct way to do this, which a lot of systems haven't adopted yet, is called RSA-PSS, the Probabilistic Signature Scheme. PSS has a proof that says if you believe RSA works, and assume certain other reasonable things, this is actually safe.

Before RSA-PSS (and still today in lots of backwards compatible systems), people used PKCS#1 v1.5 which has a scheme somebody threw together to do some padding but without any great insight. There is no security proof for PKCS#1 v1.5, it's probably safe, ish, but we can't be sure.


> There is no security proof for PKCS#1 v1.5, it's probably safe

As long as you avoid the known problems, it probably is safe for signatures and the main problem now is that PSS is not included in lots of standards which thus require PKCS1_1v5. This prevents major implementation due to those standards not being updated fast enough.

As an example of slow adoption: The HSMs i'm currently using only started native support for PSS last year, about 20 years after it's introduction.

Please note that pkcs1_1v5 is never secure for encryption/decryption schemes.


Textbook RSA is not secure, as there’s no element of randomness in the encryption, rendering it susceptible to chosen ciphertext attacks. RSA+OAEP includes randomness and also protects again vulnerability such as certain plaintexts always having the same encryption regardless of key.


Does this only apply to encryption or also signatures?


It applies to both, albeit with slightly different practical implications.


Not the OP, but I presume they meant RSA can only be used to encrypt really short messages.

More typically to sign a message, RSA is used to sign a hash of the message.


No, they really meant you mustn't use textbook RSA. Textbook RSA is useful in a classroom (hence the name) to show how this idea works. But you can't (shouldn't) use it in production systems. In the real world use RSA OAEP to encrypt (or better, if you're an online system, don't use public key encryption at all, do key exchange with a Diffie-Hellman style scheme instead) and RSA PSS for signatures. Or don't use RSA, if you have an entirely brand new system, why not pick something more modern that has smaller keys and good CPU performance?


> Or don't use RSA, if you have an entirely brand new system, why not pick something more modern that has smaller keys and good CPU performance?

If you have (international) standards to adhere to, you are out of luck most of the time since they specify the exact schemes and cryptography required to adhere to the standard. Adoption of encryption/signature schemes is slow at best unfortunately.

If you do not; go wild. If you like big keys, get some 'quantum proof' public cryptography while you are at it.


> if you have an entirely brand new system, why not pick something more modern that has smaller keys and good CPU performance?

What do you suggest here, and will it work with X.509 certificates?


Any scheme that does signatures can be used with X.509. The way X.509 works a signature method just has an OID, and new OIDs can be minted by anyone in the hierarchy, so you could even invent your own if you were building an entirely new system.

For the Web PKI, the Baseline Requirements currently permit NIST P-256, P-384, or P-521 [sic] for "Elliptic curve" public key signatures, so that would let you do this for "SSL certificates" and plenty of people do but it's not compatible with older software, so if you care about that you need to have a plan B.

Depending your exact browser etcetera, if you go to google.com the certificate you're sent will be one of their P-256 certificates and your browser will verify both that this cert is genuine, and that the server can prove it knows the corresponding private key, using elliptic curve cryptography rather than RSA.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: