[withinboredom]

I don't think you understand what I mean. I'm not talking about cracking a key. I'm talking about creating a key from seed 0, then 1, then 2, etc. etc., until you have an index of every possible key.

Then, since you know every possible public key ... it's just a matter of looking up its private key in the index.

HOWEVER, I was off by a few magnitudes on how big the seed numbers get. If you are curious, this is basically the biggest seed number:

904,625,697,166,532,776,746,648,320,380,374,280,100,293,470,930,272,690,489,102,837,043,110,636,675 ...

or 904 trevigintillion (thanks wolfram alpha!)

So, yeah, it's not happening anytime soon, though it doesn't invalidate the premise, just changes the timeline to unachievable with current technology. Technology could improve to the point where it is feasible in a human lifetime.

[yau8edq12i]

Where and how do you store your "index"? The number you wrote is multiple orders of magnitude higher than the number of atoms on Earth. It's not simply "not happening any time soon". It's physically impossible.

[withinboredom]

Good point :)

Edit to add: just found https://keys.lol that does exactly this, but generates a few dozen at a time and doesn't store the results.

[Retr0id]

This is like saying the Library of Babel[1] contains every book ever written, past present and future. Yes, it's technically true and a fun thought exercise, but it's not a threat to the publishing industry.

[1] https://libraryofbabel.info/

[01HNNWZ0MV43FF]

It would require a break through in quantum stuff, or new laws of physics to produce a 256 bit rainbow table, right?

"Computers made of something other than matter and occupying something other than space"

https://security.stackexchange.com/a/25392

[withinboredom]

Or ... just generate a few here and there, and eventually, you'll find something. Looks like https://keys.lol is an example of just that.

[tzs]

That kind of reminds me of the idea I've heard several times of compression by indexing π. The idea is that every possible finite byte sequence occurs somewhere in π [1] so if you've got some file of N bytes that you want to store you just need to store N and an index to a place in π where that sequence of bytes occurs.

The problem is the the index to the first occurrence of any particular N byte sequence will on average take around N bytes to store so your "compressed" file is about the same size as your input file.

[1] This is not known to be true. A number that has the property that every possible finite sequence of digits in base b occurs in the number's base b expansion is called a "normal number in base b". A number that is normal in base b for all integer bases b ≥ 2 is simply called a "normal number". Almost all real numbers are normal, but it is not known if π is among them.

[Dylan16807]

> Almost all real numbers are normal

Well if we're being picky then I'm going to point out that almost all real numbers cannot be written down.

Of the numbers we can write down in a reasonable way, the computable numbers, we've only proven a relative handful of them to be normal in any base, and barely any normal in all bases.

So if you have an arbitrary irrational number where you can ask if it's normal, then the answer is probably "we don't know, we haven't figured out a proof", rather than "almost certainly". Those overwhelming odds about "almost all real numbers" don't apply to your number, because your number is computable.

[pdonis]

> I'm not talking about cracking a key. I'm talking about creating a key from seed 0, then 1, then 2, etc. etc., until you have an index of every possible key.

Computationally the two are the same: cracking a key generated by a secure algorithm is equivalent to generating all possible keys and checking to see which one matches.

[Dylan16807]

> I'm talking about creating a key from seed 0, then 1, then 2, etc. etc., until you have an index of every possible key.

The cracking algorithm talked about earlier is that you create a key from seed 0, 1, 2, etc. until you find a match, and then you can keep going to look for more matches if you so desire. Or you can go in a different order, because the outcome is the same.

The only change in your version is that you don't look for matches until you've finished going through every seed.

That makes your version strictly slower.

It's not invalid, it's just worse, for the use case of cracking existing keys.

And for the use case of cracking keys made after you do most of your computing, you still wouldn't use the "one giant index" method for precomputing things. It's not efficient.