Support private key encryption, public key decryption
alexbilbie opened this issue · comments
I have a scenario whereby I want an actor to encrypt a message with a private key, and anyone with the public key can decrypt the message.
Currently this library only supports public key encryption and private key decryption.
I have a scenario whereby I want an actor to encrypt a message with a private key, and anyone with the public key can decrypt the message.
Can you explain such a scenario to me? From my experience, "Encrypt with private key, decrypt with public key" isn't a common use case. Often, it's used to shoehorn in digital signatures (encrypt a hash with the private key, decrypt it with a public key, verify the hash of the message) in libraries that don't support them.
The goal of EasyRSA is to be as simple as possible and secure by default. It's not immediately obvious what security concerns this feature would introduce. For example:
- Is it safe to use the same key for public-key encryption and private-key encryption?
- Is it safe to use the same key for digital signatures and private-key encryption?
- What padding mode should be used? RSAES-OAEP or RSASSA-PSS?
- Is MGF1-SHA256 still adequate?
- What sort of cross-protocol attacks do we need to beware of?
- Can all of the above be addressed by phpseclib, or do we have to write low-level code to handle these concerns as well?
The scenario is as described.
The payload needs to be encrypted (and transport-layer security over TLS isn't a guarantee), and n-number of parties will have the public key and can decrypt the payload.
In answer to your questions:
- The public key would never be used for encryption, only decryption.
- I can't answer that, but the private key would be used for digital signatures too
- openssl_private_encrypt doesn't support either
I'm not in a knowledgable enough position to answer 4, 5 and 6.
The payload needs to be encrypted (and transport-layer security over TLS isn't a guarantee), and n-number of parties will have the public key and can decrypt the payload.
The public key is just that, public. A bad actor who has the public key can go "hey I'll take that thanks", which means you're just transmitting cleartext with a particularly high CPU overhead.
If TLS isn't a guarantee, then you don't control your server, and if you don't control your server then you can't trust your proposed solution either, assuming it was secure.
Perhaps I'm going down the wrong path.
Thank you for your thoughts.
In this case, I would just give the server multiple public keys and encrypt it with each recipient's public key -- and then each recipient can just decrypt with their private key.