Pulling the Plug

Cryptographic hash functions have a number of properties. For example, one requirement is that a unique checksum with a fixed length can be generated from arbitrary data. Collisions – where two different datasets have the same checksum – must be practically impossible. Finally, cryptographic hash functions are one-way functions, which ensures that it is virtually impossible to reconstruct the original data from the checksum.

These properties are ideal for integrity checking arbitrary data, because it is practically impossible to change a message without also changing the message's checksum. Typical applications for digital signatures include X.509 certificates, PGP/GPG keys, software packages, and DNS entries. Of course, signatures like this are also used when you transmit data over a network to ensure the integrity of the transmitted data.

Insecure Hash Functions

If one of the aforementioned properties no longer applies to a cryptographic hash function in the public domain, it is considered broken and should no longer be used. However, you need to make a distinction between theoretical and practical attacks on the algorithm. Nowadays it is possible to break Message-Digest Algorithm 5 (MD5) [1] with very little effort, which is why it has not been used for some time. The situation is somewhat different with the Secure Hash Algorithm (SHA). The first version of SHA was published by the National Institute of Standards and Technology (NIST) in 1993. The algorithm generates a 160-bit checksum. However, because of a design flaw, a corrected version of the algorithm, commonly known as SHA-1 [2], was released just two years later.

Even for this version, an attack method was presented by Chinese scientists back in 2005, demonstrating that a collision is theoretically possible. The same year saw the publication of an optimized version of this theoretical attack, where a collision was possible with far fewer operations. However, the required computational overhead would have been so massive that an implementation was hardly practical.

From the findings of the initial attacks on SHA-1, NIST nevertheless promptly recommended that SHA-2, a SHA-1 successor, be used from that point on. SHA-2 was published back in 2001, and the hash algorithms belonging to this family have a far longer checksum than SHA-1 – 256 bits (SHA-256) or 512 bits (SHA-512). In 2011, NIST even officially classified the SHA-1 algorithm as "deprecated."

Stubborn

Despite NIST's recommendation to discontinue SHA-1 and despite the availability of a secure successor in the SHA-2 and, later, the SHA-3 family, SHA-1 continued to be used virtually everywhere without a care. Then, in 2017, Shattered [3], a new variant of an attack on SHA-1, was introduced to the general public. Scientists were able to generate two different PDF files with the same checksum but with relatively little overhead compared with previous attacks.

SHA-1 can be regarded as definitely broken since 2020, when chosen-prefix collision attacks succeeded for the first time. This attack makes it possible to generate the same checksum for any two datasets with relatively little overhead and inserts additional byte sequences into the data [4]. Currently, hardware worth less than $35,000 is required for an attack of this type, and it can be assumed that the costs will drop considerably in the coming years.

Software Projects Without SHA-1

In the meantime, many software projects have completely abandoned SHA-1 or have at least severely restricted its use. For example, OpenSSL has not allowed X.509 certificates to be signed with a SHA-1 signature for some time now [5], and OpenSSH has also not allowed RSA keys that use SHA-1 for signing since version 8.8 [6].

If you still want to use the RSA algorithm for the host key of an SSH server, it must be used together with a hash algorithm from the SHA-2 family (e.g., SHA-256 or SHA-512). However, OpenSSH does not support these algorithms below version 7.2 [7]. Alternatively, of course, another algorithm (e.g., the elliptic curve digital signature algorithm, ECDSA) can be used instead. This option is especially interesting for older OpenSSH servers that do not yet support SHA-2. You can create a new host key quite quickly with:

ssh-keygen -t ecdsa -b 384 -f /etc/ssh/ssh_host_ecdsa_key

Then, use the HostKey option and enter

HostKey /etc/ssh/ssh_host_ecdsa_key

in the /etc/ssh/sshd_config OpenSSH server configuration file.