Multithreading PBKDF2 or javascript alternative I'm using PBKDF2 in browser (can't use bcrypt, users are likely to have passwords > 72bytes, or whatever the number was). PBKDF2 is running in a webworker, something like so 

const key = PBKDF2_HMAC_SHA512.bytes(passphrase, salt, Math.pow(2,17), 64)


This key is used to encrypt data to be stored in the user's localstorage. Now I wonder, seeing as I'm already using a webworker, why not use multiple? Would I not be able parrallelize it? Could I not do something like(simplified, in reality each key is generated in a separate web worker) 

const key1 = PBKDF2_HMAC_SHA512.bytes(passphrase, salt1, Math.pow(2,17), 16)
const key2 = PBKDF2_HMAC_SHA512.bytes(passphrase, salt2, Math.pow(2,17), 16)
const key3 = PBKDF2_HMAC_SHA512.bytes(passphrase, salt3, Math.pow(2,17), 16)
const key4 = PBKDF2_HMAC_SHA512.bytes(passphrase, salt4, Math.pow(2,17), 16)
const key5 = new Uint8Array(64)
key5.set(key1)
key5.set(key2, 16)
key5.set(key3, 32)
key5.set(key4, 48)
const key = SHA_512.bytes(key5)


Would this not be 4x more secure? Or more importantly, could I not halve the rounds per instance of pbkdf2 and still end up with 2x the security? If I'm wrong, could someone point me in the right direction for a faster/more secure parallelizable kdf?
Yes, this would improve security. In fact, you do not even need to use individual salts. Simply concatenating the thread number as a counter with the input key would be enough:


Input: k, a short key to be strengthened with a KDF
Output: h, the final output hash

spawn_thread(h0 := slow_KDF(k || 0))
spawn_thread(h1 := slow_KDF(k || 1))
spawn_thread(h2 := slow_KDF(k || 2))
...
spawn_thread(hn := slow_KDF(k || n))

wait_for_all_threads()

h := fast_hash(h0 || h1 || h2 || ... || hn)


However, this is not particularly efficient. Every time you double the number of threads (assuming each thread is truly independent and not sharing any resources), you add the equivalent of one bit of security. A single extra byte added to the input provides the equivalent increase in difficulty as running this on a system with 256 independent hardware threads. Assuming you will not get more than 8 parallel KDF instances, you will never increase security by more than a mere 3 bits...

Instead, you should be using a KDF that is memory-hard, preventing an attacker from using a GPU or ASIC from parallelizing an attack against PBKDF2. An example would be Argon2, which natively supports parallelism in addition to a configurable amount of memory.