* To protect against differential power analysis, a different way of
> mixing in this randomness is used (masking the private key completely
> with randomness before continuing, rather than hashing them together,
> which is known in the literature to be vulnerable to DPA in some
> scenarios).
>
I
> Correct, except that the speedup from is_even(y) over
is_quadratic_residue(y) affects signing and not keypair generation.
Isn't this the same thing since in the spec it generates the public key in
the signing algorithm? If you pre-generate public key and pass it in there
would be no speedup to s
> Let me put change (1) into my own words.
Correct, except that the speedup from is_even(y) over is_quadratic_residue(y)
affects signing and not keypair generation.
> With change (2), I feel like including this auxiliary random data is overkill
> for the spec. [...] I feel similarly about hashing
Hi Pieter,
Let me put change (1) into my own words. We are already computing affine
coordinates since we store public keys as the affine x-coordinate. It is
faster to compute is_even(y) than is_quadratic_residue(y) so we get a speed
up here during keypair generation. In the verification algorithm,
Hello list,
Despite saying earlier that I expected no further semantical changes
to BIP 340-342, I've just opened
https://github.com/bitcoin/bips/pull/893 to make a number of small
changes that I believe are still worth making.
1. Even public keys
Only one change affects the validation rules: th
