4.0 KiB
Findings
- High: attacker-controlled headers can cause large pre-auth resource use. chunk_size and Argon2 params are read before any AEAD tag is verified, then used for allocation/KDF work. A malicious file can request huge buffers or Argon2 memory/time. See src/header.rs:107, src/crypto.rs:54, src/crypto.rs:189. Add strict max caps before allocation/KDF.
- High: output temp file handling is unsafe in hostile directories. Output uses predictable .tmp plus File::create, which follows symlinks and truncates existing files. Decrypted plaintext may also be created with permissive umask-derived permissions. See src/utils.rs:71. Use randomized create_new temp files, 0600 permissions for plaintext, and safe persist semantics.
- Medium: stdout decrypt streams verified chunks before whole-file success. File output is protected by temp-file commit, but stdout cannot roll back. A truncated valid-prefix ciphertext can emit authentic but incomplete plaintext before the final error. See src/crypto.rs:217 and src/pipeline.rs:348. Document this sharply or add a “verify before stdout” mode.
- Medium: random-access decrypt authenticates only requested chunks. That is expected for range reads, but users may mistake success for whole-file integrity. --length 0 succeeds without authenticating any chunk, so it does not prove the key or file is valid. See src/crypto.rs:307.
- Medium: weak passphrase choices are accepted. Empty/very short passphrases and very low Argon2 settings are possible. Defaults are strong, but user-supplied weak parameters are stored and honored. See src/main.rs:55, src/secrets.rs:172. Enforce floors or require an explicit insecure flag.
- Medium: raw-key UX invites misuse. --raw-key is a UTF-8 command-line string, visible in process listings, and not truly arbitrary 32 raw bytes. It is documented as dangerous, but still a first-class CLI path. See src/main.rs:37. Prefer hex/base64 from file/stdin/fd, or make raw key testing-only.
- Medium: plaintext buffers are not zeroized. Keys/passphrases get protected handling, but plaintext/ciphertext chunk buffers are ordinary Vec and may leave sensitive plaintext in heap memory after decrypt/encrypt. See src/crypto.rs:127, src/ crypto.rs:210, src/pipeline.rs:48.
- Medium/Low: unchecked arithmetic and unbounded CLI knobs remain. chunk_size + TAG_LEN, random-access offsets, huge -j values, and release overflow behavior deserve explicit checked math and caps. See src/crypto.rs:190, src/pipeline.rs:61, Cargo.toml:32.
- Low: platform hardening is partial. Unix core dumps are disabled, which is good, but Windows crash dumps are not addressed, and non-secret plaintext buffers are not protected from swap/dumps. See src/main.rs:141.
- Low: custom crypto framing needs a written threat model and test vectors. The construction is reasonable, but custom file formats are easy to misuse over time. README still says the tool is early and not thoroughly tested, and links a missing TODO. See README.md:6.
Good Signs
The core AEAD choice is solid: XChaCha20-Poly1305 with random nonce prefix, per-chunk counters, full header as AAD, and an authenticated final chunk. The code also commits plaintext length for regular files, rejects unknown header flags, uses Argon2id for passphrases, disables Unix core dumps, and avoids committing partial file outputs on failure.
Post-Quantum
For the current symmetric-only design, there is no RSA/ECC public-key crypto to replace. A 256-bit symmetric key is generally the right shape for post-quantum resistance; Grover-style search still leaves roughly 128-bit security. The weak link is password entropy, not the AEAD.
If you add recipient/public-key encryption or signatures, use standardized PQC: NIST finalized FIPS 203 ML-KEM, FIPS 204 ML-DSA, and FIPS 205 SLH-DSA in 2024, and recommends migration planning now. Sources: NIST FIPS announcement (https://www.nist.gov/news-events/news/2024/08/announcing-approval-three-federal-information-processing-standards-fips), NIST PQC project (https://www.nist.gov/programs-projects/post-quantum-cryptography).