Я создал зашифрованный файл с симметричным шифрованием.
gpg -c 50GBfile
Теперь я хочу удалить оригинал. Прежде чем удалить оригинал, я хочу проверить целостность зашифрованного файла. (Подобно тому, как файлы ZIP используют CRC). Предлагает ли gpg способ проверки содержимого симметрично зашифрованных файлов?
Если вы зашифровали файл с помощью gpg -c , то нет способа проверить, что файл содержит, не зная парольную фразу. Это основное свойство симметричного шифрования. Так как вам все равно нужно будет предоставить фразу-пароль, выполните настоящий тест: распакуйте файл и сравните его с оригиналом. В Linux или другом варианте Unix:
gpg -d <50GBfile.gpg | cmp - 50GBfile
Если вам нужна дополнительная гарантия целостности, вы можете подписать файл своим закрытым ключом, добавив параметр -s при шифровании файла.
gpg -c -s 50GBfile
Затем вы можете проверить подпись с помощью gpg --verify 50GBfile.gpg . Обратите внимание, что это только дает гарантию того, что файл является одним из файлов, которые вы подписали, это не защитит вас от ошибки, при которой вы подписали неправильный файл.
Если вы использовали асимметричное шифрование (с открытым ключом получателя - вашим собственным открытым ключом), то для проверки того, что файл имеет желаемое содержимое, потребуется закрытый ключ получателя. С несколькими получателями подойдет закрытый ключ любого получателя. Обычно вы помещаете свой собственный ключ в качестве получателя всех зашифрованных сообщений с encrypt-to или hidden-encrypt-to в файле конфигурации GPG.
Единственная операция проверки в gnupg - проверка подписи, которая в основном шифрует хэш зашифрованного файла с помощью открытого ключа (= знак).
По моему мнению, это означает, что если выходные биты будут повреждены во время шифрования файла, хеш будет вычислен по отношению к поврежденному файлу. Вы никогда не обнаружите это, проверив подпись этого файла, так как вы подписали уже поврежденный файл.
Похоже, что единственный способ убедительно проверить зашифрованный файл на предмет повреждения - это пройти длительный процесс дешифрования сгенерированного файла и сравнить его хеш с оригиналом.
И это то, что Сеперо предложил выше, но вместо «Вы можете проверить ...» должно быть « Единственный способ проверить ...»
Обновление - чтобы довести точку до дома:
Несколько минут назад я сделал именно это: разделил резервный файл объемом 9,8 ГБ на 5 частей rar, и каждый фрагмент симметрично зашифровывался с помощью gnupg. Перед удалением частей rar я проверил целостность зашифрованных частей, как я обсуждал выше: 1 из 5 не прошел хэш-тест. Я снова расшифровал этот фрагмент, и теперь хеш дешифрованного фрагмента соответствовал оригинальному фрагменту rar.
Я двоично сравнил плохую расшифрованную часть rar с хорошей расшифрованной, и единственное различие в этих файлах 2 ГБ было одним байтом: C8 против 48 - что вызвано 1-битным переворотом (то есть 11001000 против 01001000).
Мораль этой истории заключается в том, что если на хорошей системе WIN7 и хорошем жестком диске gnupg может немного перевернуться при расшифровке, он может сделать это и при шифровании. Я никогда не пропущу этот шаг проверки целостности.
Вы можете проверить это путем извлечения и сравнения md5sum с оригиналом.
$ gpg -d 50GBfile | md5sum
gpg: AES256 encrypted data
gpg: gpg-agent is not available in this session
gpg: encrypted with 1 passphrase
1df1aaffb20c5255e282d6f584489993 -
$ md5sum 50GBfile
1df1aaffb20c5255e282d6f584489993 50GBfile
Если вы хотите проверить целостность, вам также необходимо подписать исходный файл.
gpg --encrypt - подписать файл
Наконец, вы можете проверить целостность (на основе подписи), расшифровав файл (целостность проверяется автоматически)
gpg --decrypt file.asc