Алгоритм AES (длина ключа доступа) - ключ доступа AES + дополнительный PIN-код

В моем бизнес-сценарии (в основном облачное приложение для обмена файлами) у меня есть следующий случай:

  1. пользователь загружает файл (ы) в папку

  2. проверяется, защищена ли папка PIN-кодом

  3. 1) Если он не защищен PIN-кодом, зашифруйте файл, используя предварительно определенный ключ доступа, хранящийся в приложении, + ключ IV, хранящийся в базе данных.

    2) Если он защищен PIN-кодом, зашифруйте файл, используя предварительно определенный ключ доступа + значение PIN + ключ IV, хранящийся в базе данных.

Проблема в том, что AES с ограниченной длиной ключа доступа получает недопустимую длину ключа при превышении максимального размера ключа (16, 24, 32 байта). Мой главный вопрос - как добиться этого при сохранении безопасности.

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

Любое предложение будет оценено.

Примечание. Я не думаю, что код добавит никакого значения этому вопросу, но если кто-то не согласен, дайте мне знать, и я добавлю его.


encryption aes c# rijndaelmanaged
person wegelagerer    schedule 25.02.2016    source источник

Ответы (2)


arrow_upward
2
arrow_downward

Функция создания ключа создаст ключ с контролируемой длиной, если полученный ключ длиннее, чем необходимо, просто обрежьте его.

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

person zaph    schedule 25.02.2016
comment
Спасибо! В точности то, что я хотел услышать - усечение - это безопасная вещь! - person wegelagerer; 25.02.2016
comment
Последовательность случайных байтов, которая по сути является тем, что производит хеш-функция или функция деривации ключа, все одинаково случайны, ни один из них не лучше других. так что просто выберите любой диапазон из них, усечение - простой способ сделать это. - person zaph; 25.02.2016

arrow_upward
2
arrow_downward

Ваш сценарий не совсем ясен для меня, но в целом ответ будет заключаться в том, чтобы использовать все, что у вас есть, в качестве «секретов» и хешировать их, чтобы всегда получать одинаковую длину ключа для AES. Допустим, вы используете SHA256 для хеширования секретов, ваше приложение может использовать AES-256 независимо от того, какие данные вы используете для создания ключа.

Опять же, данные, которые создают ключ, должны иметь достаточную энтропию и должны храниться в секрете. Особенно, когда используется пароль, вы должны использовать безопасный пароль для схемы получения ключей, такой как PKCS # 5, а не создавать что-то самостоятельно ...

person fhissen    schedule 25.02.2016
comment
Спасибо за ответ! Я бы хотел пропустить какое-либо хеширование, потому что я не думаю, что в этом случае это необходимо, учитывая, что сам PIN-код уже хеширован (PBKDF2), и это первая линия защиты. Вторая линия защиты - это зашифрованные файлы, некоторые из которых зашифрованы с помощью ключа доступа + ПИН-кода. При этом мне не нужно сохранять дополнительные хэши, и единственное, что мне нужно сделать, - это расшифровать файл, используя ключ доступа + PIN-код, предоставленный пользователем. Ключ доступа встроен в приложение. Следует ли мне рассматривать это как угрозу безопасности? - person wegelagerer; 25.02.2016