It is now possible to perform chosen-prefix attacks against the SHA-1 algorithm for less than USD$50K. For this reason, we will be disabling the "ssh-rsa" public key signature algorithm by default in a near-future release.
Did you know that your SSH keys are public on Github?
Some of the most popular users even have DSS keys.
Other options also based on RSA such as "rsa-sha2-256/512" are fine and will remain supported. In other words, the security problem is not with RSA per se.
Having said that, I have not checked whether the people you list have RSA keys bound to SHA-1...
The option in ssh-keygen for a signature algorithm is for signing keys in an SSH CA. This is not something Github supports.
actually, they do now, but only for enterprise accounts. Which is a shame - this is useful for "normal people" too.
Rare ecdsa-sha2-nistp256 guy here. I'd welcome Brainpool, but support mostly boils down to NIST compromised curves on the majority of applications. sadface
> Did you know that your SSH keys are public on Github?
Wait, what? Github makes public keys public? Outrageous!
Unless for some reason someone imports one into their authorized_keys (which presumably would require deliberate steps not random numbskullary) in which case there is a (low) risk as they have just given a dev access to an account said dev does not know exists.
Type in a github username during the installer to import from github.com/%s.keys to /root/.ssh/authorized_keys.
> [...] but support mostly boils down to NIST compromised curves on the majority of applications.
I am doing a lot of embedded stuff, and usually all that's supported is RSA ... and NIST curves when it comes to ECC. And I like to keep my key count at 1. Ditching RSA for ECC was a huge step already in that regard.
See https://news.ycombinator.com/item?id=22324492 and https://news.ycombinator.com/item?id=22324535
The attack will calculate suffixes for these two documents such that both documents have the same hash result.
This means the attacker can then show some people a document about Donald, and others the one about Steve and if they rely on the same hash to validate that they're the same document they'd be fooled.
Digital certificates are the most prominent way computers deliberately depend on this assumption which a collision attack makes untrustworthy.
Consider the Web PKI ("SSL Certificates"). Suppose you have a web site pmf.example it is of course pretty easy to get yourself a certificate to make https://pmf.example/ work, today for free but even many years ago it was pretty affordable from several commercial vendors.
The way those certificates work is they use a digital signature based on a hash algorithm, the CA uses its private key to sign the hash, and that's how computers can immediately tell a real certificate from a bogus one and be sure this is really news.ycombinator.com and not say, your ISP's advertising front end injecting a "special offer". The CA will refuse to give you a certificate for google.com or news.ycombinator.com because those aren't yours.
But using a chosen prefix attack you can create two documents with the same hash. One of them might be a fairly ordinary looking certificate for pmf.example that you're entitled to, the other says you're google.com
You get a CA to sign the first certificate, then you simply snip off their signature and attach it to the second one, since their hashes are the same the signature matches. You now have a valid certificate for google.com. Not theory, practice, this was really done with an earlier broken hash, MD5.
A similar trick, probably done by or on behalf of the US and/or Israeli governments makes Flame work by colliding MD5 for code signing. That uses a collision nobody publicly knew about, which is a weird and expensive thing to do but of course governments have lots of money.
Last year I switched over to using signed SSH host keys, and for my fleet of ~150 VMs, some of which respin on a nightly basis, this has been a game changer. No longer do I need to keep a master "known_hosts" file updated and distributed across the fleet.
This step is very straightforward; append the public key to
authorized_keys as you would normally. Note that U2F keys are a new
OpenSSH key type, so the server must support it too.
I guess it will take a few years until all servers are upgraded.