Bugs happen: почему отказ от ECC в пользу solo PQ — катастрофа
Bugs happen: The easy way to compare solo PQ to ECC+PQ
Дэниел Бернстайн объясняет, почему переход с ECC на solo PQ станет непростительной катастрофой безопасности. Простое сравнение: в PQ-софте часто встречаются ошибки, некоторые из них эксплуатируемы, а сохранение ECC в составе ECC+PQ снижает ущерб от таких уязвимостей. При этом затраты на ECC ничтожны по сравнению с PQ, так что отказ от ECC неоправдан. Автор приводит примеры реальных багов в ML-KEM и ML-DSA, включая KyberSlash и свежие CVE, и критикует аргументы сторонников solo PQ.
Что лучше: обновить протокол на основе ECC до ECC+PQ или перейти на solo PQ? Вот самый простой способ увидеть, что solo PQ станет непростительной катастрофой безопасности.
- Retr0id
Раньше я был сторонником гибридных схем, но сейчас я всё больше сомневаюсь. В программном обеспечении ECC тоже могут быть ошибки, но я не думаю, что кто-то всерьёз предлагал гибридизировать две разные реализации ECC, например.
- rot256
Не покупаюсь на этот аргумент: эта штука достаточно проста, чтобы мы могли её формально верифицировать и очень тщательно проверить. Кроме того, NIST предусмотрительно дерандомизировал все алгоритмы, так что теперь мы можем проверить, например, что выдаст корректная реализация на конкретных seed'ах. Это очень важно, потому что многие ошибки, например, в ECDSA, такие как смещённые nonce'ы или повторное использование nonce'ов, легко выявляются такими тестами/дерандомизацией. Короче, баги будут в другом месте.
- libeclipse
Почему бы тогда не использовать гибрид RSA и ECC? Или гибрид AES и ChaCha20? Ошибки в программном обеспечении — слабый аргумент для нового гибридного стандарта и не оправдывают дополнительную сложность.