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