Greetings!

That message can be treated like a shameless advertisement of my other
project, but I hope NNCP will use it some day.

Lack of post-quantum cryptography in NNCP bothers me. When NNCP was
created, even OpenSSH did not have PQ algorithms. But nowadays there
are even NIST-standardised choices available.

There is an independent (from NNCP) project: http://www.keks.cypherpunks.su/
* it features own binary serialisation format, that is very simple to
  parse even with relatively small quantity of pure-C code. It is
  simple, fast, has wide enough data types support, deterministic,
  streaming-friendly and has pretty compact encoding
* it features own schema specification format, that can be converted by
  a couple screens of Tcl code to KEKS-encoded validation byte-code.
  Small amount of pure-C can easily interpret that byte-code to solve
  nearly all structure-validation tasks
* most importantly it already contains suggested signed and encrypted
  messages formats and bigger subset of them is already implemented in Go

They already contain post-quantum hybrid cryptography algorithms. Go
implementation supports parallelisation of encryption and signing/hashing,
giving many GiB/sec performance on my mobile amd64 CPU. Current NNCP's
speed is many times lower.

I am not sure if post-quantum signatures will be used. If so, then it
will be (already implemented) SLH-DSA, but it has ~29KiB signatures.
Maybe only sender authentication feature based on DH will be used
instead, but it won't be post-quantum safe (although confidentiality
will stay safe anyway).

I am sure that Classical McEliece (+x25519) algorithm will be used as a
KEM, having very high confident security margin and smallest
"ciphertexts" (in terms of KEM). But unfortunately it has 1MiB+ large
public keys. So they won't be kept inside the configuration file, but in
files nearby.

Also there is another project, where I have implemented post-quantum
interactive handshake resembling DJB's PQConnect: https://www.pqconnect.net/
http://www.vors.stargrave.org/PQHS.html
It should replace Noise's handshake pattern.

I do not know when I will start working on all of that. But sometime it
will definitely happen. Of course that will lead to incompatible packets
format, that will be KEKS-encoded, instead of XDR-encoded. But that
brings PQ-safety, more paranoid/safer encryption patterns,
paralleliseable speeds.

-- 
Sergey Matveev (http://www.stargrave.org/)
LibrePGP: 12AD 3268 9C66 0D42 6967  FD75 CB82 0563 2107 AD8A