Уменьшение криптостойкости при генерации ключа
Эта причина с весьма многочисленными примерами, когда криптосистема либо обрезает пароль пользователя, либо генерирует из него данные, имеющие меньшее количество бит, чем сам пароль. Примеры:
Во многих (старых) версиях UNIX пароль пользователя обрезается до 8 байт перед хэшированием. Любопытно, что, например, Linux 2.0, требуя от пользователей ввода паролей, содержащих обязательно буквы и цифры, не проверяет, чтобы 8-символьное начало пароля также состояло из букв и цифр. Поэтому пользователь, задав, например, достаточно надежный пароль passwordIsgood19, будет весьма удивлен, узнав, что хакер вошел в систему под его именем с помощью элементарного пароля password. Novell Netware позволяет пользователям иметь пароли до 128 байт, что дает (считая латинские буквы без учета регистра, цифры и спецсимволы) 68128 ~2779 комбинаций. Но при этом, во-первых, хэш-функция получает на входе всего лишь 32-байтовое значение, что ограничивает эффективную длину пароля этой же величиной. Более того, во-вторых, на выходе хэш-значение имеет длину всего 128 бит, что соответствует 2128 комбинаций. Это дополнительно снижает эффективную длину до =21 символа, т.е. в 6 раз по сравнению с первоначальной. Полностью аналогичная ситуация происходит с архиватором RAR версий 1.5x - выбор пароля больше 10 символов не приводит к росту времени, необходимого на его вскрытие.
Если длина пароля "сверху" в этом случае определяется реализацией криптоалгоритмов, то ограничение на длину "снизу" уже связано с понятием единицы информации или энтропии. В рассмотренном примере с Novell Netware для создания хэш-значения с энтропией 128 бит длина пароля должна быть не менее =69 бит или не менее 22 символов. То, что многие криптосистемы не ограничивают минимальную длину пароля, как раз и приводит к успеху атак перебором не ключей, а паролей.
Содержание раздела
