Размер ключа для AES выбран равным 256, потому что это считается минимальным размером ключа, который может защитить от атаки грубой силы, т.е. $2^{256}$ пытается.
Это не правильно, $2^{128}$ или, точнее, размер ключа 128 бит для $2^{127}$ Попыток в среднем считается достаточно, особенно против любой практической атаки.
Однако на практике для многих приложений выбранный пользователем пароль используется для получения ключа размера 256 с использованием KDF. Допустим, приложение требует пароль из 8 символов — это 64-битный пароль — так что грубая сила сводится к $2^{64}$ пытается. И, вероятно, еще больше уменьшится, потому что байт обычного пароля имеет гораздо меньшую энтропию, чем байт ключа.
64 бита - напрасная надежда, пароли генерируются человеком в среднем около 40 бит. Конечно, даже хорошо подобранные пароли из 8 символов обычно используют подмножество ASCII, которое само по себе является подмножеством всех возможных значений байтов. Со всеми 24 специальными, которые обычно используются, я получаю 86 значений из 256, т.е. $log_2(86) \примерно 6,43$ бит энтропии на байт, или $\около 51,41$ бит для 8 таких символов. Но это только в том случае, если предполагается идеальное распределение, а люди ужасно не умеют генерировать случайные значения.
Грубая сила может быть использована побайтно, а не побитно, тем самым уменьшая грубую силу до меньшего, чем $2^{64}$ пытается.
Обычно вы пытаетесь использовать ранее известные пароли из сломанных баз данных или атак по словарю. Вы бы не пробовали волей-неволей.Другие атаки возможны, если реализация нарушена, например, если при выводе ключа не используется соль.
Это означает, что AES256 даже с 32-символьным паролем будет слабее, чем AES256 со случайно сгенерированным ключом.
Да. Обратная сторона салфетки покажет вам, что вы пропали без вести 16$ \умножить на 1.5 = 24$ биты на по крайней мере.
Так почему это не беспокоит? Или я что-то упускаю?
Это огромный проблема, как правило, вы стараетесь вообще избегать использования паролей. В противном случае вы бы использовали функцию получения ключа на основе пароля, которая применяет растяжение ключа, например, один из вариантов Argon2 (вероятно, более известны PBKDF2, scrypt и bcrypt). Но они обеспечивают лишь небольшую защиту для каждого вывода ключа. Это около 20 бит на миллион итераций (как $log_2(1 000 000)$ приближается к 20). Вас это точно не поднимет $2^{128}$ для общих паролей; $40 + 20 = 60$ бит, поэтому взлом шифрования будет дорогим, но далеко не невозможным.
Там, где невозможно избежать паролей, рекомендуется использовать менеджер паролей, например. Пароли из 12 символов, которые генерируются случайным образом (возможно, потребуется присутствие некоторых символов на случай, если вам не повезет). Это не приблизит вас к 128 битам, но будет достаточно сдерживающим фактором для любого, кто пытается использовать грубую силу или подобные методы. Конечно, также можно использовать 32 случайных шестнадцатеричных символа и просто сохранить ключ, предполагая, что нет ограничений на размер пароля.
Простой трюк показывает, что вы можете использовать $$l_p = \bigg\lceil {l_k - \log_2(i) \over log_2(N)} \bigg\rceil$$ как способ узнать количество символов для каждого пароля, скажем, мы используем значения выше: $$\bigg\lceil {128 - \log_2(1,000,000) \over \log_2(86)} \bigg\rceil = \bigg\lceil {{128 - 20} \over 6,43} \bigg\rceil = 17$$ расширенный символьный пароль для достижения 128 бит с использованием KDF с 1 000 000 итераций, при условии, что он совершенно случайный.
Один из способов избежать этого — использовать шифрование с открытым ключом и обеспечить безопасность закрытого ключа.Одним из шагов защиты закрытого ключа, используемого для расшифровки, может быть шифрование на основе пароля, но вы можете начать с хранения его, например, на карте памяти, чтобы злоумышленник просто не имел к нему доступа, когда он не нужен. Конечно, есть много других способов безопасного хранения ключей.
Обратите внимание, что это менее проблематично, когда можно принять контрмеры. Например. PIN-код обычно состоит всего из 4-6 цифр, но тот факт, что вы можете попробовать только три раза, защищает его от атак (коды PUK, как правило, намного больше, так как они обычно не блокируются, так как это может привести к отказу в обслуживании). атаки). Однако, например. шифрование файлов автономные атаки вообще можно предположить.
