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.)
They have been handed a giant pile of all keys to all homes in America. They went through the pile and found all but 64,000 keys to be too damaged to be usable. Those 64,000 keys are perfectly good, but they don't know which homes they belong to.
They open up a shop allowing people to come in with their lock to check if their key is one of the 64,000. Do you go to check? Do you drive? Or do you go wearing a mask on your face and take public transit (VPN + tor)?
Unless I misunderstood, they know which keys belongs to which houses. They successfully factored those keys, and unless they threw the metadata away they still know the domain that is using that key.
And if they did throw the metadata away, they still have this pile of 64,000 prime factors. They can ask the domains for their public keys again and test if any of those factors matches.
Well they did collect all the keys from their respective houses – the only thing stopping then knowing which key goes with which house is poor record keeping on their part…
Firstly, just because they know your private key - doesn't mean they can log in - just that they can snoop on the encrypted traffic, which is spectacularly unlikely for researchers at UCSD or UoM.
BUT, if one were to assume the presence of a global passive adversary – they would already have your public key, found via snooping the start of any encrypted connection to your secured service, as well as everybody else's public keys captured the same way – and one would assume that they've got _way_ more compute power available than five bucks worth of AWS EC2 time to factor them with.
Which says to me - check your public keys using the tool. If it says you're vulnerable you're probably hosed already and the only sensible option is to take the service offline until you've generated a new key-pair.
Actually, I guess the proper advice is probably to shut down any 1024 bit key protected services right now, and generate 2048 or more bit keys for them. If you've been running any services with 1024 bit keys where sniffing the cleartext of a session would reveal login credentials to anything important, and that key is a known "weak" key, it's probably time to assume the global passive adversary already has root on that box.
Try running:
> wc .ssh/*.pub
if that's returning key files with character counts below 7 or 8 hundred, run:
> ssh-keygen -l -f .ssh/id_rsa.pub
(where id_rsa.pub is the filename of the "short" public key) to determine the actual key length. (there's probably a better heuristic than my "about 7 or 8 hundred characters", I'm seeing 1024 bit rsa keys in the 200-300 char range and 1024 bit dsa keys in the 500-600char range. There's some "random length filler" in each file for containing the email address. I'm not sure what encoding is used to make ascii-representable 512 bit numbers though. )
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?