341–350 of 524 posts
Earlier quoted context omitted.
Git was released in 2005, 12 years ago, and it's based around SHA-1. They've done a massive miscalculation there.
OTOH, 12 years of reliability from a checksum in the age of Moore's law and quantum computers is pretty good, frankly. I don't think they ever expected sha-1 to survive forever.
In fact I intended to refer to the 10 year figure as massive miscalculation here.
Even the simplest messages have ambiguity.
https://security.googleblog.com : "This website uses a weak security configuration (SHA-1 signatures), so your connection may not be private."
I get a SHA256 certificate for that site. What user agent are you using? Is there some kind of middlebox on your network, or do you use AV software that intercepts TLS connections?
Earlier quoted context omitted.
I get a SHA256 certificate for that site. What user agent are you using? Is there some kind of middlebox on your network, or do you use AV software that intercepts TLS connections?
Fair enough, I was using Chrome "Version 50.0.2661.102 (64-bit)" on Linux Mint. I have updated it to 56.0.2924.87, now I'm getting a full error page "Your connection is not private" NET::ERR_CERT_WEAK_SIGNATURE_ALGORITHM. I need to search for this issue now. No I'm not using anything that intercepts TLS connections. EDIT: It's fixed now, `sudo apt-get install libnss3-1d`. http://askubuntu.com/questions/880695/neterr-…
On a quick scroll of the comments, I haven't seen this posted so far: http://valerieaurora.org/hash.html We're at the "First collision found" stage, where the programmer reaction is "Gather around a co-worker's computer, comparing the colliding inputs and running the hash function on them", and the non-expert reaction is "Explain why a simple collision attack is still useless, it's really the second pre-image attack…
So from a security standpoint if my hash was a sha-1 concatenated to an MD5, how long would it be before they found a collision?
Earlier quoted context omitted.
The severity between the preimage attacks depends on context. For Git, for example, a first-preimage attack won't buy you anything, but a second-preimage could be potentially devastating depending on how lucky you get. If Mallory wanted to make it look like you signed a document you didn't, second-preimage would be devestating. And with the demonstration of two PDFs sharing the same hash, this is a pretty severe one:…
If you can do a first-preimage attack, you can do a second-preimage attack. Just hash the document you have. Therefore a first-preimage attack is strictly more severe.
Edit: I misinterpreted your message. I added "same" above to convey what I thought you were saying.
Earlier quoted context omitted.
> What is currently still not feasible is to create a custom git repository whose HEAD matches that of the Linux kernel. I'm not convinced that's good enough. In git, the SHA1 is always the hash of a gzip, which is subject to tricks[1] where a header might be prepared and then some padding inserted to collide a malicious tail. [1]: http://swtch.com/r.zip
Nobody's saying it's "good enough". Once we see one attack we expect to start seeing more. What's being pointed out here is that this particular attack does not let you craft custom git repos whose HEAD matches one of an existing repo. Nobody is asserting that to be generically impossible, and this new attack is at least weak evidence that such an attack may eventually be practical.
Earlier quoted context omitted.
It's almost certain that intelligence agencies could invest this effort to say, break SHA1 SSL certs. To the contrary, it is unlikely that they can do so. There is a world of difference between "come up with two things that hash to the same value" and "come up with something that hashes to a particular known value". It gets harder still if you're trying to add constraints about the format of your text (such as making…
So the Birthday Problem, basically?[1] https://en.wikipedia.org/wiki/Birthday_problem
Earlier quoted context omitted.
If you can do a first-preimage attack, you can do a second-preimage attack. Just hash the document you have. Therefore a first-preimage attack is strictly more severe.
Getting the first-preimage of the document and hashing that same preimage just gives you back the original hash---it's like an identity function. It doesn't give you a second document. Edit: I misinterpreted your message. I added "same" above to convey what I thought you were saying.