# PBKDF2WithHmacSHA512 Vs. PBKDF2WithHmacSHA1

I'm working on a Java authentication subsystem that specs the storage of passwords in the DB as PBKDF2-generated hashes, and I'm now trying to decide whether I should use SHA1 or SHA512 as PFR. I'm under the impression that the consensus is that SHA1 has some theoretical weaknesses, and that SHA512 should be chosen instead. However the standard javax.crypto package does not offer a PBKDF2WithHmacSHA512 implementation, how is that so? Furthermore, I can't seem to find any Provider offering it, apart from IKAI (they charge a few thousand $for their JCE library, oopss..) Any thoughts? private static final int HASH_BYTE_SIZE = 64; // 512 bits private static final int PBKDF2_ITERATIONS = 1000; // generate random salt SecureRandom random = new SecureRandom(); byte salt[] = new byte[SALT_BYTE_SIZE]; // use salt size at least as long as hash random.nextBytes(salt); // generate Hash PBEKeySpec spec = new PBEKeySpec(password, salt, PBKDF2_ITERATIONS, HASH_BYTE_SIZE); SecretKeyFactory skf = SecretKeyFactory.getInstance("PBKDF2WithHmacSHA1"); // this throws a NoSuchAlgorithmException if I replace with "PBKDF2WithHmacSHA512" byte[] hash = skf.generateSecret(spec).getEncoded(); // convert hash and salt to hex and store in DB as CHAR(64)...  - I guess you are better off using a binary field instead of hex for the salt, but if you must you should use a CHAR field of 128 bytes, not 64. Furthermore, it may be a good idea to store the iteration count as well or create a "protocol indicator" or version field so you can upgrade your security later on. – Maarten Bodewes Oct 13 '13 at 22:47 SHA-512 and SHA-384 (unlike SHA-1, SHA-224, and SHA-256) use 64-bit operations that reduce the margin of superiority that modern (early 2014) GPU's have over CPU's. Since an attacker is more likely to benefit from GPU's than you are, that's a good (but constant factor) reason to use PBKDF2-HMAC-SHA-512 for the same amount of CPU time you would have budgeted to PBKDF2-HMAC-SHA-1. – Anti-weakpasswords Feb 25 '14 at 5:41 ## 1 Answer Hash algorithm strength is important, but it is not so important in key derivation functions. It is unlikely that even if SHA-1 is broken that it would influence the security of PBKDF2. You are better off using SHA-1, and increase the iteration count up to a level that is tweaked for your specific configuration. If you must, you could use Bouncy Castle to create an implementation of PBKDF2 with SHA-256. The internal security of the algorithm is not that important, if your server is relatively safe against side channel attacks (and for PBKDF2 it likely is). So using a non-certified open source solution would probably not compromise your security. Your efforts are probably better spend elsewhere. Congratulate yourself on choosing a relatively good password based KDF, choose a 64 bit random salt and use a higher iteration count, and move on... Note: if you want to protect against hardware accelerated attacks, you may want to consider scrypt instead of PBKDF2. - What do you mean by "a 64 bit random hash"?$\;$– Ricky Demer Oct 13 '13 at 22:54 "an non-certified"$\:\mapsto\:$"a non-certified"$\;\;\;\$ –  Ricky Demer Oct 14 '13 at 0:15
Both issues are Fixed in above answer, thanks go to Ricky. –  Maarten Bodewes Dec 1 '13 at 18:55