back to article Dev writes Ethereum code for insecure SHA-1 crypto hash function

Using Ethereum's programming language Solidity, a dev has controversially written code for making data authentication signatures with the insecure SHA-1 cryptographic hash function. Nick Johnson, the London-based Ethereum developer who authored the code, told The Register: "SHA1 is still used by a lot of legacy systems, …

  1. Anonymous Coward
    Anonymous Coward

    SHA1 is totally dead.

    All of those examples no longer advise SHA1. Chrome doesn’t even connect to SHA1 SSL servers any more.

    1. Solarflare

      Re: SHA1 is totally dead.

      SHA1 *should* be totally dead. It really, really isn't though.

    2. nicksdjohnson

      Re: SHA1 is totally dead.

      I'm afraid you are mistaken. Git still only supports SHA1, as do DNSSEC NSEC3 records.

  2. Christian Berger

    It's rather fitting

    Implementing an algorith that should be dead (SHA1) in an environment that should not exist (smart contracts that are turing complete)

    1. Claptrap314 Silver badge

      Re: It's rather fitting

      Smart contracts run on a finite amount of gas, and are therefore not Turing complete. And by finite, I mean "must be bought with Eth, which costs real money".

      1. Christian Berger

        Re: It's rather fitting

        "Smart contracts run on a finite amount of gas, and are therefore not Turing complete."

        Well yes, but by that notion, there are no turing machines as the universe has a limited lifetime. It's like saying malware doesn't exist on mobile devices as the battery runs out.

  3. patrickstar

    Not supporting the raw hash function in a generic lib of crypto primitives would just be silly.

    Not to be confused with not supporting it in specific applications, like digital signatures.

    There are applications where SHA1 (and even MD5 and others) are perfectly unbroken and likely to remain so forever.

    HMAC being the most obvious and common example. A hash algorithm would have to be really, really broken to be totally unsuitable for that - on the level of leaking bits of the HMAC secret in the hash or having weak to no avalanche effect.

    There is certainly a lot of hardware that can do MD5 or SHA1 but nothing else. I doubt anyone will argue that you're generally better off not using any hash at all in such a scenario.

    Plus applications where you don't need protection against forgery but rather against unintentional collisions. For this you could theoretically use a non-cryptographic hash, of course, but they tend to be too small considering the birthday paradox.

    And I'm sure there are performance and/or compatibility scenarios where SHA1 or MD5 is preferable to more modern algorithms when you don't have any security considerations.

    1. Claptrap314 Silver badge

      This. CRCs are perfectly valid checks in many situations. The only real question is if the corner of the world where SHA-1 continues to make sense is worth the effort.

    2. Donn Bly

      And I'm sure there are performance and/or compatibility scenarios where SHA1 or MD5 is preferable to more modern algorithms when you don't have any security considerations.

      It comes down to fitness of purpose. In many case, a CRC-32 check is sufficient, let alone a MD5 hash. For McCorry or someone like him to claim that a hashing function shouldn't be written because it doesn't do what HE wants to do is not only short-sighted, it is pretty egotistical. His purpose and your purpose may be totally different, and he does not know your purpose.

      Additionally, while there are examples of intentional collisions for both SHA1 and MD5 there has yet to be an example of a simultaneous collision for both. If I give you a file, and supply you with both the SHA1 and MD5 hashes, you are going to be very hard pressed to create a new file that has the same hashes. To that end, with both SHA1 and MD5 being so computationally inexpensive to generate they still have a viable role to play in modern computing -- they just shouldn't shouldn't be relied upon individually in a security context.

      It took Google and researchers YEARS to create a single intentional SHA-1 collision, and they could control and modify both files until they got it. Yes, it proves the theory that an intentional collision is possible, but collisions are mathematically possible in ANY hash.

  4. foxyshadis

    Why does it even matter?

    Only these nutty Etherium wonks would raise hell over the fact that someone put another tool in the toolbox, even if it's only rarely going to be used. There are lots of uses of SHA-1 (and MD5, and CRC32) that aren't even related to security at all, so the push to phase it out in favor of something stronger is a lot less compelling. Do they cry that every other major programming language's standard library also has an implementation?

  5. dajames

    There's a difference ...

    ... between enabling verification of SHA-1 hashes and supporting generation of new ones.

    The argument, I guess, is that SHA-1 is so insecure, now, that even old SHA-1 hashes, computed back when SHA-1 was considered safe, can not be relied upon; that allowing people to check the validity of a SHA-1 hash might tempt them to assume that the hash still means something.

    That's a good argument for encouraging people to treat anything signed using SHA-1 with a pinch of salt, but it's not an argument for preventing them from checking the hash at all. SHA-1 collisions can now be engineered, but they still can't be engineered easily -- a hash has to be protecting something of appreciable value before it becomes worth anyone's effort to look for a collision.

    However, blockchain applications such as those used by Etherium -- in which the entire value of the chain depends on its validity back to the first transaction being verifiable -- are among the applications most at risk. If you can fake a signature early in the chain that used a weak hash then you can cast doubt on the entire history of the chain and everything it is supposed to secure. I can see why people are concerned.

    1. patrickstar

      Re: There's a difference ...

      Sorry - but you have very little idea what you are talking about.

      First of all, verifying a hash involves running the same hash function over the data and comparing the result. There's no magical "verification mode".

      Second of all, there's nothing "signed using SHA1". SHA1 is a hash function, not a signature algorithm. Things are 'signed' using things like RSA, DSS or one of the elliptic curve algorithms, not using SHA1, MD5, or whatever. The closest you get to 'signing' something with a hash function is things like HMAC, where you hash the data to be verified together with a secret shared by the sender and receiver. This way of using it is, by the way, pretty much immune to any of the published attacks or any attack that's likely to ever be found against any of these hash functions.

      Third of all, noone is suggesting starting the Ethereum blockchain over from the start using SHA1 as the hash algorithm instead. This is about smart contracts and such, not about the blockchain itself. The very worst case impact of a hash collision would be a single smart contract doing the wrong thing.

      I'm also not sure about the impact on a blockchain of a single hash collision - someone who's better at blockchains and current crypto currencies should fill me in here.

      Fourth of all, SHA1 is not "so broken" that ever using it is security suicide. Even for lots of security related applications, it's still perfectly fine (and so is MD5 and worse - see earlier posts), atlhough there's rarely any reason to use it in a completely new protocol.

      1. nicksdjohnson

        Re: There's a difference ...

        Public key cryptosystems don't sign data directly - they sign cryptographic hashes. A compromise in SHA1 can potentially make the same signature valid for two different plaintexts if the signature was generated using SHA1.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like