This library is designed to securely store cryptographic private keys for blockchain wallets (Ethereum, Solana) using the Web3 Secret Storage format.
-
At-Rest Key Exposure
- Private keys are encrypted with AES-128-CTR using keys derived from passwords
- Uses memory-hard KDFs (Scrypt, PBKDF2) to resist brute-force attacks
- Default Scrypt parameters (N=2^18) provide strong protection
-
Password Brute-Force Attacks
- Scrypt default: N=262,144, r=8, p=1 (~256 MB memory, ~1-2 seconds)
- PBKDF2 default: 600,000 iterations (OWASP recommended)
- Sensitive mode: N=2^20 (~1 GB memory, ~5-10 seconds)
-
Timing Attacks on Password Verification
- MAC comparison uses constant-time equality (
subtle::ConstantTimeEq) - Password correctness is not leaked via timing side-channels
- MAC comparison uses constant-time equality (
-
Memory Disclosure
- Sensitive data (derived keys, plaintext, IVs) is zeroized after use
- Chain key types implement
ZeroizeOnDrop to_keystore_bytes()returnsZeroizing<Vec<u8>>for automatic cleanup
-
File Permission Exposure (Unix)
- Keystore files are written with mode 0600 (owner read/write only)
-
Weak Passwords
- The library does not enforce password strength requirements
- Users are responsible for choosing strong, unique passwords
- Recommendation: 12+ characters with mixed case, numbers, and symbols
-
Memory Forensics While Running
- While keys are in use, they exist in memory
- A sufficiently privileged attacker with memory access can extract keys
- For highest security, use hardware security modules (HSMs)
-
Malicious Dependencies
- Users should audit dependencies and use
cargo audit - Consider using vendored dependencies in high-security contexts
- Users should audit dependencies and use
-
Side-Channel Attacks Beyond Timing
- Power analysis, electromagnetic emissions, etc. are out of scope
- Use dedicated hardware for protection against these attacks
-
Compromised System
- If the system is compromised (rootkit, keylogger), all bets are off
- Key material can be captured during password entry or key generation
-
Key Generation Entropy
- The library relies on the OS CSPRNG (
rand::thread_rng()) - On systems with poor entropy sources, keys may be predictable
- The library relies on the OS CSPRNG (
| Component | Algorithm | Security Level |
|---|---|---|
| Encryption | AES-128-CTR | 128-bit |
| MAC (Ethereum) | Keccak256 | 256-bit |
| MAC (Other chains) | SHA256 | 256-bit |
| KDF (default) | Scrypt | Memory-hard |
| KDF (alternative) | PBKDF2-HMAC-SHA256 | CPU-hard |
| Ethereum keys | secp256k1 ECDSA | ~128-bit |
| Solana keys | Ed25519 | ~128-bit |
This library uses well-audited RustCrypto implementations:
aes,ctr- AES encryptionsha2,sha3- Hash functionspbkdf2,scrypt- Key derivationk256- secp256k1 (Ethereum)ed25519-dalek- Ed25519 (Solana)subtle- Constant-time operationszeroize- Memory sanitization
Run cargo audit regularly to check for known vulnerabilities.
- Use strong, unique passwords for each keystore
- Use Scrypt (default) rather than PBKDF2 for new keystores
- Back up keystores securely - encrypted cloud storage or offline media
- Run
cargo auditin your CI/CD pipeline - Keep dependencies updated to receive security patches
- Consider hardware wallets for high-value keys
- Test with small amounts before storing significant value
- Added
ZeroizeOnDropforEthereumKeyandSolanaKey to_keystore_bytes()now returnsZeroizing<Vec<u8>>- Zeroize IV, ciphertext, and MAC bytes after decryption
- Set restrictive file permissions (0600) on Unix
- Increased PBKDF2 default iterations to 600,000 (OWASP)
- Added EIP-55 checksummed Ethereum addresses