From: Sergey Matveev Date: Fri, 28 Feb 2025 08:02:02 +0000 (+0300) Subject: Chempat KEM combiner X-Git-Url: http://www.git.stargrave.org/?a=commitdiff_plain;h=05086967962f48ea1c0e5d629217390b84c55656;p=stargrave-blog.git Chempat KEM combiner https://datatracker.ietf.org/doc/draft-josefsson-chempat/ Вот есть множество вариантов как скомбинировать результат работы разных KEM-ов (объединить полученный секрет от пост-квантового и традиционного DH, грубо говоря). X-Wing (135afdcb923cd9463751d5766279c8426ee6ab00), XYBERTLS, HPKE, https://datatracker.ietf.org/doc/html/draft-ounsworth-cfrg-kem-combiners-05, да и ещё всякие. По сути нужно просто захэшировать результат. По хорошему ещё и учесть отосланный шифротекст, а ещё лучше и публичные ключи участников, чтобы весь контекст учесть в результате. Плюс и возможность бы задать сам контекст применения. Кто-то не учитывает публичные ключи, но доказывает что это излишне, для чётко заданных двух конкретных комбинируемых алгоритмов. Кто-то хэширует в таком порядке, что не удобно делать потоково это всё. Кто-то полностью суёт в хэш публичные ключи (как это я делал в KEKS/CM), которые в случае Classic McEliece могут быть более мегабайта. Но вот смотришь на предложение от DJB. Всё учитывает. Вместо полных публичных ключей использует хэш от них, как и хэш от шифротекстов. Это позволяет заранее захэшировать эти огромные значения. Публичный ключ получателя наверняка будет один и тот же, если использовать для PGP/CMS подобных применений. Шифротекст (эфемерные ключи) тоже зачастую можно переиспользовать -- поэтому и хэш от него вычислить и переиспользовать. То есть, получаем возможность дорогие вычисления сделать заранее и переиспользовать (например если отправляем сообщение нескольким получателям). Ну вот почему именно DJB (и команда) предлагает такие простые, но продуманные решения? Даже вот в таких мелочах. ---