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.