On 27-Jul-09, at 9:59 PM, Dave Thompson wrote:
From: owner-openssl-us...@openssl.org On Behalf Of David Schwartz
Sent: Monday, 27 July, 2009 12:06
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.
For example, it's not true at all for DSA (aka DSS).
And although in raw RSA encrypt/decrypt and sign/verify are
mathematically equivalent, the common schemes built on RSA
(PKCS1 type1 and PSS for sign, type2 and OAEP for encrypt)
are different, so you can't just reuse the code.
In addition to David Schwartz' concern about direct exposure
of the pubkey, since PKC designs in general don't strive to
protect it, RSA (pub)keys frequently have a small pubexpt
since this is more efficient (public side doesn't know factors)
and for usual uses it is exposed anyway. RSA keys generated by
openssl do this, and so do many (most?) other common systems.
Then only the modulus needs to be found to break your scheme.
Now that I did not know. That's interesting to learn.
I don't think the amount of data Eve could feasibly collect is enough
to do that, but IANAMathematician so get a real expert if you care.
But if Mallory can detect any difference (even timing) for purported
keytransfer OR signature values exceeding the modulus or not, he can
determine the key in probably a few thousand probes.
If you do your own generation with a fullsize random pubexpt,
you might be safe, but pubkey=client operations will be MUCH slower
for a large key (as you said you use), if that matters.
Another idea: you're not using the benefit of PKC encryption
(unknown to one). Why not just symm-encrypt the data? You
could use (a hash of) the RSA pubkey and it would be efficient,
but still at risk if the pubkey is exposed or analyzed.
Alternatively if you (can) have other "secret" data in (or with)
your client you can use that; it doesn't need to have a specific
internal structure like RSA (or some other PKC) keys do.
Well, envelopes do have the benefit that it's only the symmetric key
that's encrypted, so it shouldn't be that slow to decrypt the 32 bytes
for the symmetric key. But yes, if I would have to create a second key
pair anyhow, I may simply create a shared symmetric key instead – the
signature should be enough to prevent forgery (right? I think that's
the point of signatures). That was my original approach, until the
thought of using envelopes occurred to me, since I was already
creating a key pair. If reusing this key pair is really a bad idea, as
is apparently the case (two people who know more about cryptography
than me is enough to make me fairly sure of that), then adding another
32 bytes to my application isn't the end of the world by any means.
By the way, as far as IVs go, I'm currently generating a random IV and
tacking that onto the beginning of the message, which I believe is
fairly common. Is there anything wrong with this? Should I be using a
static IV (I would think that would be less secure, but I'm not an
expert).
PS- the correct spelling for the attack on PKCS#1 type2 padding
is Bleichenbacher, if you want to find out about it.
Oh, and in case I haven't said it before, thank you both for your help
– it's greatly appreciated.
