From: Sergey Matveev Date: Sun, 28 Sep 2025 07:02:41 +0000 (+0300) Subject: KEKS/CM v0.1.0 X-Git-Url: http://www.git.stargrave.org/?a=commitdiff_plain;h=1622a2b02d847235ed48eae27b14868bc7604c36;p=stargrave-blog.git KEKS/CM v0.1.0 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-е. Это в пустую потерянное место было. ---