Slashdot Mirror

← Back to Stories (view on slashdot.org)

SHA-3 Finalist Candidates Known

Posted by timothy on from the not-enough-like-line-noise dept.

Skuto writes "NIST just announced the final selection of algorithms in the SHA-3 hash competition. The algorithms that are candidates to replace SHA-2 are BLAKE, Grøstl, JH, Keccak and Skein. The selection criteria included performance in software and hardware, hardware implementation size, best known attacks and being different enough from the other candidates. Curiously, some of the faster algorithms were eliminated as they were felt to be 'too fast to be true.' A full report with the (non-)selection rationale for each candidate is forthcoming."

9 of 194 comments (clear)

  1. "Too fast to be true" by MrEricSir · · Score: 4, Insightful

    Well that's mathematically sound reasoning!

    --
    There's no -1 for "I don't get it."
    1. Re:"Too fast to be true" by icebike · · Score: 4, Insightful

      Exactly my reaction.

      Is this a beauty contest or what?

      There may be some tendency to think that something that hashes too quickly would be trivial, but without even a glance at the methodology and a modicum of trials this is just like assuming the cute girl is an air-head without so much as a conversation.

      Who are these guys anyway? You expect better from NIST.

      --
      Sig Battery depleted. Reverting to safe mode.
    2. Re:"Too fast to be true" by Omnifarious · · Score: 4, Insightful

      Tangential? What are you talking about? The cryptographic uses of hashes are the whole reason SHA-1, SHA-2 224,256,384,512 were created in the first place. It's also the reason the competition is being run.

      I would also submit that your use case is not as security insensitive as you might think.

      --
      Need a Python, C++, Unix, Linux develop
    3. Re:"Too fast to be true" by nedlohs · · Score: 3, Insightful

      You believe what you read in a slashdot summary???

    4. Re:"Too fast to be true" by Surt · · Score: 2, Insightful

      Technically, if your hash algorithm is too fast, it gets easier to brute force. So it isn't completely unscientific.

      --
      "Who is the Journal of Quantum Physics going to believe?" --Stephen Hawking
    5. Re:"Too fast to be true" by Anonymous Coward · · Score: 2, Insightful

      checksum != hash table function != cryptographic hash != hashish

  2. Re:good! by John+Hasler · · Score: 3, Insightful

    The only thing you get from SHA-2 or SHA-3 over SHA-1 is better probability of not colliding, and a more difficult time of deliberately creating a collision.

    And the risk of accidental collisions is negligible while deliberate collisions are irrelevant to the use of hashes in Git as they have no security-related function there.

    --
    Warning: this article may contain humor, sarcasm, parody, and perhaps even irony. Read at your own risk.
  3. Re:Skein by Anonymous Coward · · Score: 2, Insightful

    Woosh!

    Definition of skein: A loosely-wound, oblong ball of yarn

  4. Re:good! by Mysteray · · Score: 3, Insightful

    An attacker could write a new patch and generate a collision for it. The attacker would then submit the good patch and get the maintainers to accept the patch and sign it with their GPG key. The attacker would then create a rogue mirror site and replace the good patch with the malicious collision.

    That would definitely win you the prize for "the most absurdly over-complicated and difficult way of pwning a Linux box".

    Why don't you just watch [Full-disclosure] for the 0-day of the week like everyone else?

    The bear only has to be faster than the first of the two hunters.