[О блоге] [наверх] [пред] [2025-02-28 11:02:02+03:00] [05086967962f48ea1c0e5d629217390b84c55656]
Темы: [crypto][djb]

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 (и команда) предлагает такие простые, но
продуманные решения? Даже вот в таких мелочах.

    [оставить комментарий]