From a2391563c90a712b2c45e9478b42649cd3c89bf7 Mon Sep 17 00:00:00 2001 From: Sergey Matveev Date: Mon, 21 Apr 2025 18:45:11 +0300 Subject: [PATCH] =?utf8?q?=D0=94=D0=BE=D0=B1=D0=B0=D0=B2=D0=B8=D0=BB=20?= =?utf8?q?=D0=B0=D1=83=D1=82=D0=B5=D0=BD=D1=82=D0=B8=D1=84=D0=B8=D1=86?= =?utf8?q?=D0=B8=D1=80=D0=BE=D0=B2=D0=B0=D0=BD=D0=BD=D0=BE=D0=B5=20=D1=88?= =?utf8?q?=D0=B8=D1=84=D1=80=D0=BE=D0=B2=D0=B0=D0=BD=D0=B8=D0=B5=20=D0=BD?= =?utf8?q?=D0=B0=20=D0=BE=D1=81=D0=BD=D0=BE=D0=B2=D0=B5=20=D0=BF=D1=83?= =?utf8?q?=D0=B1=D0=BB=D0=B8=D1=87=D0=BD=D1=8B=D1=85=20=D0=BA=D0=BB=D1=8E?= =?utf8?q?=D1=87=D0=B5=D0=B9?= MIME-Version: 1.0 Content-Type: text/plain; charset=utf8 Content-Transfer-Encoding: 8bit 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 уже делать над короткой строкой, чисто оптимизация. Пока всего этого ещё нет в коде, но хотя бы практически поставлена точка над этой единственной оставшейся задачей. Месяцами время от времени обдумывал и прикидывал всякие за и против. -- 2.48.1