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> _______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
