Topic: Fastest, least-likely-to-be-subtly-broken way to make lots of addresses offline (Read 1318 times)

May I ask for what kind of application you need so many addresses?

BIP32 hardened is perfectly acceptable to release private keys.  They're indistinguishable from random keys to anyone who doesn't know the master secret.  Fore BIP32 _non-hardened_ IT IS ABSOLUTELY NOT ACCEPTABLE TO PUBLISH THE PRIVATE KEYS. PUBLISHING ONE PRIVATE KEY IS EQUIVALENT TO PUBLISHING ALL OF THEM TO ANYONE WHO CAN GENERATE KEYS.

I understand.

What I'm saying is that you could generate all the keys using an xprv extended private key, and store that one key instead of storing stacks of CDs or something.
If you don't upload the master public key anywhere and use hardened paths there's really no benefit to "using bitcoind to generate tons of keys and store them on CDs"

Just use BIP32 to generate tons of keys when they are needed, offline, and never upload the xprv or xpub anywhere.

That way you're not backlogging (just in case someone accidentally sends 1,000 bitcoin to that one address you gave for that one bet on day 1), quadrillions of keys and now it's 5 years into the thing and you have to wade through 50,000 CDs to figure it out.

With BIP32, you backup one key and can keep both the xprv AND the xpub private, and just make regular backups of your server that maps all the keys to the different paths (which I'd assume your server already stores data about all the bets going on anyways, so just matching up the derivation paths with the info from your server backups would be enough to supply you with unlimited keys for all time. The only thing you'd need to do is generate the proper derivation paths necessary every now and then just as you have been doing with bitcoind.
(again, you're not uploading the master pubkey or anything, just taking note of the generation path along with other metadata about how the key was used.)


I would say that running a RNG on an offline computer that is only used for that purpose millions of times is probably not a good thing to do... not to mention you run the risk of some software/hardware bug from faulty hardware that breaks the RNG after the computer starts getting old... etc. etc.

That's another advantage to deterministic. You only need 1 high entropy key, so RNG only once. The rest is just saying "ok my derivation path will be  m / userid ' / bet_id ' / yes_or_no '  " and generating a ton of keys offline and slapping their individual addresses on your server separately.

Hmm, not sure, but I'm not qualified to say that what I'm doing matches the design assumptions behind BIP32, and I'd need (multiple) qualified people to be very confident of this to talk me out of doing the least cryptographically-interesting thing here, which is a bunch of independent random numbers.

It's still ok if you don't release the master public key but to be extra careful, you could use hardened keys.

If these were being used in regular payments then I would, but it's a special case that I think breaks the assumptions behind BIP32 HD keys, because we actually end up releasing these _private_ keys for the entire world to see. See discussion of what we do here:
https://bitcointalksearch.org/topic/ann-reality-keys-an-oracle-letting-you-use-external-state-in-transactions-423638

Why not use BIP32 HD keys? You can store one master secret and give each of your yes/no keys specific indexes of the branches.

You could even use them to generate the pubkeys on a webserver without uploading any private keys.

Thanks, I'm mainly thinking about those, plus the Rumsfeldian unknown unknowns that I haven't thought of. I guess your comment about only Bitcoin Core doing test key signing and verification makes me think it's going to be a safer choice for the latter, if there's any genuine concern there beyond my primitive superstitions.


Marginally. Would there be any difference between implementations to worry about here?


As far as possible I'm trying to design a process where the relevant points can be witnessed by a second (or third etc) party, so ideally the process would be: Sign the box that will generate keys out of secure storage, run the steps listed on the check-sheet (for example, boot the box, run script X, burn CDs Y and Z, shut down box), sign the box back into storage etc. This is quite easy to do in one session if it's under an hour or so, but if it becomes a multi-hour process it becomes a bit more complex. (Bathroom breaks?...)

What risks are you concerned about?

Just incorrect key generation? Attempt signing with all the keys and verify the results. (Bitcoin core does this internally. And I strongly recommend it, it's a little terrifying that nothing else does. It's too easy to have a bitflip cause the creation of an invalid key, and too easy to defend against)

Poor RNG quality?  Thats harder. Vanitygen allows seperated (point addition) key generation, so you could e.g. generate one key another way and generate all additional ones as that key plus some new random value, in order to have a baseline expectation of security.

Concerned about side-channel (timing, emi, etc.) leakage?

Why is speed a concern? I can understand applications for generating some large number and putting them away... but if the keys are going into a safe what do you care if it takes an hour? How fast does it need to be?

So I have a workflow which involves me pre-generating literally millions of random keypairs offline, which I then need to store securely until future dates. Last time I did this I used bitcoind and just ran getnewaddress to get a bitcoin address out, then ran dumpprivkey and validateaddress against it to get the private and public keys (which is what I actually want - I don't actually care about the address). That worked OK, except that:
1) It's a bit of a sledgehammer to crack a nut, and I think it may be doing some pointless indexing work and things.
2) It was a bit slow to generate millions of keys like this, particularly on the rather under-powered machine I was using for it at the time. (In particular it seemed to bog down once its wallet.dat file got big, although I could speed it up again by stopping bitcoind and deleting the file, then starting it again.) In this case there are some practical security-related benefits if I can do the whole thing in an hour or so on modern-but-low-end hardware.

Obviously the advantage of bitcoind is that it's had a lot of eyes on it - any other thoughts for tools that have been well enough scrutinized to trust that they'll do this simple job without somehow bollocksing it up? Vanitygen?