Хранение значения сильной хэшфункции от незашифрованного текста, рядом с зашифрованным текстом?

Question

[vsespb]

Считается ли security issue/дурным тоном хранение значения сильной хэшфункции от незашифрованного текста, рядом с зашифрованным текстом.

Например, хранится зашифрованный файл, и рядом лежит SHA256 от незашифрованного содержимого.


По идее такое соседство может облегчить брутфорс.

С другой стороны, например, архиватор winrar хранит crc32 незашифрованных файлов в зашифрованном архиве. Может дело в том что

сам crc32 тоже зашифрован? Или в том что crc32 заведомо короче ключа шифрования и не стоек?


Есть ли примеры софта/сервисов где практикуется subj?


UPD:


Есть, например, топик на stackoverflow, затрагивающий и эту проблему в том числе. И два противоположенных мнения о проблеме.

stackoverflow.com/questions/6112867/which-procedur...


часть вопроса:

A. Do I gain anything from storing encrypted Seed and CRC? Would it be less secure if I store them not encrypted?

мнение:

You should never save the CRC unencrypted since a CRC gives information about the data within the encrypted container.

противоположное мнение:

I recommend hashing the unencrypted data and storing the hash unencrypted,

Answer 1

[vsespb]

Похоже решение найдено — это не секьюрно.

Во превых
stackoverflow.com/questions/2845986/does-having-an-unencrypted-sha-224-checksum-create-a-vulnerability
уязвимо к rainbow table attack.

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

(как защиту предлагается использовать hmac и соль)

Во вторых
_http://www.cs.jhu.edu/~astubble/dss/winzip.pdf

такая же штука в WinZip считается уязвимостью:

«Due to a security flaw in AE-1 (CRC of plaintext is included in unencrypted format in the output), it was replaced by AE-2 in WinZip 9.0 Beta 3.»

Думаю выход это только хранить зашифрованное тем же или другим ключём бинарное представление хэша. Или хранить хэш от зашифрованных данных, а не
от plain текста.

Answer 2

[Владимир Мартьянов]

В общем случае наличие зашифрованного текста может указать на длину открытого, тем самым облегчив подбор. Для MD5, к примеру, это может изрядно оптимизировать перебор. Думаю, можно придумать причины по которой и зашифрованные тексты не стоит отдавать :-)

Comments

[vsespb]

Не совсем понял честно говоря…

[Владимир Мартьянов]

Допустим, у нас хранится хэш текста и он же, зашифрованный AES256. Злоумышленник может сделать несколько записей в таблицу с произвольным текстом, следовательно он поймет, что длина блока — 16 символов. Далее, имея неизвестный зашифрованный текст и его же зашифрованным, можно ограничить перебор 16-ю вариантами длины, а не всеми длинами меньше длины зашифрованного текста. Чем меньше длина блока шифрования, тем меньше диапазон длин текста для перебора.

[vsespb]

Давайте попорядку.
Что такое «таблицу с произвольным текстом»? Что такое «длина блока» — это из реализации AES?
Как он именно поймёт что длина блока 16 символов? И как на это повлияет наличие хэш функции от незашифрованного текста?

[Владимир Мартьянов]

У вас данные где-то хранятся, я предполагаю что в некоторой таблице, но это не важно. Просто есть четкая связь между хэшем и зашифрованными данными. По условиям задачи злоумышленник получает доступ к этой информации. После этого он засылает в сервис открытый текст длиной 1 байт, блочный алгоритм этот 1 байт «расширяет» до длины своего блока. Для проверки засылаем открытый текст длиной в предполагаемую длину блока и видим, что длина осталась той же, значит длина блока установлена. Это позволяет установить нижнюю и верхнюю границы длин исходного текста (отличаются они не более чем на blocklen). Наличие хэша на процедуру вообще никак не влияет, но установление длины (диапазона длин) открытого текста может упростить перебор хэша.

[vsespb]

> У вас данные где-то хранятся, я предполагаю что в некоторой таблице, но это не важно. Просто есть четкая связь между хэшем и зашифрованными данными.
да

> По условиям задачи злоумышленник получает доступ к этой информации
да

> После этого он засылает в сервис открытый текст длиной 1 байт
нет, нет никакого сервиса.

давайте переформулирую задачу:

Случай A: У злоумышленника есть зашифрованный текст. Нужно получить не зашифрованный.
Случай Б: У злоумышленника есть зашифрованный текст и SHA256 от не зашифрованного текста. Нужно получить не зашифрованный.

Будет ли в случае Б атака более простой чем в случае А?

Теоретически конечно будет, т.к. SHA256 от не зашифрованного текста уже дополнительная информация.
Но считается ли на практике это плохим дизайном в криптографии. (теория как известно отличается от практики)

[Владимир Мартьянов]

Ну один из вариантов: открытый текст нельзя проверить на корректность расшифровки. Тогда совпадение хэшей будет говорить о корректной расшифровке.

[vsespb]

Да. Теоретически.

Но на практике можно проверить корректность расшифровки в случае А. Сам алгоритм шифрования содержит какую-то контрольную сумму ключа или plaintext'а. Например если я с помощью gpg пытаюсь расшифровать AES256 с неправильным ключём, я получаю 'gpg: decryption failed: bad key'

К тому же некоторых известные решения хранят CRC от незашифрованного текста, например, Rar, судя по сообщению об ошибке при попытке расшифровать неправильным паролем:
Encrypted file: CRC failed in somefile.rar (password incorrect ?)

Интересно именно считается ли это на практике плохим дизайном.

[Владимир Мартьянов]

Сами криптоалгоритмы никаких признаков целостности не проверяют и контрольных сумм не хранят. Это абсолютно справедливо для (X)TEA, AES, Blowfish, RSA, RC4 — это то, с чем я работал. Думаю, для остальных тоже справедливо. Довески — продукт софта типа pgp или WinRAR :-)

[vsespb]

Ок, Спасибо, это уже интересно…