http://www.keks.cypherpunks.su/Authcrypt.html
Аутентификация отправителя зашифрованного сообщения без подписи мало кем
предоставляется. Ни в CMS, ни в PGP такого нету например. А было бы
полезно: может работать быстрее, нет non-repudiability свойства, которое
кому-то может не нравится.
По идее, достаточно просто сделать ещё один DH между статическими
ключами (DH(s,s)), а не только один DH(e,s). Засада в том, что у меня
не-ГОСТовые KEM-ы -- гибридные, из традиционных и постквантовых
алгоритмов. А PQC KEM-ы не предоставляют API которым бы можно было
выполнить аналог DH(s,s). Поэтому решил его делать без участия PQC, ведь
это не повлияет на конфиденциальность, только аутентификацию, причём
deniable/repudiable. Результат просто подмешивается HKDF-ом.
Но это всё просто. А вот в чём настоящая засада, так это проблема
нескольких получателей. Дешифровать сообщение может каждый из
получателей. Соответственно и перешифровать сообщение, так как CEK
ключ же один на всех.
Начитался про всякие message franking, про key commitment (снова), про
committing AEAD и ccAEAD (compactly committing). Многие статьи и люди в
рассылках предлагают использовать ccAEAD, commitment которого использовать
в KDF при шифровании CEK-а. Всё это красиво, да, но не применимо к тому
как KEKS/CM шифрует: потоково, разделяя на независимые 128KiB блоки.
В итоге остановился на практически простейшем решении, как это также
сделали и в Saltpack (
f9e33af95af9179a24c5539e9e9661d60d0a3c0b).
Добавлять MAC над хэшом от шифротекста для каждого получателя по
отдельности. Хэш от шифротекста -- чтобы один раз его можно было дорого
посчитать, а MAC уже делать над короткой строкой, чисто оптимизация.
Пока всего этого ещё нет в коде, но хотя бы практически поставлена точка
над этой единственной оставшейся задачей. Месяцами время от времени
обдумывал и прикидывал всякие за и против.