AES шифрование 16 байтов без соли

Question

Насколько безопасно шифровать 16 байтов данных как один блок с AES? Нет соли / IV, нет режима работы, миллионы различных 16-байтовых блоков зашифрованы. Я не знаю достаточно о крипто, но это пахнет для меня.

Редактировать: чтобы дать немного больше подробностей, речь идет не о шифровании сообщения, а о столбце таблицы базы данных, где длина обычного текста составляет 16 байтов. Данные не являются полностью случайными (первые 8 байтов часто будут одинаковыми), и существует контрольная сумма для определения успешного дешифрования.

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

Answer 1

ECB не является безопасным для общего пользования. Данный простой текст всегда зашифровывается в один и тот же зашифрованный текст, поэтому шаблоны могут быть обнаружены. Тем не менее, есть особые случаи, когда это безопасно, и это приложение может быть одним из них.

Цитирование Прикладная криптография, второе издание, стр. 190, в отношении режима ECB для блочного шифра:

С положительной стороны нет безопасности риск при шифровании нескольких сообщений с тем же ключом. На самом деле, каждый блок можно рассматривать как отдельный сообщение зашифровано тем же ключом.

Позже (с. 208) Шнайер говорит:

Если ваша главная простота и скорость проблемы, ЕЦБ является самым простым и Самый быстрый режим для использования блочного шифра. Это также самый слабый. Помимо того уязвимы для повторных атак, алгоритм в режиме ECB самый простой Криптоанализ. Я не рекомендую ЕЦБ для шифрования сообщений.

Для шифрования случайных данных, таких как другие ключи, ECB - хороший режим для использования. Поскольку данные короткие и случайные, ни один из недостатков ЕЦБ не имеет значения для этого приложения.

Общий префикс и контрольная цифра в вашем случае не создадут общий зашифрованный текст. Это происходит только в том случае, если дублируется текстовый блок весь . Исходя из того, что вы описали, ваше приложение может хорошо подходить для ECB - особенно, если каждое текстовое значение в целом уникально.

Answer 2

Без соли, также известной как вектор инициализации или IV, безопасность зашифрованного текста (и, я полагаю, также ключа) значительно снижается. Потенциальный злоумышленник гораздо легче сможет разглядеть повторяющиеся шаблоны в зашифрованном тексте. IIRC это была та же самая основная ошибка, которую Microsoft допустила при обновлении схемы шифрования MS Office.

Answer 3

AES довольно сильна против атак только зашифрованным текстом. Однако шифрование большого количества открытых текстов одним и тем же ключом делает вашу систему более уязвимой для атак с использованием известного открытого текста и выбранных открытых текстов.

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

С другой стороны, если открытые тексты связаны друг с другом и / или кажутся не случайными, ECB вообще не защищен.

Answer 4

Мне не известны какие-либо недостатки в AES для коротких сообщений. Алгоритм должен быть достаточно счастливым.

Чтобы принять на свою встречу, вы хотите:

1) Модель угрозы (кто может видеть, что, когда и что происходит, когда они уходят или становятся «плохим парнем»).

2) Некоторые варианты использования вашей модели угрозы.

С этим вы сможете определить, действительно ли вам нужно подсолить AES и действительно ли шифрование защищает значение в столбце, если вы можете получить его в другом месте, что делает использование AES бессмысленным. Наконец, задайте вопрос: «Действительно ли ключ более безопасен, чем данные?» Я видел подобные схемы, в которых ключ был того же размера, что и данные (где size = "своего рода маленький") и был так же доступен, как и данные, которые он защищал. Да, это купит вам несколько часов, пока злоумышленник выяснит, что вы сделали на земле, но это не даст вам много для надежной безопасности.

Надеюсь, что это помогает и дает вам что-то пережевывать. Не зная вашей конкретной позиции, сложно адаптировать ответ. :)

Answer 5

В терминах криптографии это небезопасно, только если злоумышленник знает конкретный алгоритм и IV.

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

Но с точки зрения взлома, все еще есть 2 ^ 128 комбинаций клавиш (для 128-битного шифра), что так же безопасно, как использование того же ключа для терабайтов данных. Режим работы не имеет значения, потому что 16 байтов данных - это только один блок, поэтому цепочка блоков шифрования (CBC) не применяется.

Однако соль IV применяется, и это значение должно быть таким же секретным, как и сам ключ. Радужный стол можно использовать для ускорения атаки методом грубой силы на шифры, не использующие соль; это ваше слабое звено.