Вопрос о расширении ключа AES

Я читаю о ключевом расширении для AES, но пока не могу найти ответ на этот вопрос. В книге упоминаются шифровальный ключ и расширенный ключ (или схема ключей). Это алгоритм из книги:

процедура KeyExpansion(байт K[4][Nk], байт W[4][Nb (N r + 1)]) ? № 6
    для j = 0 до Nk ≈ 1 сделать
        для i = от 0 до 3 сделать
            W [i] [j] â K [i] [j]
        конец для
    конец для
    для j = Nk to Nb (N r + 1) ≈ 1 do
        если j mod Nk = 0, то
            W[0][j] → W[0][j → Nk] + S RD [W[1][j → 1]] + RC[j/Nk]
            для i = от 1 до 3 сделать
                W[i][j] - W[i][j - Nk] + S RD [W[i] + 1 mod 4][j - 1]]
            конец для
        еще
            для i = от 0 до 3 сделать
                W[i][j] - W[i][j - Nk] + W[i][j - 1]
            конец для
        конец, если
    конец для
завершение процедуры

Вопрос 1: В первой строке эта процедура берет ключ. Какой ключевой объект должен быть принят этой функцией? Похоже, что этот ключ уже имеет необходимое количество 32-битных слов для 128 или 192 (поскольку это расширение ключа для 6 столбцов или меньше), но как вы получите это из пользовательского пароля случайной длины? Будет ли PKCS7 уже запущен, чтобы ключ был дополнен?

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

Похоже, что этот ключ уже имеет необходимое количество 32-битных слов для 128 или 192 (поскольку это расширение ключа для 6 столбцов или меньше), но как вы получите это из пользовательского пароля случайной длины?

Способ получения 128-, 192- или 256-битного ключа не входит в спецификацию AES. Он принимает на вход этот ключ; то, что вы делаете, чтобы найти ключ, не является его заботой.

Обычно мы не преобразовываем пароль пользователя непосредственно в ключ; обычно мы либо генерируем его из функции вывода ключа (с входными данными, которые могут включать результаты операции обмена ключами), либо, возможно, напрямую используем выходные данные безопасного генератора случайных чисел (и умудряемся каким-то образом передать этот ключ другой стороне) . Проблема с использованием пароля пользователя напрямую заключается в том, что пароль является самой слабой частью системы — гораздо проще попытаться угадать пароль, чем взломать AES (или операцию обмена ключами).

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

Расширение ключа генерирует 11, 13 или 15 подключа, которые использует AES (в зависимости от размера ключа). Начальные 1, 3/2 или 2 блока будут битами, взятыми непосредственно из введенного ключа; однако это не важно для работы AES.

Какой ключевой объект должен быть принят этой функцией?

Массив байтов.

как бы вы получили это из пароля случайной длины пользователя?

Обычной практикой является использование функций получения ключей на основе пароля (PBKDF), таких как PBKDF2, Bcrypt, Argon2, BalloonHash и т. д. Имейте в виду, что они не могут увеличить надежность ввода. Поэтому пользователь должен выбрать хороший пароль с достаточной надежностью, такой как пароль, сгенерированный методом dicewire.

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

Кроме того, материал ключа может быть источником обмена ключами, такого как DHKE, в этом случае функция создания ключа, такая как HKDF, должна применяться к материалу ключа для получения ключа AES (байты).

Будет ли PKCS7 уже запущен, чтобы ключ был дополнен?

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

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

Пароль пользователя должен быть обработан с помощью PBKDF для получения ключа. Расписанию ключей требуется массив ключей, размер которого зависит от предпочтительного AES (128 192 256). ключевой график не различает качество ключевого материала и это не является частью его дизайна. Ответственность за качество ключевого материала лежит на пользователе и библиотеках. Библиотеки, которые шифруют, должны были обрабатывать пароли с хорошим PBKDF и вводить выходные данные в расписание ключей. Этот процесс должен быть независимым от пользователя, за исключением некоторого предупреждения о качестве пароля.

Все в одном;

1. Получите пароль от пользователя и предупредите пользователя, если пароль короткий.
2. получить желаемый массив байтов ключа из пароля с помощью PBKDF
3. Предоставьте ключевому расписанию производный ключевой массив байтов.

Похоже, что этот ключ уже имеет необходимое количество 32-битных слов для 128 или 192 (поскольку это расширение ключа для 6 столбцов или меньше), но как вы получите это из пользовательского пароля случайной длины?

Пароли сами по себе не являются ключами.

Чтобы получить ключ из пароля, вы должны использовать функцию получения ключа на основе пароля. Вы можете использовать такие функции, как хеширование PBKDF2, Argon2 или Balloon. Другими хорошо известными алгоритмами являются bcrypt и scrypt.

Будет ли PKCS7 уже запущен, чтобы ключ был дополнен?

Нет, заполнение, совместимое с PKCS#7, — это то, что вы запускаете в открытом тексте (или — при эффективной реализации — в буфере размером с блок, который используется для шифрования/дешифрования во время последней операции шифрования). Ключ не нуждается в методе заполнения при правильном создании/выводе; он всегда должен иметь правильный размер, иначе нулевое заполнение будет работать нормально.

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

Симметричные ключи состоят из битов/байтов. Таким образом, ключ AES состоит из 128, 192 или 256 бит / 16, 24 или 32 бит соответственно. Все, кроме этого, не является ключом AES. Строка обычно не считается ключом, хотя может быть шестнадцатеричной или кодировкой ключа base64. Если это строка любого размера, то она обычно считается паролем.

Что касается расписания ключей, внутреннего для AES: нет, первый раунд (ы) вполне может использовать исходный входной ключ. Как видите, значение Дж не начинается с Дж. Это имеет смысл, расписание ключей гарантирует, что подразделы достаточно различны, так что информация о более позднем подразделе не представляет никакой информации о более раннем подразделе.