Rene Struik <rstruik....@gmail.com> wrote: > The papers [1] and [2] may be of interest here. In [2], Section 3.3, Alfred > Menezes and Neil Koblitz compare FDH-hash RSA signatures, PSS (lots of > randomness in the salt), and a scheme by Wang and Katz that only contains > one bit of randomness with signing and is claimed to have tight reductions > (see also [1]) and argue a "Pass on PSS". > > [1] Signature Schemes - Efficient, with Tight Security Reductions (Jonathan > Katz, Nan Wang, CCCS 2003). Available from > https://www.cs.umd.edu/~jkatz/papers/CCCS03_sigs.pdf > [2] Provable Security, Another Look at (Alfred Menezes, Neal Koblitz, IACR > ePrint 2004-152). Available from https://eprint.iacr.org/2004/152
Right, these are the papers I read that made me start to think it might actually be dumb to randomize the salt when generating a PSS signature. It seems like the randomization is purely needed purely as an artifact of the method used in the security reduction, and seems unlikely to actually improve security. In fact, it would hurt security because it adds significant complexity to PSS signature generation and provides a means to efficiently smuggle secrets out of the security module containing the RSA private key. Thus, an implementer of RSA-PSS signature generation who wants to maximize security likely won't want to randomize the salt. Another interesting paper is [3], which says "However, since PSS (with random salt of arbitrary length) is at least as secure as FDH, we obtain as a corollary from Section 3 a tight security proof from lossiness to the security of PSS, with random salt of arbitrary (possibly zero) length." At the time I suggested [4] that the salt length be fixed to the length of the digest function for RSA PSS signatures in TLS, I wasn't aware of all the research that had been done. Unfortunately, my under-informed suggestion is what is currently prescribed in the current draft. I'd like to make sure that whatever the spec ultimately prescribes is actually motivated by a current scientific argument, even if it means I have to admit I was wrong. [3] Optimal Security Proofs for Full Domain Hash, Revisited (Saqib A. Kakvi and Eike Kiltz). Available from https://www.iacr.org/archive/eurocrypt2012/72370533/72370533.pdf. [4] https://www.ietf.org/mail-archive/web/tls/current/msg15601.html Cheers, Brian -- https://briansmith.org/ _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
