Actually the signing process won't fail, seckey will be silently reduced by this call (and e*x output will be correct, I was wrong in my previous comment).
I think that if an invalid key is given, it should return an error. This is the behavior of the other signature functions, or secp256k1_ec_pubkey_create.

The remark was not about including it but rather about the numbering. Maybe you could add a link to the source CSV file in a comment ?
Also you dismissed test 4c (message should not be reduced), which is more relevant.

Yes

Yes

ok

You can check the output of secp256k1_eckey_pubkey_serialize which test against infinity

I think it's it's fine either way, given the twice-probable numbers are so rare. We can do it this way, no problem and I think it's certainly the 'safer' way. It's also fully compatible with batch verification. Of course, we should modify the spec to match our system.

BTW a thought occurred to me in my sleep regarding this, which is that if a third party is somehow able to crack sha256 far enough to produce e==0, then under sipa's construction they can trivially forge a signature since the key drops out of the signature curve equation (it becomes R = s*G). I suppose output == 0 (or output == group order) is not a particularly special number in sha256, so it would effectively require a full preimage break of sha256. But still, it is a curious property.

If we go with the approach of having invalid e values, then it would make sense to write the nonce-retry loop to cover this code as well.

When Schnorr one day makes it to hardware wallets, will the discrepancy be an issue? Hardware wallets may initially do things 'the BTC way' and rarely produce out-of-range e values, though it wouldn't hurt for them to opt in to restricting the range of e.

No problem, I just have to alter the spec to reflect the 'recommended' nonce generation algo and this is a fine way to do it.

Wait no, that is incorrect.

Ok.

e cannot be generated in a loop like k is. Generating k is generating a random number (blinding factor). The signer can use any method as long as nobody else can predict anything about k. So looping until you find a suitable value for k is doable.

One the other hand, e is a challenge. The whole point of the challenge is that it cannot be chosen by the signer. You should think of e as a random challenge generated by the verifier, but, because we don't want to proof to be interactive, everybody using the algorithm can decide they trust SHA256 to be as good as a randomly selected challenge by the verifier.

You might want to loop the whole signature procedure if computing e fails, starting with a new value for k, but at this point we might as well return false and let the caller deal with it.

The nonce can be generated any way really, these are just recommendations.

"You might want to loop the whole signature procedure if computing e fails, starting with a new value for k" -- yes, this is what I was imagining, that the rfc6979 counter should be incremented also if e fails. That way the signing is guaranteed to succeed for all msg32 and key.

Otherwise, the caller would be faced with a few undesirable options:

• give up and pass error message to user,
• somehow automatically malleate msg32 and try again,
• automatically fallback to a different noncefp instead of rfc6979 (instead use CSPRNG?) and keep retrying.

+1 I think reducing the public API to it's simplest form is important for reducing any potential attack surface.

ECDSA doesn't need the pubkey for signing, so that wouldn't make sense to pass it. The comment on attack surface makes no sense to me. The public key is public anyways, so in what case can I attack anything using the public key ?

I'm referring to the attack surface of the API itself, not the use of the public key. If you derive the public key from the private key that's provided, the attack surface is reduced by removing the case of providing a mismatching pub-priv keypair.

Regardless of attacks, it looks like it is not helpful to have pubkey argument in the first place:

• If the secp256k1_schnorr_sign caller would have ready access to a cached pubkey that would give a speed-up, but that doesn't seem to me like it will be a common situation:
• The main place this will get called (SignSchnorr in D2348) currently has to do the work of regenerating the pubkey itself.
• It doesn't seem useful to ever allow the caller to provide a different pubkey. In particular this function cannot be used for multi-key aggregation.
• It's inconsistent API anyway, see my first comment above.

Is the reason to keep this pubkey argument because of the speedup for other hypothetical codebases, or am I missing something? If so, it would be even more optimized to require the pubkey to be passed in compressed form (unsigned char * type, instead of secp256k1_pubkey * type).