Core’s secp256k1 lib and libbase58 without GNU Autohell?

[nullius]

Following all the recent discussion about Segwit and Bech32, I felt the urge to have some fun.  I happily put together Core’s  secp256k1 and luke-jr’s libbase58 (plus sipa’s reference bech32) to whip up a trivial Segwit bulk address generator—which of course, just had to grow a simple regex bruteforce vanity function:

Segwit addresses are sexy!

Pleased with my new toy, I grabbed my little C file plus its few dependencies, and catapaulted them to an airgap Unix machine.  It would be so nice to let it grind away on some spiffy long-term tip addresses.

No, wait:  secp256k1 and libbase58 both use autoreconf in their build systems.  Sigh.  Download GNU autoconf and its signature, load ’em into the catapault, and let fly across the airgap.  ./configure.  Easy, right?

Code:

checking for GNU M4 that supports accurate traces... configure: error: no acceptable m4 could be found in $PATH.
GNU M4 1.4.6 or later is required; 1.4.16 or newer is recommended.
GNU M4 1.4.15 uses a buggy replacement strstr on some systems.
Glibc 2.9 - 2.12 and GNU M4 1.4.11 - 1.4.15 have another strstr bug.

Sigh.  So much for a way to relax and unwind.  My system has an M4, but not GNU M4.  More downloading.  Ready the catapault again.  It is running out of fuel—actually, it’s not a catapault:  It’s a magnetic railgun.  I take my airgap seriously.

Code:

configure: error: perl is not found

At this point, I gave up and hacked together some ersatz—with OpenSSL’s[1] libcrypto, for secp256k1 and bignums (base58).  Of course, I still want to use Core’s code on machines which have autoreconf.  Thus now, my neat little C file is a mess of #ifdefs—plus a few ad hoc extern declarations to another C file, where I put my OpenSSL glue and my quicky little base58check encoder.

Then, I wrote a set of automatic runtime self-tests to make sure this bucket of bolts gives exactly the same observable behavior in both configurations.

So—is there any reasonable way to get this stuff built without autoreconf?  It’s an absurdly horrid “portability” fix, if it gives your project a build-time dependency on GNU M4, Perl (!!!), and who knows what hundred other packages in the spiralling dependency chain.  This would be inconvenient in ordinary circumstances.  It can be much worse for software expected to be used in a security-critical context, implying an airgapped machine with the minimum possible junk installed on it.  Seriously—I use the kernel’s virtual terminals there, because I reasonably distrust Xorg, window managers, toolkit libraries....  I was exaggerating about the railgun; I am not exaggerating about shell job control and my trusty old nvi.

Thanks for any reasonable[2] suggestions.

1. Yes, I know that OpenSSL’s build system directly uses Perl.  My platform’s distributor runs all that Perl stuff as a sort of preprocessing step, and imports the results into a vendor directory in the source tree.  It is unfortunate that that piece of bugware because such a ubiquitous dependency, though this is slowly changing.

2. Please, nobody say “just use Linux”.  That would sound exactly to me as “just use Microsoft” would sound to you.

[1715135584]

1715135584

[1715135584]

1715135584

[Andre_Goldman]

Following all the recent discussion about Segwit and Bech32, I felt the urge to have some fun.  I happily put together Core’s  secp256k1 and luke-jr’s libbase58 (plus sipa’s reference bech32) to whip up a trivial Segwit bulk address generator—which of course, just had to grow a simple regex bruteforce vanity function:

Segwit addresses are sexy!

Pleased with my new toy, I grabbed my little C file plus its few dependencies, and catapaulted them to an airgap Unix machine.  It would be so nice to let it grind away on some spiffy long-term tip addresses.

No, wait:  secp256k1 and libbase58 both use autoreconf in their build systems.  Sigh.  Download GNU autoconf and its signature, load ’em into the catapault, and let fly across the airgap.  ./configure.  Easy, right?

Code:

