From 1622a2b02d847235ed48eae27b14868bc7604c36 Mon Sep 17 00:00:00 2001 From: Sergey Matveev Date: Sun, 28 Sep 2025 10:02:41 +0300 Subject: [PATCH] KEKS/CM v0.1.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf8 Content-Transfer-Encoding: 8bit https://soatok.blog/2021/11/17/understanding-hkdf/ На доработку моего KEKS пока не особо хватает времени, а на работе проекту, где он бы был задействован, пока ещё не давали старт. Но потихоньку посещают то одни, то другие мысли и поэтому немного дорабатывается. С момента v0.0.0 (0f3b3d1cd63008298fec7a4d1fefcb7740eccf9c) "нулевого" релиза, я поменял формат подписанных сообщений. Вместо: signed { load { t -- тип данных v -- сами данные, возможно отсутствуют (detached) } sigs [{ tbs {...} }] } где подпись считалась над: detached-data || /load || /sigs/./tbs теперь: signed { tbs { t -- тип данных } data -- сами данные, возможно отсутствуют (detached) sigs [{ tbs {...} }] } и подпись над data || /tbs || /sigs/./tbs. Что делает detached-data подписи неотличимыми от не-detached. Плюс в tbs можно далеко не только "t" пихать, но и произвольные сопутствующие data штуки, не специфичные для подписи. Почему я раньше так не сделал? Почему "tbs" и "data" за счёт особенностей сортировки KEKS прекрасно в нужном порядке при этом лежат и имеют понятные всем имена? Видимо, должно отлежаться в голове. А ещё я обнаружил, что выходы HKDF-Extract не должны сразу же попадать на входы в другие HKDF-Extract-ы. Речь про key ratcheting и подмешивание ключей в процессе выработки ключей. Так делают и в Noise и даже в TLS 1.3 прям явно указано что между Extract должен быть хотя бы один Expand. Всё же корректное использование HKDF -- не столь тривиальная штука. На наличие Expand между Extract что-то упорно не обращал внимания. Плюс в xchapoly-krkc DEM убрал явную передачу MAC-а, так как она всё равно присутствует в commitment-е. Это в пустую потерянное место было. -- 2.52.0