Hacker News Reader

Comment by oaiey | Hacker News Reader

well... strictly speaking ... how can a git repo exist when a single artifact is blocked. the hashes will not sum up anymore.

View on HN

The hashes will sum to something. To do it, at least as far as I understand, you'd have to use https://git-scm.com/docs/git-filter-branch . This will create a divergent history and the new master branch or any other branches that exists will have to be forced pushed. As far as "but local copies of the repo will have the 'problem files' still" - Yes they would. All parties would have to be notified of the legal request.

I'm not a copyright expert but it seems like enforcing this is another step in the erosion of fair use. Something about transformative works. The problem was transformed into a solution.

On the other hand hackerrank's terms of service should have banned this activity. I would imagine it does. I'm not sure how much leverage that gets them legally though. I suppose once you intend to publish it you're no longer an authorized user, and then you're violating that https://en.wikipedia.org/wiki/Computer_Fraud_and_Abuse_Act we see get applied harshly from time to time.

Well, GitHub seems to be able to remove single `globalMaximum.hs` file from https://github.com/cmk/HR-Haskell

This is a great point. The author would have to rebase and force push. Or at least Github could try to selectively block access in the web UI.

Since we're getting technical, couldn't you could find a hash collision in the repo without the artifact to make them sum up again?

No, that's not how it works. (Finding a hash collission for an existing hash would be a preimage attack, and that's not possible for SHA1 with computing power available to humans.)

SHA-1 collisions have been proven as an attack vector for a few years now.

https://security.googleblog.com/2017/02/announcing-first-sha...

And, as the parent correctly pointed out, that would be a preimage attack, which is far harder.

In theory. In practice, since you roughly know the contents of the file, you could probably brute-force it pretty efficiently.

That just makes it a second preimage attack, which even SHA-1 is still resistant to.

SHA-1 as cryptography was broken in 2005. The first collision created by humans was in 2017.

See https://shattered.it for the practicals.

SHAttered is a collision attack. A collision attack is easier than a preimage attack. There are no known preimage attacks against SHA-1.

... Or even against MD5, IIRC, which is why you are still kind of able to use HMAC-MD5. You probably still shouldn’t, but I don’t know of any other symmetric authenticator that is as short and requires neither vast tables of constants nor 64-bit operations for an implementation. (For all the recent lightweight crypto work, the only cipher I can reasonably see myself implementing on an oldish ATMega without disgust is the NSA’s Speck, with all the accompanying caveats, and there isn’t a single hash of a comparable complexity at all.)

I never wrote shattered is a preimage attack. What I wrote is exactly correct. There are multiple preimage attacks, neither of which I referenced.

A first preimage is where one searches for h(m1)=h(m2). A second preimage attack is where, given m1, find m2 such that h(m1)=h(m2).

It's best not to give the incorrect impression when discussing something exact. As with any crypto, the construction is either valid or not, but it is actually the use of the construction that determines real world correctness.

For example, if SHA-1 is used over input where there is known data in specific positions, that is quite different to SHA-1 over unknown data. In pratice, the first is often the case.

Reply on news.ycombinator.com