]> Sergey Matveev's repositories - stargrave-blog.git/commit
KEKS/CM в NNCP
authorSergey Matveev <stargrave@stargrave.org>
Sun, 30 Nov 2025 09:09:50 +0000 (12:09 +0300)
committerSergey Matveev <stargrave@stargrave.org>
Sun, 30 Nov 2025 09:09:50 +0000 (12:09 +0300)
commit15f294f11124a57ff15ba2999db5f152fd72b5dd
tree4b825dc642cb6eb9a060e54bf8d69288fbee4904
parente028b3ca649cc2d55c6ef54e3fef1338015c0554
KEKS/CM в NNCP

Начиная с 5c92ce5cbbc610719487c27d564bb1fa3d728175, мне не даёт покоя
тот факт, что среди всего используемого софта только NNCP не имеет
поддержки PQ криптографии. Напрягает что софт то ведь мой. Интересно,
FiloSottile тоже в свой age не добавляет PQ схожим образом?

Думал что переезд на KEKS/CM для шифрования сообщений в NNCP будет не
раньше новогодних каникул реализован, ибо много чего делать и
переделывать. Как минимум невозможность хранить Classic McEliece ключи в
Hjson конфиге из-за их размера. Нужен переезд на мой DSC.

А тут меня осенило: а кто меня заставляет хранить ключи прямо в
единственном конфигурационном файле? За пару часов переделал NNCP на
использование cmenctool+cmkeytool. В конфиге keyid просто хранит hex
идентификатор ключевой пары. Сами ключи в /usr/local/etc/nncp.keys
директории хранятся, со всеми необходимыми символическими ссылками
дружелюбными к cmenctool.

Заголовок NNCPEv7 пакета стал хранить только magic, nice, keyid
отправителя и keyid получателя. После него идёт просто выхлоп от
cmenctool утилиты. Причём она вызывается с -no-from, -no-to -- значения
этих полей подставляются при расшифровке из NNCP заголовка.

Пока нет никакой поддержки (просто panic()-ую) area, но я их и не
использую. Нет поддержки padding. Вроде поломал transitional пакеты. Но
для моих нужд пока хватает. Зато используется PQ-ready криптография.