checking for GNU M4 that supports accurate traces... configure: error: no acceptable m4 could be found in $PATH.
GNU M4 1.4.6 or later is required; 1.4.16 or newer is recommended.
GNU M4 1.4.15 uses a buggy replacement strstr on some systems.
Glibc 2.9 - 2.12 and GNU M4 1.4.11 - 1.4.15 have another strstr bug.

Sigh.  So much for a way to relax and unwind.  My system has an M4, but not GNU M4.  More downloading.  Ready the catapault again.  It is running out of fuel—actually, it’s not a catapault:  It’s a magnetic railgun.  I take my airgap seriously.

Code:

configure: error: perl is not found

At this point, I gave up and hacked together some ersatz—with OpenSSL’s[1] libcrypto, for secp256k1 and bignums (base58).  Of course, I still want to use Core’s code on machines which have autoreconf.  Thus now, my neat little C file is a mess of #ifdefs—plus a few ad hoc extern declarations to another C file, where I put my OpenSSL glue and my quicky little base58check encoder.

Then, I wrote a set of automatic runtime self-tests to make sure this bucket of bolts gives exactly the same observable behavior in both configurations.

So—is there any reasonable way to get this stuff built without autoreconf?  It’s an absurdly horrid “portability” fix, if it gives your project a build-time dependency on GNU M4, Perl (!!!), and who knows what hundred other packages in the spiralling dependency chain.  This would be inconvenient in ordinary circumstances.  It can be much worse for software expected to be used in a security-critical context, implying an airgapped machine with the minimum possible junk installed on it.  Seriously—I use the kernel’s virtual terminals there, because I reasonably distrust Xorg, window managers, toolkit libraries....  I was exaggerating about the railgun; I am not exaggerating about shell job control and my trusty old nvi.

Thanks for any reasonable[2] suggestions.

1. Yes, I know that OpenSSL’s build system directly uses Perl.  My platform’s distributor runs all that Perl stuff as a sort of preprocessing step, and imports the results into a vendor directory in the source tree.  It is unfortunate that that piece of bugware because such a ubiquitous dependency, though this is slowly changing.

2. Please, nobody say “just use Linux”.  That would sound exactly to me as “just use Microsoft” would sound to you.

 .... and who knows what hundred other packages in the spiralling dependency chain ...

Indeed,
I am trying to install Neug (True Random Number Generator) and Gnuk in a much less complicate system and there always something broken ...

In my case, Regards to secp256k1 reminds me ...

http://gnupg.10057.n7.nabble.com/Adding-the-secp256k1-curve-for-ECDSA-td34670.html

https://github.com/ggkitsas/gnuk/blob/master/src/ec_p256k1.c

[nullius]

.... and who knows what hundred other packages in the spiralling dependency chain ...

Indeed,
I am trying to install Neug (True Random Number Generator) and Gnuk in a much less complicate system and there always something broken ...

In my case, Regards to secp256k1 reminds me ...

http://gnupg.10057.n7.nabble.com/Adding-the-secp256k1-curve-for-ECDSA-td34670.html

https://github.com/ggkitsas/gnuk/blob/master/src/ec_p256k1.c

Interesting.  Using an isolated agent (such as gpg-agent) for Bitcoin signing would be a generally excellent idea, of course.

From your first link:

Speaking about taste, I don't want to use Java for signing.  Using the code of ECDSA running by Python interpreter is the thing to avoid for me, either.  I don't evaluate how much risk it would have, though.

Right.  Though I make moderate use of some “pure Python” Bitcoin stuff, in the back of my mind, I always have the same worry.  IMO, crypto algorithms should be done reasonably “close to the metal”.  Does the Python interpreter have any behavior which opens side channels?  And in a related matter, don’t get me started on all the advice to “download bitaddress.org and burn it into a CD”, or the like.  Forget algorithm implementation side channels:  In Javascriptland, whence comes its randomness?  I peeked, and it’s not a pretty sight!

