With the recent discussions regarding std.crypt/std.hash, I thought it would be worth announcing that the SHA-3 competition has ended and the winner is KECCAK.

http://csrc.nist.gov/groups/ST/hash/sha-3/winner_sha-3.html

On Wednesday, 3 October 2012 at 11:35:42 UTC, Xinok wrote:
> With the recent discussions regarding std.crypt/std.hash, I thought it would be worth announcing that the SHA-3 competition has ended and the winner is KECCAK.
>
> http://csrc.nist.gov/groups/ST/hash/sha-3/winner_sha-3.html

I would love to see D support SHA3 ASAP. I cringe at the fact that many still use MD5.

I support the idea that it would be useful to have an implementation or binding for Keccak and may be other crypto hash functions. Now all what I found are pycrypto implementation an official implementation written with C at http://keccak.noekeon.org/. But I was unable to deal with the interface of this library. There are a little of comments in the code and I couldn't find concrete examples how to use it. Phobos simple interface like in std.digest.md would be more suitable for casual use. Very often in not needed to tweek all of these parameters for algorithm, but needed that it will just work.

I will appreciate for some guidelines if someone tried to bind this C implementation for using in D.

On Wednesday, 3 October 2012 at 12:39:15 UTC, Chris Cain wrote:
> On Wednesday, 3 October 2012 at 11:35:42 UTC, Xinok wrote:
>> With the recent discussions regarding std.crypt/std.hash, I thought it would be worth announcing that the SHA-3 competition has ended and the winner is KECCAK.
>>
>> http://csrc.nist.gov/groups/ST/hash/sha-3/winner_sha-3.html
>
> I would love to see D support SHA3 ASAP. I cringe at the fact that many still use MD5.

MD5 is good enough for most cases. AFAIK, keccak uses weird bit fiddling. Wasn't it considered a bad practice since DES because a specialized hardware would give a considerable speedup, which will help in brute force attacks?

On Friday, 17 January 2014 at 11:37:26 UTC, Kagamin wrote:
> MD5 is good enough for most cases.

For any use where security isn't an actual concern, sure. If it's just to casually verify that a file transferred successfully (like an alternative to a checksum), then it's fine to use. But don't use it to secure anything against an attacker at this point.

> AFAIK, keccak uses weird bit fiddling. Wasn't it considered a bad practice since DES because a specialized hardware would give a considerable speedup, which will help in brute force attacks?

Actually, the idea is that it _should_ be implemented in specialized hardware to make it faster. And improving brute force attacks in this manner will only provide a multiplicative increase in speed, and that's not a concern. The overall strategy of using brute force isn't going to be turned from infeasible to feasible because of that. It's still completely infeasible to find two different messages s.t. their SHA-3 hash is equal.

On Friday, 17 January 2014 at 13:11:57 UTC, Chris Cain wrote:
> On Friday, 17 January 2014 at 11:37:26 UTC, Kagamin wrote:
>> MD5 is good enough for most cases.
>
> For any use where security isn't an actual concern, sure. If it's just to casually verify that a file transferred successfully (like an alternative to a checksum), then it's fine to use. But don't use it to secure anything against an attacker at this point.

There's no successful preimage attack on MD5, which is the only deadly attack on a hash function. 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.

>> AFAIK, keccak uses weird bit fiddling. Wasn't it considered a bad practice since DES because a specialized hardware would give a considerable speedup, which will help in brute force attacks?
>
> Actually, the idea is that it _should_ be implemented in specialized hardware to make it faster.

That's rather inconvenient, that you can't have an efficient implementation of the algorithm on common hardware. MD5 family has no such flaw.

> And improving brute force attacks in this manner will only provide a multiplicative increase in speed, and that's not a concern. The overall strategy of using brute force isn't going to be turned from infeasible to feasible because of that. It's still completely infeasible to find two different messages s.t. their SHA-3 hash is equal.

You assume that Moore's law doesn't and won't work. Write asserts for assumptions.

On Friday, 17 January 2014 at 13:11:57 UTC, Chris Cain wrote:
> For any use where security isn't an actual concern, sure. If it's just to casually verify that a file transferred successfully (like an alternative to a checksum)

Doesn't TCP take care of that?

17-Jan-2014 18:06, Kagamin пишет:
> On Friday, 17 January 2014 at 13:11:57 UTC, Chris Cain wrote:
>> For any use where security isn't an actual concern, sure. If it's just
>> to casually verify that a file transferred successfully (like an
>> alternative to a checksum)
>
> Doesn't TCP take care of that?

As long as 16 bit CHECKSUM feels sufficient for you.

-- 
Dmitry Olshansky

On 2014-01-17 15:06, Kagamin wrote:

> Doesn't TCP take care of that?

Doesn't TCP only verify that a package is received intact, not a complete file?

-- 
/Jacob Carlborg

On Friday, 17 January 2014 at 14:04:29 UTC, Kagamin wrote:
> On Friday, 17 January 2014 at 13:11:57 UTC, Chris Cain wrote:
>> On Friday, 17 January 2014 at 11:37:26 UTC, Kagamin wrote:
>>> MD5 is good enough for most cases.
>>
>> For any use where security isn't an actual concern, sure. If it's just to casually verify that a file transferred successfully (like an alternative to a checksum), then it's fine to use. But don't use it to secure anything against an attacker at this point.
>
> There's no successful preimage attack on MD5, which is the only deadly attack on a hash function.

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.

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.

> 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.

> 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).

> You assume that Moore's law doesn't and won't work. Write asserts for assumptions.

I'm not sure what you mean here. No such assumptions need to be made. You are aware of how large the space of 256-bit message digests are, right? Multiplicative (specialized hardware) increases in performance makes no difference because of the ridiculous size of such a space. Exponential increases in performance (like Moore's law) are flawed because of how long it takes for those improvements to accumulate.

The way you defeat such a thing is not via multiplicative increases nor exponential increases over a long time, but by instantaneous, SIGNIFICANT breaks. Even effectively cutting a 256-bit message digest down to the complexity of 128-bit (which is a *massive* break) is still not enough, for comparison.