The previous code is correct and harmless to initialize an array with a
non-terminated character sequence using a string literal.
However, it requires exactly specifying the array size, which can be
cumbersome.
Also, GCC-15 may issue the -Wunterminated-string-initialization warning.
[1]
Fix both issues by using array initialization. This refactoring commit
does not change behavior.
[1] Example warning:
src/modules/schnorrsig/main_impl.h:48:46: error: initializer-string for array of 'unsigned char' is too long [-Werror=unterminated-string-initialization]
48 | static const unsigned char bip340_algo[13] = "BIP0340/nonce";
| ^~~~~~~~~~~~~~~
(cherry picked from commit fa67b6752d)
Conflicts:
src/testrand_impl.h (kept local name `secp256k1_testrand_seed`)
3a1c39625e rangeproof: add unit test for malleating single-value proofs (Andrew Poelstra)
Pull request description:
I was a bit confused reading `secp256k1_rangeproof_getheader_impl` because in the case of single-value proofs (`has_nz_range == 0`) some bits of the header are unconstrained. At first I thought this was a malleability vector. And I think I've had this same confusion in the past.
But in fact it is not a malleability vector because the whole header gets hashed into the proof.
Add a unit test to confirm this to reduce future confusion.
ACKs for top commit:
real-or-random:
utACK 3a1c39625e
Tree-SHA512: 9670cd04fcc0bb322d89c2c86ef863e13c29e4477dc6fecdda16b9a745e42a84f237a7ec387b3291f334e2a5c5806a8cc7cc00e40246ad5b36366be841195b4b
I was a bit confused reading `secp256k1_rangeproof_getheader_impl`
because in the case of single-value proofs (`has_nz_range == 0`) some
bits of the header are unconstrained. At first I thought this was a
malleability vector. And I think I've had this same confusion in the
past.
But in fact it is not a malleability vector because the whole header
gets hashed into the proof.
Add a unit test to confirm this to reduce future confusion.
Similar to speeding up serialization; in our parsing logic we did a
bunch of expensive stuff then expensively inverted it. Drop everything
except the essential checks and then memcpy.
`secp256k1_pedersen_commit_serialize` would call `_load` (which does a
sqrt to fully decompress the key, then a conditional negation based on
the flag), then check the Jacobian symbol of the resulting y-coordinate,
then re-serialize based on this.
Instead, don't do any of this stuff. Copy the flag directly out of the
internal representation and copy the x-coordinate directly out of the
internal representation.
Checked that none of the other _serialize methods in the modules do
this.
Fixes#293
The expression `G.decode('hex')` fails with the following error message
on Sage 9.5:
AttributeError: 'str' object has no attribute 'decode'
Fix that by converting the hex-string to bytes using `bytes.fromhex`.
"... neither can be equal to b." could suggest that the values are not
allowed to be identical, but what is meant here is that the mentioned
inputs shouldn't point to the same object.
Currently the `run_sqr` test doesn't do anything with the
result of the `fe_sqr` call. Improve that by checking that
the equation `(x+y)*(x-y) = x^2 - y^2` holds for some random
values y, as suggested in issue #1471 by real-or-random.
The existing loop for generating the x values is kept as-is.
`check_fe_equal` is a wrapper around `secp256k1_fe_equal` that takes
care of normalization. Since it doesn't check anything itself, the
CHECK macro is needed at the call-sites to actually ensure equality.
The previous implementation returns an off-curve point for the input t=0.
This rewrite addresses that issue by implicity returning the on-curve point
(d, sqrt(1 + b)), which is the point that the paper Indifferentiable Hashing
to Barreto–Naehrig Curves suggests returning in this case.
Note: At the moment it is cryptographically impossible for the input t to be 0.
This also splits the big "&&" expression into separate expressions. If
we ever see an assertion fail, the error message will tell it precisely
which one failed.
This gets rid of an untested code path. Resolves#1352.
secp256k1_ge_storage is a struct with two secp256k1_fe_storage fields.
The C standard allows the compiler to add padding between the fields and
at the end of the struct, but no sane compiler in the end would do this:
The only reason to add padding is to ensure alignment, but such padding
is never necessary between two fields of the same type.
Similarly, secp256k1_fe_storage is a struct with a single array of
uintXX_t. No padding is allowed between array elements. Again, C allows
the compiler to insert padding at the end of the struct, but there's no
absolute reason to do so in this case.
For the uintXX_t itself, this guaranteed to have no padding bits, i.e.,
it's guaranteed to have exactly XX bits.
So I claim that for any existing compiler in the real world,
sizeof(secp256k1_ge_storage) == 64.
Without this commit, the res[i][1] test vectors are unused. They were introduced
to test the correctness of scalar_sqr(x) and scalar_mul(x, x). These tests were
deleted as part of removing scalar_sqr in commit
5437e7bdfb.
e02f313b1f Add comment on length checks when parsing ECDSA sigs (Tim Ruffing)
Pull request description:
I claim the check can be removed but I don't want to touch this
stable and well-tested code.
On the way, we fix grammar in another comment.
ACKs for top commit:
sipa:
ACK e02f313b1f
RandyMcMillan:
ACK e02f313
Tree-SHA512: f82691a8f5db82a1e9683e52ce8e952ebd56b476a2817c5a876ce4638254b7b4ac93175318fb59598ed5532f33433951d75afea03724ef4419c3e1bd12ca8c20
This define was seemingly introduced for VERIFY mode code with side
effects (for setup purposes), that should just be executed without any
checks. The same can be achieved by putting it in an `#if VERIFY` block,
so we can remove it.
By providing an uppercase variant of these verification functions, it is
better visible that it is test code and surrounding `#ifdef VERIFY`
blocks can be removed (if there is no other code around that could
remain in production mode), as they don't serve their purpose any more.
At some places intentional blank lines are inserted for grouping and
better readadbility.
