PBKDF2 derive

A salt of the literal text salt, 100000 iterations, SHA-256 as the HMAC hash, and a 32-byte output, all editable. Password and salt are read as UTF-8 text. The result is the derived key as hex. It runs through crypto.subtle.deriveBits in your browser, so the numbers you set are the numbers used, with nothing added behind the scenes.

It is the default here, not a recommendation. For comparison, the AES-GCM encrypt tool on this site uses 210,000 iterations with SHA-256 internally, citing the OWASP 2023 minimum for PBKDF2-HMAC-SHA256. If you are deriving a key that protects something real, set the count to whatever your own guidance says, and remember that the cost lands on your browser tab.

SHA-1, SHA-256, SHA-384 or SHA-512, with SHA-256 as the default. SHA-1 is offered so you can reproduce output from older systems that used PBKDF2-HMAC-SHA1; it is not a reason to choose SHA-1 for new work. The choice changes the result completely, so it has to match whatever produced the value you are comparing against.

Every parameter has to match exactly: the password bytes, the salt bytes, the iteration count, the hash and the output length. The salt here is a text field encoded as UTF-8, so a tool that takes a hex or base64 salt will disagree unless you account for that. Output length is set in bytes here, not in bits and not in hex characters.

Values that are not positive whole numbers. You get "iterations must be a positive whole number" and "keylen must be a positive whole number". There is no upper bound enforced on either, so a large iteration count takes a long time in your browser, and a large key length takes a long time and a lot of memory.

No. crypto.subtle runs inside a Web Worker in this tab. The password is imported as a non-extractable PBKDF2 key, used for the derivation, and dropped when the run ends. Nothing is uploaded, nothing is saved between runs, and the tool works with the network off.