ni...@lysator.liu.se (Niels Möller) writes:
> I've added these changes on a branch merge-pss in the main repo,
> together with some smaller post-merge cleanups.
Thank you!
> I'm considering renaming some of the pss files and functions to use a
> "pkcs1" prefix, and perhaps move declarations to pkcs1.h, do you think
> that's appropriate?
Considering that PSS is part of PKCS#1, I agree to move the declaration
to pkcs1.h. On the other hand, some people refer to the PKCS#1 v1.5
padding as "pkcs1", which might cause confusion.
>> "These variants
>> take advantage of a randomly choosen salt value, which could enhance the
>> security by causing output to be different for equivalent inputs.
>>
>> However, assuming the same security level as inverting the @acronym{RSA}
>> algorithm, a longer salt value does not always mean a better security
>> @uref{http://www.iacr.org/archive/eurocrypt2002/23320268/coron.pdf}.
>> The typical choices of the length are between 0 and the digest size of
>> the underlying hash function."
>
> That's better, but still not crystal clear. In what scenarios does the
> salt provide additional security? If the attacker gets to see signatures
> but not the corresponding messages?
I am no expert in math, but having a look at the original paper[1]
(section 1.4), I got an impression that introducing salt does not
directly correspond to any practical attacks, but is to ensure the same
level of security with smaller RSA modulus (than the one required by
zero-salt version).
ni...@lysator.liu.se (Niels Möller) writes:
> I've tried to actually enable use of this function, by replacing
> pss_encode_mgf1 by pss_encode_mgf1_for_test below in the pss-test.c
> file.
I am sorry for forgetting to update the test code after introducing the
valgrind check.
> It's curious that pkcs#1 v1.5 signatures don't have this particular
> issue, since v1.5 padding always puts the most significant 1 bit at the
> same position.
>
> So I guess we'll unfortunately have to take out the valgrind magic
> from this test.
That's unfortunate, but I can't think of any other idea either.
Footnotes:
[1] http://web.cs.ucdavis.edu/~rogaway/papers/exact.pdf
Regards,
--
Daiki Ueno
_______________________________________________
nettle-bugs mailing list
nettle-bugs@lists.lysator.liu.se
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
