121–130 of 369 posts
Just a curiosity, since people are talking about Git still using SHA-1 (despite work on SHA-256 since 2017). I see that Git doesn't actually use SHA-1 any more, it uses "hardened SHA-1": https://stackoverflow.com/questions/10434326/hash-collision-...
Earlier quoted context omitted.
The GP was likely hinting at SHA1 being an hashing function, non an encryption function, so just applying sha* wouldn't produce a working backup
It probably will if your data is less than 128 bytes, and you're willing to wait a few decades to decrypt it.
Earlier quoted context omitted.
Downvoted. There's no ISO standard for English, since language is a social phenomenon. "Correct" language is whatever the community of speakers uses in practice, not what someone claims is correct in a blog post (or even a book).
And the linked article showed you that, in practice, "a shambles" is perfectly correct English. It is therefore correct in a descriptivist sense. Beyond that prefixing your comment by "downvoted" is frankly silly and only serves to derail the conversation IMO.
I'd think "in practice" would mean evidence of contemporary usage.
Just a curiosity, since people are talking about Git still using SHA-1 (despite work on SHA-256 since 2017). I see that Git doesn't actually use SHA-1 any more, it uses "hardened SHA-1": https://stackoverflow.com/questions/10434326/hash-collision-...
Well, according to that reference, it's hardened against a specific, previously known attack. Do you have any information on whether that also protects against the different, new attack which was just published?
Quick question about the "What should I do" section. It says " use instead SHA-256 ". Isn't SHA-512 both better and faster on modern hardware?
SHA-512 is faster than SHA-256 in software on 64-bit machines. That's a more important difference than the security level. However, there are two major caveats to consider: 1) Hash function performance is more likely to matter on cheap (non-64-bit) hardware where everything is slow, than on fancy hardware where everything is fast. 2) Some x86 and ARM chips have hardware accelerated implementations of SHA-256, but not of SHA-512.
Earlier quoted context omitted.
It probably will if your data is less than 128 bytes, and you're willing to wait a few decades to decrypt it.
You might be able to find bytes that result in your hash, but they probably won't be the same bytes you 'backed up'.
Earlier quoted context omitted.
It adds to the weight of the argument, but there isn't a big issue. This article ( https://www.zdnet.com/article/linus-torvalds-on-sha-1-and-gi... ) and the linked email ( https://marc.info/?l=git&m=148787047422954 ) both seem to still apply.
Further details as to why Torvalds is not concerned: From the email... "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." [...] "I haven't seen the attack detail…
With this chosen-prefix attack, they chose two prefixes and generated collisions by appending some data. So your two prefixes just need to be "tree {GOOD,BAD}\nauthor foo\n\nmerge me\0"
The only thing preventing injecting a backdoor into a pull request now seems to be git's use of hardened sha1.
> SHA-1 has been broken for 15 years, so there is no good reason to use this hash function in modern security software. Why are cryptographers always exaggerating things and so out of touch with reality? The first actual collision was like 3 years ago. It's not like the world has been on fire in the meantime, and it's not like SHA-1 is broken for every single possible usage even now. And why the nonsense with "no goo…
Depreciating things takes a long time. It could be 10 years before 'that guy' in your office gets it in to his head that SHA-1 isn't appropriate where security is concerned. Thus you want to make it unambiguous that now is a good time to move to something else so that when it is thoroughly broken in 10 years time you're minimising the number of people who have yet to switch.
Deprecating things does take a long time, and the only practical thing to do about that is to get ahead of the game as you say.