bip-schnorr: Add k values to test-vectors
Coding-Enthusiast opened this issue · 8 comments
Usually EC signature test vectors also contain the ephemeral key (k) so that developers can use the tests no matter how they compute k (eg. random or using RFC-6979 instead of tagged hash).
Hm, yes. I think there are two sides here. The drawback of having k in the test vectors is that this potentially encourages people (including us in the pseudocode) to write signing algorithms that accept k as a parameter. If people need k, can't they compute it on their own, and then still use the current vectors?
The drawback of having k in the test vectors is that this potentially encourages people (including us in the pseudocode) to write signing algorithms that accept k as a parameter.
I honestly don't see anything wrong with an internal method that separates concerns and improves testability.
If people need k, can't they compute it on their own, and then still use the current vectors?
One point of having test vectors is to have already-computed values that are also viewed and tested by other implementations so there is no chance of them being wrong.
The drawback of having k in the test vectors is that this potentially encourages people (including us in the pseudocode) to write signing algorithms that accept k as a parameter.
I honestly don't see anything wrong with an internal method that separates concerns and improves testability.
Indeed, there's nothing wrong with an internal method. My point is not that all ways to use k test vectors are bad, but some are.
If people need k, can't they compute it on their own, and then still use the current vectors?
One point of having test vectors is to have already-computed values that are also viewed and tested by other implementations so there is no chance of them being wrong.
Even if we don't provide k, and people will compute a wrong k on their own, then the current test vectors will fail.
@sipa @jonasnick @gmaxwell opinions?
I think it's pretty standard practice to add intermediary values to test vectors, to aid with development. There is of course a concern that they're misinterpreted as inputs, but that can be addressed.
The test vectors that test signing are setup to use the derandomized nonce scheme so they already do, effectively.
So only use of them is to help bisect a disagreement, in which adjusting the demo codebase to print k is what's called for. That could be done generally, stick prints in it at every branch point and maybe comment them out.
As an implementer, if the vectors provided k I'd feel obligated to use provide an interface that takes it. Not everyone is going to realize you can make a wrapper to hide it.
So only use of them is to help bisect a disagreement, in which adjusting the demo codebase to print k is what's called for. That could be done generally, stick prints in it at every branch point and maybe comment them out.
I like that idea.