|
Hi there,
Yes new release is coming but still in dev, I added:
- Case unsensitive search (should run at almost nominal speed)
- Wildcard search (on my hardware ~5 times slower on CPU and GPU compare to single prefix search, mainly due to slow base58 and double sha checksum that have to be computed each time) Still need tests and improvements...
- Crypto Secure RNG for default seed
|
|
|
|
The OS is going to be much more random than the user, even if the OS has issues. Moreover, if the user's OS rng is faulty then their security would be totally broken in every other respect as well.
If you want to be paranoid you can combine the OS randomness with user provided keyboard mashing using a cryptographic hash... but please don't just depend on users to provide a truly random value on their own: humans are notoriously bad at it, and that structure reliably results in funds loss.
OK for the paranoid mode. Edit: I would just add the nuance that humans especially bad at password generation when they have to recall it, which is not the case here. |
|
|
|
|
I would like to apologize if I was hurtful but I was a bit choked by the question of AntiMaxwellian.
Sorry.
|
|
|
|
Every operating system offers a source of cryptographically strong random numbers. Why isn't it using 256-bits (or at least 128 bits) of OS provided entropy?
At the beginning the default seed was used especially to allow the program to be run easily and I always recommend to users to use a seed for generating safe keys. You're right, it is better to suppress the default seed and to force user to use a password or a split key. OS random number are still coming from PNRG and a failure might always be found on them. |
|
|
|
Yes if you don't use a seed, for very short prefix. But it will still require lot's of power.
Again, I recommend to use a strong password (-s option) to generate safe base key.
And I recommend to the community not to use this, if he doesn't modify it. The default seed has an entropy of ~48bit (if you manage to guess the date of the address creation), so to guess a key generated by the default seed used by VanitySearch, you need to execute ~2^48 pbkdf2_hmac_sha512 and to run ~2^48 times the search up to the desired prefix. I let you do the calculation of the necessary power to compute an address in a feasible time when you know the day of an address creation  But ok, I will modify the code and add the PID, it will add 16 more bits to the default seed entropy. There are 2 ways to generate safe addresses: 1) Use a strong seed. 2) Use a split key (-sp) with a public key generated by a third party software (In that case, VanitySearch cannot suffer from any vulnerability) |
|
|
|
On page ten of this thread, you concede there is at least one exploit for someone resourceful, assuming you know what you are saying or doing.
Yes if you don't use a seed, for very short prefix. But it will still require lot's of power. Again, I recommend to use a strong password (-s option) to generate safe base key. |
|
|
|
I don't, you do, and if you want people to use it, you are going to have to do something.
The way pbkdf2_hmac_sha512 is implemented is safe, long passwords (>128 characters for SHA512) are truncated to 128. No change needed here unless someone finds a trap of really wants password longer than 128 char. Hi, I just remembered a few features of "profanity" used for ETH-addresses: --letters Score on letters anywhere in hash.
--numbers Score on numbers anywhere in hash.
--mirror Score on mirroring from center.
Would it be possible to implement those "modes" into VanitySearch? Hi, Yes it could be done but I still have work with fast base58 encoding and I will be off the next week. |
|
|
|
|
Why do you want to implement in a different way ?
|
|
|
|
|
and ?
did you manage to exploit something ?
|
|
|
|
I would have never know that signing is risky.  It is not if you sign with a reputed secure software on a computer where you are alone (not subject to various side channel attack). |
|
|
|
I fail to see how such a thing could reverse two hashing functions.
You can use the magic Grover's algorithm and a partial RIPEMD160 round reversing (Biclique attack) to decrease drastically the complexity of finding collisions on RIPDEMD160(SHA2(x)) You are way off. https://www.scottaaronson.com/papers/qchvpra.pdfIn fact the O(2^(n/3)) cannot be achieved due to memory complexity (Read this https://eprint.iacr.org/2017/847.pdf). But the Grover's algorithm optimization proposed by Inria's researcher can achieve O(2^(n/2.5)) with a feasible memory complexity ( still need few million dollars of investment just for the classic memory  ) and this algorithm has a very interesting feature, the complexity can be greatly reduced for multiple targets. RIPDEMD160 consists of 2 parallel and independent hashes that are merged with simple additions (mod 2^32) at the end, and this can be easily exploited to create efficient multiple target attack on the 2 independent hashes RIPEMD160_1(SHA2(x)) and RIPEMD160_2(SHA2(x)). |
|
|
|
also, Is it possible to add this address to a specific electrum wallet? I don't think it's possible without creating a new wallet, correct?
You can use Wallet->Private keys>Import to import address(es) (giving the corresponding private key(s)) in the current opened wallet. I'm using Electrum 3.3.4. |
|
|
|
Thanks to all for these performance reports. I appreciate it  Note that the Tesla V100 result was with an old release. If i compare to the result of the 1080 ti posted in the same SlarkBoy's post, 1255M/Ks for 2 1080Ti, (627MK/s per board), and the result from here (1001 MK/s) we may expect a 60% speed increase on the Tesla with last VanitySearch release (~2800MK/s). |
|
|
|
It is provably resistant to collision attacks up to 128 bits security, there is no way to manage a collision attack on such a huge search space.
You should claim the recompense to the Clay institute for this |
|
|
|
I fail to see how such a thing could reverse two hashing functions.
You can use the magic Grover's algorithm and a partial RIPEMD160 round reversing (Biclique attack) to decrease drastically the complexity of finding collisions on RIPDEMD160(SHA2(x)) @aliashraf I'm not saying that SHA-2 is vulnerable to all side-channel type attacks, only to meltdown attack (which is also considered as a side-channel attack) and address generation is obviously vulnerable to nearly same side-channel attacks as ECC. |
|
|
|
I simply wanted to say there are valid mechanism to discover private key
OK. Also, if SHA could be reversed, attacker/thief still need to reverse ECC as well to take user coins (ignoring mining system broken and powerful quantum computer)
Yes but if you manage to reverse the address hashing function, you will be able to get a very large number of public key that match with the address and it will reduce drastically the complexity to find a matching private key. |
|
|
|
Interestingly, we are talking about multiple instances, aren't we?
Yes but even for multiple instance, the precomputation is still enormous and not feasible for a 256bit prime. I'm not saying that it is broken right now, ECC, my argument is about the main attack range not being a magical mathematical technique that solves ECDLP in a glance, it is about optimizations, algorithm back doors, pre-computations, and technology enhancements that gradually justify costs of an attack against its rewards.
You can think the same for addresses. There is no objective reason today to say that RIPEMD160(SHA2(pukey)) brings a supplementary protection and you can even think that using directly pubkey could be more reliable. A failure can also come from the function f(x) = RIPEMD160(SHA2(x)). |
|
|
|
It is not true.
On the contrary a gradual collapse is exactly what will happen with 99% possibility.
"The authors of the Logjam attack estimate that the much more difficult precomputation needed to solve the discrete log problem for a 1024-bit prime would be within the budget of a large national intelligence agency such as the U.S. National Security Agency (NSA). The Logjam authors speculate that precomputation against widely reused 1024 DH primes is behind claims in leaked NSA documents that NSA is able to break much of current cryptography." (Wikipedia)
With that kind of information, you can prove what you want. The best known precomputation (Bernstein and Lange) needed to solve the discrete log problem is just huge and not feasible even for the NSA. The only advantages of this precomputation is for solving multiple instance but for a single instance it does not bring benefits. Also your argument proves to be wrong, considering how QC technology is under development right now: they scale qbit by qbit slowly but continuously. When they proved to be able to break ESDCA in like couple of years bitcoin community will have enough time to enhance their cryptography scheme and users can gradually move their funds to new addresses.
The difficulty of adding qbit does not grow linearly and it is interesting to see that De Broglie's prediction concerning QC seems to be more and more true, and that the Pilot wave theory in which I believe becomes more and more attractive. |
|
|
|
Many thanks for your report Dave Some news: Wildcard search is between 4 and 5 times slower than classic search for known prefixes. I reach ~40MK/s with my 1050 Ti and ~4MK/s with my i7-4770. It is due to the fact that I have to compute full address each time and it requires 2 SHA for the checksum and a base58 encoding. For the CPU release, I implemented SSE checksum and I will try to implement SSE Base58 encoding using Barret's reduction (for computing div and mod 58). |
|
|
|
@Jean_Luc bro, you are seriously wrong in comparing ECC with Sha2 both in their vulnerability to side-channel and direct attack. Bitcoin will collapse immediately if there could be found a flaw, it relies totally on security of sha256. It is not the case with ECDSA256k1, bitcoin needs this scheme to resist just few minutes against search attacks when it is used properly, disclosing pubkey extends this requirement which nobody can guarantee for any encryption algorithm for infinite time (unlike hash functions) to be satisfied. Actually I can guarantee that in less than few decades ECDSA256k1 will be breakable by a QC computer in polynomial time (not necessarily and effectively in few minutes)
Address generation is also subject to side-channel attack, it depends on the implementation. I agree, if ECDLP can be solved in few minutes, bitcoin would die and if SHA can be reversed in few minutes, bitcoin would also die. Today ECDLP takes ages to be solved. Your argument is ok if ECDLP becomes feasible in let's say few years or months but the probability that ECDLP256 becomes feasible in fews years or month and not in few minutes in nearly zero. Saying that because both sha256 and ECC are some mathematical functions implemented by computer codes and they are both exposed to hypothetical attacks so let's rely on both or rely on none, is not a strong argument.
You have to rely on both algorithms. As of the core algorithm: ECC is based on vague/unproven assumptions about discrete logarithm being non-polynomial in time and space which is challenged already by Shor algorithm and QC. SHA256 is not based on such assumptions.
It is exactly the same for SHA, it is based on vague/unproven assumptions that the set of solution becomes more and more difficult to describe at each round. As of side-channel attacks: ECDSA256k1 is a complicated algorithm with a lot of design and implementation choices, we have a history of successful side-channel attacks against its implementations, it is not the case for SHA256.
I'm speaking of address generation which is also vulnerable to side-channel attack. SHA alone is also vulnerable to Meltdown attack. last words: Would you personally put your life saving for next two-three decades in a wallet with an exposed public key? I wouldn't!
I wouldn't put my life in a wallet in any case, with pubkey exposed or not. |
|
|
|
|
Show Posts
