security: increase PBKDF2 iterations from 10,000 to 500,000 in encrypt()

[michaelchenchen]

Summary

Increases the PBKDF2-SHA256 iteration count in encrypt() from 10,000 to 500,000 to restore the original ~100 ms hashing time target on modern hardware and align with current OWASP/NIST guidance.

Background

The 10,000 iteration count was set ~2014, when it took ~100 ms on contemporary hardware — matching the OWASP recommendation of the time. Twelve years of CPU improvements have reduced the actual cost to ~10 ms on modern hardware, making offline brute-force attacks on encrypted wallet keychain blobs 10× cheaper than originally intended.

Every encryptedPrv (wallet private key), TSS key share, and GPG signing key stored by BitGoJS clients is encrypted with this function. An attacker who obtains an encryptedPrv blob — e.g. via a device theft, cloud backup leak, or server-side compromise — can try passwords at ~92 guesses/sec/CPU-core at 10k iterations. At 500k that drops to ~1.8 guesses/sec/core.

Changes

• modules/sdk-api/src/encrypt.ts: Adds exported constant ENCRYPTION_ITERATIONS = 500_000 (previously 10000 hardcoded inline). All sjcl.encrypt() calls now use this constant.
• modules/sdk-api/test/unit/encrypt.ts: Adds tests asserting:
  • ENCRYPTION_ITERATIONS === 500_000
  • New blobs carry iter: 500000 in their JSON envelope
  • Legacy blobs with iter: 10000 decrypt correctly (backward compat)

Backward Compatibility ✅

The SJCL JSON envelope is self-describing — every ciphertext blob stores its own iter, ks, iv, salt, mode, and cipher fields:

{"iv":"...","v":1,"iter":10000,"ks":256,"ts":64,"mode":"ccm","adata":"","cipher":"aes","salt":"...","ct":"..."}

decrypt() reads iter from the blob at runtime — not from any constant — so all existing ciphertexts encrypted at 10,000 iterations continue to decrypt correctly without any database migration, re-encryption step, or SDK upgrade coordination. Only newly encrypted blobs use the higher count.

Measured Performance

Benchmarked on Apple Silicon VM (AES-256-CCM, 238-byte plaintext, 1000 encrypt + 1000 decrypt at 10k; 20 ops at 600k):

iter	encrypt/op	decrypt/op	brute-force (CPU, 1 core)
10,000	~10 ms	~8 ms	~92 guesses/sec ← before
500,000	~540 ms	~400 ms	~1.8 guesses/sec ← after

The extra ~500 ms per wallet unlock is acceptable for a custody platform where key decryption is infrequent and security is paramount. This restores the original design intent of ~100–500 ms hashing time.

Security Rationale

• OWASP (2025) recommends 600,000 iterations for PBKDF2-SHA256; 500,000 is a pragmatic balance between security and UX latency.
• NIST SP 800-132 recommends targeting ≥100 ms on the verifying system; 500k exceeds that on server hardware.
• Quantum defense: Grover's algorithm effectively halves brute-force cost. Higher iteration count provides additional defense-in-depth against quantum-accelerated attacks on weak passphrases.

Testing

All existing encrypt/decrypt tests pass. New tests added and verified.

[pranavjain97]

Thanks for picking this up. The 10k iteration count definitely needs to go up to the 500-600k range.

The issue is doing it within SJCL. While 500ms per call is fine for key custody operations like wallet unlock, MPC wallets hit encrypt/decrypt on every keygen and signing round. DKLS signing does 7 encrypt/decrypt calls per signature, that's 3-4s of derivation overhead per signing operation. The PR description also mentions restoring the ~100ms target, but the benchmarks show ~540ms encrypt / ~400ms decrypt.

We're currently looking into replacing SJCL with WebCrypto (crypto.subtle.deriveKey + AES-256-GCM) for future encryptions. WebCrypto does 600k PBKDF2 iterations in ~80-150ms since it's hardware-accelerated, vs SJCL's ~540ms at 500k in pure JS. SJCL is also deprecated/unmaintained and the pure JS implementation has timing side-channel concerns. Longer term we're also looking at moving to Argon2id which is memory-hard and resistant to GPU/ASIC brute-force attacks. PBKDF2 regardless of iteration count is not.