Security
Bip39Chiper-TS implements the same Positional BIP-39 Obfuscation v1 scheme as the macOS app. Cryptography and threat model are shared across the product line.
Canonical write-up: Security on chiper.developer.pm (shared with the macOS app).
Library docs: ts.chiper.developer.pm.
Normative algorithm: Algorithm specification / online.
Summary
| Property | Value |
|---|---|
| Purpose | Obfuscation of a BIP-39 mnemonic |
| Network | None in the library |
| Password in export | Never |
| Code order | Irrelevant for recovery |
| Seed validation | BIP-39 checksum on complete recover |
| Default iterations | 600,000 PBKDF2-HMAC-SHA256 |
| Default key size | 32 bytes |
| Min password | 8 characters (API) |
Warning
Not encryption · not a hardware wallet
Anyone with both codes and password recovers the phrase. Keep them separate. Do not treat this as a replacement for a hardware wallet or audited key-management system.
Library-specific notes
- No I/O — the package does not touch the filesystem, network, or clipboard. You control how secrets enter and leave the process.
- Memory —
createSessionholds the derived key and lookup table untilclear(). Prefer clearing after use; JS cannot guarantee secure wipe. - Browser main thread — default PBKDF2 (600k) plus N×2048 HMAC for recover is CPU-heavy. Use a Web Worker for UI apps.
- Async API — KDF uses
@noble/hashesasync PBKDF2 so the event loop can breathe; recover table build is still synchronous CPU work after the key is ready. - Password policy — length ≥ 8 is enforced on high-level APIs to match the reference app; it is a product rule, not a cryptographic parameter.
Recommendations
- Strong, unique password — iterations only help if guessing is hard.
- Store codes and password separately.
- Verify recovery with a test phrase before relying on real funds.
- For high-value keys, use a hardware wallet; treat Bip39Chiper as an optional obfuscation layer only.