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