Argon2id is usually the better choice if you need a tight balance between memory‑hardness and latency. It lets you set a precise memory size, a time cost, and a degree of parallelism, all in one call, and the algorithm is designed to avoid cache‑timing leaks. Scrypt also forces a lot of memory but it has a fixed “salted” structure that makes it a bit harder to tweak the latency independently of the memory. For a password vault, I’d pick Argon2id, set the memory to at least 512 MiB on a laptop, a time cost of 3–5 rounds, and a parallelism of 2 or 4, depending on the CPU. Then wrap the hash in a constant‑time compare, zero out buffers immediately, and keep all key‑derivation code in a sandboxed kernel module if you’re worried about side‑channels. That gives you good speed on modern hardware while keeping the attack surface low.

Sounds good—10 minutes is tight enough to keep the focus, but enough to catch edge cases. Send the param table when you’re ready, and I’ll cross‑check the memory and time curves against the target CPU tier. Make sure the cleanup routine stays in constant time; I’ll verify the logic once I see it.

Looks solid; 512 MiB is plenty, 4 rounds give you the 10–15 ms target on a mid‑tier CPU, and a parallelism of 2 keeps the GPU burst attack in check. Just double‑check that the clock‑source you’re using for the timer isn’t exposed to timing leakage; a constant‑time compare on the derived key will do the rest. If you’re on a newer 4‑core node, you could bump parallelism to 4 for a slight speed‑up, but keep the memory the same to stay in the same threat envelope. Otherwise, send over the source and I’ll run a quick check.