Topic: eCommerce disposable keys (Read 764 times)

I just realized that if I need to tell you to use armory, you probably have no idea how armory works.

Armory uses EC math to generate two parallel streams of keys.  Your insecure computer can create new addresses and give them out to orders while an offline computer generates matching private keys.  The offline computer generates the real secret and calculates seed values to be given to the online computer.  You only need to back up the initial secret once.  If the online computer is penetrated, all the attacker learns is the sequence of addresses, never the keys needed to spend money sent to those addresses.

You should seriously consider using armory instead of rolling your own system.  It does what you are trying to do, and it does it better.

Yes, so change the master key periodically or upload new set of addresses periodically.
What's the difference?

I suppose an advantage to master key is that you can't run out but you can avoid running out by just keeping on top of things anyway and adding to the pool before it becomes critically low.

You have to upload new addresses periodically with my method, you don't have to change the master key periodically, and most people won't.
Hell the whole reason deterministic is so attractive to many is because they don't even want to back-up periodically.

Just change the public master key periodically.

In your system you are planning to upload X public keys correct?  Then the attack has knowledge of the next X public keys if the server is compromised.  Use a deterministic public key seed and increment the master public key every x keys.

There's a serious problem with using deterministic on an e-commerce site with the keys generated on the e-commerce site.

If a hacker gets access, they can off-line monitor every sale you ever do and that kind of info can be gold.
So people using that algorythm, I still would suggest doing it in a way that the addresses are generated elsewhere and uploaded to the server, and that the server not have the data necessary to generate them itself.

Thanks, so I'll add a preg_replace in the event the sha256 ends up with a dozen F's in a row.
It'll probably never trigger but...

Would it really let me generate addresses without first generating the keys?
That does look interesting, though it also looks like if the master key is figured out then all is lost.
With mine - if a private key or two is managed to be brute forced, just the corresponding public address is lost.

Why not use BIP32? https://en.bitcoin.it/wiki/BIP_0032

Your plan sounds a little insecure to me, but I'm no expert in the matter.  I'll let more knowledgeable people comment on that, maybe I'm wrong.

As to your second question, I found the answer in the wiki:

https://en.bitcoin.it/wiki/Private_key

Here's script as I have it so far - the ecclib classes cause some memory issues, even with disabling maximum script memory it still seems to die after generating about 50k addresses or so -

http://www.sakari.us/generateAddresses.phps

so generating 65,536 at a time might be a little too ambitious.

Spot checking dozens of generated pairs it seems like it works just dandy.
Couple of the functions I stole from elsewhere -

http://pastebin.com/vmRQC7ha

Hi,

I'm working on a site that will *just* use bitcoin for the means of commerce.
I'm writing the code myself because - hey, it's fun - but also because it is a form of security through obscurity. The less my codebase has in common with other sites the less likely an exploitable flaw elsewhere will work with mine. But mostly I'm doing it because I'm stubborn, I've been into php since php 3.x days and I'm not a fan of most modern coding styles. And too many existing projects in general don't get basic security right (like using prepared statements - I blame MySQL for that, since it didn't support them back when LAMP first became popular)

For tracking customer purchases, I'm going with unique public address, but I'm using a generator rather than random. Specifically -


Idea being to generate a series of keys on non-connected machine, import public addresses into postgresql on web server.
When I start to run low on addresses, increment the series and regenerate.

The salt I need to back up, the phrase I need to remember, and thus I can regenerate from the salt, series, and phrase as needed.
Now generation of the keys -


int2hex converts an integer to hex with padding 0's as needed 0000 - FFFF
genPublicAddress uses bcmath_Utils and related classes to generate a base58 public address from the generated key.

Right now in testing I am just having it print the results so I can test the results via http://gobittest.appspot.com/Address but eventually it will insert the private key, series, and public address into a table - idea being I query table for all public addresses associated with a series and make an insert for the web server to use with shopping cart.

Then at end of day / week / whatever I can query web server for public addresses that have confirmed transactions, and take that list to off-line machine with the database of private keys and query for associated private keys, import into a wallet and smile.

Mostly what I'm looking for is criticisms on my generation of private keys. Does that look OK or do I need to do more steps before final sha256 hash?

I think adding the salt to a ripemd160 hash and hashing that is enough that I don't have to worry about someone intentionally creating collisions but I would value the input of others with experience in this arena.

Secondly, I want to verify that a sha256 hash will in fact result in a valid private key. All the docs I read seemed to indicate 64 character hex was the only limitation, but I just want to make sure there aren't some reserved ranges or something I need to watch out for.

Thanks