I have a program A which needs to send messages to several instances of program B (B1, B2, etc...). The messages must be encrypted, and also signed. Which means only Bn instances can decode, and they must be sure that the messages come from A.

Also, B1 should not be able to send messages to B2, etc. ...

Theoretically, it should be possible to use a single RSA key pair, with a key for A and a key for Bn. Once decoded by Bn, if the recovered message is validated (such as by a hash function), it must have been sent by A which did not disclose its key to anybody. In that case, both keys are private (which means they have to be exchanged in a secure channel)

  1. Is this recommended or is there a strong argument in favor of having separate encryption and signing steps with independent key pairs?

  2. Practically, in the Crypto++ library, the PrivateKey class also contains the public key. Is there a way to load a private key only?

  • Re 2: Given any standard representation of the private key it is trivial to recover the public key and thus it wouldn't make sense to hide it here. Additionally it would make the user experience much worse because you usually generate and store a private key to then send someone a public key. – SEJPM May 17 '16 at 15:45
  • I don't yet understand what you mean by "a single RSA key pair, with a key for A and a key for B" (I use B for your Bn). Do you mean the pair (e,n) and (d,n), with the same n, of A, i.e. the public and private key of A respectively, and B doesn't have any keys of its own or what? Wouldn't A need B's public key in order to send something encrypted to it at all? – Mok-Kong Shen May 17 '16 at 15:46
  • At the heart of RSA, a key is neither public nor private, there are just to related keys (ie a key pair). It's the use which makes them public or private. For encryption, the receiver key is private. For signing, the sender key is private. If you use the same keys for a signed encrypted message, both should not be disclosed and are to be considered private. This is why I'm using the term "key pair" instead of "public" and "private" keys. – galinette May 17 '16 at 16:32
  • But "a pair" means 2 pieces, isn't it? So that the receiver can read an encrypted message, the sender has to use receiver's public key. If the sender has to sign anything, he has to use his private key. So that the receiver can verify sender's signature, he has to use sender's public key. So with the requirements of your OP, there are a total of 3 keys involved, not 2 or just 1 (in the common case of no signature). There are certainly diverse ways to achieve the same goal, One way I use is in Example 3S of s13.zetaboards.com/Crypto/topic/7234475/1/ which employs RSA alone (nothing else). – Mok-Kong Shen May 17 '16 at 20:11

I can answer your first question. It's not recommended to use the same RSA key pair for signing and encryption. The reason for that may be differences in expiration or key-escrow (e.g. sometimes organizations will want to back up your encryption key (confidentiality), but you do not want them to have your signing key(non-repudiation)). There's also a long shot possibility that if you blindly sign messages without checking or hashing the message a user can decrypt the message (signing applies the private key on a message). This is quite rare and would result from atypical application development that has bad design anyway.

Also, if you can manage one key, why not two?

  • The A key(s) would be the sold product, and one of the options was to store it inside a hardware dongle, where we have only 4kB space... Also, the implementation would be simpler (hash then encrypt). But if this is a bad idea we will take another option. – galinette May 17 '16 at 11:11
  • What if you add a hash to the message, and encrypt the whole, and if both A and B keep their key secret? Is this flawed? – galinette May 17 '16 at 16:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.