Talk:PBKDF2

Some not very wide used programms were added into Software section. But I think, the wikipedia is not a WP:DIRECTORY of programms, which uses PBKDF2, because PBKDF2 is easy to implement and it is an open standard. So, I deleted a lot of software in this list. `a5b (talk) 23:32, 26 May 2011 (UTC)

I am missing the standard implementation that comes with Java 6 JSSE: PBKDF2WithHmacSHA1 ^[1]. Not because there are not enough implementations, but because this is the one that is installed with every Sun Java implementation. Wjgerrit (talk) 12:35, 15 January 2013 (UTC)

I will add it.--agr (talk) 15:15, 15 January 2013 (UTC)

The Cisco type 4 passwords are NOT pbkdf2 - they accidentally did plain unsalted SHA256. They added type 8 and 9 passwords, one of which is PBKDF2 (Sorry, I couldn't find a citation for this - I just found it on an actual router I have). Therealmik (talk) 02:06, 24 November 2013 (UTC)

WPA2 formula mentioned is contradicting with what CWSP book by Sybex is saying. In the book, the formula is: PSK = PBKDF2(passphrase,ssid,ssidlength,40926,256). book: CWSP Certified Wireless Security Professional Official study guide. By David Coleman and others. ISBN: 978-0-470-43891-6 Page 206 Amjad Abdullah (talk) 10:22, 22 April 2012 (UTC)

As far as I know, no independent cryptographic analysis has been performed on the scrypt proposal. Until such is available, I think it's a bad idea for WP to claim that it is "stronger". — Preceding unsigned comment added by 71.195.220.229 (talk) 06:33, 8 July 2012 (UTC)

I read this article and was very confused by how complicated math terminology is being used to obscure something so simple:

DK = PBKDF2(PRF, P,S,c,dkLen)

Seriously? DK, PDF, P, S, c, dkLen? Is Wikipedia running out of letters? There's a whole section explaining what these variables mean and most of it's unnecessary if you give them names that make sense:

Derived Key = PBKDF2(Pseudorandom Function, Password, Salt, Iterations, Output Length)

Unfortunately, the section below relies on this too so most of the article would need to be rewritten. I've made a note to do this, but I figured I'd mention it here in case other people can think of a simpler solution.--Korin43 (talk) 21:14, 21 September 2012 (UTC)

I agree with Korin43's plea for using meaningful words as parameter names. It's basic to good software engineering, yet ignored by a many cryptographic experts for some reason. This practice would make the field of cryptography more accessible and easier to learn. David Spector (talk) 00:05, 13 April 2014 (UTC)

There are two errors: Firstly, according to PKCS #5, the index of the last block, i.e., dklen/hlen has to be rounded up. Furthermore, not all bits of this last block may be added to the derived key, depending on wether dkLen was chosen as a multiple of hLen or not. Otherwise the length of the derived key could be greater than dkLen. — Preceding unsigned comment added by 134.147.40.207 (talk) 12:23, 21 May 2013 (UTC)

PBKDF2#Implementations is a long list of external links in the body of this article. Maybe move some of them to the external links section and delete the rest? --82.136.210.153 (talk) 14:32, 25 January 2015 (UTC)

As someone who doesn't know anything about PBKDF2, I expected a basic history here. Even a year of proposal/implementation would be a good start. --Steven Fisher (talk) 18:31, 17 March 2015 (UTC)

Note that there seems to be some confusion as to how the length of the result is measured. Should the Parameter called dkLen in the article give the length of the result in bits or in bytes? You refer to RFC2898 which clearly states this parameter specifies the length in octects (which is also the convention used in the OpenSSL implementation). However your example based on WPA2 (DK = PBKDF2(HMAC−SHA1, passphrase, ssid, 4096, 256)) clearly seems to use the convention known from NIST special publication 800-132 which says that this length is specified in bits - at least, I believe WPA2 is actually using a 256-Bit-Key, not a 256-Byte-Key. ;-)

Part of Alternatives to PBKDF2 reads
while the more modern scrypt key derivation function can use arbitrarily large amounts of memory and is therefore more resistant to ASIC and GPU attacks.

while Scrypt#Cryptocurrency_uses does not exactly reflect this:
Mining of cryptocurrencies that use scrypt is often performed on graphics processing units (GPUs) since GPUs tend to have significantly more processing power compared to the CPU. This led to shortages of high end GPUs due to the rising price of these currencies in the months of November and December 2013. As of May 2014, specialized ASIC mining hardware is available for scrypt-based cryptocurrencies.

What's the truth? Which should be changed? — Preceding unsigned comment added by EpicWumbo (talk • contribs) 03:40, 29 November 2016 (UTC)

I think this article needs a clean up and refactor for clarity. It reads like a slalom and a half-assed, first attempt at an explanation, not a peer reviews and crystal clear depiction. Neaumusic (talk) 07:46, 16 November 2018 (UTC)