<div dir="ltr"><pre style="white-space:pre-wrap">>PSS is completely incompatible with blind signatures because the signer
>must provide randomness.  You could maybe fix this with some sort of cut
>& choose or zero knowledge scheme for choosing the randomness, but..
>
>All the security proofs for RSA blind signatures just replace PSS with
>FDH anyways.  In fact, CloudFlare might not need a FDH for verification
>because hash factoring attacks sound implausible, but worse..</pre><pre style="white-space:pre-wrap"><font face="sans-serif">Yeah this is a mistake in the specification - thanks for pointing it out. We planned to use a FDH hash for this operation.</font></pre><pre style="white-space:pre-wrap"><span style="color:rgb(33,33,33);white-space:normal">>There is nothing about how the blinding factors get chosen!</span><br class="gmail_msg" style="color:rgb(33,33,33);white-space:normal">><br class="gmail_msg" style="color:rgb(33,33,33);white-space:normal"><span style="color:rgb(33,33,33);white-space:normal">>There are absolutely brutal deanonymization attack on blind signatures</span><br class="gmail_msg" style="color:rgb(33,33,33);white-space:normal"><span style="color:rgb(33,33,33);white-space:normal">>where the blinding factor is not created using a full domain PRNG,</span><br class="gmail_msg" style="color:rgb(33,33,33);white-space:normal"><span style="color:rgb(33,33,33);white-space:normal">>probably your FDH for the signature.  In this case, I really mean full</span><br class="gmail_msg" style="color:rgb(33,33,33);white-space:normal"><span style="color:rgb(33,33,33);white-space:normal">>domain where you (1) generate a random 2048 bit number, (2) test that</span><br class="gmail_msg" style="color:rgb(33,33,33);white-space:normal"><span style="color:rgb(33,33,33);white-space:normal">>it's less than the RSA modulus n, and (3) throw it away and start again</span><br class="gmail_msg" style="color:rgb(33,33,33);white-space:normal"><span style="color:rgb(33,33,33);white-space:normal">>if it is not.  On average, this requires generating two 2048 bit numbers</span><br class="gmail_msg" style="color:rgb(33,33,33);white-space:normal"><span style="color:rgb(33,33,33);white-space:normal">>because n should lie half way between 2^2047 and 2^2048, but obviously a</span><br class="gmail_msg" style="color:rgb(33,33,33);white-space:normal"><span style="color:rgb(33,33,33);white-space:normal">>malicious exchange could pick a small n to make the clients do a bit</span><br class="gmail_msg" style="color:rgb(33,33,33);white-space:normal"><span style="color:rgb(33,33,33);white-space:normal">>more work.</span></pre><pre style="white-space:pre-wrap"><span style="color:rgb(33,33,33);white-space:normal"><font face="sans-serif">I agree that the blinding factors should be chosen carefully and this is something that is currently being built into the extension we're developing. I'll add this explicitly to the document as well as it is an important consideration. </font></span></pre><pre style="white-space:pre-wrap"><span style="color:rgb(33,33,33);white-space:normal"><font face="sans-serif">Regarding the possibility of a malicious edge using a small modulus n. Given that there will only be one public signing key available at any time and since this will be publicly available (and checked by the clients using the CT log) it will be difficult to get away with this without clients realising.</font></span></pre><pre style="white-space:pre-wrap">>There are more issues with blind Schnorr signatures, but they look
>susceptible to this attack too.  The blind BLS signature scheme somes
>with different concerns :</pre><pre style="white-space:pre-wrap"><font face="sans-serif">Thanks for the update on the security of BLS signatures. I haven't thought about these too much and they were added to the spec more as just an afterthought in case we wanted to explore an alternative to RSA. I had a conversation with Filippo a while ago and he mentioned that Tanja thought that going with RSA for now was probably the best idea due to the relative simplicity of the scheme. I'm open to re-engaging in the conversation however and if there are genuine attacks on this scheme then we'd have to consider something else.</font></pre></div>