So, the biggest improve is, that heavy EC-product is computed only twice!!! New test address is taken from single EC-add operation which is relatively cheap in compute resources.
Indeed, performing one EC_POINT_add() instead of an EC_POINT_mul() per iteration saves a lot of time, and improves the search rate by about a factor of four. It would be a lot more than four if there were a faster way to convert the public key to hashable form. Anyway, this is exactly how vanitygen works now.
Really!?
From your code, I think you pick a random number and an EC-product in each iteration.
Network random number seeding is an extreme security feature. I'm not against adding it, but it wouldn't be trivial to implement, and I question whether any actual user will care enough to turn it on. So prove me wrong.
You mean: if a guy in random.org knows what and why I'm picking, then he can clone my random data and reproduce the process to take my private key. Yes, you are right. This is why I propose TWO different network sources, and one of these is made through secure server. So, if someone snuffs the modem, she won't able to deal with the data. Moreover, local entropy is added in my proposal.
Anyway you can simply implement the option adding external entropy source. Say, "
-E file" where "file" is some file the user provides. Then, the program reads up to, say, 64 bytes from file, concatenates these data to your local random data and hash it all together. If the option is not used, only local entropy is gathered and used.
User is responsible about what she provides as "file".
Shouldn't that be
s = SHA256(E1 ^ E2 ^ E3) mod p
where ^ is bitwise xor?
I think Shevek was using the cryptographer's |, which means concatenation. Not the C/C++ |.
Sure!
