cpp-Enchive一个文件加密工具

# Enchive : encrypted personal archives Enchive is a tool to encrypt files to yourself for long-term archival. It's a focused, simple alternative to more complex solutions such as GnuPG or encrypted filesystems. Enchive has no external dependencies and is trivial to build for local use. Portability is emphasized over performance. Supported platforms: Linux, BSD, macOS, Windows The name is a portmanteau of "encrypt" and "archive," pronounced en'kīv. Files are secured with ChaCha20, Curve25519, and HMAC-SHA256. Manual page: [`enchive(1)`](http://nullprogram.com/enchive/) ## Installation Clone this repository, then: $ make PREFIX=/usr install This will install both the compiled binary and manual page under `PREFIX`. For staged installs, `DESTDIR` is also supported. The binary doesn't have any external dependencies and doesn't actually need to be installed before use. ## Usage There are only three commands to worry about: `keygen`, `archive`, and `extract`. The very first thing to do is generate a master keypair using `keygen`. You will be prompted for the passphrase to protect the secret key, just like `ssh-keygen`. $ enchive keygen By default, this will create two files in `$XDG_CONFIG_HOME/enchive` (or `$HOME/.config/enchive`): `enchive.pub` (public key) and `enchive.sec` (secret key). On Windows, these are found under `%APPDATA%\enchive` instead. Distribute `enchive.pub` to any machines where you plan to archive files. It's sufficient to encrypt files, but not to decrypt them. To archive a file for storage: $ enchive archive sensitive.zip This will encrypt `sensitive.zip` as `sensitive.zip.enchive` (leaving the original in place). You can safely archive this wherever. To extract the file on a machine with `encrypt.sec`, use `extract`. It will prompt for the passphrase you entered during key generation. $ enchive extract sensitive.zip.enchive The original `sensitive.zip` will be reproduced. With no filenames, `archive` and `extract` operate on standard input and output. ### Key management One of the core features of Enchive is the ability to derive an asymmetric key pair from a passphrase. This means you can store your archive key in your brain! To access this feature, use the `--derive` (`-d`) option with the `keygen` command. $ enchive keygen --derive There's an optional argument to `--derive` that controls the number of key derivation iterations (e.g. `--derive=26`). The default is 29. This is a power two exponent, so every increment doubles the cost both in memory and computational demands. If you want to change your protection passphrase, use the `--edit` option with `keygen`. It will load the secret key as if it were going to "extract" an archive, then write it back out with the new options. This mode will also regenerate the public key file whether or not it exists. Enchive has a built-in protection key agent that keeps the protection key in memory for a configurable period of time (default: 15 minutes) after a protection passphrase has been read. This allows many files to be decrypted inside a brief window with only a single passphrase prompt. Use the `--agent` (`-a`) global option to enable it. If it's enabled by default, use `--no-agent` to turn it off. $ enchive --agent extract file.enchive Unlike gpg-agent and ssh-agent, this agent need not be started ahead of time. It is started on demand, shuts down on timeout, and does not coordinate with environment variables. One agent is created per unique secret key file. This feature requires a unix-like system. ## Notes The major version number increments each time any of the file formats change, including the key derivation algorithm. There's no effort at error recovery. It bails out on early on the first error. It should clean up any incomplete files when it does so. A purposeful design choice is that encrypted/archived files have no distinguishing marks whatsoever (magic numbers, etc.), making them indistinguishable from random data. No effort is made to set stdin and stdout to binary mode. For Windows this means passing data through Enchive using stdin/stdout isn't useful. This is low priority because Microsoft's [UCRT file streams are broken anyway][pipe] when pipes are involved. ### Frequently asked questions > This tool will never achieve critical mass, so what's the point? Enchive doesn't need to interact with any other systems or people, so there's no need for critical mass, nor that there are any other users. > Why can't you use an existing/established tool instead? I'm not aware of any tool that does everything Enchive does. GnuPG comes close, but doesn't support deriving a key pair from a passphrase. If you're aware of an equal or better tool, please let me know. > Isn't it dangerous to derive a key pair from a passphrase? It is when it's done incorrectly. However, Enchive uses a memory-hard key derivation scheme that makes cracking passphrases very expensive — prohibitively so for any decent passphrase. This is because anyone who has access to even a single encrypted file can mount an offline attack. Deriving asymmetric keys from a passphrase is a standard practice in the Bitcoin world: [brainwallets][bw]. The caveat is that the passphrase must be sufficiently long, preferably chosen by a computer or [with dice][dw]. When generating a master key, Enchive's default configuration is extremely paranoid. It would be far cheaper to break into your home and perform an evil maid attack than it would be to crack even a short passphrase. This is not the weak point. > Shouldn't the initialization vector (IV) be generated randomly? The purpose of an IV is to allow the same key to be safely used multiple times. This is particularly important when the same key is derived on different occasions by Diffie-Hellman between the same key pair. Enchive generates a random ephemeral key pair each time a file is encrypted, so the IV is unnecessary. Since ChaCha20 requires an IV regardless, Enchive simply uses the hash of the key. This has the additional effect of allowing the client to verify its symmetric key before beginning decryption. Otherwise a wrong key would only be detected by the MAC after decryption has completed. > I'm getting the error "Value too large for defined data type." This is a flaw in the 32-bit version of glibc that prevents C programs from even opening files larger than 2GB. Compile with "large file support" enabled: make CFLAGS='-O3 -D_FILE_OFFSET_BITS=64' Alternatively, use your shell to open files for Enchive: $ enchive archive <largefile >largefile.enchive Note that Enchive will not be able to delete shell-opened files in case of errors (tampering, etc.). ## Encryption/decryption algorithm The process for encrypting a file: 1. Generate an ephemeral 256-bit Curve25519 key pair. 2. Perform a Curve25519 Diffie-Hellman key exchange with the master key to produce a shared secret. 3. SHA-256 hash the shared secret to generate a 64-bit IV. 4. Add the format number to the first byte of the IV. 5. Initialize ChaCha20 with the shared secret as the key. 6. Write the 8-byte IV. 7. Write the 32-byte ephemeral public key. 8. Encrypt the file with ChaCha20 and write the ciphertext. 9. Write `HMAC(key, plaintext)`. The process for decrypting a file: 1. Read the 8-byte ChaCha20 IV. 2. Read the 32-byte ephemeral public key. 3. Perform a Curve25519 Diffie-Hellman key exchange with the ephemeral public key. 4. Validate the IV against the shared secret hash and format version. 5. Initialize ChaCha20 with the shared secret as the key. 6. Decrypt the ciphertext using ChaCha20. 7. Verify `HMAC(key, plaintext)`. ## Key derivation algorithm Enchive uses an scrypt-like algorithm for key derivation, requiring a large buffer of random access memory. Derivation is controlled by a single difficulty exponent *D*. Secret key derivation requires 512MB of memory (D=29) by default, and protection key derivation requi