Ideas with regard to "guestimating" bruteforce attack times

[cipriancraciun]

In reply to the discussion started in #18:

I'd also worry about "bruteforce time" section having not enough context:
[...]

And afaik bruteforcing credentials is a bit of a cottage-industry craft too, with other less obvious variables in there, but idk, also easy to ignore of course, just a bit worrying that it might be quite misleading, especially couple years down the line.

I agree with you with regard the "guestimate" status of these numbers. Perhaps I'll have to add a warning stating that these are "guestimates" for 2023.

However, these times are based on my calculations as described in
https://github.com/volution/z-tokens/blob/development/sources/patterns/entropy_estimates.rs

• they are based on HashCat benchmarks with one Nvidia RTX 4090 as published in https://gist.github.com/Chick3nman/32e662a5bb63bc4f51b847bb422222fd;
• they are very optimistic (in for the attacker, and pessimistic in terms of "bad-luck" on our side);
• for example I assume that the attacker is lucky enough to skip 10 bits;
• I also assume that the attacker finds another way to shave 10 bits;
• the attacker can start with 1000 units; (quite expensive as of today;)
• in case of storage, I assume each 5 years the performance doubles;
• in case of storage, I also assume that each 5 years the cost halves, thus one has more units;
• etc.

I'll have to get more feedback upon this before I change the current implementation.

[cipriancraciun]

There is also an extra comment from @mk-fg on the topic:
=> #18 (comment)