public inbox for nncp-devel@lists.stargrave.org
Atom feed

From: Sergey Matveev <stargrave@stargrave•org>
To: nncp-devel@lists.cypherpunks.su
Subject: Possible distant future cryptography and format changes
Date: Sun, 28 Sep 2025 13:05:43 +0300	[thread overview]
Message-ID: <aNkId5QemUNoyZKX@stargrave.org> (raw)

[-- Attachment #1: Type: text/plain, Size: 2566 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 265 bytes --]

next             reply	other threads:[~2025-09-28 10:05 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-09-28 10:05 Sergey Matveev [this message]
2025-10-03  0:11 ` Possible distant future cryptography and format changes John Goerzen
2025-10-03 12:34   ` Sergey Matveev
2025-10-07 13:31     ` John Goerzen
2025-10-08  8:54       ` Sergey Matveev
2026-03-18 10:57 ` Sergey Matveev
2026-03-18 15:02   ` Rafael Diniz
2026-03-18 15:10     ` Sergey Matveev
2026-03-18 19:27       ` Rafael Diniz