Разрешить дешифрование любых данных с использованием AES 256 для целей HMAC - PullRequest
2 голосов
/ 12 марта 2012

Рассмотрим файл, который будет зашифрован библиотекой C #, которую я напишу, состоящую из 64-байтового HMAC, за которым сразу следуют зашифрованные данные, зашифрованные с помощью AES 256. 16-байтовый IV, 32-байтовый ключ и 64-байтовый Ключ инициализации HMACSHA512 будет получен из Rfc2898DeriveBytes с помощью однострочного пароля, введенного пользователем (4096 итераций и единственная соль из random.org).

  1. Есть ли какие-либо негативные последствия для безопасности этого проекта?

  2. Я вышел за борт? (это, с 64-байтовым ключом инициализации или 4096 итерациями)

  3. Я хочу иметь возможность дешифровать любые данные, чтобы использовать встроенный HMAC для проверки правильности пароля (то есть, что «дешифрованный файл является исходным файлом»). В частности, я стараюсь избегать ошибок, таких как «Заполнение недопустимо и не может быть удалено». Есть идеи, как это сделать?

1 Ответ

1 голос
/ 12 марта 2012
  1. Да, IV должен быть добавлен перед текстом шифра и должен быть случайным.Если вы используете Rfc2898DeriveBytes, вы будете получать один и тот же IV каждый раз, поэтому шифрование разных простых текстов приведет к одинаковым зашифрованным текстам, утечка информации.

  2. Да, 64-байтовый ключ инициализации - битмного.От 16 до 32 байтов должно быть более чем достаточно.Тем не менее, это не имеет большого значения с точки зрения производительности, поэтому ... итерации 4Ki - это хорошо (почему бы не 4000, алгоритм не меняется).

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

В качестве альтернативы вы можете использовать AES в режиме GCM, чтобы вы моглимне больше не нужен HMAC.Однако режим GCM (или EAX) не всегда доступен.

...