On 25-Jul-09, at 6:30 AM, David Schwartz wrote:
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.
It's also a good reason to understand why my solution isn't valid
(assuming it isn't) so that I have the understanding to correctly
engineer future programs that use cryptography.
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.
The public key is not transmitted over the wire – all clients are
known to have the key in advance (it's built in), so it will never be
transmitted as a part of the message.
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.
As the public key will already exist on the clients, I only intend to
send the
encrypted checksum, not the public key.
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
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
