151–160 of 187 posts
One thing SHA-256 has going for it is that millions can be made from finding pre-image weaknesses in it, because it's used in Bitcoin mining. If you could "figure out" SHA-256, and use it to take over Bitcoin mining, you'd make $2M the first 24 hours, at current rates. And if you play it wise, it could take a long time before anyone figure out what's going on. With regards to market price for a successful attack, I d…
The actual mailing list discussion thread can be found here, and is infinitely more informative than any of the bull being spouted in this thread: http://public-inbox.org/git/20170226004657.zowlojdzqrrcalsm@...
My takeaway from all that - the git project is internally taking steps to mitigate vulnerabilities from this particular attack (making it harder to insert the arbitrary binary data necessary into git metadata), but a) is just throwing up their hands at the problem of projects that store binary blobs like image data in their repos, and b) is not taking this as a signal that more serious sha-1 attacks are on the horizo…
The actual mailing list discussion thread can be found here, and is infinitely more informative than any of the bull being spouted in this thread: http://public-inbox.org/git/20170226004657.zowlojdzqrrcalsm@...
My takeaway from all that - the git project is internally taking steps to mitigate vulnerabilities from this particular attack (making it harder to insert the arbitrary binary data necessary into git metadata), but a) is just throwing up their hands at the problem of projects that store binary blobs like image data in their repos, and b) is not taking this as a signal that more serious sha-1 attacks are on the horizo…
edit: rephrase: Git has no security model.
``Other SCM's have used things like CRC's for error detection, although honestly the most common error handling method in most SCM's tends to be "tough luck, maybe your data is there, maybe it isn't, I don't care".''
BitKeeper has an error detection (CRC per block) and error correction (XOR block at the end) system. Any single block loss is correctable. Block sizes vary with file size so large files have to lose a large amount of data to be non-correctable.
Earlier quoted context omitted.
All git repos have "repositoryversionformat", you can bump it. And nobody is going to complain about having to do a fresh clone, given what just happened. "Not having security eggs in one basket" is exactly irrelevant here. Upgrading the hash does not make the other parts of the system weaker, and should have been done years ago. Yes, SHA2 will also become weak eventually - so then you bump it again. The point is to…
> Yes, SHA2 will also become weak eventually - so then you bump it again. I disagree here. I doubt SHA2 or any modern hash will become weak within our lifetime. JP Aumasson, who is one of the experts of the field, agrees with me on that: https://twitter.com/veorq/status/834872988445065218
Reactions to stages in the life cycle of cryptographic hash functions
Stage | Expert reaction | Programmer reaction | Non-expert ("slashdotter") reaction
---------------------+---------------------------------------------+-------------------------------------------------+----------------------------------------
... | ... | ... | ...
General acceptance | Top-level researchers begin serious work on | Even Microsoft is using the hash function now | Flame anyone who suggests the function
| finding a weakness (and international fame) | | may be broken in our lifetime
The actual mailing list discussion thread can be found here, and is infinitely more informative than any of the bull being spouted in this thread: http://public-inbox.org/git/20170226004657.zowlojdzqrrcalsm@...
My takeaway from all that - the git project is internally taking steps to mitigate vulnerabilities from this particular attack (making it harder to insert the arbitrary binary data necessary into git metadata), but a) is just throwing up their hands at the problem of projects that store binary blobs like image data in their repos, and b) is not taking this as a signal that more serious sha-1 attacks are on the horizo…
[1] http://public-inbox.org/git/20170217214513.giua5ksuiqqs2laj@...
Like many volunteer projects, the work would go faster if more people helped. What "the git project" considers important works the same way as "how much is bitcoin worth", or "how much is gold worth". People who think it's important can show the value by putting their effort where they think it is most important. Or, of course, people can snipe from the side-lines, and make themselves feel all self-important.
There has actually been a lot of thought about how to do a graceful transition period, but to also on how switch from a soft cutover to a hard cutover (breaking backwards compatibility and requiring people to upgrade their clients) to allow time for developers to upgrade at a reasonable rate, where reasonable can be defined on a per-git repository basis. So if you want to force a flag day as soon as the code is available, and not wait for stability testing, etc., those people who value security uber ales, and who don't want to rely on trusting kernel.org, etc., can do so.
I will note, though, that most people are doing blind pulls, or worse, blind merges, from developers outside of their immediate circle of trust _all_ _the_ _time_. Heck, people will cut and paste command lines from web pages of the form "curl http://alfred.e.numman/what/me/worry | bash" into root shells all the time! So if you are not auditing every line of code before a git pull, the fact that git is using SHA-1 is the least of your worries.
Personally, if I were a nation state planning on trying to insert the equivalent of a DUAL-EC backdoor into open source software, I'd do that by spending a person year or ten getting a collection of developers to be trusted contributors to some key open source project, like Docker, or Python, or even yes, the Linux kernel or git, and then "accidentally on purpose" introducing a buffer-overrun or some other zero day into said OSS code base. Or heck, just simply invest in finding more zero days that people have inserted into their code just because they're not careful!
So, sure, "we" should upgrade git to be able to support multiple crypto hash algorithms, and there is work going into doing this. But at the same time, it's important to keep a sense of perspective on all of this --- unless, of course, your goal is to make yourself seem important by exuding a sense of self-righteousness.
Earlier quoted context omitted.
My takeaway from all that - the git project is internally taking steps to mitigate vulnerabilities from this particular attack (making it harder to insert the arbitrary binary data necessary into git metadata), but a) is just throwing up their hands at the problem of projects that store binary blobs like image data in their repos, and b) is not taking this as a signal that more serious sha-1 attacks are on the horizo…
That's not all "the git project" is doing. Work to allow git to support an alternate crypto checksums is on-going. One of the key steps is to replace the hard-coded use of char[40] with a "struct object_id" object, and it is about 40% done[1]. [1] http://public-inbox.org/git/20170217214513.giua5ksuiqqs2laj@... Like many volunteer projects, the work would go faster if more people helped. What "the git project" conside…
Do they? I've never encountered anyone using a root shell to go about their business unless they had to do some exclusive operation that could only be done as root, and even then they would rather just sudo that specific operation. Hell, even if they do do that, they have bigger problems than just git, given that cut and paste is inherently broken[1].
Earlier quoted context omitted.
My takeaway from all that - the git project is internally taking steps to mitigate vulnerabilities from this particular attack (making it harder to insert the arbitrary binary data necessary into git metadata), but a) is just throwing up their hands at the problem of projects that store binary blobs like image data in their repos, and b) is not taking this as a signal that more serious sha-1 attacks are on the horizo…
SHA1 is only used for uniqueness. You still need to have write access to repo to perform attack. If you already have write access you do not need to make collision...
Earlier quoted context omitted.
That's not all "the git project" is doing. Work to allow git to support an alternate crypto checksums is on-going. One of the key steps is to replace the hard-coded use of char[40] with a "struct object_id" object, and it is about 40% done[1]. [1] http://public-inbox.org/git/20170217214513.giua5ksuiqqs2laj@... Like many volunteer projects, the work would go faster if more people helped. What "the git project" conside…
> people will cut and paste command lines from web pages [...] into root shells all the time! Do they? I've never encountered anyone using a root shell to go about their business unless they had to do some exclusive operation that could only be done as root, and even then they would rather just sudo that specific operation . Hell, even if they do do that, they have bigger problems than just git, given that cut and pa…
sudo -v && wget -nv -O- https://download.calibre-ebook.com/linux-installer.py | sudo python -c "import sys; main=lambda:sys.stderr.write('Download failed\n'); exec(sys.stdin.read()); main()"
Or you can trust my docker image, where I've done this for you:
https://hub.docker.com/r/tytso/calibre/
(Hint: blindly using my docker image is only slightly better from a security perspective. What you _should_ do is download the dockerfile, audit it carefully, and then create your own docker image. And then you're _still_ trusting the Calibre folks to have access to your X server....)
Earlier quoted context omitted.
I am likewise perplexed why "cryptographic hash functions are unnecessary in the absence of an attacker" is such a difficult concept for you to grasp. It is not an "odd angle". It is literally the very purpose for which they were created in the first place: to defend against attacks (preimage, collision) If there are no attackers, the cryptography buys you nothing and merely makes the system slower. Again, to go back…
I recently worked on a project where I had to choose a hash function for non-cryptographic error checking. I investigated CRC in detail for it, even wrote two different implementations from scratch. CRC-X is complicated to use and terrible choice. First of all, it is not a single algorithm, it is a family of algorithms . For a CRC of size N, you have to also choose a N-bit polynomial, N-bit starting value, and N-bit…
So why SHA-1 over MD5 which probably is move available and order of magnitude faster ? what problems MD5 has outside of its security that SHA-1 does not ?