191–200 of 273 posts
Earlier quoted context omitted.
Package managers allow you to download from git repositories too. He'd suffer from the same attack vector.
Erm... Which ones?
Earlier quoted context omitted.
Wow, Linus raises an entirely different issue which is that the PDF-based attack won't work on git at all . Due to length prefixing, it is extremely difficult to insert nonsense into the middle of a git object which is how this attack works on PDFs. Linus correctly notes that using the first forty bytes of SHA-256 is an option if an attack against git's use of SHA1 were developed. 1) Git doesn't rely on SHA-1 for sec…
> Wow, Linus raises an entirely different issue which is that the PDF-based attack can't and won't work on git at all. Due to length prefixing it is extremely difficult to insert some nonsense into the middle of a git object which is how this attack works on PDFs. Please note that the shattered-{1,2}.pdf files both have exactly the same length. And even with cleartext it is easy to pad passages so they contain the sa…
The Git docs have some very specific claims about cryptographic integrity of git: https://git-scm.com/about/info-assurance These claims are wrong as long as it uses SHA-1. Full stop. It'd be really nice if git had cryptographic integrity. Not just because it'd prevent some attacks on git repos, but because it'd make git essentially a secure append only log. Which would be interesting, as it'd more or less automatical…
Like for instance rebases?
The Git docs have some very specific claims about cryptographic integrity of git: https://git-scm.com/about/info-assurance These claims are wrong as long as it uses SHA-1. Full stop. It'd be really nice if git had cryptographic integrity. Not just because it'd prevent some attacks on git repos, but because it'd make git essentially a secure append only log. Which would be interesting, as it'd more or less automatical…
Some more advanced Git operations (I sadly never needed so far) can be used to break the "append only" part, right? Like for instance rebases?
Earlier quoted context omitted.
> In 20 years, the $100,000 attack will be a $100 attack (or perhaps a $1 attack) No. Moore's Law has been dead for years and will never come back. The benefits we saw in recent years came from people figuring out how to compile code for SIMD processors like GPU's, not faster or cheaper silicon.
Moore's law still holds, and is expected to hold true until at least 2025 (see wikipedia). I don't think it will be done by then, but that is just guess work.
Pertinent facts for the worried: 1) Git doesn't rely on SHA-1 for security. It relies on HTTPS, and a web of trust. 2) Even if git did rely on SHA-1, there's no imminent threat. What happened today was a SHA-1 collision, not a preimage attack. If a collision costs 2^n, a preimage attack costs 2^(2n). 3) Even if someone managed to pull off a preimage attack, creating a "poisonous" version of one your git repository's…
> 1) Git doesn't rely on SHA-1 for security. It relies on HTTPS, and a web of trust. Some security-focused developers sign git tags and/or commits, specifically to have things verifiable end-to-end and not having to trust HTTPS and all the middle men that entails. Would that not be a case where git relies on SHA1 for security? Someone could replace a tag or commit with a malicious version that verifies fine since it…
This is a completely orthogonal, separate layer of security that has nothing to do with this particular issue.
Earlier quoted context omitted.
apt-get can (and do) check signatures of repos But yeah, you could put an unverified repos to be used
Git has tag signing, surely there's a way to clone a specific tag and check the signature against a specific GPG key fingerprint?
git checkout 0.1.0
git tag -v 0.1.0Earlier quoted context omitted.
That's not entirely true. You could fork a popular git repo, and then make some kind of patch for a bug in some seldomly changed file. Then force a collision in the new file with the benign change as well as your poisoned version. Then they could convince you to pull in the changes. Then they could reset their repository to the one with the poisoned version and anyone who pulls from them first would get the poisoned…
thats stretching it. if you could convince anybody to pull from you then why even bother to go to a great expense of creating a collision.
Earlier quoted context omitted.
apt-get can (and do) check signatures of repos But yeah, you could put an unverified repos to be used
Git has tag signing, surely there's a way to clone a specific tag and check the signature against a specific GPG key fingerprint?
Tag signatures are mostly worthless now from a crypto point of view -- with the caveat that you can still get some value from them if you still trust sha1 to be secure against second-preimage attacks.
Earlier quoted context omitted.
Don't forget the extra computation cost with a more complex hash.
Nobody cares. Hashes are plenty fast. Even the code complexity doesn't matter: I've implemented both SHA-256, and SHA-512, take less than a hundred lines of code. And of course, Linus would have use some existing implementation. Also, "more secure" doesn't necessarily mean "more complex", or "slower". Blake2b for instance is as fast as md5 and has a simple RAX (xor, rot, add) core from Chacha20.