Overview
Keystore decryption reverses the encryption process to recover a private key. It derives the same encryption key from the password, verifies the MAC to ensure correctness, then decrypts the ciphertext.
Decryption Process
Algorithm Flow
Step by Step
- Validate keystore version (must be 3) and KDF (scrypt or pbkdf2)
- Extract parameters from keystore (salt, IV, ciphertext, MAC)
- Derive key from password using same KDF and parameters
- Split derived key: first 16 bytes for decryption, next 16 for MAC verification
- Compute expected MAC as
keccak256(macKey || ciphertext)
- Verify MAC using constant-time comparison
- Decrypt ciphertext with AES-128-CTR if MAC matches
Basic Decryption
Error Handling
Decryption can fail for several reasons. Always handle errors:
Error Types
Security Features
Constant-Time MAC Comparison
MAC verification uses constant-time comparison to prevent timing attacks:
This ensures:
- Attackers cannot determine how many bytes of the MAC matched
- Password guessing attacks don’t get timing hints
- Both correct and incorrect passwords take the same time to compare
No Partial Decryption
If MAC verification fails, no decryption attempt is made:
Advanced Usage
Wallet Unlock Flow
Loading from File
Browser localStorage
Batch Decryption
Decryption time depends on KDF parameters stored in the keystore:
Showing Progress
Web Worker (Non-blocking)
Common Issues
Wrong Password
The most common decryption error:
There’s no way to “recover” a keystore with a forgotten password. The only option is to try different passwords or use the original private key if backed up elsewhere.
Corrupted Keystore
If the keystore JSON is modified, decryption fails:
IV Corruption
A special case: corrupted IV passes MAC verification but produces wrong plaintext:
Always validate the resulting private key (e.g., check that it produces the expected address) after decryption.
References