Subject: Re: Possible distant future cryptography and format changes

From: John Goerzen <[email-masked]>
Date: Thu, 02 Oct 2025 19:11:00 -0500

On Sun, Sep 28 2025, Sergey Matveev wrote:

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

<grin>

> 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

That looks interesting!  I have been using MessagePack in a number of
contexts, such as Filespooler https://www.complete.org/filespooler/.

I have a bit of a bias towards using existing libraries where possible.
With crypto code, that is a stronger bias since there is something of a
long history of (hopefully unintentional) weaknesses being discovered in
crypto code.  I know TLS folks are doing ML-KEM these days.

I got the NNCP packet parsers and generators done for my Rust
implementation in nncprs but the project stalled a bit due to lack of
time.  Still I do hope to have a working NNCP library for Rust sometime
soon.

I have been thinking of the possibilities of that -- integrating more
tightly with Filespooler (maybe Filespooler could use NNCP's packet
format as a native one?).  Having it librarized allows for faster
generation in contexts that might not use the NNCP command line tools
(ie, passing it by email, by messsage queues, etc.)

However, the current format has some notable limitations, particularly
the 255-byte limits.

The Filespooler packet format is given here:

https://salsa.debian.org/jgoerzen/filespooler/-/blame/main/src/header.rs?ref_type=heads#L39

It's a sort of nested data structure, but the params for a command to
execute are variable-length, and any number of environment variables of
any size can also be specified.  A future NNCP packet format that does
away with the fixed-length limits would be nice (and carrying some
key-value parameters could make for easier enhancement in the future).

> 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.

I would like to add a vote for compatibility when that changes.  We now
have a larger installed base of NNCP users, and we have people
communicating with each other and taking advantage of nodes they don't
control (such as quux) as relays.  Having a large breaking change like
that is more difficult to accomplish these days.

Perhaps it could be accomplished by having upgraded nodes generate both
old-style keys and new-style ones.  When communicating between nodes
that both have new-style keys, NNCP can use them; otherwise, it can fall
back to the current format.  If the current NNCP were modified to treat
unknown fields in the hjson file as warnings rather than errors, that
would allow for easy upgrades.

John