| > Couldn't I simply "brute force" the hop count? Well, yes and no. Yes, the bruteforce attack is a valid one. No, because usually the private key is around 256 bits, so you need to compute 2^255 hops on average to find the key. The current biggest supercomputer can compute 10^17 flops/sec, assume you can do as many hops/sec. It still requires you 10^52 years to find the key. The same is true for RSA : given a number N, find the two prime numbers p, q such that N = p * q. Trivial for N=15, a computer can do 13201225834171 = 1564571 * 8437601 in a matter of a second. However, current RSA N numbers have ~627 digits and we don't expect them to be factored in a reasonable amount of time. As the other commenter said, there are much more efficient algorithms than bruteforce, but for current RSA keys (2048 bits) and ECC keys (256 bits), they are not reasonably efficient. > Does this mean that a higher hop count is equal to a better private key? So yes, the size of the key is a very important indicator of the strength of the key (but long keys can still be super weak if you don't generate them correctly). However bigger keys also result in longer encryption/decryption times. |
So if my key is 255 bits long, then don't I need to do the 255 2^255 hops anyway to actually decrypt something? And in running 2^255 hops, wouldn't I have also cracked the key if it was any number less than that?
> bigger keys also result in longer encryption/decryption times.
So, there's a reasonable upper bound for the key length? Does that mean 256 bits aren't reasonable, and wouldn't this reasonable upper bound be more brute forceable?