One thing this paper ignores is side channel attacks. Those may involve hardware or software vulnerabilities, or they may be inherent to the process itself.<p>So the real bogeyman is not whether we have figured out how to factor large numbers yet (aside from Shor and the as of now mythical quantum computer), but how much information you might leak by using your key.<p>One (generally) overlooked idea might be, some sort of vulnerability between they key and the data being used. E.g., by multiplying many, many smaller numbers with the private key, is it possible to increase the efficiency of the sieve.<p>Then it might be the case that commonly used keys are more vulnerable and keys used less are less vulnerable.<p>Another idea would be a rainbow table of keys. It might not matter so much that you can arbitrarily factor a large number, if generating keys is fast. Especially when you mount attacks on the random number generators involved, you can reduce the search spaces.<p>Forcing the key itself is not so much the concern, this doesn't make me think "oh we are fine".<p>Historically we only have to look back to e.g. Heartbleed to be reminded that we broke ssl not by factoring primes, but by exploiting the many flaws in the protocol itself.