Bitcoin Forum
March 28, 2024, 02:04:04 PM *
News: Latest Bitcoin Core release: 26.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Fastest, least-likely-to-be-subtly-broken way to make lots of addresses offline  (Read 1292 times)
edmundedgar (OP)
Sr. Member
****
Offline Offline

Activity: 352
Merit: 250


https://www.realitykeys.com


View Profile WWW
January 03, 2015, 01:42:42 AM
 #1

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?
1711634644
Hero Member
*
Offline Offline

Posts: 1711634644

View Profile Personal Message (Offline)

Ignore
1711634644
Reply with quote  #2

1711634644
Report to moderator
1711634644
Hero Member
*
Offline Offline

Posts: 1711634644

View Profile Personal Message (Offline)

Ignore
1711634644
Reply with quote  #2

1711634644
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
gmaxwell
Moderator
Legendary
*
expert
Offline Offline

Activity: 4158
Merit: 8343



View Profile WWW
January 03, 2015, 02:24:02 AM
 #2

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?




edmundedgar (OP)
Sr. Member
****
Offline Offline

Activity: 352
Merit: 250


https://www.realitykeys.com


View Profile WWW
January 03, 2015, 04:28:07 AM
 #3

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.

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.

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

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

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?

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?...)
dabura667
Sr. Member
****
Offline Offline

Activity: 475
Merit: 252


View Profile
January 03, 2015, 06:39:35 AM
 #4

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.

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.

My Tip Address:
1DXcHTJS2DJ3xDoxw22wCt11FeAsgfzdBU
edmundedgar (OP)
Sr. Member
****
Offline Offline

Activity: 352
Merit: 250


https://www.realitykeys.com


View Profile WWW
January 03, 2015, 06:59:27 AM
 #5

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.

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.

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://bitcointalk.org/index.php?topic=423638
hhanh00
Sr. Member
****
Offline Offline

Activity: 467
Merit: 266


View Profile
January 03, 2015, 07:17:22 AM
 #6

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

edmundedgar (OP)
Sr. Member
****
Offline Offline

Activity: 352
Merit: 250


https://www.realitykeys.com


View Profile WWW
January 03, 2015, 08:30:51 AM
 #7

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

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.
dabura667
Sr. Member
****
Offline Offline

Activity: 475
Merit: 252


View Profile
January 03, 2015, 01:04:22 PM
 #8

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://bitcointalk.org/index.php?topic=423638

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.

My Tip Address:
1DXcHTJS2DJ3xDoxw22wCt11FeAsgfzdBU
gmaxwell
Moderator
Legendary
*
expert
Offline Offline

Activity: 4158
Merit: 8343



View Profile WWW
January 03, 2015, 05:22:40 PM
 #9

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.
Tarion
Member
**
Offline Offline

Activity: 224
Merit: 10


View Profile
January 05, 2015, 12:19:29 AM
 #10

May I ask for what kind of application you need so many addresses?
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!