wk at gnupg
Jun 9, 2011, 12:23 AM
Post #1 of 9
(998 views)
Permalink
|
Hi,
I reworked the PSS code in the uene-pss branch and merged it with
master. I did this similar to my changes for OAEP to help reading and
comparing the code to the the specs.
I see one problem with it. According to rfc-3447 we are doing this
+-----------+
| M |
+-----------+
|
V
Hash
|
V
+--------+----------+----------+
M' = |Padding1| mHash | salt |
+--------+----------+----------+
[....]
Out input is the actual message; for example:
{ "(data\n (flags pss)\n"
" (hash sha1 #11223344556677889900AABBCCDDEEFF10203040#))\n",
However we don't consider #1122...# a hash value but the actual message
to be signed. If we really want to do this it would be better to use a
new construct than this "(hash ALGO DIGEST)" pattern. However I dount
that it is a good idea. We have always used gcry_pk_sign in the way
that the caller passed the hash of the message (here mHash) to it and
not the entire message. Many applications have large messages and it
should be possigble to stream them.
Having said this, I'd propose to change the semantics and require that
mHash is passed to gcry_pk_sign and gcry_pk_verify if PSS is used.
rfc-3447 actually allows this:
3. Without compromising the security proof for RSASSA-PSS, one may
perform steps 1 and 2 of EMSA-PSS-ENCODE and EMSA-PSS-VERIFY (the
application of the hash function to the message) outside the
module that computes the rest of the signature operation, so that
mHash rather than the message M itself is input to the module. In
[...]
Shall I do these changes?
I'd also like to see a way to test at least the verification of a PSS
message against a known test vector. Are there any real world
application of PSS or even test vectors?
Salam-Shalom,
Werner
--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel
|
