Jeremy R.: > Thanks for your reply, first of all. I'm by no means an expert in > cryptography (and obviously not on OpenSSL), and I'd appreciate any > insight you can provide.
So that's a good reason not to invent your own solution. > Yes, but what I have neglected to mention is that this information > will be broadcast > from my server to all instances of the client application. > Therefore, anyone with access > to a copy of the client application will be able to decrypt the > message, period. Or anyone who gets the public key off the wire. > I think you misunderstand. My message format works like this: my > application's data is already signed by the server's private key. As a > result, it has a copy of the public key. The public and private keys > are part of a key pair. From what I understand, RSA makes no > distinction between which key is public and which is private, only > that data encrypted with one can only be decrypted with the other. > > So I already have a key pair established, and the client is only aware > of one key, which is currently used only for signature verification. > Could I not also use that key to decrypt the symmetric message key? Yes, if you could show that no attacker could have that public key. But I don't think you can show that. > The corresponding key, which only the server has, and is currently > termed the "private key", is not known to the client. It is my > understanding, then, that I should be able to use this key to encrypt > my message, and that message will only be able to be decrypted by the > client's key. > > Why should I need to create a second RSA key pair, when I already have > a perfectly good 4096-bit key pair between the client and server > applications? Because you probably don't have a way to sign the data from the server that is guaranteed not to reveal the public key. For example, the following would be a perfectly reasonable RSA signature algorithm: 1) Take in the public key, private key, and data to be signed. 2) Checksum the data to be signed. 3) Sign the checksum with the private key. 4) Create a structure including the signature, checksum, and public key. Output that as the signature. This would be a perfectly reasonable signature algorithm, but it would also reveal the public key to the public. Any attacker possession such a signature could trivially extract the public key -- since it's in the signature. You need to prove that no attacker can have the public key to use this method. If you can do that, then more power to you. But what I'm trying to say is that I don't think you can. > The public key (the client's key) will only be distributed with the > client application. Right, but it may also be revealed by your wire protocol. If you trust the wire, why are you bothering with all this trouble? If you don't trust the wire, how can you be sure the public key will only be distributed with the client application? > In the event that the client's key is compromised, I may implement a > re-keying > mechanism that allows the server to give the clients a new key. That assumes you know the public key is compromised. DS ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
