Sort of correct, but not entirely. The problem is it uses a hash, as we know all hash have a finite output (usually 32, 64, 128, 160, 224, 256, 512, etc. bits), so no matter what there are always (theoretically at least) more inputs than outputs (although past 128 bits the practicality dies off rapidly unless the hash is somehow significantly flawed).
In this case the hashing algorithm used has a significant flaw rendering the whole point moot (it mangles the data into a forced 32 bit output). As such there are now two major factors:
1) the entire key space is so small that you don't have to guess per se, you can simply brute force it quickly.
2) the hash is so sufficiently bad that we can just walk though 00000000 - FFFFFFFF, we don't have to go "beyond" and try anything else (e.g. the permutation of the data is weak)
Basically they did this so badly that you can skip most of the birthday part of the birthday attack.
However even with a proper hash algorithm instead of what they used, they could still be potentially vulnerable to a birthday attack (e.g. MD5).
------------------------------
Kurt Seifried
Chief Blockchain Officer and Director of Special Projects
Cloud Security Alliance
[email protected]------------------------------
Original Message:
Sent: Jun 17, 2020 10:29:07 AM
From: Chaddy Huussin
Subject: Wallet Security and Key Space
This has nothing todo with Birthday Attack, and they are correctly using the right hashing function, the problem is with the processing of the seed. In a BIP39 compliant wallet the password in reality is used as salt. The problem was the faulty implementation of the Key Stretching Function reduced the entropy and thats it.
for more context please check;
https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki
https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki
------------------------------
Chaddy Huussin
VP
JPMC
Original Message:
Sent: Jun 16, 2020 11:34:44 AM
From: Kurt Seifried
Subject: Wallet Security and Key Space
This is actually something I've been researching in general, hash functions, search space, at what point do we consider a value "unguessable" aka how resistant are these to birthday attacks? For some numbers please see:
https://en.wikipedia.org/wiki/Birthday_attack
The TL;DR: 32 bit and below is to small, 20 years ago it was maybe ok, but not now. 32bit integer (4bytes) times 2^32 integers... is a mere 32 gigabytes of data (plus overhead, my gaming PC has 32gigs of ram...) and a modern CPU can grind through the space in minutes. 64 bit is not currently safe (and certainly won't be in a decade), 128 bit is ok now and probably safe for a while, but 256 bits is probably the simplest long term strategy if you want to be collision resistant for the next few decades (assuming your hashing system has no major flaws).
As such as hashing algorithm like SHA-3, which conveniently outputs a 256bit hash value is your best bet, also it's the most tested/analyzed of the newer hashing algorithms, NIST approved, etc and shows good resistance to quantum attacks. Back to the old "people who roll their own crypto (and by extension hashing) are probably doing it wrong" maxim.
------------------------------
Kurt Seifried
Chief Blockchain Officer and Director of Special Projects
Cloud Security Alliance
[email protected]
Original Message:
Sent: Jun 16, 2020 10:20:44 AM
From: Hillary Baron
Subject: Wallet Security and Key Space
@Kurt Seifried Thoughts on this?
------------------------------
Hillary Baron CCSK v4
Program Manager, Research
CSA
Seattle WA
Original Message:
Sent: Jun 15, 2020 12:23:50 PM
From: Ken Huang
Subject: Wallet Security and Key Space
The article "Loopring's Frontend Vulnerability, Explained" published in Medium talks about use wallet security related to the key space.
The analysis shows that due to use of non-standard hash function, the wallet's account key has only 32 bit space, which is very easy to emmulate and attack. This could be a good use case for the front end wallet design and key security.
------------------------------
Ken Huang
DistributedApps
------------------------------