Debian weak keys are still out there on the Internet
cryptographycaffe.sandboxaq.com
cryptographycaffe.sandboxaq.com
An innovative technique compared to other commercial and open-source scanning software: downgrade TLS and SSH scanners to older protocol versions to find older keys alongside newer ones. (For example, a TLS server might offer an EC cert+key to TLS 1.2/1.3 clients, but an RSA key to clients that can only do TLS 1.0.)
Some notable findings:
- Debian weak keys (generated in 2006-2008) are still in use, including by highly active users on Github and Gitlab
- 512-bit and 1024-bit RSA keys are still in use, including their use as DNSKEYs for prominent companies and government agencies
- RSA keys generated by older versions of Putty and OpenSSH are easily distinguishable by their exponents; if a vulnerability in one of those implementations were discovered (similar to the recent https://cert.europa.eu/publications/security-advisories/2024...), it would be easy to find a very large number of vulnerable keys to target.
Good news:
- Unlike earlier research from 2012-2016, none of the RSA keys could be easily factored into large primes. (Other than Debian weak keys.)
- Certificate Transparency appears to be doing a good job of motivating reputable CAs to scrutinize the cryptographic material in the certificates they sign. No cryptographic weaknesses were identified in any of the keys in millions of recent CT-logged certificates.
https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...
I am not ChatGPT though… I am the author of the survey in question.
And did not use any LLMs in any way at all in performing or documenting it.
> hardware compatibility
I don't have any evidence that hardware compatibility plays any significant role at all in the persistence of insecurely-sized or badly-generated keys for public-key cryptography.
Do you have a reason to think otherwise?
Some remarks that I found interesting on the topic:
-While compatibility/reliability are 110% nice (compatibility being defined as "it works"), that doesn't mean full stability in generating entropy. "Components may be perfect; composition(they all together) can still be flawed", where the components are: Device Hardware, Device OS, and Device Software (KeyGen)"
- "in low-margin devices there aren't high-quality entropy sources to rely on", so its harder to know for sure that key was well generated.
- a large scale on RSA keys enabled the detection of entropy failures that manifested in the RSA keys of millions of devices. Most affected product families were lower-margin devices past their end-of-support date.
https://www.acsac.org/2023/program/final/s111.html https://www.acsac.org/2023/files/web/slides/chi-111-weakrsak... https://samvartaka.github.io/cryptanalysis/2017/01/03/33c3-e...
The 2012 Heninger paper (https://www.usenix.org/system/files/conference/usenixsecurit...) found quite a high number of duplicate TLS keys across seemingly-independent hosts, and attributed it to this issue:
Over the next few years there was quite a lot of work, including in the Linux kernel, on improving the entropy sources available to such devices, and making them more foolproof to use. https://lwn.net/Articles/724643/
The issues identified in this survey are related, but distinct. The Debian weak keys generated in 2006-8 are due to a straight up bug in Debian, and RSA keys that are of a too-small size are orthogonal. I found far fewer "inexplicable duplicate" TLS keys than Heninger et al did in 2012.