Encryption
沒有密鑰完整性檢查的文件加密實用程序（對稱密鑰）
使用對稱密鑰加密文件時，大多數常用實用程序（如 gpg、mcrypt 等）將資訊儲存在加密消息中，可用於在解密期間驗證密鑰的完整性。例如，如果在解密過程中輸入了錯誤的密鑰，gpg 將反駁：
gpg：解密失敗：密鑰錯誤
假設我正在加密一個包含隨機字元串的文件。然後，標準實用程序中使用的密鑰完整性檢查會增加一個漏洞。
是否有一個通用實用程序不會儲存用於驗證密鑰/消息完整性的任何資訊或冗餘（因此將為任何提供的密鑰“解密”加密文件）？
作為我其他答案的替代方案，我想提供其他東西。美麗的東西…… dm-crypt。
普通的 dm-crypt（沒有 LUKS）不儲存任何關於密鑰的資訊；相反，
cryptsetup非常樂意使用任何密碼打開普通設備並開始使用它。請允許我舉例說明：[root:tmp]# fallocate -l 16M cryptfile [root:tmp]# cryptsetup --key-file - open --type plain cryptfile cfile-open <<<"pa55w0rd"注意：您
cryptfile必須大於或等於 512 字節。我假設由於最小扇區大小cryptsetup強制執行。此時，您可能希望將所有隨機數據寫入
/dev/mapper/cfile-open. 對我來說，提前適當地調整原始密碼文件的大小，以便使用所有空間，這似乎是明智的；但是，您可以輕鬆地將其視為另一種通過隱蔽性增加的安全性，並準確記錄您寫入的數據量。（這只有在底層塊已經是半隨機的情況下才真正起作用，即，如果你不打算完全填充文件，你應該用openssl randordd if=/dev/urandom代替創建它fallocate。）……你甚至可以dd用來開始寫作在設備中間的某個地方。現在，我將做一些更簡單的事情。
[root:tmp]# cryptsetup status cfile-open /dev/mapper/cfile-open is active. type: PLAIN cipher: aes-cbc-essiv:sha256 keysize: 256 bits device: /dev/loop0 loop: /tmp/cryptfile offset: 0 sectors size: 32768 sectors mode: read/write [root:tmp]# b $((32768*512)) B KiB MiB GiB TiB PiB EiB 16777216 16384.0 16.00 .01 0 0 0 [root:tmp]# ll cryptfile -rw-r--r--. 1 root root 16777216 Feb 21 00:28 cryptfile [root:tmp]# openssl rand -out /dev/mapper/cfile-open $((32768*512)) [root:tmp]# hexdump -n 16 -C /dev/mapper/cfile-open 00000000 00 1d 2d 11 ac 38 c4 d3 cc 81 4f 32 de 64 01 ca |..-..8....O2.d..| 00000010 [root:tmp]# cryptsetup close cfile-open至此，我已經用 16 MiB 的隨機數據填充了我的加密文件。看看當我使用錯誤的密碼再次打開它時會發生什麼，然後為了清楚起見，我會用正確的密碼再次打開它，你會看到原始數據仍然完好無損。
[root:tmp]# cryptsetup --key-file - open --type plain cryptfile cfile-open <<<"pass" [root:tmp]# hexdump -n 16 -C /dev/mapper/cfile-open 00000000 89 97 91 26 b5 46 87 0c 67 87 d8 4a cf 78 e6 d8 |...&.F..g..J.x..| 00000010 [root:tmp]# cryptsetup close cfile-open [root:tmp]# cryptsetup --key-file - open --type plain cryptfile cfile-open <<<"pa55w0rd" [root:tmp]# hexdump -n 16 -C /dev/mapper/cfile-open 00000000 00 1d 2d 11 ac 38 c4 d3 cc 81 4f 32 de 64 01 ca |..-..8....O2.d..| 00000010 [root:tmp]#享受。