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.
The keys themselves are not bound to sha1 or sha256. The hash is just used for the ephemeral signatures during authentication (or certificates as mentioned in the release notes). "ssh-rsa" signature scheme at runtime (sha1) will be deprecated, but rsa keys themselves are fine (edit typo name)
Indeed, and so to actually use this $50k attack on SSH you'd need to somehow arrange for your target to pick random numbers you expected so that your attack works. But for clarity, OpenSSH isn't saying this can be used against SSH today - the deprecation is because we should abandon broken hashes before they actually cause us harm, not wait until after. Don't Walk Past.
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.
Exactly. That would be the deliberate steps I mentioned as a gate for this causing a problem. If you give it someone else's key you have a problem, though a minor one unless you've been conned into doing so by an adversary who will later scan for accounts that allow their key pair for auth.
Importing your own public key this way is not problematical at all.
Of course you might end up with people publishing their private key along with the private one, by error or because it seems convenient & they don't think things through...
If you are needing to keep your identity hidden/ambiguous, then you need to be careful with your keys. Don't publish a public key if you don't want it to be public!
These keys and the ways people often used them are very much not designed with privacy as a priority: they are explicitly for proving who you are so you can be given access to something. Key management with regard to keeping different concerns separated is up to the user.
> [...] 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.
Chosen prefix means somebody doing this attack gets to pick the start of both the colliding documents. For example maybe I want two children's stories, one which starts "Donald was an innocent young boy," and the other begins "Steve was a corrupt old gangster,"
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.
It means that you can influence the result by controlling the first part of the input. In other words, you can find an x such that H(x) == H(y) (for x != y) if you get to control the beginning bytes of x and know (or control) the beginning bytes of y.
Notable in this release is support for generating and using keys backed by FIDO/U2F tokens (and, with supported tokens, keys fully resident in FIDO/U2F tokens that you can transport between computers).
I'm happy to see this, however I'd be far more excited if I thought there was a chance of it landing in the upcoming Ubuntu 20.04 release - else I'll likely be waiting impatiently until 22.04 for server-side support.
Likewise, I would be glad to see it in 20.04. According to this page, https://wiki.ubuntu.com/FocalFossa/ReleaseSchedule, feature freeze for 20.04 is on the 27th of February so I don't see any reason why Openssh 8.2 can't make it into the LTS. Unless there are other considerations I'm not aware of.
As a (very) longtime user of SSH, are there any features in (relatively) newer releases that have changed peoples lives?
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.
Yes! Read the realease notes on U2F keys as SSH Keys; this means a cheap ($5-$25 USD) hardware key can now be used as an ssh key! These physical keys require a tap or physical touch to release a signature and are hardened against physical attack.
The FIDO/U2F support is really nice! Though I had a question about this: is it only necessary for the client to use an OpenSSH version (>= 8.2) that supports this, or should the server also have support?
> Fortunately, RSA using SHA1 is not a problem here because the value being signed is actually a SHA2 hash. The hash function SHA1(SHA2(x)) is just as secure as SHA2 (it has less bits of course but no better attacks).