Linus' reply on Git and SHA-1 collision
1–10 of 273 posts
Re: Linus' reply on Git and SHA-1 collision
#2I prefer the entire thread: http://marc.info/?t=148786884600001&r=1&w=2
Re: Linus' reply on Git and SHA-1 collision
#3Re: Linus' reply on Git and SHA-1 collision
#4Do you know if git objects' size header was designed to deal with a possible collision or does it serve another purpose as well?
Just some context - git calculates an object's name by his content in the following way. Say we have a blob that represent a file who's content is 'Here be dragons', then the file name would be:
printf "blob 17\0Here be dragons\!\n" | openssl sha1
# => a54eff8e0fa05c40cca0ab3851be5aa8058f20ea
Re: Linus' reply on Git and SHA-1 collision
#5Normally I eye roll whenever I see that there is some sort of reply to anything from Linus, but this time I agree with him.
Re: Linus' reply on Git and SHA-1 collision
#6I prefer the entire thread: http://marc.info/?t=148786884600001&r=1&w=2
the ratio of relevant new relevant to this problem information/new information is low.
If a low signal/noise ratio is still the purpose of information then the thread is less interesting than Linus mail:
- if we add size it will make forgery harder - yes SHA1 should be replaced
What linus is missing is people rewriting history. This will not be a concern for git, but certainly will for any crypto currency relying on SHA1 in a close future. (Hint this transaction belonged to me)
Re: Linus' reply on Git and SHA-1 collision
#7I prefer the entire thread: http://marc.info/?t=148786884600001&r=1&w=2
the ratio of relevant new relevant to this problem information/new information is low. If a low signal/noise ratio is still the purpose of information then the thread is less interesting than Linus mail: - if we add size it will make forgery harder - yes SHA1 should be replaced What linus is missing is people rewriting history. This will not be a concern for git, but certainly will for any crypto currency relying on…
What does that have to do with git?
Re: Linus' reply on Git and SHA-1 collision
#8Do you know if git objects' size header was designed to deal with a possible collision or does it serve another purpose as well? Just some context - git calculates an object's name by his content in the following way. Say we have a blob that represent a file who's content is 'Here be dragons', then the file name would be: printf "blob 17\0Here be dragons\!\n" | openssl sha1 # => a54eff8e0fa05c40cca0ab3851be5aa8058f20…
Actually AFAIK this specific attack doesn't let the two files have different lengths, so the size header is irrelevant anyway.
Re: Linus' reply on Git and SHA-1 collision
#9I prefer the entire thread: http://marc.info/?t=148786884600001&r=1&w=2
the ratio of relevant new relevant to this problem information/new information is low. If a low signal/noise ratio is still the purpose of information then the thread is less interesting than Linus mail: - if we add size it will make forgery harder - yes SHA1 should be replaced What linus is missing is people rewriting history. This will not be a concern for git, but certainly will for any crypto currency relying on…
I'm not aware of any crypto currencies that rely on SHA1.
Can you name one that does?
Re: Linus' reply on Git and SHA-1 collision
#10Do you know if git objects' size header was designed to deal with a possible collision or does it serve another purpose as well? Just some context - git calculates an object's name by his content in the following way. Say we have a blob that represent a file who's content is 'Here be dragons', then the file name would be: printf "blob 17\0Here be dragons\!\n" | openssl sha1 # => a54eff8e0fa05c40cca0ab3851be5aa8058f20…
The size is useful when you want to know the length of an object without unpacking it. The size is uncompressed length and not the size on disk.
For example, if you want to stream the blob over http you can use it to set the content-length. Otherwise, you have to use chunked transfer.