
Dangerous SHA-1 crypto function is about to die in SSH - headalgorithm
https://arstechnica.com/information-technology/2020/05/dangerous-sha-1-crypto-function-is-about-to-die-in-ssh/
======
upofadown
>The unanimous agreement among experts is that it's no longer safe in almost
all security contexts.

Except for the great many security contexts where chosen-prefix collisions are
not problematic. NIST for example has suggested SHA-1 is acceptable for such
applications ("Hash (B)") for "2019 - 2030 & beyond".

* [https://www.keylength.com/en/4/](https://www.keylength.com/en/4/)

~~~
zaarn
The german BSI does not recommend SHA1 and NIST only recommends it for 128bit
security applications. And knowing if your application is not vulnerable to
prefix attacks can be a bit of a challenge, depending on what you do. If you
have to ask yourself what to use, you probably shouldn't be starting to use
SHA1. If your application supports it, then you're good to go for "2020 - 2030
& beyond", otherwise I'd just go with SHA256/SHA3-256 or even SHA512/SHA3-512.

~~~
upofadown
From the 2020 BSI report:

>From a security-technical perspective, however, there is, according to
present knowledge,no reason speaking against using it in constructions which
do not require collision resistance...

~~~
zaarn
Just because there is no reason against using something doesn't mean it's a
good idea. They recommend SHA256 and upwards, they see no reason that SHA1
must be removed immediately from some corners of cryptography, those are no
conflicting viewpoints.

Just don't use SHA1 unless you absolutely are forced to do so, not when you
make something new from scratch that can use SHA256.

~~~
upofadown
For all we know using SHA-1 where collisions are not an issue _is_ a good
idea. This sort of question has already came up for MD5 used where collisions
were not an issue. Everyone spent a lot of time, money and compatibility
moving away from MD5. We were told to move to SHA-1 which is now broken in the
same way. It was pointless effort caused by pointless hysteria. Now we have
pointless SHA-1 hysteria...

~~~
zaarn
Maybe stop hardcoding cryptoalgo's so you have to spend a lot of money to
migrate? This is why protocols like TLS support negotiations.

------
rwmj
One of the things we do at Red Hat is migrate virtual machines off RHEL 5-era
Xen to modern KVM, and one of the problems we have is that you can no longer
ssh into a RHEL 5 machine from a RHEL 8 machine because there's no common set
of cyphers available. Currently you can work around this by relaxing the RHEL
8 machine's crypto policy to include "legacy"[1], although I wonder how long
that option will be available.

For reference RHEL 5 was released in 2007 and is supported to the end of this
year for some customers.

[1] [http://libguestfs.org/virt-v2v-input-xen.1.html#ssh-
authenti...](http://libguestfs.org/virt-v2v-input-xen.1.html#ssh-
authentication)

~~~
user5994461
RHEL 6 is going end of support in November 2020. RHEL 5 has been out of
support for quite a while.
[https://en.wikipedia.org/wiki/Red_Hat_Enterprise_Linux#Produ...](https://en.wikipedia.org/wiki/Red_Hat_Enterprise_Linux#Product_life_cycle)

Of course there are extended extended extended support programs for companies
who are willing to pay.

RHEL 5 is unusable at this point in time. It can't even run a HTTPS request to
other systems because it's doesn't support TLS. It can't compile any software
because it's stuck on gcc from more than 10 years ago.

My company is upgrading the last machines from RHEL 6 and they're causing
quite a bit of issues due to all the packages and operating systems being
obsolete. It's reaching a point where it's less trouble to upgrade than to
keep running. I can't imagine people still running on RHEL 5 willingly, they
must be stuck running old software whom source code was lost.

~~~
rwmj
RHEL 5 ELS ends Nov 30th 2020 (source:
[https://access.redhat.com/solutions/690063](https://access.redhat.com/solutions/690063)).

I agree on your other points though, but for some customers they still want to
run RHEL 5 and it may not be a priority for them to do TLS requests or run GCC
on new software - if they haven't been doing that on RHEL 5 up til now, why
would they start? They often have some old database or bit of software that
keep chugging along and would cost money to replicate or replace.

We even offer a way to virtualize RHEL 5 servers so you can keep them running
on "new" (virtual) hardware.
([http://libguestfs.org/virt-p2v.1.html](http://libguestfs.org/virt-p2v.1.html))

~~~
user5994461
Systems have to continue to run and to interface with other systems (that
shift over time). There isn't an option to never do a HTTPS request or never
compile anything.

Should clarify that the end-of-life schedule is coinciding for many platforms:
RHEL 5 and RHEL 6, java 7 + 8, windows server 2008 + 2012, python 2.

I don't think it's possible for RHEL 5 upgrade to not be an emergency priority
at this stage. It's not able to run or to communicate with much of anything
else (all platforms dropping SSL is one issue for example). What is the
company gonna do when they can't curl and ssh between systems anymore?

------
usr1106
Good that arstechnica clearly explains that SHA-1 is the problem here. The
protocol in question is called ssh-rsa, which easily leads to the
misunderstanding that RSA keys would be deprecated.

If I as a non-cryptographer understood it correctly the keys can remain, but
different fingerprints are needed. Is it so that you have fingerprints in
known_hosts, but not in authorized_keys?

~~~
mkj
The authorized_keys file will not change.

ssh-rsa as a key format will stay (it isn't specific to sha1 or sha2), just
the client and server need to upgrade to sign/verify session-specific
signatures using sha256 instead of sha1. rsasign(sha1(sessiondata)) becomes
rsasign(sha256(sessiondata)).

OpenSSH CA certificates are more urgent to upgrade since those are/were long
lived sha1 signatures - sha1 there got disabled a couple of releases ago I
think.

The article seems bit sensational and lacking understanding.

------
fortran77
> Theoretically, the digests are supposed to be unique for every file,
> message, or other input fed into the function

Given that the digests are shorter than the messages they are meant to
identify, this is not at all a "theoretical" possibility (you can prove this
with a "pigeonhole" proof).

~~~
dasnab
I think they meant that the input should be unique for every two inputs
_actually fed_ into the function. That is, there are many, many collisions,
but they won't ever be found in our lifetime.

------
knorker
So if ssh-rsa is going away, does that mean millions of smart card second
factors will be bricked?

Or since it's not RSA being taken out, is this just a matter of updating
.authorized_keys with new SHA256 hashes for the same keys?

~~~
tialaramex
Neither. The smart card just makes RSA signatures over input data, and an
updated SSH client will use SHA256 rather than SHA-1, as input data so nothing
changes for the smart card.

The Authorized Keys list is of actual public keys, not hashes, so that doesn't
change. That's why the line length is much longer for a larger key (e.g.
4096-bit RSA) and shorter for small key like ECDSA.

~~~
knorker
Doh, of course. Think-o on my part. Thanks.

So in what sense is "ssh-rsa" going to be removed? Just as a protocol enum,
with no user-visible impact for these purposes?

~~~
tialaramex
Both future clients and servers will refuse to do this algorithm, so it
becomes user visible if your clients are not new enough to know anything
acceptable to your servers or vice versa.

The ssh-rsa algorithm is one of two authentication algorithms described in the
first SecSH (IETF standardised SSH version 2) documents in 2006. The other
(ssh-dsa) was never very popular and has been untrustworthy for a long time.
So up until this point even a very old client or server could expect to
interoperate with the latest software using ssh-rsa. Of course an individual
setup might forbid this, but in general it could work. The announced change in
OpenSSH means it will be necessary to give up on very old systems because
they're incompatible, or else use a shim to restore compatibility if that's
essential for you.

This previously happened with SSH version 1 - once upon a time OpenSSH could
interoperate with SSHv1, then it required a config override to allow that, and
then they removed the compatibility from their source code entirely, but SSHv1
pre-dates the widespread modern popularity of SSH, so it probably had less
impact than this will.

------
grizzles
We need a new default hash algorithm for general purpose stuff, because sha512
is a bit too long for copy/paste imho.

I propose shac = sha1sum(sha512sum(data)) - for sha concatenated.

Thoughts?

~~~
WatchDog
How much of exploitability of SHA1 is due to cryptographic weaknesses, and how
much are due to it's digest size?

If you were able to generalize the SHA1 algorithm, to 256 bits, would it still
be in the realm of exploitability?

~~~
kroeckx
SHA1 is 160 bits and should have a complexity of 2^80 for collision
resistance. The last paper puts a chosen-prefix collision at 2^63.4.

