Skip to content

fix(cli): derive identity encryption key with scrypt and a random salt - #635

Open
Kamirus wants to merge 2 commits into
mainfrom
fix/identity-encryption-kdf
Open

fix(cli): derive identity encryption key with scrypt and a random salt#635
Kamirus wants to merge 2 commits into
mainfrom
fix/identity-encryption-kdf

Conversation

@Kamirus

@Kamirus Kamirus commented Jul 27, 2026

Copy link
Copy Markdown
Collaborator

Password-protected identities (mops user import with a password) were encrypted with AES-256-CTR under a key derived as an unsalted, single-round SHA-256 of the password, truncated to 32 base64 characters (192 bits of key material). If identity.pem.encrypted leaks, this allows fast offline brute-force — one cheap hash per guess, and rainbow tables apply since there is no salt. Flagged by CodeQL as js/insufficient-password-hash (high severity).

Encrypted identity files are now versioned with a MOPSENCv1 magic header. New-format files derive the key with scrypt (random 16-byte per-file salt, N=2^17, ~100ms per derivation) and encrypt with AES-256-GCM, so tampering and wrong passwords are detected by authentication rather than by failing to parse the decrypted PEM.

Compatibility

Headerless files are decrypted with the legacy scheme and transparently re-encrypted in the new format after a successful decode (best-effort — a read-only file keeps working, just unupgraded). Legacy collision with the magic header is not a concern: legacy files start with a random 16-byte IV, so a 9-byte match has probability 2^-72.

No CLI surface changes; --help and docs don't describe the on-disk format, so no doc updates beyond the changelog.

Verified end-to-end via the real CLI against a scratch XDG_CONFIG_HOME: import → file starts with MOPSENCv1; correct password → principal; wrong password → Error: Invalid password; a legacy-encrypted file decodes to the same principal and is upgraded in place.

🤖 Generated with Claude Code

The encrypted identity file (identity.pem.encrypted) used an unsalted
single-round SHA-256 of the password as the AES-256-CTR key, allowing
fast offline brute-force if the file leaks (CodeQL
js/insufficient-password-hash).

New files are versioned with a MOPSENCv1 magic header and encrypted
with AES-256-GCM using a scrypt-derived key (random 16-byte per-file
salt, N=2^17). Legacy headerless files still decrypt and are
transparently re-encrypted in the new format after a successful decode.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Comment thread cli/tests/pem.test.ts
const encryptLegacy = (buffer: Buffer, password: string): Buffer => {
let key = crypto
.createHash("sha256")
.update(password)
…on-kdf

# Conflicts:
#	cli/CHANGELOG.md
#	cli/pem.ts
#	cli/tests/pem.test.ts
@github-actions

Copy link
Copy Markdown
Contributor

Cursor AI review

👀 HUMAN REVIEW REQUESTED — significant intended changes detected

Review complete. The diff is fully contained (3 files), and I've verified the crypto correctness, caller compatibility (cli/mops.ts, cli/commands/user.ts), legacy fallback, and the base behavior from the patch.

Category Assessment Details
Summary Replaces the unsalted SHA-256 + AES-256-CTR identity encryption with scrypt-derived keys (random per-file salt) + authenticated AES-256-GCM behind a MOPSENCv1 magic header, keeping legacy decryption and transparently re-encrypting old files in place.
Code Quality Clean, DRY (deriveKey/hasMagic shared), no speculative surface; legacy path retained only for decryption.
Consistency Matches existing cli/pem.ts structure and export patterns; no CLI surface change.
Security Fixes CodeQL high-severity weak hash; salted scrypt + AEAD detects tampering and wrong passwords; legacy re-encrypt guarded behind successful decode.
Tests High-signal targeted assertions cover round-trip, magic header, salt freshness, wrong-password, tamper, legacy decrypt, and in-place upgrade/no-touch-on-failure.
Maintainability File layout documented in comments; versioned magic header enables future format evolution.

Significant Changes Requiring Human Review

  • S2: On-disk identity encryption format migration with in-place rewrite
    • References: cli/pem.ts:7-21 (decodeFile re-encrypt), cli/pem.ts:80-107 (new GCM/scrypt format)
    • Base behavior: encrypted identity.pem.encrypted files used an unsalted SHA-256 key + AES-256-CTR with no header, and were only read, never rewritten, on decode.
    • Diff proof: this PR intentionally introduces a new MOPSENCv1 scrypt/AES-256-GCM format and rewrites the user's existing identity key file in place (fs.writeFileSync(file, encrypt(...))) on the first successful decode.
    • Impact: a reviewer should confirm the identity-file security path is acceptable — specifically that the non-atomic in-place rewrite of the user's key file is tolerable (best-effort, try/catch, post-decode) and that the resulting forward-incompatibility (a re-encrypted file cannot be read by an older mops CLI) is intended.
    • Confidence: High

Verdict

Decision: REQUEST_HUMAN_REVIEW
Risk: Low
Reason: A correct, well-tested security hardening of the identity encryption path with no detected bugs, but it changes the on-disk identity key format and rewrites existing key files in place, which falls under the security-sensitive identity category warranting a human sign-off.


Generated for commit 5a9d633

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants