Я создал зашифрованный файл с симметричным шифрованием.
gpg -c 50GBfile
Теперь я хочу удалить оригинал. Перед тем как удалить оригинал, я хочу проверить целостность зашифрованного файла. (Похоже на то, как файлы ZIP используют CRC). Предлагает ли gpg способ проверки содержимого симметрично зашифрованных файлов?
решение1
Если вы зашифровали файл с помощью 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.
решение2
Единственная операция «проверки» в gnupg — это проверка подписи., который в основном шифруетхэшзашифрованного файла с открытым ключом (=sign).
По моему мнению, это означает, что если выходные биты будут повреждены во время шифрования файла, хэш будет рассчитан поповрежденный файл. Вы никогда не узнаете этого, проверивподписьэтого файла, поскольку вы подписали уже поврежденный файл.
Похоже, единственный способ достоверно проверить зашифрованный файл на предмет повреждения — это пройти длительный процесс расшифровки сгенерированного файла и сравнить его хэш с оригиналом.
И это то, что Сеперо предложил выше, но вместо«Вы могли бы проверить...»должен быть"Theтолькоспособ проверить..."
Обновление — чтобы донести суть:
Несколько минут назад я сделал именно это: разделил файл резервной копии размером 9,8 ГБ на 5 частей rar, и каждая часть была симметрично зашифрована gnupg. Перед удалением частей rar я проверил целостность зашифрованных частей, как я уже говорил выше: 1 из 5 не прошел хэш-тест. Я снова расшифровал эту часть, и теперь хэш расшифрованной части совпал с исходной частью rar.
Я сравнил плохо расшифрованную часть rar с хорошо расшифрованной, и единственное различие в этих 2 ГБ файлах было в одном байте: C8 против 48, что вызвано переворотом одного бита (т. е. 11001000 против 01001000).
Мораль истории в том, что если на хорошей системе WIN7 и хорошем жестком диске gnupg может немного изменить расшифровку, он может сделать то же самое и с шифрованием. Я больше никогда не пропущу этот шаг проверки целостности.
решение3
Вы можете проверить это, извлекая и сравнивая 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
решение4
Если вы хотите проверить целостность, вам необходимознака также исходный файл.
gpg --encrypt --signфайл
Наконец, вы можете проверить целостность (на основе подписи), расшифровав файл (целостность проверяется автоматически)
gpg --расшифроватьфайл.asc