I do want to get Core’s secp256k1 running on all my systems.  Despite being plastered with warnings, “work in progress... research... Use at your own risk,” I trust it more (or distrust it less) than the vast heaps of junk out there.  I definitely trust it more than OpenSSL.  It was designed specifically for safety (as well as performance), “structured to facilitate review and analysis”, and made with an explicit design goal, “‘Be difficult to use insecurely.’”  I know the difference between a programmer and a cryptographer; and I am a programmer.  secp256k1 is exactly the kind of library I want.  I don’t want any coins lost to accident or malice!

There is also the matter of programming sanity.  Using OpenSSL, I don’t even know which context objects (if any) can be safely reused, and/or shared between threads.  The manpages do not mention such trifling concerns.  Core’s secp256k1 gives explicit instructions about this in the reasonably concise, copiously commented header which currently seems to serve as its documentation.  For my little “toy”, I am only generating keys; so I can initialize a context once, then reuse it a few billion times without reinitialization.

Core secp256k1’s README says, “Intended to be portable to any system with a C89 compiler and uint64_t support.”  Excellent!  I’ve poked around in the code; and I think the Autohell build requirement could be excised with relative ease.  But for the same aforestated reason, this is just not something I want to mess with.  (libbase58 is a different matter, plus a few orders of magnitude smaller and simpler; I should poke at it later.)

[Andre_Goldman]

.... and who knows what hundred other packages in the spiralling dependency chain ...

Indeed,
I am trying to install Neug (True Random Number Generator) and Gnuk in a much less complicate system and there always something broken ...

In my case, Regards to secp256k1 reminds me ...

http://gnupg.10057.n7.nabble.com/Adding-the-secp256k1-curve-for-ECDSA-td34670.html

https://github.com/ggkitsas/gnuk/blob/master/src/ec_p256k1.c

Interesting.  Using an isolated agent (such as gpg-agent) for Bitcoin signing would be a generally excellent idea, of course.

From your first link:

Speaking about taste, I don't want to use Java for signing.  Using the code of ECDSA running by Python interpreter is the thing to avoid for me, either.  I don't evaluate how much risk it would have, though.

Right.  Though I make moderate use of some “pure Python” Bitcoin stuff, in the back of my mind, I always have the same worry.  IMO, crypto algorithms should be done reasonably “close to the metal”.  Does the Python interpreter have any behavior which opens side channels?  And in a related matter, don’t get me started on all the advice to “download bitaddress.org and burn it into a CD”, or the like.  Forget algorithm implementation side channels:  In Javascriptland, whence comes its randomness?  I peeked, and it’s not a pretty sight!

I do want to get Core’s secp256k1 running on all my systems.  Despite being plastered with warnings, “work in progress... research... Use at your own risk,” I trust it more (or distrust it less) than the vast heaps of junk out there.  I definitely trust it more than OpenSSL.  It was designed specifically for safety (as well as performance), “structured to facilitate review and analysis”, and made with an explicit design goal, “‘Be difficult to use insecurely.’”  I know the difference between a programmer and a cryptographer; and I am a programmer.  secp256k1 is exactly the kind of library I want.  I don’t want any coins lost to accident or malice!

There is also the matter of programming sanity.  Using OpenSSL, I don’t even know which context objects (if any) can be safely reused, and/or shared between threads.  The manpages do not mention such trifling concerns.  Core’s secp256k1 gives explicit instructions about this in the reasonably concise, copiously commented header which currently seems to serve as its documentation.  For my little “toy”, I am only generating keys; so I can initialize a context once, then reuse it a few billion times without reinitialization.

Core secp256k1’s README says, “Intended to be portable to any system with a C89 compiler and uint64_t support.”  Excellent!  I’ve poked around in the code; and I think the Autohell build requirement could be excised with relative ease.  But for the same aforestated reason, this is just not something I want to mess with.  (libbase58 is a different matter, plus a few orders of magnitude smaller and simpler; I should poke at it later.)

as EVE used to say .... you have no idea what is possile ....

Hela Destroys Thor's Hammer
https://www.youtube.com/watch?v=cszhXmN_uGY