Okay, forgive my ignorance, but isn't the most common way of signing
data simply taking a cryptographic hash (SHA-1, RIPEMD-160, WHIRLPOOL,
etc.) and then encrypting it with a public-key technology? By
definition, isn't any public-key technology (including RSA) guaranteed
to make it impossible to determine the key used to encrypt data, even
if the key used to decrypt it is known?
If that's the case, then how is it possible to compromise the key used
to sign the data based on having a signature and the corresponding key?
In the case of an envelope (the other use I want to use the key pair
with), I'm relying on the same goal. I need to be sure that nobody can
determine the key used to encrypt the symmetric key, even given the
key used to decrypt it. That's the goal of public-key cryptography,
unless I'm that far off the mark.
Both of these separately are quite frequent uses for RSA (built into
OpenSSL), so my question is this: why does using the same key pair
weaken the system? If there is significant reason that it would,
putting an additional kilobyte into my client application isn't a huge
hardship; it just seems inelegant.
On 25-Jul-09, at 9:56 PM, David Schwartz wrote:
Jeremy R. wrote:
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.
Because it relies on special properties of the RSA internals where
those
properties are not intended to be, nor guaranteed to be, maintained
by the
outer algorithms.
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.
Not intentionally. But what's the guarantee that the messages sent
won't
compromise the public key? Do you know of any signature algorithm that
specifically guarantees that signatures will not compromise the
public key?
Is that the algorithm you're using? Note that RSA *directly* is not a
signature algorithm -- attempts to use RSA alone as a signature
algorithm
have been demonstrated to be insecure.
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.
Of course that's all you intend. But the issue is not what you
intend but
what you actually *do*.
You are using some signature algorithm X that uses RSA internally.
You are
assuming that X will have security properties that RSA will have.
That is
only a valid assumption if you can prove it. Can you do that? I'm
betting
you can't.
You cannot use RSA directly as a signature algorithm, see for example,
Daniel Belichenbacker's 1998 paper, John Hastad's attack on RSA, and
various
chosen-ciphertext attacks. You must use a signature algorithm that
uses RSA
internally. As a result of this, you gain the security properties of
that
outer algorithm, but you lose the ability to claim that known
properties of
RSA itself are properties of your algorithm unless you can show they
are.
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
