Hacker News new | ask | show | jobs
by aasasd 2582 days ago
> using the same key for signing and encryption is catastrophic for general public key schemes

Weird thing, I'm fifteen years in web programming with an interest in crypto, but it's the first time I hear that, at least in such categorical form. On the contrary, it's usually “public-key crypto allows you to have both this and that.”

2 comments

The bit being referred to is how signing and encryption can be inverse operations of each other in some schemes. The canonical example is textbook RSA. Signing is the same operation/math as decryption. Likewise, verifying signatures and encryption are the same operation/math. So, if one used textbook RSA for both things under the same key pair, then an encrypted blob under public key PK could be decrypted if you can get the same person to sign that same blob using secret key SK. In other words, in textbook RSA sign(private, encrypt(public, message)) == message.

There are things that make this less trivial to exploit for non-textbook cases. But, either way, it is generally easier to mostly go with “don’t use the same key for both signing and encryption” so you don’t have to do a bunch of stuff to figure out if a given construction is safe. If Filippo is supporting RSA ssh keys, I’d love a post walking through the way to prove that reusing RSA keys turns out to be safe if done carefully/thoughtfully.

Almost every scheme that does signing and encryption has separate keys for each (even in cases like GnuPG which pretends to have a single key).

In fact, TFA explicitly mentions an example of this causing a security problem[1]. In addition, not all public-key cryptosystems can be used to create both encryption and signing primitives[2].

[1]: https://eprint.iacr.org/2011/615.pdf [2]: https://www.cs.cornell.edu/courses/cs5430/2015sp/notes/rsa_s...