ML-KEM и скорость вычислений
Реализации ML-KEM могут быть очень быстрыми, быстрее, чем X25519 – это относится к гибридам в браузерах. Например, реализация ML-KEM-768 для OpenSSL из проекта OpenQuantumSafe для инкапсуляции ключа работает в пять раз быстрее, чем X25519 в том же OpenSSL “при прочих равных” (декапсуляция – в три раза быстрее):
(openssl speed X25519 mlkem768) keygens/s encaps/s decaps/s X25519 26646.1 12213.9 24366.2 mlkem768 53101.6 62756.0 63933.0
То есть, в гибридной схеме, где ML-KEM присоединяется к X25519, будет весьма небольшой рост вычислительных затрат по сравнению с X25519. При этом браузер Firefox, скажем, ещё и экономит время на генерирование ключей, поскольку использует один и тот же открытый параметр X25519 и в гибриде, и в отдельном варианте. Понятно, что на серверной стороне разницы тут нет – серверу так или иначе придётся для гибрида выполнить и X25519, и ML-KEM. Но всё равно это лишь небольшой дополнительный расход вычислительных мощностей.
Конечно, ML-KEM, согласно стандарту, может использоваться отдельно, тогда схема будет и работать быстрее, и постквантовую стойкость обеспечивать; гибрид используется для подстраховки – и совсем не лишней подстраховки, надо заметить. А работает ML-KEM быстро потому, что там используется NTT (“теоретико-числовое преобразование”) и, соответственно, быстрые операции с полиномами.
Адрес записки: https://dxdt.ru/2025/02/21/15069/
Похожие записки:
- Техническое: ECDSA на кривой Curve25519 в GNS
- Уровни сигнатур клиентских подключений
- Техническое: TLS-сообщение с постквантовой криптосистемой Kyber768
- Вывод ключей Kyber768 на tls13.1d.pw
- "Блокирующие" источники случайности в операционных системах
- Постквантовые криптосистемы и квантовые компьютеры
- ИИ с превышением
- HTTPS-запись в DNS для dxdt.ru
- Реплика: атака посредника в TLS и проблема доверия сертификатам
- Маскирование криптографических ключей в памяти
- Машинный ИИ в книгах прошлого века
Написать комментарий