Hacker News: hn_p4ttern

New comment by hn_p4ttern in "First practical SHA-256 collision for 31 steps. fse2024"

hn_p4ttern — Wed, 27 Mar 2024 17:03:49 +0000

> "I believe there is one more step. You have to somehow get the collision into the repository."

Yes, Exactly. So, is it necessary to change SHA-1 having in git ? At the moment, I think there is no reason because SHA-1 doesn't expose security vulnerabilities or functional issues.

New comment by hn_p4ttern in "First practical SHA-256 collision for 31 steps. fse2024"

hn_p4ttern — Wed, 27 Mar 2024 17:01:14 +0000

> "For now the SHA-1 collisions are easily detectable, but it could get worse."

Your opinion: prove it! And Again, if you instead of trolling actually read the post in THIS BRANCH , the question is: shout SHA-1 inn GIT be substituted ?

New comment by hn_p4ttern in "First practical SHA-256 collision for 31 steps. fse2024"

hn_p4ttern — Wed, 27 Mar 2024 15:21:17 +0000

My point is: why you should change hashing algorithm in GIT ??? Let's elaborate:

1. Do SHA-1 put a security risk in GIT ?

2. Is that practically exploitable in any way?

In some application, for example password hashing, SSH MAC, etc, you have good reasons to change hashing algorithm when it became obsolete: because an attacker can be computationally advantaged to crack a password, to compromise the integrity of transmitted packets, etc.

But not because an hashing algorithm became obsolete for some application is obsolete for ALL possible application. Moreover, in some specific application could be DESIRABLE a fasted hashing algorithm.

So why You should change SHA-1 in GIT ?

>> "But a few more of these tricks and I can see those "garbage comments" collision happening"

I don't think so, is computationally astronomically difficult whatever tricks yo u invent. The point here IS NOT to generate a collision adding "garbage comments", again, is to alter the behaviour of committed code in a functional way.

>> "Even without language models you could use something like a language's EBNF grammar as a token generator for source code which would probably pass any glance checks, but definitely not dedicated inspection like a code review. That is probably something that IS PRACTICAL TODAY for SHA1"

Yeah, prove it!

New comment by hn_p4ttern in "First practical SHA-256 collision for 31 steps. fse2024"

hn_p4ttern — Wed, 27 Mar 2024 14:21:48 +0000

1) We are talking about sha1, md5 is out of topic

2) This is the main topic ! Being able to generate >>valid code<< with a >>specific purpose<< , so that GIT have to change its hashing algorithm;

3) A.K.A your answer is total nonsense.

Everyone else, ok, I'm listening, give proof that you can change code on GitHub stealthy messing with hashing, moreover inserting a "payload" creating a SHA-1 collision in a reasonable computational time, everything else is BS.

New comment by hn_p4ttern in "First practical SHA-256 collision for 31 steps. fse2024"

hn_p4ttern — Wed, 27 Mar 2024 10:26:28 +0000

IMHO "be padded into a comment" is included in "is valid code", still 1 in is a good approximation of that probability.

Please, correct me if I'm wrong.

New comment by hn_p4ttern in "First practical SHA-256 collision for 31 steps. fse2024"

hn_p4ttern — Wed, 27 Mar 2024 10:05:19 +0000

Is it used to sign a commit, right ? Which are the probabilities to have a collision that:

a) is still code

b) is still code AND is code similar to a previous commit

c) is still code AND is code similar to a previous commit AND is valid

d) is still code AND is code similar to a previous commit AND is valid AND makes sense for something

OR at least

a) is still code

b) is still code AND is valid

d) is still code AND is valid AND makes sense for something

Let me know.