<div dir="ltr"><div class="gmail_default" style="font-size:small">  As folk know, I have been working on various threshold crypto schemes. I recently realized a rather stunning anti-symmetry akin to conservation of well something.<br></div><div class="gmail_default"><br></div><div class="gmail_default">Recall that if {A, a}, {B,b} are {public, private} ECDH keypairs that we can construct a new keypair {Z, z} as follows:</div><div class="gmail_default"><br></div><div class="gmail_default">z = a+b mod Q</div><div class="gmail_default">Z = A+B</div><div class="gmail_default"><br></div><div class="gmail_default">(where Q is the order of the prime subgroup.)</div><div class="gmail_default"><br></div><div class="gmail_default">Proof:</div><div class="gmail_default"><br></div><div class="gmail_default">A = a.P, B = b.P => </div><div class="gmail_default">Z = A+B = a.P + b.P = (a+b).P  = ( a+b mod Q).P + nQ.P = z.P</div><div class="gmail_default"><br></div><div class="gmail_default">Now for the interesting part. There seems to be a conservation of security law going on.</div><div class="gmail_default"><br></div><div class="gmail_default">The unguessability of z is the maximum of the unguessability of a, b. If we design the protocol right with appropriate hashes to avoid stride issues, we can get the  unguessability to be the sum of the 

unguessability of a, b (with a ceiling of course)</div><div class="gmail_default"><br></div><div class="gmail_default">Bottom line, using this approach to generating private keys means that you can mitigate many weak key attacks that are real issues in deployed systems.</div><div class="gmail_default"><br></div><div class="gmail_default"><br></div><div class="gmail_default">But now lest see what happens when you try to play games on the public key side to achieve integrity. It turns out that the trustworthiness of the composite public key is the lesser of the trustworthiness of A, B.</div><div class="gmail_default"><br></div><div class="gmail_default">Lets say Alice and Bob both contribute keys to a joint signature key Z and Alice goes first. Bob can determine the value Z buy picking B = Z-A.</div><div class="gmail_default"><br></div><div class="gmail_default">This is the basis for rogue key attacks in threshold signatures.</div><div class="gmail_default"><br></div><div class="gmail_default"><br></div><div class="gmail_default">So it seems like there is a conservation thing going on. Using naive approaches, we get the maximum trustworthiness on the private key side and the minimum on the public key side.</div><div class="gmail_default"><br></div><div class="gmail_default">Of course the control here is to either use a key generation approach that constrains Bob in some way (e.g. he has to commit to his value B before he sees A) or we have to limit the functionality we provide. I do not support threshold signatures created by people specifying their own independently generated keys. I only support generating a key pair and then splitting it. So I effectively eliminate the attack by ruling it out as a security control being provided.</div><div class="gmail_default"><br></div></div>