Hacker News new | ask | show | jobs
by hannob 3297 days ago
There are a couple of strange things here.

It lists oakley group 14 as insecure with no justification. That's a 2048 bit diffie hellman group and it should be totally fine.

It also lists hmac-sha1 as problematic, although in hmac the weaknesses of sha1 are irrelevant.

I'm not sure about the umac 64 bit block size. That should at least have some more info why it's considered problematic.

Usually OpenSSH is pretty good at deprecating problematic algorithm choices, so I tend to stick with upstream defaults.

2 comments

Hi hannob, I'll re-check the classifications. Pretty sure you're right about the hmac-sha1 being still ok. Wrt oakley 14 and umac64 (and others) I'll try to add more detailed justifications. Thanks for your comment!
It's important to note that "HMAC-SHA-1" is an entirely different construction compared to SHA-1. It is a HMAC that happens to use SHA-1 internally, and it uses it in a way that means it does not yet share weaknesses with SHA-1 as a hash.

Of course, if you are writing something today, you should lean towards HMAC-SHA-256 or 512 as an extra buffer, but choosing to avoid HMAC-SHA-1 because it says "SHA-1" is not a valid reason.

The site also seems to flag RSA host keys. Using SHA1 in this case shouldn't be a security issue since the hash is calculated as SHA1(SHA2(x)) and you would need to break SHA2 as well. [1]

[1] - https://stribika.github.io/2015/01/04/secure-secure-shell.ht...

It shows this as justification right now:

Oakley Group 14 is no longer considered secure enough. SHA-1 is no longer considered secure enough (see shattered.io).

Here is my problem with this statement: SHA-1 can be used in different configurations for different applications. Some are secure, some are not.

People making these blanket statement very clearly demonstrate that they don't understand security and cryptography. Do you really want to use a security tool written by such people?

https://plus.google.com/+LinusTorvalds/posts/7tp2gYWQugL

I disagree with Linus here -- there are hashes which are secure in all ways, and hashes which are broken, like SHA1. Why try to figure out where SHA1 is safe?

Also, git's use of SHA1 is completely broken, it's just that no-one (that we know of) has chosen to spend the money required to make evil git repositories (you can't just take existing collisions and use them in git, you would have to go find git-specific ones).

You'd have to find collisions that are of an identical length and still be useful (i.e. able to do something evil rather than just being a bunch of random data). The current techniques for creating collisions in SHA1 don't make it possible to find identical length collisions. So your statement that nobody has bothered to spend the money to create the collisions is not correct.

Now if you want to say that nobody has spent the time to find a technique to produce identically sized collisions, that would be correct. But that's far from trivial and we don't know that such a technique is guaranteed to exist.

I think you are behind the times. There is already pairs of identical SHA1s, that do "interesting things", like these two PDFs by Google (and others): http://shattered.io/. Both 422435 bytes.
Or you aren't understanding the key statement of his comment

> You'd have to find collisions that are of an identical length and still be useful

Creating a collision is possible, making it work in a way that conforms to the manner of which Git uses SHA1 and also provides the malicious code is the part that the Shattered research did not prove possible.

Git doesn't simply SHA-1 a file or the repo, it's more than that.

Linus:

> I haven't seen the attack yet, but git doesn't actually just hash the data, it does prepend a type/length field to it. That usually tends to make collision attacks much harder, because you either have to make the resulting size the same too, or you have to be able to also edit the size field in the header.

[https://stackoverflow.com/questions/42433126/how-does-the-ne...]