Nanoseconds since epoch, which means eventually it does loop around, so at the very least it's not possible to generate a specific wallet by knowing when it was first used.

A quick search says it's actually ticks, which is OS and machine dependent (kernel tunable). Nanosecond resolution is not enough for a seed if it's a real datetime, so the 32-bit truncation is a separate problem.

As discussed elsethread, it used the lower bits of the time value, so while there is is a fraction of the 2^32 space due to precision loss in the OS time calculations, it is not as simple as "between when this software was released and now, in seconds".

As long as people can write code, bugs will exist.

It looks neat, I'll pass this along to the team and take a deeper look at it later.

Also generating a BIP39 seed from https://iancoleman.io/bip39/ and using as many words from the output as you want for your purposes.

That is correct, you still have 2^32 permutations of possible values.

Given it's seeded with system time, depending on the resolution, that may in practice be as low as tens of thousands of possible values (as in time(2) )

2^32 is still incredibly small for crypto and is inexcusable.

A fact which was unambiguously well known to the authors prior to the report: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022...

We used the broken algorithm from `bx` in a custom Rust program to brute force this.

What sort of rate did you get for computing the hashed public keys?

I was not involved in that specific aspect, so I can't provide accurate information. We may release more information later in the future.

2^32 search space for each set? That seems to imply a little under 2,000 keys per second?

My numbers are very rough estimates and not good enough to do work on. More accurate information may be made public later.

I would be interested to see performance stats - I would expect an optimized attack (batch point inversion, large precomputed table to speed up multiplication, not bothering to try to be constant time) to run well over an order of magnitude faster than that.

Not that it's particularly worth bothering if you have an 80 core machine and only 13 billion keys to check.

And indeed, we did have an 80 core machine. <1 day after some code optimization passes.

we had so much fun trying to figure out the icon!

It actually uses the most precise 32 bits of the date, so it's any, like, nanosecond between 0 and some other small amount of seconds. You can't brute force a wallet by knowing approximately when it was made, but you can brute force every mnemonic if you have the time or a bit of cash to throw at a server.

EDIT: It loops around to 0 every 4.something seconds, so it's not like everything after 4 is the same key. It's just a more random distribution than what you may be thinking.

There is often very low entropy in the lowest few bits of system time as well (due to the underlying clock having a different resolution than the system call). Given that every bit you lose halves the time for a brute-force, that's a problem.

The difference between 32 bits and 64 bits is the amount of people on Earth compared to (EDIT) the amount of grains of sand on Earth. 32 bits is nothing when it comes to entropy, and it can take a security researcher (like us) only $100 to rent a machine to completely brute force it. Nowadays, only values less than 128 or 256 bits (which are exponentially bigger) are seen as appropriate.

You mean time is the only source of entropy there? I don't think number of bits would even matter for it to be bad in such case.

That is correct, time is the only entropy for the command, and the function they use to generate random numbers is also flawed in that it can only produce 2^32 possible outputs.

To verify, this is something anyone can attack, as was proven by our brute force lookup service: https://lookup.milksad.info.