Обеспечивает ли код аутентификации сообщений (MAC) подлинность используемого ключа?

Я должен защитить конфиденциальность, целостность и подлинность файла записей с помощью пароля. Количество записей потенциально может быть больше 32^2, и к каждой записи можно получить доступ независимо.

Одним из способов его реализации является

  1. Создайте 256-битную случайную соль и сохраните ее в заголовке файла.
  2. Сгенерируйте производный ключ из пароля и соли, используя PBKDF2 с HMAC-SHA256 из PKCS #5.
  3. Для каждой записи сгенерируйте 96-битный случайный вектор инициализации.
  4. Зашифруйте содержимое каждой записи с помощью AES-256 в режиме GCM, используя производный ключ, вектор инициализации и (в качестве дополнительных аутентифицированных данных) положение записи в файле.
  5. В результате каждая запись будет хранить вектор инициализации, зашифрованное содержимое и MAC.

Но Специальная публикация NIST SP800-38D, определяющая GCM и GMAC требует, чтобы количество записей было меньше 32^2, чтобы векторы инициализации были уникальными.

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

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

Кроме того, мне действительно нужно вообще использовать векторы инициализации, поскольку все записи будут зашифрованы и аутентифицированы с использованием предположительно разных ключей, сгенерированных HMAC-SHA256 (PBKDF2 (HMAC-SHA256, пароль, соль, iterationCount, 256), blockAddress)?

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


encryption security hmac password-encryption authenticity
person Taras Puchko    schedule 15.12.2011    source источник

Ответы (1)


arrow_upward
0
arrow_downward

Если я вас правильно понял (что-то вроде отказа от ответственности, извините), то вы должны быть в порядке, не добавляя позицию в запись в файле.

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

person Maarten Bodewes    schedule 17.12.2011
comment
Как обычно, несколько советов по безопасности: убедитесь, что вы можете различать неверные пароли, измененный зашифрованный текст и переупорядоченные записи, иначе вы можете оказаться в затруднительном положении, если что-то случится с одним из них. Кроме того, стоит использовать один и тот же уровень безопасности для всех примитивов, например. используйте SHA-512 (безопасность ~ 256 бит) с AES 256 (безопасность также ~ 256 бит). - person Maarten Bodewes; 17.12.2011
comment
1. Для меня имеет смысл различать только неправильный пароль и поврежденный файл (измененный шифрованный текст, переупорядоченные записи, измененная соль), но если злоумышленник изменит соль, я не смогу отличить его от неправильного пароля. - person Taras Puchko; 18.12.2011
comment
2. Я не понимаю, как я могу использовать ключ, созданный SHA-512, с AES-256, так как последний требует 256-битных ключей. Один из вариантов — усечение, но он эффективно ослабляет тональность. И хотя NIST-SP-800-107 говорит, что усечение допустимо, поиск в Google усечения SHA дает неоднозначные результаты. Другой вариант аналогичен, но с использованием других 256 бит в качестве IV. - person Taras Puchko; 18.12.2011
comment
Ответ на 2) Нет ничего плохого в усечении безопасного алгоритма хеширования. Он постоянно используется во всевозможных методах получения ключей, а SHA-384 — это даже SHA-512 с удаленными битами и другими внутренними константами. - person Maarten Bodewes; 18.12.2011
comment
1) эм, нет, неправильный пароль и соль не отличишь, в этом соль. Извините, если это было неясно. Пока вы можете выяснить, что не так, насколько это возможно. Дизайн для неудачи, вот что я пытался сказать. Заранее решите, что делать, если что-то пойдет не так. Для такого большого количества записей это имело бы смысл. - person Maarten Bodewes; 18.12.2011
comment
Я до сих пор не понимаю, зачем мне генерировать ключ с SHA-512, а затем усекать его до 256 бит вместо того, чтобы просто использовать SHA-256. Оба варианта дают мне одинаковую силу сопротивления. Я могу только подумать об использовании некоторого дополнительного бита из SHA-512 для других целей, таких как проверка пароля. Но, как я уже говорил, меня немного беспокоило простое усечение, когда я читал eprint.iacr. org/2010/548.pdf и csrc.nist. gov/groups/ST/hash/documents/Kelsey_Truncation.pdf - person Taras Puchko; 18.12.2011
comment
Хм, хорошо, прочитайте оба документа, и хотя я не могу напрямую увидеть, полностью ли это применимо (по первой ссылке утверждается, что это по крайней мере), вы можете выбрать SHA-256. Мое общее эмпирическое правило состоит в том, чтобы использовать одинаковые примитивы и параметры, а SHA-512 и AES-256 более или менее «на одном уровне». Поскольку это менее важно для получения ключа, и поскольку половина вывода все равно отбрасывается, я должен признать, что имеет смысл использовать SHA-256 (или SHA-512/256, если атаки в первой статье неприменимы к этому алгоритму). ). - person Maarten Bodewes; 19.12.2011