On 27-Jul-09, at 12:05 PM, David Schwartz wrote:
Jeremy R. wrote:
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?
Yes, that's the most common way. But it is not a general property of
public-key encryption. It just happens to be true of RSA and RSA just
happens to be popular. But you cannot conclude automatically that a
system
has the properties of its components.
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?
Yes, but that is valid for encryption only because it is an
intentional
property of encryption and any scheme that didn't have it would be
useless.
But if it's so for signing, it's only an accidental property. So it
may or
may not be maintained by the system.
Did you understand my example of a system that bundles the public
key with
the signature? Why would that not be a perfectly valid signature
scheme?
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?
I guess you're not reading what I'm writing. Let's try it again.
Consider an RSA signature scheme that bundles the public key in with
the
signature. This would be a perfectly valid signature scheme and
would meet
all of the general security properties of public key signature
schemes. Yet
a "signature" in this scheme *would* compromise the public key.
Are you with me so far?
So there is no automatic guarantee that a signature scheme that
happens to
use RSA internally happens to preserve this one particular security
property
of RSA because it is not typically relevent to signature schemes.
I understand, but realize that I am coding the application, so I can
choose to use a signature scheme that does not include the public 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.
That's the goal of public key encryption. The goal of public key
signatures
is simply to ensure the signature cannot be forged and the secret
key is not
compromised. Not "compromising" the public key is not generally a
goal of
public key signature algorithms. So you need to find a complete
signature
algorithm that is guaranteed to have this property.
But RSA, from what I understand, doesn't by definition make one key
"public" and the other "private". Unless I'm really mistaken, you
create a key pair, whereby data encrypted with either can be decrypted
only by the other. I think it's only by convention that one is private
and the other is public.
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.
You don't get to make that decision. Either not compromising the
public key
is a property of the full signature algorithm you are using or it's
not. If
it's not, you cannot "deduce" the property. You can only rely on
guaranteed
properties of the outer, entire algorithm you are using.
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
