Endian related failure #442

Running the following on little endian systems results in success, on big endian systems failure. Code provided below, along with platform output: test.cpp.txt

Little endian output:

$ ./a.out
Tests completed successfully.

Big endian output:

$ ./a.out
Signing: signature mismatch, expected [4832febef8b31c7c922a15cb4063a43ab69b099bba765e24facef50dfbb4d057928ed5c6b6886562c2fe6972fd7c7f462e557129067542cce6b37d72e5ea5037] not matched by [7c1cb3f8befe32483aa46340cb152a92245e76ba9b099bb657d0b4fb0df5cefa626588b6c6d58e92467f7cfd7269fec2cc4275062971552e3750eae5727db3e6]
DER Serialization: signature mismatch, expected [3044022057d0b4fb0df5cefa245e76ba9b099bb63aa46340cb152a927c1cb3f8befe324802203750eae5727db3e6cc4275062971552e467f7cfd7269fec2626588b6c6d58e92] not matched by [3046022100facef50dfbb4d057b69b099bba765e24922a15cb4063a43a4832febef8b31c7c022100e6b37d72e5ea50372e557129067542ccc2fe6972fd7c7f46928ed5c6b6886562]
Test failure encountered.

Are you testing with a recent version of libsecp256k1 on the big endian system? That reported DER signature is a high-s one, which we stopped producing over 2 years ago.

Completely up to date.

On Thu, Feb 16, 2017, 7:25 PM Pieter Wuille notifications@github.com wrote:

Are you testing with a recent version of libsecp256k1 on the big endian system? That reported DER signature is a high-s one, which we stopped producing over 2 years ago.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/bitcoin-core/secp256k1/issues/442#issuecomment-280539527, or mute the thread https://github.com/notifications/unsubscribe-auth/AGL5OJR6Gb6cPsOl4NYq0vzSTfFYOtjcks5rdRMOgaJpZM4MD0nF .

Looking into this, but it'll be hard to reproduce without access to a big-endian machine (especially one with a c++11 compiler...).

A quick note: the "signature mismatch" is completely expected, as you're printing out the internal data of the secp256k1_signature type for this the header states The exact representation of data inside is implementation defined and not guaranteed to be portable between different platforms or versions.. However, the produced DER signature is clearly wrong.

FWIW, our internal tests and benchmarks all work on a BE host, but I don't currently have one with a C++11 compiler.

I ran on big-endian MIPS and got this output:

Signing: signature mismatch, expected [4832febef8b31c7c922a15cb4063a43ab69b099bba765e24facef50dfbb4d057928ed5c6b6886562c2fe6972fd7c7f462e557129067542cce6b37d72e5ea5037] not matched by [befe32487c1cb3f8cb152a923aa463409b099bb6245e76ba0df5cefa57d0b4fbc6d58e92626588b67269fec2467f7cfd2971552ecc427506727db3e63750eae5]
Test failure encountered.

Notably lacking the DER failure. The signature error is different and expected according to @sipa.

Perhaps I will just be stating the obvious, but the given test appears to be completely spurious. For the first part (test_sign) EC_SIGNATURE purports to be the expected raw contents of the signature, but that is an opaque format (secp256k1_ecdsa_signature) as pointed out by others, and in practice varies according to endianness (and 32/64-bit). The second part (test_serialize_der) of the test independently serializes EC_SIGNATURE (note: not the actual generated signature) to a DER signature, but this test makes the same invalid assumption about the opaque format and cannot portably produce the expected DER result.

Closing as "not a bug". Users of the library should never be inspecting or operating on opaque data structures.