[Bitcoin Hardware Wallet] Looking for libraries to generate public/private keys

Been working on my own version of a hardware wallet for cryptocurrencies for a while now, the progress can be seen on the link above (though it is a little out of date now). I have a libraries to handle AES-CBC and SHA-256 which I am using to secure the device itself and the private keys that it will be storing, all of which works perfectly already. There are two main things I am trying to add to the device now:

  1. Generate new private keys on the device itself - This will not be too terribly difficult as it is basically just large random numbers with a little bit of quality control.

  2. Derive Public keys reliably from the stored Private keys on the fly so that the Public keys do not need to be stored on the device and so that new keys generated by the device itself can actually be transferred to.

I have not found any existing libraries out there that I can make any sense of. Though I have researched the process of deriving public from private, I have become stuck mainly at the point of needing to implement the first steps of the process.

is a very good outline of the routine in question.

For the record, I am actually using a Teensy 3.1 on this build, so RAM, program memory, and clock speed are not much of an issue...Any advice would be greatly appreciated!

Harbinger_x81:

  1. Generate new private keys on the device itself - This will not be too terribly difficult as it is basically just large random numbers with a little bit of quality control.

  2. Derive Public keys reliably from the stored Private keys on the fly so that the Public keys do not need to be stored on the device and so that new keys generated by the device itself can actually be transferred to.

Are you sure you’ve understood how PPK works correctly? In my experience it’s usual to generate a key pair, not to derive the public key from the private key. I don’t suppose it matters whether you generate the public key once rather than every time you need it since you need a way to generate it in either case, but given that you are storing the private key I don’t see any reason not to store the corresponding public key too, in which case generating the key pair in the conventional way should be sufficient for you.

As an aside, this is purely a cryptography problem, and no different than anyone else faces when writing a wallet application - it’s really nothing to do with Arduino. If you want help with encryption algorithms there must be communities that specialise in that sort of thing. I think you’ll find that the Bitcoin wallet source code is openly and freely available in any case, and all you’re really changing is the front end UI and back end storage - the core logic should be common.

There was another Thread about Bitcoin in the last week (I think).

...R

PeterH:
Are you sure you’ve understood how PPK works correctly? In my experience it’s usual to generate a key pair, not to derive the public key from the private key.

This clearly indicates he does not, or is at the very least sorely confused in his explanation. Determining a public key from the private key is in fact the very same problem as deriving the private key from the public due to the symmetry of the process. And I really should not have to explain the implications of that.

Further, “just large random numbers with a little bit of quality control” is in actual fact, a terribly difficult problem which has caused major problems time and time again in cryptographic systems. It is by no means something to take lightly at the amateur level. At the very least, even if you are not proposing to write such software, it is highly recommended to follow Steve Gibson’s “Security Now” Podcasts.

Paul__B:
Determining a public key from the private key is in fact the very same problem as deriving the private key from the public due to the symmetry of the process.

I don't think it's valid with ECC keys, take a look please https://github.com/bitcoinj/bitcoinj/blob/master/core/src/main/java/com/google/bitcoin/core/ECKey.java#L253