Talk:PBKDF2

Naming

Some naming needs to be sorted out for this article. Should there be a general Password Key Derivation Function page and discuss PBKDF1 and 2 there? Or should PBKDF be a page, and discuss 1 and 2 there? or should 1 and 2 be seperated into their own pages? Thoughts? --ORBIT 18:46, 28 Mar 2005 (UTC)

Thoughts: there is already a general page, I believe: Key derivation function. I think the PBKDF stuff can be treated separately, but my hunch is that it's best to cover both PBKDF 1 & 2 in the same article, in which case we might consider renaming this article PBKDF2 -> PBKDF. — Matt Crypto 19:56, 28 Mar 2005 (UTC)

However PBKDF2 pretty much obsoleted PBKDF1, so I suppose it v1 merits a historical footnote in PBKDF2 and not its own article. jett 18:56, 27 April 2007 (UTC)

I agree with Matt Crypto. PBKDF2 has undesirable properties (see last paragraph of Key derivation function) which should be addressed by future releases of the standard (PBKDF3, perhaps?). Covering all of them in the same article will show the progression, and point out the latest version to the reader. Rein Radin (talk) 03:34, 9 August 2009 (UTC)

Clarification on Procedure

The given explanation of the derivation procedure is more accurate for the earlier PBKDF1. An explanation of the differences between versions 1 and 2 could be used to expand the article and drop the "stub" tag.Giordano87 (talk) 01:06, 7 October 2010 (UTC)

List of software

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

References

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

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)

scrypt stronger?

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)

Explaination is way too complicated

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)

Key derivation process incorrect

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)

External links

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)

History?

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)

Length measuring

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

Contradiction with scrypt article

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)

“Trivial” and “Mere” use of superfluous indirect language

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)

https://foundation.m.wikimedia.org/wiki/Special:MyLanguage/Policy:Terms_of_Use

10$ 36.37.142.201 (talk) 18:36, 23 January 2024 (UTC)