id: Гость   вход   регистрация
текущее время 00:23 29/03/2024
Автор темы: Гость, тема открыта 23/01/2011 17:19 Печать
Категории: криптография, софт, gnupg, шифрование с открытым ключом, протоколы
http://www.pgpru.com/Форум/РаботаСGnuPG/GPGИЦелостностьДанных
создать
просмотр
ссылки

GPG и целостность данных


Проверяет ли GPG целостность данных во время шифрования файлов?
Сейчас криптую большие файлы по несколько гиг, очень длительный процесс, поэтому конечно не хотелось бы каждый раз обратно расшифровывать и проверять md5sum или другие хэши – с ума сойдешь иначе.
Возник вопрос, если работа gpg завершается без ошибок

могу я быть сколь-нибудь уверен, что в процессе криптования файла не потерялись какие-то данные, и он раскриптуется в нормальной виде, а не в виде абракадабры?



 
Комментарии
— SATtva (23/01/2011 19:54)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Проверяет ли GPG целостность данных во время шифрования файлов?

s/шифрования/расшифрования/ ?

Если шифровальный ключ поддерживает функцию MDC, то да, контроль целостности осуществляется.
— Гость (24/01/2011 10:58)   <#>
s/шифрования/расшифрования/ ?


Не, имеется ввиду целостность шифруемых данных. В случае, если во время шифрования произодет какой-нибудь программный или аппаратный сбой, например.

Если шифровальный ключ поддерживает функцию MDC, то да, контроль целостности осуществляется.


Дефолтный ELG-E/AES256 ?
В частности, из gpg (GnuPG) 1.4.9 из стандартного дистра Debian Lenny
— unknown (24/01/2011 11:33, исправлен 24/01/2011 11:35)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Что-то похожее обсуждалось. Это раз.


--force-mdc
Force the use of encryption with a modification detection code.
This is always used with the newer ciphers (those with a blocksize
greater than 64 bits), or if all of the recipient keys indicate MDC
support in their feature flags.

Это два.



Это три.

— Гость (24/01/2011 12:24)   <#>
unknown, спасибо.
1) Если предупреждений нет, то вроде все ок?
2)
То есть, включен, и форсить mdc через опцию --force-mdc не надо?
3) а сам mdc использует хэши md5, как видно из названия, или не обязательно?
P.S. Вообще, для проверки целостности файла принципиально md5 или sha512? Я пробовал один знак в большом файле поменять, хэш md5 принципиально изменяется в этом случае.
— unknown (24/01/2011 13:16, исправлен 24/01/2011 13:17)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

1 — да, если соблюден п.2. Можете повредить небольшой файл и посмотреть на это сообщение, почему бы самому не проверить ради интереса?
3 — нет, сходу не скажу, но скорее HMAC — сложную комбинацию md5 и sha-1, она более защищена от атак удлинения сообщения, например.

Вообще, для проверки целостности файла принципиально md5 или sha512?

Против какого противника? Самый стойкий пока-что SHA-512.

Я пробовал один знак в большом файле поменять, хэш md5 принципиально изменяется в этом случае.

Random Oracles are Practical (c)
А если применить специальные методы криптоанализа, то вдруг будет не так.

— SATtva (24/01/2011 13:48, исправлен 24/01/2011 13:48)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
3 — нет, сходу не скажу, но скорее HMAC — сложную комбинацию md5 и sha-1

MDC — "дешёвый" детектор модификаций: хэш SHA1 от шифруемых данных подаётся на алгоритм шифрования вместе с открытым текстом. Так, если шифртекст будет модифицирован, то за счёт сцепления блоков при расшифровании хэши не совпадут.


Не, имеется ввиду целостность шифруемых данных. В случае, если во время шифрования произодет какой-нибудь программный или аппаратный сбой, например.

Типа чего? Если файловая подсистема глюкнет (сама или получив некорректные данные с физического уровня), то этот глюк и будет корректно зашифрован, а потом так же корректно расшифрован. Если какая-то программная ошибка или сбой памяти/процессора, то программа или система с наибольшей вероятностью рухнут/зависнут в процессе работы, и ничего зашифровано не будет. Другое дело, если уже зашифрованные данные подвергнутся какому-то изменению (злонамеренному или случайному от повреждения физического носителя) — такой факт будет выявлен механизмом MDC.

— Гость (24/01/2011 14:20)   <#>
Можете повредить небольшой файл и посмотреть на это сообщение, почему бы самому не проверить ради интереса?

Попробовал. Создал простой текстовой файл с несколькими строчками текста, зафишровал, открыл шифрованный в редакторе vim и исправил один из знаков :-)
Без изменений дешифруется, внес изменения – открыл зашифрованный файл в текстовом редакторе, заменил один знак, получаю:

Обратно поменял знак на тот, который был – все нормально дешифрует.
Но в данном случае речь об изменении файла в ходе дешифрования, а я имел ввиду сбой во время выполнения gpg -e, т.е., например, когда gpg из-за сбоя получил на stdin деформированную строку из файла и ее зашифровал.

Против какого противника? Самый стойкий пока-что SHA-512.

В моем случае я просто разбивал старые бэкапы в формате .tar или .tgz на несколько файлов с помощью split, шифровал их через gpg и записывал на DVD-диски, чтобы расчистить внешний хард. Соответственно, я вычислял md5-хэши для зашифрованных файлов, чтобы потом проверить, корректно ли записалось на диск. Это делалось относительно долго для 4-гигобайтных файлов, и особенно долго считывалось при проверке хэшей уже с файлов, записанных на оптику. Боюсь, что с sha1 или паче sha512 было бы намного дольше.
В данном случае – "противник" – аппаратный (или программный) сбой при записи на DVD.

А если применить специальные методы криптоанализа, то вдруг будет не так.

То есть, скажем, имеется файл, выложенный на публичном ресурсе, кто-то подменяет его содержимое, причем делает так, чтобы md5-хэш получился такой же, как и с неизмененным файлом? При этом, внесенные в него изменения должны быть не какой-то ерундовой, а менять содержимое файла целенаправленно, с тем, чтобы его получатель получил неправильный текст (если этот файл носит информационный характер) или чтобы заруктить компьютер пользователя, который устанавливает к себе этот файл в составе какой-то программы?
Такое возможно? И, соответственно, если даны хэши md5, sha256 и sha512 – лучше все проверять, или можно самый стойкий?
Если сам где-то выкладываешь, также лучше давать несколько хэшей?
— Гость (24/01/2011 14:23)   <#>
Типа чего? Если файловая подсистема глюкнет (сама или получив некорректные данные с физического уровня), то этот глюк и будет корректно зашифрован, а потом так же корректно расшифрован.

Ясно, спасибо.
То есть, никакого другого варианта, как расшифровать, и вычислить хэш и сравнить с ориги.налом, нет? Прискорбно, когда шифруешь большие файлы.
Следующий раз, видимо, экономичнее будет делать кучу файлов криптоконтейнеров (с помощью того же dm-crypt/cryptsetup), класть куски архивов в них, и уже эти файло криптоконтейнеров записывать на DVD.
Наверное, так лучше и быстрее?
— SATtva (24/01/2011 14:45)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
В данном случае – "противник" – аппаратный (или программный) сбой при записи на DVD.

Так в любой "дискорезке" есть функция для побайтовой проверки записанных данных — после завершения записи они сравниваются с оригиналом на жёстком диске.

Но в данном случае речь об изменении файла в ходе дешифрования, а я имел ввиду сбой во время выполнения gpg -e, т.е., например, когда gpg из-за сбоя получил на stdin деформированную строку из файла и ее зашифровал.

GPG, ясное дело, не может знать, отличается ли то, что он получил, от того, что получила ОС от пользователя или с жёсткого диска. И я слабо себе представляю, в какой ситуации подобное может произойти. Более того, предварительное вычисление хэш-значений файлов эту Вашу гипотетическую проблему тоже не решит: тот же sha1sum ничем не более привилегирован, чем gpg, и тоже хэширует лишь то, что получает от ОС. По-моему, проблема надумана.
— Гость (24/01/2011 14:51)   <#>
Так в любой "дискорезке" есть функция для побайтовой проверки записанных данных — после завершения записи они сравниваются с оригиналом на жёстком диске.


growisofs или wodim из консоли – тоже проверяют?


GPG, ясное дело, не может знать, отличается ли то, что он получил, от того, что получила ОС от пользователя или с жёсткого диска. И я слабо себе представляю, в какой ситуации подобное может произойти. Более того, предварительное вычисление хэш-значений файлов эту Вашу гипотетическую проблему тоже не решит: тот же sha1sum ничем не более привилегирован, чем gpg, и тоже хэширует лишь то, что получает от ОС. По-моему, проблемона надумана.


Предельно конкретизирую проблему. Когда я выполнял часть работ по шифрованию, мне пришлось на некоторое время отойти из помещения. Я размонтировал и закрыл cryptsetup все шифроразделы, и сделал sudo smem -vl.
Во время выполнения smem система на некоторое время "подвисла", по крайней мере – иксы. К тому же, smem могла что-то удалить из RAM, то, что вышло из читаемого файла, но не дошло до обработки gpg и т.п., хотя вроде она не препятствует работе запущенных прог.
Вот меня и забеспокоил этот вопрос, т.к. не хотелось бы потерять данные.
Бэкапы, правда, древние, за 2 года к ним я не обращался, но все-таки...
— unknown (24/01/2011 14:59)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
записывал на DVD-диски, чтобы расчистить внешний хард

dvdisaster?
экономичнее будет делать кучу файлов криптоконтейнеров (с помощью того же dm-crypt/cryptsetup)

Это не гарантирует целостности. Быстро проверить целостность против случайных сбоев можно по некриптостойкой сумме crc-32. Её легко подделать, но это защита от случайных ошибок. Аналогичные некриптостойкие суммы есть в архиваторах.
То есть, скажем, имеется файл, выложенный на публичном ресурсе, кто-то подменяет его содержимое, причем делает так, чтобы md5-хэш получился такой же, как и с неизмененным файлом?

md5 был взломан давно, кое-какие практические атаки продемонстрированы были (хотя всё не так просто), sha-1 взломан теоретически, конкурс на SHA-3 идёт не зря.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3