Randomized hashing

[Peter Lebbing]

On 27/11/14 13:04, NdK wrote:
> (note that r is not signed, as the rhash scheme suggests and the paper 
> confirms!)

> "In contrast to a previous proposal by the same authors, the salt r does not
>  need to be included under the signature."

I read this quite differently. I read it as that 'r' is not included in the
signature, that is, what is signed is still just the hash. It seems profoundly
silly to not include it in the signed data, for the reasons you mention. Can you
give a quote that actually says 'r' is not included in the signed data?

> At a first glance, it would be safer to have r *inside* the signature.

Oh, I agree, I already thought that might close any 'r'-swapping security
issues, if there would be any; just like you can include the hash
algorithm in the signature to prevent swapping it out for a weaker one. But when
swapping 'r''s does not actually create any security issues, it just makes
things needlessly complicated. To use your smartcard example: the smartcard only
accepts a specifically formatted message. If you change that message to now
include a new value, you would need a new smartcard. Furthermore, the size of
'r' might pose a problem; it's a significant addition to the data structure that
is signed.


> Maybe it's just a performance issue?

I suppose also simplicity, verifiability, implementation cost...


The rest seems unrelated to randomized hashing except for what I already
mentioned: that including 'r' in the signature would mean you can't use an
existing OpenPGP card. But I'll answer anyway.

> And IMVHO it's better if the padding is generated by the card, depending on
> the operation being performed

For RSA signatures, the padding is constant; there's nothing to generate. For
RSA decryption, the input is generated by the encrypting party; there's nothing
to generate on decryption.

> while the op is anyway 'RSA encrypt', the padding should be different if
> you're signing an hash or exchanging a session key. Failing to let the card
> do the padding could lead to exposure of the private key, IIRC.

I think you mean "RSA decrypt", for signing you use the "RSA decrypt" primitive,
just as you use to decrypt a session key.

But this is all already done in the OpenPGP card. It checks the data to be
signed conforms to PKCS#1; it is optional to check the DigestInfo, but the rest
of the data structure already differentiates it from an encrypted session key.
It will only let you sign with the "Signing" and "Authentication" keys.
Likewise, it checks that the output of decrypting with the "Decryption" key
conforms to the PKCS#1 format, so you can't fool it into a signing operation either.

Failing to let the card check the padding could lead to major issues. But this
is a solved problem and unrelated to randomized hashing. I don't understand the
relevance.

HTH,

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at <http://digitalbrains.com/2012/openpgp-key-peter>