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
    Commented May 17, 2016 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? Commented May 17, 2016 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
    Commented May 17, 2016 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). Commented May 17, 2016 at 20:11

1 Answer 1


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
    Commented May 17, 2016 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
    Commented May 17, 2016 at 16:36

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .