6 ms·

Big things affected: * DHT/torrent hashes - A group of malicious peers could serve malware for a given hash. * Git - A commit may be replaced by another witho

Big things affected: * DHT/torrent hashes - A group of malicious peers could serve malware for a given hash. * Git - A commit may be replaced by another without affecting the following commits. * PGP/GPG -- Any old keys still in use. (New keys do not use SHA1.) * Distribution software checksum. SHA1 is the most common digest provided (even MD5 for many). Edit: Yes, I understand this is a collision attack. But yes, it's still a attack vector as 2 same blocks can be generated now, with one published, widely deployed (torrent/git), and then replaced at a later date.

sanduu 10y ago
Do you have a pay_pal ? because if you have you can get an additional 1600 weekly in your pay just working on the internet 4 hours per day.. see this site... http://bit.ly/2atnA1a http://bit.ly/2atnA1a
deleted 10y ago
[deleted]
baq 10y ago
i can imagine the torrent thing to be worth the $100k per collision.
- qjighap 10y ago
  You haven't seen my collection of cat pics torrent ;) Also from a more serious stance the danger is the malware vector or the destruction of the ability to have integrity and not the data in the torrent itself.
fivesigma 10y ago
None of what you mentioned is affected since this is a collision attack. They purposely created 2 files with the same hash. Creating a file with the same hash as legit file is a preimage attack and is much more difficult to perform (many orders of magnitude more difficult). This still doesn't mean that SHA-1 isn't dogshit however. It should have been phased out years ago.
- anilgulecha 10y ago
  Create 2 torrents with the same hash. Release one into the wild. Wait. Infect.
  - koolba 10y ago
    Torrents have a tree of hashes for the parts. That allows validating pieces without the entire file (which is also validated at the end). Probabilistically, the hashes of the parts would not match even if the top level hash matched.
    - anilgulecha 10y ago
      The initial torrent metadata is pulled from nothing but the first hash. This is the point where the rest of the data forks.. someone gets the movie, another gets the .exe.
      - koolba 10y ago
        That's not an issue with the torrent. That would be with the magnet link format. Also, and more importantly, this isn't a preimage attack so replacing an existing torrent's SHA-1 hash with a malicious one isn't computational possible.
        anilgulecha 10y ago
        Magnet URI hash is SHA1. A hash collision can still be used as an attack if you create 2 torrents with the same hash and then distribute.
        koolba 10y ago
        That's not an issue with the torrents. It's an issue with the magnet URI format for referncing torrents. The "good" torrent would not be susceptible to attack via this receiving the entire torrent file directly (say over HTTPS) is fine.
contravariant 10y ago
>* Distribution software checksum. SHA1 is the most common digest provided (even MD5 for many). Maybe I'm mistaken, but isn't the purpose of those mainly to verify that you've downloaded the file correctly? At least, the use of MD5 suggests that this is the case.
- anilgulecha 10y ago
  Correct, and if you have 2 images that have the same hash, you can serve one or the other at different times. This is the attack.
  - pgeorgi 10y ago
    If you can switch between the images, you can also switch hashes. Without a signature they serve _only_ for making sure the network didn't barf into your stream.
  - deleted 10y ago
    [deleted]
  - antoinealb 10y ago
    SHA hashes cannot protect you against the distribution site getting compromised and the hash replaced. That is why most package manager include a form of cryptographic signatures (e.g. Ed25519 for OpenBSD's). SHA and MD5 hashes are just used to protect against accidental corruption, not targeted attacks.
    - simias 10y ago
      You can use SHA for this purpose if you retrieve the hashes from a trusted and secured source. Buildroot does that for 3rd party packages for instance. It downloads the source from the original website (possibly completely non-secured) but then validates the checksum against a locally trusted hash list. Buildroot supports a variety of hash algorithms but many packages still use SHA-1.
    - jnwatson 10y ago
maxtaco 10y ago
PGP V4 key fingerprints still use SHA-1 exclusively. There hasn't been an update to this part of the RFC as far as I know [1]. Collisions where both preimages are of the attacker's choosing matter less in this context, but who knows what clever attacks people can come up with. [1] https://tools.ietf.org/html/rfc4880#page-71 https://tools.ietf.org/html/rfc4880#page-71
agentgt 10y ago
> * PGP/GPG -- Any old keys still in use. (New keys do not use SHA1.) > * Distribution software checksum. SHA1 is the most common digest provided (even MD5 for many). Software distribution seems to be the greatest threat (e.g. a Maven repository or Debian repository). It still seems like an enormous amount of work. You would have to go after a package with an old PGP key and then I guess go spoof a mirror (most of these guys already use SSL so that is a problem). There are probably easier and far more cost effective attack vectors.

sanduu 10y ago

Do you have a pay_pal ? because if you have you can get an additional 1600 weekly in your pay just working on the internet 4 hours per day.. see this site... http://bit.ly/2atnA1a http://bit.ly/2atnA1a

deleted 10y ago

[deleted]

baq 10y ago

i can imagine the torrent thing to be worth the $100k per collision.

qjighap 10y ago
You haven't seen my collection of cat pics torrent ;) Also from a more serious stance the danger is the malware vector or the destruction of the ability to have integrity and not the data in the torrent itself.

fivesigma 10y ago

None of what you mentioned is affected since this is a collision attack. They purposely created 2 files with the same hash. Creating a file with the same hash as legit file is a preimage attack and is much more difficult to perform (many orders of magnitude more difficult). This still doesn't mean that SHA-1 isn't dogshit however. It should have been phased out years ago.

anilgulecha 10y ago
Create 2 torrents with the same hash. Release one into the wild. Wait. Infect.
- koolba 10y ago
  Torrents have a tree of hashes for the parts. That allows validating pieces without the entire file (which is also validated at the end). Probabilistically, the hashes of the parts would not match even if the top level hash matched.
  - anilgulecha 10y ago
    The initial torrent metadata is pulled from nothing but the first hash. This is the point where the rest of the data forks.. someone gets the movie, another gets the .exe.
    - koolba 10y ago
      That's not an issue with the torrent. That would be with the magnet link format. Also, and more importantly, this isn't a preimage attack so replacing an existing torrent's SHA-1 hash with a malicious one isn't computational possible.
      - anilgulecha 10y ago
        Magnet URI hash is SHA1. A hash collision can still be used as an attack if you create 2 torrents with the same hash and then distribute.
        koolba 10y ago
        That's not an issue with the torrents. It's an issue with the magnet URI format for referncing torrents. The "good" torrent would not be susceptible to attack via this receiving the entire torrent file directly (say over HTTPS) is fine.

contravariant 10y ago

>* Distribution software checksum. SHA1 is the most common digest provided (even MD5 for many). Maybe I'm mistaken, but isn't the purpose of those mainly to verify that you've downloaded the file correctly? At least, the use of MD5 suggests that this is the case.

anilgulecha 10y ago
Correct, and if you have 2 images that have the same hash, you can serve one or the other at different times. This is the attack.
- pgeorgi 10y ago
  If you can switch between the images, you can also switch hashes. Without a signature they serve _only_ for making sure the network didn't barf into your stream.
- deleted 10y ago
  [deleted]
- antoinealb 10y ago
  SHA hashes cannot protect you against the distribution site getting compromised and the hash replaced. That is why most package manager include a form of cryptographic signatures (e.g. Ed25519 for OpenBSD's). SHA and MD5 hashes are just used to protect against accidental corruption, not targeted attacks.
  - simias 10y ago
    You can use SHA for this purpose if you retrieve the hashes from a trusted and secured source. Buildroot does that for 3rd party packages for instance. It downloads the source from the original website (possibly completely non-secured) but then validates the checksum against a locally trusted hash list. Buildroot supports a variety of hash algorithms but many packages still use SHA-1.
  - jnwatson 10y ago

maxtaco 10y ago

PGP V4 key fingerprints still use SHA-1 exclusively. There hasn't been an update to this part of the RFC as far as I know [1]. Collisions where both preimages are of the attacker's choosing matter less in this context, but who knows what clever attacks people can come up with. [1] https://tools.ietf.org/html/rfc4880#page-71 https://tools.ietf.org/html/rfc4880#page-71

agentgt 10y ago

> * PGP/GPG -- Any old keys still in use. (New keys do not use SHA1.) > * Distribution software checksum. SHA1 is the most common digest provided (even MD5 for many). Software distribution seems to be the greatest threat (e.g. a Maven repository or Debian repository). It still seems like an enormous amount of work. You would have to go after a package with an old PGP key and then I guess go spoof a mirror (most of these guys already use SSL so that is a problem). There are probably easier and far more cost effective attack vectors.