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-е. Это в пустую потерянное место было.