** [veil-cli #2] Ethereum keystore v3 with zero new dependencies — just node:crypto **

Post original

Previously: veil-cli #1 — decode, simulate, risk before you sign When you're building a security tool, every dependency becomes part of your threat model. That's why we implemented Ethereum keystore v3 using only node:crypto and dependencies we already had. What keystore v3 actually is The format used by geth, MetaMask, and MyCrypto is straightforward: Derive a key from your password using scrypt Encrypt the private key with AES-128-CTR using the first 16 bytes of the derived key Compute a MAC over the last 16 bytes + ciphertext to detect wrong passwords on decryption Everything needed is in node:crypto — except the MAC, which uses keccak256. We already had viem as a dependency, so we pulled keccak256 from there. No new packages. One implementation detail surprised me crypto.scryptSync() with N=131072 blocks the event loop for ~1–2 seconds. For a CLI that's technically acceptable, but we switched to the async version anyway — and had to raise maxmem to 160MB because the Node default of 32MB isn't enough for these parameters. That one caught us off guard. One thing that's probably overkill The MAC comparison uses crypto.timingSafeEqual() instead of a plain string comparison. Is a timing attack against a local CLI keystore a realistic threat? Probably not. But if you're writing a security tool, it's hard to justify doing it the wrong way. Result veil wallet create — generates a key, asks for a password with confirmation, writes an encrypted .json to ~/.veil/wallets/ .json with 0o600 permissions. veil wallet import — same flow, bring your own private key. veil wallet list — shows all wallets and their addresses. The output is a standard keystore v3 file — importable into MetaMask or any client that supports the format. One thing I'm still debating: Should a security-focused CLI store encrypted private keys at all, or should it only integrate with external signers (hardware wallets, browser extensions)? Curious how others have approached that tradeoff. Repo: github link   submitted by   /u/Economy_Hamster_8645 [link]   [comments]