Restating and expanding on what the linked example says: when using PBKDF2-HMAC-H for storing a password hash (salted/peppered) for later comparison, it makes no sense to make PBKDF2's output size parameter $\mathsf{dkLen}$ more than the output size $h$ octets of H (if $h\ge16$ octets or similar threshold), nor more than perhaps $20$ octets, because:
- The adversary doing brute force password search will seldom find a match of the first $h$ octets: when having found the right password, or with probability $2^{-8h}$ for random other inputs. The search can thus skip the (independent) computing of the other octets for the overwhelming majority of passwords tested. The extra data past $h$ has a cost for the legitimate user, but almost none (in proportion of total effort) for the attacker. Thus the legitimate user is better lowering $\mathsf{dkLen}$ to $h$ (as long as it remains enough to repel accidental match with the wrong password, which $\mathsf{dkLen}\ge16$ insures well-enough in practice), and should increase the PBKDF2 iteration count instead, which will cost the attacker.
- In practice, odds of finding a password other than the genuine one that matches the hash over more than about $20$ octets are impossibly low, and adding more octets adds no useful security from that standpoint.
So there's not really a problem to solve; when using PBKDF2-HMAC-H for storing a password hash (with a common cryptographic hash thus $h\ge16$), we can just use $\min(h,20)$ for $\mathsf{dkLen}$, and pump PBKDF2's iteration count to whatever we can afford for comparable performance in legitimate use. If $\mathsf{dkLen}$ was $l$ octets with $l>h$, we can multiply the iteration count (thus attack time) by a factor of $\lceil l/h\rceil$ at comparable cost for the legitimate user.
However, yes, it is correct that in an application keeping a password hash for later comparison, re-hashing the result of PBKDF2-HMAC-H with H (or another hash) with $h\ge16$ octets, and truncating to $20$ octets, will similarly shorten the result, and won't harm compared to storing the whole result. Indeed, computing the whole PBKDF2 output is necessary to find the overall hash, forcing an attacker to perform for each password tested all the work a legitimate user does. Security is thus comparable to reducing $\mathsf{dkLen}$.
The only benefit that I can think of in asking for longer output, and hashing it to get the final result, is that the increased complexity will require a slightly more complex code for a brute force password cracker. But that does not even require memory proportional to $\mathsf{dkLen}$ (the final hash can be computed on the fly), thus it will not markedly increase build and operating cost of a password cracker well designed with that oddity in mind.
Note: large $\mathsf{dkLen}$ can still make sense in applications of PBKDF2 other than testing if the password is correct.
Note: contrary to what the quoted remark suggest, it is not mathematically certain that if the first $h$ octets match, the others will; that's just very likely.
kdf(phs(pw,s,small_output,high_parameters),large_output)
yields a secure, large output? yes. $\endgroup$There are some subtle differences between PBKDF2 and HKDF.
- they're for 2 different goals. $\endgroup$