On Mon, Feb 18, 2013 at 2:30 PM, Niels Möller <[email protected]> wrote: >> So has this particular case higher probability than k being randomly >> chosen to be 3? (I've not seen this test anywhere else, that's why I'd >> be curious on why you mention this test). > If the verify code is done as > P1 = u1*G > P2 = u2*Y > P = P1 + P2 > then an equivalent test is needed there, sine we have to do > if (P1 == P2) > P = ecc_dup (P1) > else > P = ecc_add(P1 ,P2) > And if we do this test, it's trivial to extend it to > > if (P1 == P2) > { > P = ecc_dup (P1) > output private key (it's -u2/u1 (mod q) or something like that)
That's an interesting case :) Several implementations do not include that case. I was told of a fault injection attack in hardware implementations to force them reach that state (and do an addition instead), but that wouldn't be of much importance here (since it is a verification function). I don't know if caring about that case makes sense. At best I think that looks like the definition for the unlikely() macro. regards, Nikos _______________________________________________ nettle-bugs mailing list [email protected] http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
