Единственный ключ в KEKS/CM

С самого начала в моих KEKS/CM публичных ключах был список из этих самых
ключей. Предполагалось, что если используется какой-нибудь NNCP, то с
ним всегда сообща применяются и x25519 и ed25519 ключи, плюс возможно
ещё для Noise отдельные. Идея была в том, чтобы их разом скопом нести в
ключевом контейнере.

Но до сих пор эту возможность не использовал. Всё равно у меня были
mceliece6960119-x25519 ключи, где просто конкатенация ключей была, а не
две отдельных структуры с "mceliece6960119" и "x25519" алгоритмами.

Принялся было реализовывать как изначально задумывалось. git status
из-за изменений на весь экран не умещается. В итоге... плюнул и вообще
убрал этот список. По сути я шёл по пути ASN.1-щиков, которые даже
подписи ECDSA додумывались кодировать как структуру с INTEGER-ами. С
одной стороны то это красиво, но столько геморроя добавляет. Вот и моя
идея с несколькими ключами -- никакого практического profit не имеет.
Раз известен алгоритм, то известны и чёткие длины его ключей. В чём
сложность slice-ами откусывать нужный ключ? Пускай не так красиво, но
насколько же всё упростилось в коде, в котором даже ещё не начали
применяться этим списки!

В тысячный раз убеждаюсь: делать просто -- сложно.

Но раз формат поменялся, то и ключи нужно переконвертировать же? Не стал
создавать совершенно новые, а просто подправил старые.
    kekspp -tcl key.pub >tcl
    vi tcl # убираю руками LIST {} обёртку
    ~keks/tcl/keks.tcl <tcl >key.pub
Идентификаторы остались прежними (хоть и не являются честным расчётом
хэша над /data/pub полем, но у меня и не задекларирован MUST для этого),
подписи и KEM остаются корректными.

Почти для всех проектов я сделал SLH-DSA KEKS/CM ключи подписи. Не во
все это запушил, но в некоторых уже сделал подписанные tarball-ы. Надо
всё же заранее иметь PQ-ready подписи на практике.