Talk:Key derivation function

This excellent list needs adding
http://www.di-mgt.com.au/cryptoKDFs.html but I don't know how to do wiki tables... — Preceding unsigned comment added by 120.151.160.158 (talk) 01:51, 8 March 2016 (UTC)

Please - No MD5
I agree the following is a correct statement:

"Modern password-based key derivation functions, such as PBKDF2 (specified in RFC 2898), use a cryptographic hash, such as MD5 or SHA1, more salt (e.g. 64 bits) and a high iteration count (often 1000 or more)."

However, I feel mentioning MD5 is an implicit approval of the algorithm. MD5 was broken some time ago, and its often available for compatibility only. For example, MD5 is banned from US Federal use except in some compatibility cases such as use in SSL/TLS as part of pseudorandom number generator component. Additionally, others, such as the author of md5crypt, has stated the algorithm is broken, should not be used, and the program is at End of Life.

Would it be possible to yank references to MD5 that sound like an endorsement? In its place, mention Whirlpool, which is NESSIE and ISO/IEC approved. More importantly, the SHA-2 family and Whirlpool's security properties are in tact.


 * It is not the purpose of wikipedia to define new standards, to revise existing protocols or to make endorsements. Doing this is the goal of a standardization process. What wikipedia should do is to report on existing standards and give references to attacks and criticism. E.g., a reader who wants to know if the weaknesses of MD5 decrease the security of PBKDF2 with MD5 might be interested in research papers about the topic or recommendations from the crypto community. However, you can't just go and express your opinion. Hence, the text you quote is OK, since RFC 2898 does explicitely mention MD5 and SHA1, but not Whirlpool. Furthermore, MD5 and SHA1 are indeed currently used in practice. So the text does reflect the current state. Generally all statements on wikipedia should be verifiable. E.g., your recent change that salts should be 128 bit long are the same as NIST SP 800-132 Section 5.1, but without a reference such a claim on wikipedia is of little help. 178.195.225.28 (talk) 05:43, 16 July 2012 (UTC)
 * RFC 2898 talks about 64 bit salt and many modern systems use that amount. 64 bit salt means an attacker needs 1.8 x 1019 entries per password for a table attack. 128 bits gets you into the atoms-in-the-universe range. Also while MD5 is broken in terms of collision attack, it is not, as far as I know, broken in terms of pre-image attack, which is what is relevant for key derivation use. We should not give the impression that systems that use 64 bit salt or MD5 are now broken. Instead, I've made the NIST requirements explicit in the text, including making it clear that they do not approve MD5. That should provide a balanced picture to our readers, as well as pointing them to the NIST specs, which should be the reference they use in designing new systems, not a Wikipedia article.--agr (talk) 14:29, 16 July 2012 (UTC)

External links modified
Hello fellow Wikipedians,

I have just modified one external link on Key derivation function. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:
 * Added tag to http://cm.bell-labs.com/cm/cs/who/dmr/passwd.ps
 * Added archive https://web.archive.org/web/20101229081854/http://di-mgt.com.au/cryptoKDFs.html to http://www.di-mgt.com.au/cryptoKDFs.html

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

Cheers.— InternetArchiveBot  (Report bug) 13:36, 9 December 2017 (UTC)

Keyed cryptographic hash functions
In the first part of the article there was a reference to "Keyed cryptographic hash functions", with a link to the simple "cryptographic hash functions". HMAC looks to me much more accurate, but a check into the reference book (Zdziarski, Jonathan) was not successful. The book only speaks about the use of crypto hash to improve security. Truman (talk) 16:59, 30 May 2019 (UTC)

Key Strengthening
The section on deleting the salt to provide "key strengthening" seems suspect. Deleting the salt and requiring legitimate users to brute force attack their own stuff doesn't seem reasonable. The quoted links are to offline sources. (Journals/books) Can anyone find an online source for this? And is there a known implementation that uses this technique today? The citations don't directly support this paragraph. — Preceding unsigned comment added by Javacodehead (talk • contribs) 19:31, 30 December 2019 (UTC)