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

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

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

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

Ответ 1

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

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

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

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

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

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

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

Ответ 2

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

Ответ 3

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

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

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

Ответ 4

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

Чтобы выполнить вашу встречу, вы действительно хотите:

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

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

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

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

Ответ 5

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

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

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

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