Пароли и постквантовая стойкость

Представьте, что дистанционный пользователь некоторого интернет-узла авторизуется по паролю, который ранее создал и запомнил. Сама сессия работы с интернет-узлом защищена TLS (для примера), поэтому пароль передаётся внутри зашифрованного трафика, но в момент сравнения – используется в открытом виде: то есть, сервер видит открытый пароль, а третья сторона, прослушивающая TLS-трафик, видит зашифрованный пароль. Сервер пароль использует прямо только при начальном сравнении, и в серверной базе данных (БД) долговременно сохраняется не пароль, а значение хеш-функции, полученное по алгоритму, стойкому к перебору (типовая практика).

Пусть теперь появился квантовый компьютер, реализующий алгоритм Шора большой разрядности. Этот алогоритм позволяет атаковать асимметричные криптосистемы, в том числе, в TLS. И если TLS-сессия, в рамках которой передавался пароль, была записана, а для получения сессионных ключей не использовался постквантовый алгоритм, то трафик может быть раскрыт при помощи квантового криптоанализа. Пользовательский пароль, который передавался в TLS-сессии, тоже окажется раскрыт. Естественно, всё то же самое применимо и к неквантовому криптоанализу TLS: например, если сессионные ключи утекли ещё как-то или просто оказались нестойкими, то прочитать пароль можно точно так же. Но тут речь именно про квантовый компьютер, а об эффектах классического взлома – будут оговорки ниже.

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

Другое дело – аутентификация/авторизация “по ключам”, то есть, если у пользователя какой-нибудь доступ “без пароля”, на основе электронной подписи (RSA или ECDSA), но при этом на стороне сервера сохраняется открытый ключ, как он есть (не отпечаток, полученный через хеш-функцию), то квантовый компьютер позволит раскрыть пользовательский секрет уже по значению открытого ключа из БД сервера. Даже не нужно записывать TLS-трафик. Хранение на сервере непосредственно открытых ключей – является вполне себе типовым методом.

Неожиданно, но выглядит так, что, при прочих равных, пароль защищён от квантовых атак получше: для его утечки ещё нужно предварительно записать трафик. А поскольку квантовых компьютеров ещё нет, то трафик нужно где-то хранить, в надежде, что пароль расшифруется позже, и не будет заменён до момента расшифрования. Другое дело, что классический взлом того же TLS может быть осуществлён и без всякого квантового компьютера. В таком случае – пароль, передаваемый в рамках сессии, будет так же прочитан. А вот секретный ключ, при аутентификации по ключам, – таким способом не вычислить: нужно взламывать уже криптосистему цифровой подписи. С одной стороны, это существенное преимущество – получается, что система “по ключам” гораздо лучше защищена от классических атак на протоколы передачи трафика. А такие атаки, в отличие от квантовых компьютеров, уже давно являются строго практическими. С другой стороны – если успешной оказалась атака на криптосистему подписи, то тут уже никакая защита трафика не помогает: ни классическая, ни постквантовая.

Естественно, есть много других “если”. Например, можно использовать пароль, но не передавать его на сервер. Можно испльзовать пароль, но заменять его каждый раз после успешного использования (или даже по счётчику с секретом – см. про одноразовые пароли). Можно использовать пароль, но в дополнение к криптосистеме цифровой подписи. Можно использовать постквантовую криптосистему подписи в дополнение к классической. Так что тут многое зависит от выбранной модели угроз.

Адрес записки: https://dxdt.blog/2026/07/11/18576/

Похожие записки:



Далее - мнения и дискуссии

(Сообщения ниже добавляются читателями сайта, через форму, расположенную в конце страницы.)

Написать комментарий

Ваш комментарий:

Введите ключевое слово "88ZUW" латиницей СПРАВА НАЛЕВО (<--) без кавычек: (это необходимо для защиты от спама).

Если видите "капчу", то решите её. Это необходимо для отправки комментария ("капча" не применяется для зарегистрированных пользователей). Обычно, комментарии поступают на премодерацию, которая нередко занимает продолжительное время.