b2KIT

Argon2 Key Derivation Tool

Derive keys from passwords using Argon2id with configurable memory cost, time cost, and parallelism parameters.

Tested tool guide Tested browser tools Checked August 16, 2026

What Argon2 Key Derivation Tool does and how it behaves

Enter a password, a salt, and memory/time/parallelism parameters, and this tool computes the Argon2id derived key entirely in the browser. Argon2id is a memory-hard function: it deliberately forces each computation to touch a large, tunable block of RAM, which is what makes it slow to brute-force on GPUs and ASICs compared to older hash-based KDFs. What people most often get wrong is the salt: they treat it as a fixed or optional field, when in fact a new random salt must be generated per password and stored alongside the output, or the derivation can never be reproduced or verified correctly.

How the result is produced

1

Memory, time, and parallelism costs

Memory cost (m) sets how many kibibytes of RAM each hash requires; time cost (t) sets how many passes the algorithm makes over that memory; parallelism (p) sets how many independent lanes run at once. Raising m is the strongest defense against custom cracking hardware since it forces attackers to buy RAM per guess, not just CPU time.

2

Why 'id' specifically

Argon2 has three variants: Argon2d uses data-dependent memory access (fast, resists GPU attacks, but leaks timing information), Argon2i uses data-independent access (side-channel resistant, weaker against GPUs), and Argon2id runs Argon2i for roughly the first half of the first pass and Argon2d after. This tool computes only Argon2id, the variant RFC 9106 recommends for most password hashing and key derivation.

Good uses

  • deriving a symmetric encryption key from a user passphrase before encrypting a file or message
  • generating a password hash to store in place of a plaintext password for a custom login system
  • checking how long a candidate memory/time/parallelism combination actually takes on real hardware before locking it into a production configuration

Limits and checks

  • High memory-cost settings (multi-gigabyte) can be slow or stall the browser tab, since JavaScript engines can hit allocation ceilings well below what a native implementation allows - test your intended parameters on the actual device before relying on them.
  • The tool has no way to confirm your salt is random or unique; typing a memorable string, reusing one salt across multiple passwords, or leaving it blank defeats a large part of what makes Argon2 resistant to precomputed and rainbow-table attacks.
  • A key derived here will only match a key derived elsewhere if every parameter lines up exactly - memory cost, time cost, parallelism, salt, output length, and Argon2 variant - so check the tool's default output length and encoding against what the receiving system expects before assuming a mismatch is a bug.

Common questions

What memory, time, and parallelism values should I actually use?

RFC 9106 gives two reference options: m=2 GiB, t=1, p=4 when memory is plentiful, or m=64 MiB, t=3, p=4 for constrained environments like mobile devices. Memory cost is generally the more effective lever against GPU and ASIC attackers. The right values depend on your hardware and how much derivation time you can tolerate, so test before deploying.

Is Argon2id better than bcrypt or PBKDF2 for this?

For most new designs, yes. PBKDF2 has no memory cost at all, and bcrypt's memory use is fixed and small, so both are cheaper to attack in parallel on GPUs than a properly tuned Argon2id. Argon2id's tunable memory hardness is why it's the current recommendation in RFC 9106 and OWASP's password storage guidance.

References and verification

The behavioral notes were checked against the browser implementation. Standards and primary references below define the relevant format, formula, or platform behavior.

Related Tools