Topic: Zsh/OpenSSL Shell Script Key Generator (Read 5513 times)

+100 It's a must! Thanks!

If your Linux box stumbles on "tail -r", substitute by "tac" (thanks to mintymark).

You lost me at secp256k1 ;-)

If I install Armory on a machine, say without the Satoshi client, can I use it from a command line (or within Armory) to generate key pairs from passphrases? And if so what commands would I use? I don't see the option within Armory.

If you intend to use this on a live CD make sure you aren't generating keys on a freshly booted machine.

See http://eprint.iacr.org/2006/086.pdf and http://eprint.iacr.org/2012/251.pdf

Live CD distributions boot with a preset entropy pool. In theory, generating keys right after you boot will greatly reduce the 256bit keyspace since you have only added a few bits of mouse and IO entropy. You probably need to leave the system on a for a while - maybe even seed /dev/random with microphone data. OpenSSL seeds its PRNG with data from /dev/urandom plus the process ID of the current process.

On a normal system this isn't an issue since all distros will save some bytes from /dev/*random on shutdown and use them on startup to seed the PRNG.

Notice that xxd might not be present on some Unix system.

An alternative is to use the 'pack' perl function.  Perl is always present on any decent GNU/linux/Unix system:

I did play around quite a bit with trying to create a DER file, but without the public key (it looks optional in the format spec), in the hopes that OpenSSL would figure it out and calculate it itself, but OpenSSL would just crash when given it.

But, if anyone was using what I originally posted, I've updated it to support compressed public keys as well as generating testnet addresses. It also prints the unhashed public key, which is useful if you're using the key for a multisig address. As before, any aspects original to me I put in public domain, and I sure hope there's no bug that causes you to lose your coins since I'd hate for that to happen, but I'm not going to be held liable if it does.

The predecessor to Armory (PyBtcEngine) used pure-python implementation of ECDSA.  This implementation was created by forum user "Lis" here:

https://bitcointalksearch.org/topic/solved-python-secp256k1-23241

If you plug that into google translate, you'll see that he declared that code to be public domain.  It's not exactly fast, but it most definitely works.  I was able to create, sign, and verify blockchain transactions with it.  It is based on python's native handling of arbitrary-sized integers -- go ahead, open a python shell and type "2**10000" ... you'll see what I mean )

Not only can you verify that the code is just a basic EC library with hardcoded secp256k1 constants, it's stupid easy to wrap in a shell script to get whatever you need out of it.  I would recommend using entropy generated from a reliable source (OpenSSL?), and pass that into Lis' script.  His script uses the python "random" solely for testing that signing and verification work.  But as is mentioned in python's own docs "python's PRNG is wholly unsuitable for cryptographic purposes".

EDIT:  also, you can use armoryengine.py, but it doesn't use Lis' code anymore... it uses Crypto++ libraries made available to python via SWIG.  It has turned out to be pretty simple to compile and run on any Linux (even OSX, because you can use armoryengine.py without any Qt dependencies).   But that could be a lot of code just to get to its ECDSA implementation.   (you can probably strip out 90% of armoryengine.py, though, and keep just the ECDSA parts)

Alternatively, you could extract my wrapper around Crypto++ and use that somehow.  It does exactly what you want, and you can use publicly-verifiable download the crypto++ libraries, which have no external dependencies.   (use only SecureBinaryData objects and all methods below this line).

To get this to work with Ubuntu, I had to change tail -r to tac.

Both reverse the order of lines in a file.

I've created a simple utility that can take hex private keys and output various related data using a format string. So you can give it random data and it outputs WIF keys with address, etc.

It currently only takes HEX keys in but if people would find it useful I could have it take WIF keys as well. That would be a bit more of a swiss army bitcoin knife.
Now supports either Hex or WIF input keys with autodetection.

See my post here, with link to my github misc repo.
https://bitcointalksearch.org/topic/m.1425723

Generate keys from the cmd line, from random data,

hexdump -v -e '/1 "%02X"' -n 32 /dev/urandom | keyfmt '%a:%w'

Another thing you can do with private keys and OpenSSL is create MultiBit encrypted private key export files. You can then import these later into MultiBit, specifying the same encryption password in the UI.

The file format is described here:
https://github.com/jim618/multibit/wiki/Export%20and%20limited%20import%20of%20private%20keys

The OpenSSL commands to encrypt and decrypt the private key export file are near the bottom of the wiki.

https://github.com/etotheipi/BitcoinArmory

Where do I find this program, how do I trust it (is the source available?) and what is the usage? Something like this?

echo -n C4BBCB1FBEC99D65BF59D85C8CB62EE2DB963F0FE106F483D9AFA73BD4E39A8A | armoryengine.pl -genPublicKey

armoryengine.py would be the solution!

Yep, all three of us were noticing that.  Any useful suggestion on how to get a public key from a command line terminal on a Mac given a 256 bit private key?

openssl dosnt support this.

And here I was hoping you were that "actual expert"  

I'll keep playing with it a bit too.  If neither of us comes up with a solution in the next day or two (and no actual experts happen across this discussion), I'll try posting the question in the "Technical Support" sub-forum.

I'm not necessarily looking for a solution using "openssl", I'm just looking for something I can run from a command line terminal on a Mac that will give me the appropriate public key if I have the private key.

I'm sure there's a way to do it, but getting as far as I did was stretching my knowledge of openssl. (Which is largely why I did it.) When OpenSSL generates a key, it creates a PEM file with all sorts of information beyond the private key, at least the curve being used, but I suspect much more (See the output of "openssl ecparam -name secp256k1 -genkey"). OpenSSL seems to expect all keys to be in either that format or DER format, and I don't know how to construct such a file given just the private key, though I assume that it couldn't be that hard for somebody who actually knew the nuts and bolts of all this, either using some obscure (at least to me) OpenSSL option, or via just smashing some sort of header and footer bytes onto the key. I'll look into it a little, but I suspect you'll need an actual expert here.

I was trying to modify the script to generate a private key and bitcoin address from a passphrase, essentially creating a brainwallet version of your script.

If I've generated a 256 bit private key, for example with the following:


How would I go about determining what the associated public key is?

Can I use the openssl command? Something like:

I'm also on a Mac and have been thinking about putting something like this together.  Thanks for saving me the work, this is great!

I don't have any particular objection to a POSIX version. I was mainly working on adapting it for my own use, and posted it in case anybody else found it useful. But if somebody wants to tell me what to change to make it POSIX-compliant, I'd be happy to.

2. how about making a POSIX version? (runs on every *nix, atleast it should)