Randomized hashing

[NdK]

Il 27/11/2014 14:45, Peter Lebbing ha scritto:
> 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?
When it says that 'r' have to be sent separately. It's 'included' only 
indirectly in the hash calculation.

>> 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.
I don't understand you.
I said that if you have a short message (less than hash len) it's 
trivial for an attacker to fix a new M' and calculate a new r' value 
that satisfies r xor M == r' xor M' . It gets harder with longer messages.

> 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.
Depends on how strict the checking is.
E.g., if the smartcard only uses the raw buffer you pass it (just adding 
the needed padding before signing) and is able to accept SHA-512, then 
you could just use SHA-256 and append 256bits of 'r' w/o having to 
change the smartcard: it sees 512bits and pads 'em like in SHA-512. 
That's one of the reasons I like the cards that do the last hash round more.

>> Maybe it's just a performance issue?
> I suppose also simplicity, verifiability, implementation cost...
Probably.

> 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.
I didn't study OpenPGP card protocol enough.

>> 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.
Yup. Terminology slip. The RSA op involving the private key, so 
sign/decrypt.

> 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.
Ok.

BYtE,
  Diego