201–210 of 210 posts
Earlier quoted context omitted.
No, because reversing the hash has infinite possible answers (well, "very many" for bounded input size). You can't decompress 32 bytes into 1GB because you don't know which of the 1GB-sized answers is the intended one.
Natural data is easily identifiable.
Earlier quoted context omitted.
Commits aren't patches. They contain the whole tree. Retroactively changing a commit can't possibly introduce conflicts with other commits on top of it, the worst it can do is introduce big funny-looking diffs.
It's true that semantically git commits store the whole tree but doing that naively would be inefficient. Instead, packfiles will store some objects as deltas which could either result in inconsitencies or noticeable knock-on changes if the original object contents are changed.
For example, suppose you started with a commit graph that looked like this:
C1 --- C2 --- C3
\ \ \
T1 T2 T3
\ \ \
F1 - - F2 - - F3
C1 --- C2'--- C3
\ \ \
T1 T2' T3
\ \ \
F1 - - \ - - F3
\
F2'
Fortunately, Fossil can now use SHA3-256 as well as SHA-1 (even in the same repository if necessary, perhaps due to upgrading an older repository), and I think it also has a hard mode to detect if SHA-1 collisions seem likely. (I think git doesn't allow a repository to have multiple kind of hashes; from what I understand, only a single algorithm must be used.) Since SHA-1 and SHA3-256 have different hash length, you…
Unfortunately Fossil uses a fast SHA hash for the password hashes of user accounts in the database, rather than a key derivation function, which is disappointing.
If someone gets hold of the hashes, they already have everything. So, whats the threat that is enabled by poor pw hashing?
Anyways, passwords should always be hashed with good password hashing functions (not all kdf are good for that) even if it is not strictly necessary. Just in case.
Earlier quoted context omitted.
This is why I always get mad when people say something like "you are more likely to be struck by lightning than eaten by a shark!".... we'll, that REALLY depends on where you are.
> that REALLY depends on where you are There's only 10 fatal shark attacks per year. What's your calculation for the sharkiest area to live? It has to be something like 100+ times sharkier than average for your claim to be true. And keep in mind that half the US population can easily day trip to the ocean. Edit: Actually, that's using a number of 2000 lightning fatalities which might be 10x too low. And lightning inj…
And if I live in a place where there is very rarely lightning, that chance gets really low as well.
I’ve wondered for a while if it is viable to use multiple hashes, or nested hashes, to mitigate these vulnerabilities, for example: message+hash1(message)+hash2(message) message+hash1(hash1(message)) To my lay understanding, it would provide multiple chained validation steps, but I’m curious if there are any obvious flaws with this model.
(With the technical caveat that doing at least two serial hashes does improve the properties of the hash function by defending against length extension attacks. That's why things like HMAC do multiple chained hashes. But it does zilch for collision or preimage resistance.
Earlier quoted context omitted.
Or roughly 1.3M GPU hours. Less as GPUs get upgraded. Not sure how many AWS F1 (FPGA) hours it would take.
So somewhere between $300,000 (running consumer GPUs cheaply) and $30 million (paying AWS on-demand prices for Tesla V100). Even the upper bound for that seems well worth it for well-funded attackers if the target is juicy enough.
Earlier quoted context omitted.
You focused on the shark side and not on the lightning side. You will never get struck by lightning in a city, so there the probability is 0. Similarly if you go out swimming in the ocean on a sunny day the probability of getting struck by lightning is also 0, but the probability of getting eaten by a shark is not 0.
0 is not a probability; trying to use it as one leads to division-by-zero errors.
Earlier quoted context omitted.
> that REALLY depends on where you are There's only 10 fatal shark attacks per year. What's your calculation for the sharkiest area to live? It has to be something like 100+ times sharkier than average for your claim to be true. And keep in mind that half the US population can easily day trip to the ocean. Edit: Actually, that's using a number of 2000 lightning fatalities which might be 10x too low. And lightning inj…
It also depends on what you are doing. If you are spear fishing in shark filled waters, you have a much higher chance of being bitten by a shark. And if I live in a place where there is very rarely lightning, that chance gets really low as well.
Like I said in my other comment, it's not about finding one specific guy. Picking a place where people live is a reasonable starting point for making a rebuttal to a general statement like that. I don't think pointing at Fisherman Sam is.
> And if I live in a place where there is very rarely lightning, that chance gets really low as well.
How low can that number go? The numbers I picked made consideration for some amount of variation in lightning. Does lightning have a huge variance?
It's important to have real numbers when you're making the claim that there are places where the lightning:shark ratio is multiple orders of magnitude lower than the average. That's not a claim you can justify by merely pointing out that the risks will vary by location.
Git was created 16 years ago. The impending breakage of SHA-1 was known even at that time, just like how MD5 had been broken before it. I'm honestly still shocked that updating the hashing algorithm wasn't built into Git from day one. I really wonder why. Did people think this wouldn't happen? Were they so in love with the performance of C/C++ being able to pass around 20 byte hashes on the stack without worrying abo…
> I'm honestly still shocked that updating the hashing algorithm wasn't built into Git from day one. I really wonder why. The first basically functional version of Git was created in less than a month by Linus Torvalds, immediately after Bitkeeper revoked the license/permission for linux kernel developers to use that proprietary source control tool for free. Linus took a look at Monotone and Mercurial IIRC, but they…
That's incorrect for Mercurial, it was started by another kernel developer (Matt Mackall) at the same time, for the same reasons (but they ended-up with different trade-offs, which makes mercurial still very interesting and relevant in a post-github world).