SHA-3 is KECCAK

Kagamin spam at here.lot
Sat Jan 18 04:48:27 PST 2014


On Friday, 17 January 2014 at 14:53:04 UTC, Chris Cain wrote:
> Your first part is true, but the second part is not. A generic 
> collision attack can cause issues depending on what you're 
> trying to do. For general use, MD5 is not safe enough based on 
> that alone.

No technology is safe, and SHA3 doesn't solve this problem. 
Cryptography is particularly not fool-proof. Remember issues in 
RSA? The factorization math behind it is bulletproof, yet, it's 
still considered hackable.

> The wikipedia article on MD5 covers this reasonably well enough:
> http://en.wikipedia.org/wiki/MD5
>
> Do note that SHA1 is similar enough to MD5 that many are 
> recommending against SHA1 as well (and I recommend following 
> that advice). It's not as broken as MD5 but since we have SHA2 
> there's no good reason not to use the better version.
>
> For general messages requiring any degree of security against 
> an attacker, use SHA2 (this does not necessarily apply to 
> hashing passwords which have their own concerns, obviously). 
> Stay away from MD5 and no new projects should use SHA1 
> (although my understanding is that no one is saying "jump from 
> the ship" for SHA1 right now). These are generally accepted 
> practices in the cryptography community. If you want to roll 
> the dice with MD5, by all means, but don't spread acceptance of 
> MD5 because someone might follow your advice against the clear 
> recommendations of the cryptography community. As far as I'm 
> concerned, it's unethical to recommend MD5 for security 
> purposes at this point.

Ethics don't help in cryptography, only real factors play role.
Your insistence on blind following to recommendations and 
expecting them to magically protect security - by encouraging 
thoughtless behavior such voodooism is way more troublesome.

>> SHA3 is just more convenient than MD5 because when you want to 
>> change the hash function, you don't have to ditch the whole 
>> system, only change its parameters.
>
> I'm sorry but no. The reason we wanted a SHA3 is because we 
> needed a message digest algorithm that is different enough from 
> MD5, SHA1, and SHA2 so that an attack discovered on those 
> algorithms should not be applicable to SHA3 as well (as was the 
> case with MD5 and SHA1). The things you describe are just 
> bonuses.

This works both ways: an attack on SHA3 doesn't affect other hash 
functions.
The older algorithms are more trustworthy exactly because they 
are well studied, have no dark corners and evolve gradually by 
fixing discovered weaknesses.

>> That's rather inconvenient, that you can't have an efficient 
>> implementation of the algorithm on common hardware. MD5 family 
>> has no such flaw.
>
> You seem to not know enough about this topic to discuss it. 
> SHA3 is fast on common hardware, as it is designed. Specialized 
> hardware can be made and that's fine, intentional, and even 
> beneficial. Most cryptography is designed that way. DES was, 
> AES is (AES instructions exist on many modern hardware, in 
> fact), and SHA3 is as well. This is not a flaw and if you think 
> it is, go talk with cryptographers instead of me because you're 
> clearly well beyond my skill level (that said, since you're 
> discussing the viability of MD5, you're not anywhere close to 
> as competent on this matter as you think you are, no offense).

It's even worse that new algorithms force hardware vendors to add 
specialized instructions which are of no use for other software.

On Friday, 17 January 2014 at 15:13:27 UTC, Chris Cain wrote:
> On Friday, 17 January 2014 at 14:04:29 UTC, Kagamin wrote:
>> There's no successful preimage attack on MD5, which is the 
>> only deadly attack on a hash function.
>
> For one amusing example of why MD5 is broken (from years ago 
> using a video game console, of all things), consider:
> http://www.win.tue.nl/hashclash/Nostradamus/

They didn't predict the result of elections, not sure what you 
want to prove by a lie.


More information about the Digitalmars-d mailing list