SoylentNews is people
SoylentNews
Dangerous SHA-1 crypto function will die in SSH linking millions of computers:
Developers of two open source code libraries for Secure Shell—the protocol millions of computers use to create encrypted connections to each other—are retiring the SHA-1 hashing algorithm, four months after researchers piled a final nail in its coffin.
The moves, announced in release notes and a code update for OpenSSH and libssh respectively, mean that SHA-1 will no longer be a means for digitally signing encryption keys that prevent the monitoring or manipulating of data passing between two computers connected by SSH—the common abbreviation for Secure Shell. (Wednesday's release notes concerning SHA-1 deprecation in OpenSSH repeated word for word what developers put in February release notes, but few people seemed to notice the planned change until now.)
Cryptographic hash functions generate a long string of characters that are known as a hash digest. Theoretically, the digests are supposed to be unique for every file, message, or other input fed into the function. Practically speaking, digest collisions must be mathematically infeasible given the performance capabilities of available computing resources. In recent years, a host of software and services have stopped using SHA-1 after researchers demonstrated practical ways for attackers to forge digital signatures that use SHA-1. The unanimous agreement among experts is that it's no longer safe in almost all security contexts.
"Its a chainsaw in a nursery," security researcher Kenn White said of the hash function, which made its debut in 1995.
[...] The final death knell for SHA-1 sounded in January, when researchers unveiled an even more powerful collision attack that cost as little as $45,000. Known as a chosen prefix collision, it allowed attackers to impersonate a target of their choosing, as was the case in the MD5 attack against Microsoft's infrastructure.
It was in this context that OpenSSH developers wrote in release notes published on Wednesday:
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.
This algorithm is unfortunately still used widely despite the existence of better alternatives, being the only remaining public key signature algorithm specified by the original SSH RFCs.
[...] In an email, Gaëtan Leurent, an Inria France researcher and one of the co-authors of the January research, said he didn't expect OpenSSH developers to implement the deprecations quickly. He wrote:
When they completely disable SHA-1, it will become impossible to connect from a recent OpenSSH to a device with an old SSH server, but they will probably take gradual steps (with big warnings) before that. Also, embedded systems with an SSH access that have not been updated in many years probably have a lot of security issues, so maybe it's not too bad to disrupt them...
In any case, I am quite happy with this move, this is exactly what we wanted to achieve :-)
(Score: 0) by Anonymous Coward on Tuesday June 02 2020, @01:19PM (4 children)
I don't get it.
(Score: 0) by Anonymous Coward on Tuesday June 02 2020, @03:42PM (1 child)
For the same reason anyone does anything potentially risky, because they've looked at the risks, though 'fuck it, we know the issues, we're deeming the potential risks to be acceptable...'
humans, eh?
(Score: 2) by DannyB on Tuesday June 02 2020, @06:13PM
We can just wear masks and practice social distancing from MD5.
The lower I set my standards the more accomplishments I have.
(Score: 0) by Anonymous Coward on Tuesday June 02 2020, @10:53PM
Here is one to make you shudder: I know legacy systems in use today that use MD4.
(Score: 0) by Anonymous Coward on Friday June 05 2020, @09:07AM
md5 has the benefit of hashing really fast even on old hardware. That makes it great for going through large checksum listings really fast, and the odds of duplicate hashes are pretty low (unlike md4, sha0 and earlier where you could actually find duplicate checksums in listings of files on your own system back in the 1-4GB hard disk days.
Using old checksums by itself isn't bad. It's this assumption that we should ONLY use one checksum that is. If you did interwoven checksumming with multiple checksums iterating over the same block of data at the same time (so it's in the cache) then checksum performance would be negligable compared to duplicated i/o access. And if you use different checksum models on the same data then it becomes mathematically unlikely that the same checksum groups will show up for both the original and modified files, especially when you include file size with them. The point at which they do is when the file size exceeds the effective maximum unique size of that checksum algorithm for the number of characters it outputs. At that point you MUST move to a larger checksum format if you still want non-duplicate hashes in all circumstances.
I still don't get why more organizations don't do this. It helps ensure even if a hash algorithm is compromised that the data remains verifiable and secure, and it reduces the likelihood of even an effective collision attack being undetectable.