The keys to the keydom
bit-player.org
The keys to the keydom
1–10 of 28 posts
Re: The keys to the keydom
#2Thanks for posting. Well worth the time spent reading it :)
Re: The keys to the keydom
#3A very interesting read.
The final point is probably the most notable one, that key-generation immediately following a boot up can compromise the PRNG (as we know). Also a cool thought, comparing all those keys. I just compared the few keys I have hanging around (only of order 10, not 4 billion), and none of mine have common factors other than 1. Yay!
Spoofing host keys also sounds like a potential target, so you could spoof the server identity and then decrypt communications without having to deal with the actual key-cracking.
Re: The keys to the keydom
#464,081 is really close to 65536 (2^16) -- I wonder if the 64,000 vulnerable TLS keys have anything to do with a bug similar to the 2008 Debian SSL key fiasco, where the only contributor to the key's entropy was the PID (2^15 combinations). It would be interesting to see data about the types of devices that have these weak keys, but then again if there is a correlation its release could be used maliciously in the wild.
Re: The keys to the keydom
#5Check if your site uses a known weak key here:
https://factorable.net/keycheck.html
Enter a domain name or an IP address.
Re: The keys to the keydom
#664,081 is really close to 65536 (2^16) -- I wonder if the 64,000 vulnerable TLS keys have anything to do with a bug similar to the 2008 Debian SSL key fiasco, where the only contributor to the key's entropy was the PID (2^15 combinations). It would be interesting to see data about the types of devices that have these weak keys, but then again if there is a correlation its release could be used maliciously in the wild…
It's definitely a bug, most likely in the pre-prime generation (not enough entropy).
If we're talking 1024-bit integers created by multiplying two 512-bit primes, the facts are:
1) The number of 512-bit primes is estimated around 11.36×10^150
2) The chance that two truly random primes are the same is one in 3.37*10^75. It is safe to assume it has never happened and never will (at least on our current hardware).
Re: The keys to the keydom
#764,081 is really close to 65536 (2^16) -- I wonder if the 64,000 vulnerable TLS keys have anything to do with a bug similar to the 2008 Debian SSL key fiasco, where the only contributor to the key's entropy was the PID (2^15 combinations). It would be interesting to see data about the types of devices that have these weak keys, but then again if there is a correlation its release could be used maliciously in the wild…
The post mentions "Most of them are found in embedded networked devices, such as routers and firewalls". Embedded devices like that have very little entropy on first boot - that could might cause them to generate very poor keys.
I wonder how many of the 60% non-unique keys are embedded devices with hardcoded keys...
Re: The keys to the keydom
#8I don't have a source to back this up, but I thought this problem had been tracked down to a faulty Cisco CSPRNG.
(Later: nope, I'm wrong; the P's and Q's paper has Juniper vulnerable as well. The more likely commonality might be solid state devices and cold-start entropy.)
Re: The keys to the keydom
#9Check if your site uses a known weak key here: https://factorable.net/keycheck.html Enter a domain name or an IP address.
I pasted my key in to check. Came out as: "Factorable RSA Key Check Pass! This RSA key is not known to be factorable."
I would have felt uncomfortable checking my publicly available TLS or SSH server because if it comes back a fail, how do I know the site is not logging the data and logging in?
Re: The keys to the keydom
#10Check if your site uses a known weak key here: https://factorable.net/keycheck.html Enter a domain name or an IP address.
I pasted my key in to check. Came out as: "Factorable RSA Key Check Pass! This RSA key is not known to be factorable." I would have felt uncomfortable checking my publicly available TLS or SSH server because if it comes back a fail, how do I know the site is not logging the data and logging in?
I'm not seeing the risk if it's a publicly available address. Analogy:
They tested every door lock in America.
They found that 64,000 door locks are trivially opened.
They put up a website where you can enter your home address to see if you're vulnerable.
If you enter your home address ("123 Maple Street"), they could lie and tell you that you're secure, but then go and rob you.
The thing is that they already knew whether 123 Maple Street was secure or not. They could have robbed you beforehand.
(Also, let's say that they never tested 123 Maple Street, and they tell you arbitrarily that you're secure. In this case, they still haven't gained any new knowledge.)