ddidderr
53bb927a87
`Header::encode()` previously hard-coded `VERSION_CURRENT` (= 2) on every write. Because the encoded header is fed back as AEAD AAD on decrypt, this broke decryption of any v1 ciphertext written before commit75afadb: the file's authenticated AAD has version byte 1, but the recomputed AAD has byte 2, so AEAD verification fails on every chunk. The release notes for75afadbexplicitly promised v1 compatibility, so this is a regression against the documented contract — caught by an external reviewer who reproduced it by encrypting with HEAD^ and decrypting with HEAD. Fix by adding a `version: u8` field to `Header`. `Header::read()` now captures the on-disk byte and `encode()` writes it back. New encrypts in `crypto::encrypt()` set `version = VERSION_CURRENT`, so freshly written files are unchanged on the wire; only the round-trip path through `read → encode` is now byte-identical for v1 inputs. This was the simplest fix that preserves the existing AAD design (header bytes verbatim → AAD). Alternatives considered: - Storing the raw header bytes alongside the parsed struct would also work but spends an extra allocation and adds a second source of truth for the same data. - Conditionally emitting v2 only when flags != 0 would happen to produce v1 bytes for a v1 input, but it conflates "what version does this file claim" with "does it carry length commitment" — two things that should stay independent for future flag bits. Test plan: - `header::tests::reads_v1_header` now also asserts that re-encoding a parsed v1 header reproduces the original bytes exactly (so the AAD round-trips). - New `crypto::tests::decrypts_v1_ciphertext` and `decrypts_v1_ciphertext_parallel` build a multi-chunk v1 fixture by hand (XChaCha20Poly1305 with version-byte-1 AAD) and confirm `decrypt()` succeeds on both the serial and parallel paths. - Manual: built `HEAD^` in a worktree, encrypted a 200-byte payload with `--chunk-size 64`, decrypted with the patched binary at `-j 1` and `-j 4`. Both round-trip; output bytes match input. Refs: external review identifying this regression.
fcry - [f]ile[cry]pt
A file en-/decryption tool for easy use.
Currently fcry uses ChaCha20Poly1305 (RFC 8439) as AEAD cipher provided by the chacha20poly1305 crate.
Status
Currently fcry is not thoroughly tested and in early stages of development.
There is a chance, that something is broken as of now.
Encryption seems to work, but due to a possible lack of understanding of some underlying methods
(or misinterpretation) it could theoretically be not effective at all.
See TODO.md for further information.