This describes research published in 2012 by Arjen Lenstra et al. (https://eprint.iacr.org/2012/064.pdf), which relied on a scalable n-way GCD algorithm that Lenstra's team thought best not to explain to readers (in the hope that the attack wouldn't be quickly replicated for malicious purposes). Coincidentally, another team (Nadia Heninger et al., https://factorable.net/) published extremely similar research in a similar timeframe, without withholding details of that team's GCD calculation approach.
The Heninger et al. paper explains quite a lot about where the underlying problems came from, most often inadequately seeded PRNGs in embedded devices. As the linked article mentions, other subsequent papers have also analyzed variants of this technique and so there's not much secret left about it.
If people are interested in learning about the impact of common factors on the security of RSA, I created a puzzle based on this which you can try out, which also includes an explanation of the issue for programmers who are less familiar with the mathematical context: http://www.loyalty.org/~schoen/rsa/
Notably, my puzzle uses a small set of keys so you can do "easy" pairwise GCD calculations rather than needing an efficient n-way algorithm as described here (which becomes increasingly relevant as the number of keys in question grows).
"www.loyalty.org itself is the server for the web site of Californians for Academic Freedom, the group I founded to oppose the California loyalty oath, which is still a non-negotiable requirement for anyone who wants to work for the State of California -- including student employees of the University of California. "
That's the most controversial thing about the page. In my view it's not a big deal to have that stance but some people don't like others who rock the boat when it comes to the status quo.
My activism on this issue for the past decade and a half has basically consisted of corresponding for a few minutes each year with some new person who objects to signing the loyalty oath. I doubt that the site blocking has anything to do with this.
I'm guessing it's a false positive from using an IP similar to a sketchy site. It looks like the IP points to Linode.
For what it's worth, I enjoyed the puzzle when I completed it three years ago. A practical exercise cracking the RSA keys followed by a small classic code breaking puzzle.
My experience with these firewalls/blacklists is that they have quite a few random false positives. Requests for fixing them one-by-one seems to be a recurring theme on our company chat.
I would leave a company that used an internet blocker. They constantly get in the way of real work and benefit no one. The only valid use case I see is attempting to stop idiots downloading malware and installing it on company computers
In more "traditional" companies that have software dev departments, they are extremely common in my experience, so switching companies wouldn't help much if you're in such a field.
If 90% of the company employees only use IE and MS Word and are actually likely to install malware, and the last 10% are software engineers/data analysts/numerical simulation people, the latter are gonna have to work within/around these types of constraints.
I guess we all find different optima. To me it's not really being treated like an idiot, it's "we need to have a policy that takes into account that most of the people are idiots, you smart guys work around it if necessary".
I don't know where you work, but off-hand I would postulate that working at "such places" also has advantages over where you work (e.g. better work-life balance, living in an area where property prices are not insane, etc.). As I said, we find different optima in these tradeoffs.
The Heninger et al. paper explains quite a lot about where the underlying problems came from, most often inadequately seeded PRNGs in embedded devices. As the linked article mentions, other subsequent papers have also analyzed variants of this technique and so there's not much secret left about it.
If people are interested in learning about the impact of common factors on the security of RSA, I created a puzzle based on this which you can try out, which also includes an explanation of the issue for programmers who are less familiar with the mathematical context: http://www.loyalty.org/~schoen/rsa/
Notably, my puzzle uses a small set of keys so you can do "easy" pairwise GCD calculations rather than needing an efficient n-way algorithm as described here (which becomes increasingly relevant as the number of keys in question grows).