Announcement

Collapse
No announcement yet.

BLAKE2: A New Alternative To MD5 & SHA-2/SHA-3

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • phoronix
    started a topic BLAKE2: A New Alternative To MD5 & SHA-2/SHA-3

    BLAKE2: A New Alternative To MD5 & SHA-2/SHA-3

    Phoronix: BLAKE2: A New Alternative To MD5 & SHA-2/SHA-3

    For those interested in cryptography, BLAKE2 has been announced as a new alternative for MD5 and SHA-2/3 algorithms. The benefits of BLAKE2 is better security than MD5 while being higher performance in software...

    http://www.phoronix.com/vr.php?view=MTI2MDY

  • Licaon
    replied
    Originally posted by liam View Post
    The algorithm was clearly a finalist but I don't know if blake2 is the same code as that which was in the competition.
    So, as I said, it may be a reimplementation of a sha3 finalist algorithm.
    https://blake2.net/blake2_20121223.pdf TL;DR "BLAKE was already more secure, we reduced some params to gain speed"

    Leave a comment:


  • kazetsukai
    replied
    Originally posted by MaxToTheMax View Post
    Improved performance isn't necessarily a good thing, when it comes to these sorts of hash functions. The faster a hash function, the easier it is to brute-force.
    Funny. BLAKE2 (being faster than MD5 yet more secure) seems to disprove that absolute (and utterly incorrect) correlation.

    The takeaway message for us lowly non-security types was pretty simple, yet none of us got it: I'll be pretty happy when I can replace the md5sum command line tool with something faster that I can have a reasonable amount of confidence in.

    Leave a comment:


  • liam
    replied
    Originally posted by Licaon View Post
    So decide already, it was either a finalist or a redesign, it can't be both.
    The algorithm was clearly a finalist but I don't know if blake2 is the same code as that which was in the competition.
    So, as I said, it may be a reimplementation of a sha3 finalist algorithm.

    Leave a comment:


  • Licaon
    replied
    Originally posted by liam View Post
    The article claimed BLAKE2 was a finalist. According to this link, http://crypto.junod.info/2010/12/10/...unced-by-nist/, it was a finalist (well, BLAKE was, I'm assuming BLAKE2 is simply a different implementation.
    So decide already, it was either a finalist or a redesign, it can't be both.

    Leave a comment:


  • elanthis
    replied
    Originally posted by zanny View Post
    Keccak and Sha2-256 or greater can't be brute forced.
    All well said. Put in simpler terms for the simpler readers: these speedups mentioned are all linear, and while a linear improvement in hash computation is pleasantly noticeable when you're trying to compute hashes for a few hundred files while making a git commit or something like that, it is completely irrelevant when trying to search a ridiculously huge hash space. One thousandth of the time of "practically forever" is still "practically forever."

    Leave a comment:


  • zanny
    replied
    Originally posted by MaxToTheMax View Post
    Improved performance isn't necessarily a good thing, when it comes to these sorts of hash functions. The faster a hash function, the easier it is to brute-force. When Intel added SHA hardware instructions, they weren't necessarily making SHA better, they were bringing it closer to obsolescence (for certain applications.)
    Keccak and Sha2-256 or greater can't be brute forced. Their key spaces are within 3 orders of magnitude of the estimated number of atoms in the universe. It would take billions of years with all our available computational power to cover them. Hell, a 128 bit keyspace is currently completely impossible to brute force as well, but that is only a problem at a galactic scale rather than a universal one.

    And if you really wanted to be OCD, 512 bit keyspace (or just 384) is laughably impossible to even consider brute forcing. But 256 bit is already impossible. The lowest used key space for either algorithm is 224 bits, which is just as crazy. Here is the wikipedia entry on 128 bit vs 256 bit keyspace brute forcing:

    AES permits the use of 256-bit keys. Breaking a symmetric 256-bit key by brute force requires 2128 times more computational power than a 128-bit key. A device that could check a billion billion (10^18) AES keys per second (if such a device could ever be made - as of 2012, supercomputers have computing capacities of 20 Peta-FLOPS, see Titan. So 50 supercomputers would be required to process (1018) operations per second) would in theory require about 3?10^51 years to exhaust the 256-bit key space.
    Keccak is already supposed to be really easy on cycles though, right? The real tradeoffs here isn't size of key storage vs execution time to have a secure key. The question isn't if you can brute force it, but if the algorithm has a vulnerability to reduce a 128 bit or 256 bit keyspace into a solvable problem.
    Last edited by zanny; 12-24-2012, 09:00 PM.

    Leave a comment:


  • michal
    replied
    Originally posted by MaxToTheMax View Post
    Improved performance isn't necessarily a good thing, when it comes to these sorts of hash functions. The faster a hash function, the easier it is to brute-force. When Intel added SHA hardware instructions, they weren't necessarily making SHA better, they were bringing it closer to obsolescence (for certain applications.)
    Exactly.

    (I need make my message at least 10 chars long. what a stupid cms)

    Leave a comment:


  • liam
    replied
    Originally posted by Licaon View Post
    So instead of using the winner of the SHA-3 competition or even one of the finalists that were under a lot of checks and scrutiny, let's take one of those finalists, redesign it and call it better? 4real?
    The article claimed BLAKE2 was a finalist. According to this link, http://crypto.junod.info/2010/12/10/...unced-by-nist/, it was a finalist (well, BLAKE was, I'm assuming BLAKE2 is simply a different implementation.

    Leave a comment:


  • MaxToTheMax
    replied
    Improved performance isn't necessarily a good thing, when it comes to these sorts of hash functions. The faster a hash function, the easier it is to brute-force. When Intel added SHA hardware instructions, they weren't necessarily making SHA better, they were bringing it closer to obsolescence (for certain applications.)

    Leave a comment:

Working...
X