3

I have a project where I'd like to use public-key cryptography in both typical sign/verify situations and encrypt/decrypt situations. For example, I'd like to create a self-signed X.509 certificate for Bob (certificate request containing PubK.bob, signed by PrivK.bob to form Certificate.bob), and I'd also like to conduct transactions like:

  • Alice selects document key DocK, encrypts document DocK[document], computes PubK.bob[DocK], and sends PubK.bob[DocK] to Bob.

  • Bob uses PrivK.bob to recover DocK from PubK.bob[DocK], then decrypts DocK[document] to receive document from Alice.

However, the RSA keys that can be generated by crypto.subtle.generateKey (RSASSA-PKCS1-v1_5, RSA-PSS and RSA-OAEP) can only be used for either ['sign','verify'] or ['encrypt','decrypt'] -- if you try to generate a key with all four usages, you get Cannot create a key using the specified key usages.

Is there a subtle crypto reason not to use a single RSA keypair for both sign/verify and encrypt/decrypt operations?

Is there a standard way of dealing with this? A good way of doing it using WebCrypto? (I can imagine putting an encrypt-capable public key into Bob's certificate, along with the verify-capable one, but that seems redundant, and also makes my certificates a little different from what other certificate-management tools are used to dealing with.)

Dave M.
  • 133
  • 7
  • This comment: https://crypto.stackexchange.com/questions/32907/choosing-which-is-public-vs-private-key suggests that encrypt and sign can't be treated as equivalent, which I think is what I'm proposing to do (letting Bob sign his certificate with PubK.bob and letting Alice encrypt DocK as PubK.bob[DocK].) So maybe the answer really is "put Bob's public key for encrypting purposes into his certificate." – Dave M. Jan 26 '20 at 20:20
  • RSA is not for encryption. we prefer hybrid encryption. You can use RSA for Key Encapsulation Mechanism named RSA-KEM. – kelalaka Jan 26 '20 at 20:21
  • Thanks for that link -- that's exactly what I want to do (transfer AES keys from Alice to Bob using asymmetric crypto). – Dave M. Jan 26 '20 at 20:24
  • For using one key, see Using the same RSA keypair to sign and encrypt – kelalaka Jan 26 '20 at 20:25
  • While there may be very good reasons to simply use two certificates / private keys for authentication and for encryption, I don't think it is the responsibility of an API to not allow you such use cases. There certainly have been certs / keys that would be able to be used to implement both - so I don't think you'll find anything in standards to that effect. – Maarten Bodewes Jan 26 '20 at 21:54
  • @MaartenBodewes: FWIW rfc3279 (from 2002) 2.3.1 says "The use of a single [RSA] key for both signature and encryption purposes is not recommended, but is not forbidden" and describes KeyUsage values accordingly. I note 'recommended' there is not uppercase, although 3279 uses 2119's uppercase keywords extensively.. OTOH rfc4055 in 2005 uses distinct OIDs for PSS and OAEP, citing section 8 which says "[v1.5] has been employed for both key transport and digital signature without any known bad interactions, [but this] is not recommended in the future." – dave_thompson_085 Jan 27 '20 at 02:15

0 Answers0