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

* Possible distant future cryptography and format changes
@ 2025-09-28 10:05 Sergey Matveev
  2025-10-03  0:11 ` John Goerzen
  2026-03-18 10:57 ` Sergey Matveev
  0 siblings, 2 replies; 9+ messages in thread
From: Sergey Matveev @ 2025-09-28 10:05 UTC (permalink / raw)
  To: nncp-devel

[-- 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 --]

^ permalink raw reply	[flat|nested] 9+ messages in thread

• * Re: Possible distant future cryptography and format changes
    2025-09-28 10:05 Possible distant future cryptography and format changes Sergey Matveev
  @ 2025-10-03  0:11 ` John Goerzen
    2025-10-03 12:34   ` Sergey Matveev
    2026-03-18 10:57 ` Sergey Matveev
    1 sibling, 1 reply; 9+ messages in thread
  From: John Goerzen @ 2025-10-03  0:11 UTC (permalink / raw)
    To: nncp-devel
  
  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
  
  ^ permalink raw reply	[flat|nested] 9+ messages in thread

• • * Re: Possible distant future cryptography and format changes
      2025-10-03  0:11 ` John Goerzen
    @ 2025-10-03 12:34   ` Sergey Matveev
      2025-10-07 13:31     ` John Goerzen
      0 siblings, 1 reply; 9+ messages in thread
    From: Sergey Matveev @ 2025-10-03 12:34 UTC (permalink / raw)
      To: nncp-devel
    
    [-- Attachment #1: Type: text/plain, Size: 5094 bytes --]
    
    Greetings!
    
    *** John Goerzen [2025-10-02 19:11]:
    >That looks interesting!  I have been using MessagePack in a number of
    >contexts, such as Filespooler https://www.complete.org/filespooler/.
    
    I love MessagePack and it is the most preferred format for me in most
    cases. But it does not support streaming (field's length must be known
    in advance) and does not force deterministic encoding (but in practice I
    won't be surprised that most implementations have strict behaviour),
    that was not perfect for embedded systems. So I just have not found good
    enough existing format. MessagePack won't be a problem for NNCP use-cases,
    but cryptographic messages (KEKS/CM) are already defined and Go
    implementation covers a big subset of them.
    
    >I have a bit of a bias towards using existing libraries where possible.
    
    Completely support that bias. Me too. But sometimes there are no
    satisfiable enough solutions.
    
    >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.
    
    Agreed. But I am biased against ML-KEM, because of DJB's:
    https://ntruprime.cr.yp.to/faq.html
    https://blog.cr.yp.to/20231003-countcorrectly.html
    NIST has pretty bad reputation (especially after Dual EC DRBG), so its
    decisions must be taken with high level of awareness. And, maybe most
    importantly, SNTRUP was used in practice a long before Kyber/ML-KEM,
    because of its inclusion in OpenSSH. It is just more mature and seems to
    have higher security level than ML-KEM. According to various maillists,
    many cryptographers are far from being satisfied with ML-KEM and they
    want to see at least FrodoKEM (which was chosen by German's BSI) and
    Classical McEliece more.
    
    >I got the NNCP packet parsers and generators done [...]
    >However, the current format has some notable limitations, particularly
    >the 255-byte limits.
    >The Filespooler packet format is given here: [...]
    
    Yeah, I understand a will to implement all of that. Current NNCP's
    format can be treated like a fixed structures, nothing more. No
    flexibility.
    
    Honestly I lost my interest in developing NNCP. It just works for me (I
    use it extensively everyday). But I am already satisfied with only a part
    of its functionality. Many features I have not used maybe since their
    addition. I have got many items in my TODO list, but they are not
    important personally for me. Adding PQ-cryptography, as an
    counterexample :-), is an interesting task, so I will try to find time
    for it. Adding or even fixing of some other issues... it is boring,
    but of course they should be done. Maybe that is some kind of burnout.
    NNCP get much attention (mainly by your, John, work) when my interest
    was already declining :-). I even have not updated FreeBSD's port for a
    long time. Recently I tried to update it, but it has some port-ecosystem
    related issues that I am not too enthusiastic to debug and fix.
    
    >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).
    
    Yeah, that would be mainly various maps (objects in JSON terms).
    
    >I would like to add a vote for compatibility [...]
    >Perhaps it could be accomplished by having upgraded nodes generate both
    >old-style keys and new-style ones. [...]
    
    Agreed. But... I am not sure that backward compatibility will stay.
    
    One of the annoying things in NNCP is its configuration format. It is
    not friendly for machine editing. Hjson can be converted to JSON and
    JSON can be edited by jq-like utilities, but that is not too convenient.
    I do not like the fact of having two completely different configuration
    formats: (h)json and "cfgdir" one, that has a huge hard-coded mapping
    how to store each field of the configuration. So I am also thinking
    about replacing all of that with something different, especially when
    huge McEliece post-quantum keys will be definitely outside the
    configuration file. That is just a coincidence, but recently I wrote
    "damn small configuration" tool, that some kind mimics OpenWRT's like
    UCI configuration tool experience, keeping all the data in a directories
    hierarchy, but also allowing exporting/importing all of that in a single
    text txtar-file.
    http://www.git.cypherpunks.su/?p=dsc.git;a=blob_plain;f=dsc;h=837942ba3c2e0c0c9511be721afb92c597f2e78b8bd0d0d56a99335b47fea072;hb=HEAD
    But maybe it is bad idea. Even does not have enough time to think about it.
    
    But if configuration format will change, then newer NNCP will transform
    to something completely incompatible, starting from configuration file
    format, to different format of all kinds of packets and online protocol.
    Keeping an old and new implementations will be like keeping two
    different programs together. But I have no plans in changing nncp-*
    command's API or any other logic.
    
    -- 
    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 --]
    
    ^ permalink raw reply	[flat|nested] 9+ messages in thread

  • • * Re: Possible distant future cryptography and format changes
        2025-10-03 12:34   ` Sergey Matveev
      @ 2025-10-07 13:31     ` John Goerzen
        2025-10-08  8:54       ` Sergey Matveev
        0 siblings, 1 reply; 9+ messages in thread
      From: John Goerzen @ 2025-10-07 13:31 UTC (permalink / raw)
        To: nncp-devel
      
      On Fri, Oct 03 2025, Sergey Matveev wrote:
      
      > Greetings!
      >
      > *** John Goerzen [2025-10-02 19:11]:
      >>That looks interesting!  I have been using MessagePack in a number of
      >>contexts, such as Filespooler https://www.complete.org/filespooler/.
      >
      > I love MessagePack and it is the most preferred format for me in most
      > cases. But it does not support streaming (field's length must be known
      
      Very true.  I often have wrapped it in frames, with a leading u64 length
      indicator.  Somewhat annoying, but it has generally been OK for me to
      put the large payload, whatever it is, outside of the MessagePack and in
      a frame.
      
      > in advance) and does not force deterministic encoding (but in practice I
      > won't be surprised that most implementations have strict behaviour),
      > that was not perfect for embedded systems. So I just have not found good
      > enough existing format. MessagePack won't be a problem for NNCP use-cases,
      > but cryptographic messages (KEKS/CM) are already defined and Go
      > implementation covers a big subset of them.
      
      Can you send me a pointer to this definition and Go implementation?  I
      haven't been able to dig it up.
      
      >>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.
      >
      > Agreed. But I am biased against ML-KEM, because of DJB's:
      > https://ntruprime.cr.yp.to/faq.html
      > https://blog.cr.yp.to/20231003-countcorrectly.html
      > NIST has pretty bad reputation (especially after Dual EC DRBG), so its
      > decisions must be taken with high level of awareness. And, maybe most
      > importantly, SNTRUP was used in practice a long before Kyber/ML-KEM,
      > because of its inclusion in OpenSSH. It is just more mature and seems to
      > have higher security level than ML-KEM. According to various maillists,
      > many cryptographers are far from being satisfied with ML-KEM and they
      > want to see at least FrodoKEM (which was chosen by German's BSI) and
      > Classical McEliece more.
      
      Thanks for the links & info!  I am not at all well-versed in the
      post-quantum algorithms, so this is helpful.
      
      >
      >>I got the NNCP packet parsers and generators done [...]
      >>However, the current format has some notable limitations, particularly
      >>the 255-byte limits.
      >>The Filespooler packet format is given here: [...]
      >
      > Yeah, I understand a will to implement all of that. Current NNCP's
      > format can be treated like a fixed structures, nothing more. No
      > flexibility.
      >
      > Honestly I lost my interest in developing NNCP. It just works for me (I
      > use it extensively everyday). But I am already satisfied with only a part
      > of its functionality. Many features I have not used maybe since their
      > addition. I have got many items in my TODO list, but they are not
      > important personally for me. Adding PQ-cryptography, as an
      > counterexample :-), is an interesting task, so I will try to find time
      > for it. Adding or even fixing of some other issues... it is boring,
      > but of course they should be done. Maybe that is some kind of burnout.
      
      That is totally understandable!  I've moved on from a number of my
      earlier projects also, sometimes revisiting them years later.
      
      I'm curious what other items are on your TODO list?
      
      
      > NNCP get much attention (mainly by your, John, work) when my interest
      > was already declining :-). I even have not updated FreeBSD's port for a
      > long time. Recently I tried to update it, but it has some port-ecosystem
      > related issues that I am not too enthusiastic to debug and fix.
      
      Totally understandable.  Maybe this will finally get me to learn Go :-)
      
      FWIW, I process around a thousand packets a day using NNCP for backups
      (every ZFS dataset on every machine, every hour).  It is fantastic and
      Just Works!
      
      >>I would like to add a vote for compatibility [...]
      >>Perhaps it could be accomplished by having upgraded nodes generate both
      >>old-style keys and new-style ones. [...]
      >
      > Agreed. But... I am not sure that backward compatibility will stay.
      >
      > One of the annoying things in NNCP is its configuration format. It is
      > not friendly for machine editing. Hjson can be converted to JSON and
      > JSON can be edited by jq-like utilities, but that is not too convenient.
      > I do not like the fact of having two completely different configuration
      > formats: (h)json and "cfgdir" one, that has a huge hard-coded mapping
      
      It's a bit janky, but it seems to work well enough for NNCPNET.  I
      mostly use cfgdir for that.
      
      > how to store each field of the configuration. So I am also thinking
      > about replacing all of that with something different, especially when
      > huge McEliece post-quantum keys will be definitely outside the
      > configuration file. That is just a coincidence, but recently I wrote
      
      Yep, that makes sense.
      
      > "damn small configuration" tool, that some kind mimics OpenWRT's like
      > UCI configuration tool experience, keeping all the data in a directories
      > hierarchy, but also allowing exporting/importing all of that in a single
      > text txtar-file.
      > http://www.git.cypherpunks.su/?p=dsc.git;a=blob_plain;f=dsc;h=837942ba3c2e0c0c9511be721afb92c597f2e78b8bd0d0d56a99335b47fea072;hb=HEAD
      > But maybe it is bad idea. Even does not have enough time to think about it.
      
      There are a number of libraries for dealing with the old Windows .ini
      format.  Python and Rust have one named configparser, for instance.
      Most of these have support for both reading and writing.  It's a
      reasonable format, better than all the YAML ones :-)
      
      > But if configuration format will change, then newer NNCP will transform
      > to something completely incompatible, starting from configuration file
      > format, to different format of all kinds of packets and online protocol.
      > Keeping an old and new implementations will be like keeping two
      > different programs together. But I have no plans in changing nncp-*
      > command's API or any other logic.
      
      Just a comment - a different config file format doesn't necessarily mean
      the other things have to change.  Though maybe it is the other changes
      that would drive the different config file format.
      
      Thanks!
      
      - John
      
      ^ permalink raw reply	[flat|nested] 9+ messages in thread

    • • * Re: Possible distant future cryptography and format changes
          2025-10-07 13:31     ` John Goerzen
        @ 2025-10-08  8:54       ` Sergey Matveev
          0 siblings, 0 replies; 9+ messages in thread
        From: Sergey Matveev @ 2025-10-08  8:54 UTC (permalink / raw)
          To: nncp-devel
        
        [-- Attachment #1: Type: text/plain, Size: 3436 bytes --]
        
        Greetings!
        
        *** John Goerzen [2025-10-07 08:31]:
        >Very true.  I often have wrapped it in frames, with a leading u64 length
        >indicator.  Somewhat annoying, but it has generally been OK for me to
        >put the large payload, whatever it is, outside of the MessagePack and in
        >a frame.
        
        Like I do with NNCP, where there are some raw data of non-32bit length
        outside XDR structures. But that is an unfortunate hack, workaround for
        codec/format limitations.
        
        >> in advance) and does not force deterministic encoding (but in practice I
        >> won't be surprised that most implementations have strict behaviour),
        >> that was not perfect for embedded systems. So I just have not found good
        >> enough existing format. MessagePack won't be a problem for NNCP use-cases,
        >> but cryptographic messages (KEKS/CM) are already defined and Go
        >> implementation covers a big subset of them.
        >
        >Can you send me a pointer to this definition and Go implementation?  I
        >haven't been able to dig it up.
        
        What definition? About KEKS and comparison with other codecs?
        http://www.keks.cypherpunks.su/
        Draft/dirty-but-working Go implementation of its cryptographic messages
        is in Git: http://www.git.cypherpunks.su/?p=keks.git;a=tree;f=go
        
        >I'm curious what other items are on your TODO list?
        
        Well, I am ashamed of sharing it and maybe some important (for other
        people) issues were missed by me unintentionally. There is a will to
        make integration tests (cfgdir was created exactly at least for them).
        To think about authorisation in areas. Route printer. Errors
        refactoring. Something related to downloads resuming (I even do not
        remember the details).
        
        >> NNCP get much attention (mainly by your, John, work) when my interest
        >> was already declining :-). I even have not updated FreeBSD's port for a
        >> long time. Recently I tried to update it, but it has some port-ecosystem
        >> related issues that I am not too enthusiastic to debug and fix.
        >
        >Totally understandable.  Maybe this will finally get me to learn Go :-)
        
        That weekend port was updated: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=289697
        
        >FWIW, I process around a thousand packets a day using NNCP for backups
        >(every ZFS dataset on every machine, every hour).  It is fantastic and
        >Just Works!
        
        Glad to hear that :-)
        
        >There are a number of libraries for dealing with the old Windows .ini
        >format.  Python and Rust have one named configparser, for instance.
        >Most of these have support for both reading and writing.  It's a
        >reasonable format, better than all the YAML ones :-)
        
        YAML is the worst by all means, in my opinion. .ini is good for very
        simple cases indeed, but TOML, also being very widely supported, not bad
        comparing to it. Actually I moved NNCP's YAML configuration to TOML
        once, but then I saw how it looks with more complex nested structures,
        like NNCP has, it was not even committed.
        
        >Just a comment - a different config file format doesn't necessarily mean
        >the other things have to change.  Though maybe it is the other changes
        >that would drive the different config file format.
        
        Yeah, actually exactly the other changes (like using (unfortunately
        huge) Classic McEliece keys) some kind of forces to use non-single-file
        configuration (keeping BaseXXX-encoded >1MiB key for each node is bad).
        
        -- 
        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 --]
        
        ^ permalink raw reply	[flat|nested] 9+ messages in thread

• * Re: Possible distant future cryptography and format changes
    2025-09-28 10:05 Possible distant future cryptography and format changes Sergey Matveev
    2025-10-03  0:11 ` John Goerzen
  @ 2026-03-18 10:57 ` Sergey Matveev
    2026-03-18 15:02   ` Rafael Diniz
    1 sibling, 1 reply; 9+ messages in thread
  From: Sergey Matveev @ 2026-03-18 10:57 UTC (permalink / raw)
    To: nncp-devel
  
  [-- Attachment #1: Type: text/plain, Size: 1507 bytes --]
  
  Greetings!
  
  *** Sergey Matveev [2025-09-28 13:05]:
  >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/
  >[...]
  >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 am writing all of this just for your information, because I use that
  since ~2025-12. I made "kekscm" branch in NNCP's Git repository,
  containing very quick and dirty hack to bring PQ-security for encrypted
  packets. Maybe that code will never be in develop/master releases. In
  that branch I added another encrypted packet's version, which holds
  KEKS/CM (http://www.keks.cypherpunks.su/cm/encrypted/index.html)
  encrypted payload. All tests are broken. cfgdir, packet's padding, areas
  do not work. exchpub/exchprv/signpub/signprv are replaced with "keyid"
  field, holding the hexadecimal fingerprint of the KEKS/CM keypair,
  located in $NNCPKEYS directory. KEKS/CM'es utilities (cmkeytool,
  cmenctool) are used just by calling them through exec.
  
  -- 
  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 --]
  
  ^ permalink raw reply	[flat|nested] 9+ messages in thread

• • * Re: Possible distant future cryptography and format changes
      2026-03-18 10:57 ` Sergey Matveev
    @ 2026-03-18 15:02   ` Rafael Diniz
      2026-03-18 15:10     ` Sergey Matveev
      0 siblings, 1 reply; 9+ messages in thread
    From: Rafael Diniz @ 2026-03-18 15:02 UTC (permalink / raw)
      To: nncp-devel
    
    
    [-- Attachment #1.1: Type: text/plain, Size: 1855 bytes --]
    
    Greetings!
    
    I read this "* Ability to use multiple recipients" in the URL page.
    
    One dummy question - with the current nncp implementation, is it 
    possible to send a file in broadcast mode (something easy in HF), for 
    example, to multiple nodes, and the nodes be able to decrypt the payload?
    
    Right now I'm doing mostly p2p connections.
    
    - Rafael
    
    On 3/18/26 10:57 AM, Sergey Matveev wrote:
    > Greetings!
    > 
    > *** Sergey Matveev [2025-09-28 13:05]:
    >> 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/
    >> [...]
    >> 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 am writing all of this just for your information, because I use that
    > since ~2025-12. I made "kekscm" branch in NNCP's Git repository,
    > containing very quick and dirty hack to bring PQ-security for encrypted
    > packets. Maybe that code will never be in develop/master releases. In
    > that branch I added another encrypted packet's version, which holds
    > KEKS/CM (http://www.keks.cypherpunks.su/cm/encrypted/index.html)
    > encrypted payload. All tests are broken. cfgdir, packet's padding, areas
    > do not work. exchpub/exchprv/signpub/signprv are replaced with "keyid"
    > field, holding the hexadecimal fingerprint of the KEKS/CM keypair,
    > located in $NNCPKEYS directory. KEKS/CM'es utilities (cmkeytool,
    > cmenctool) are used just by calling them through exec.
    > 
    
    
    [-- Attachment #2: OpenPGP digital signature --]
    [-- Type: application/pgp-signature, Size: 840 bytes --]
    
    ^ permalink raw reply	[flat|nested] 9+ messages in thread

  • • * Re: Possible distant future cryptography and format changes
        2026-03-18 15:02   ` Rafael Diniz
      @ 2026-03-18 15:10     ` Sergey Matveev
        2026-03-18 19:27       ` Rafael Diniz
        0 siblings, 1 reply; 9+ messages in thread
      From: Sergey Matveev @ 2026-03-18 15:10 UTC (permalink / raw)
        To: nncp-devel
      
      [-- Attachment #1: Type: text/plain, Size: 603 bytes --]
      
      *** Rafael Diniz [2026-03-18 15:02]:
      >One dummy question - with the current nncp implementation, is it possible to
      >send a file in broadcast mode (something easy in HF), for example, to
      >multiple nodes, and the nodes be able to decrypt the payload?
      
      There is some ability to multicast: http://www.nncpgo.org/Multicast.html
      but not broadcast.
      
      >Right now I'm doing mostly p2p connections.
      
      Personally I do only unicast ones :-)
      
      PS: please, do not use top-post in the maillist.
      
      -- 
      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 --]
      
      ^ permalink raw reply	[flat|nested] 9+ messages in thread

    • • * Re: Possible distant future cryptography and format changes
          2026-03-18 15:10     ` Sergey Matveev
        @ 2026-03-18 19:27       ` Rafael Diniz
          0 siblings, 0 replies; 9+ messages in thread
        From: Rafael Diniz @ 2026-03-18 19:27 UTC (permalink / raw)
          To: nncp-devel
        
        
        [-- Attachment #1.1: Type: text/plain, Size: 902 bytes --]
        
        On 3/18/26 3:10 PM, Sergey Matveev wrote:
        > *** Rafael Diniz [2026-03-18 15:02]:
        >> One dummy question - with the current nncp implementation, is it possible to
        >> send a file in broadcast mode (something easy in HF), for example, to
        >> multiple nodes, and the nodes be able to decrypt the payload?
        > 
        > There is some ability to multicast: http://www.nncpgo.org/Multicast.html
        > but not broadcast.
        
        Right. I might use this together with nncp-bundle to carry broadcasts, 
        if I understood well.
        
        >> Right now I'm doing mostly p2p connections.
        > 
        > Personally I do only unicast ones :-)
        > 
        > PS: please, do not use top-post in the maillist.
        
        I missed this netiquette class.
        : )
        
        I should also have created another topic, as I don't want to hijack this 
        thread, which is obviously very important. I'm still understanding all 
        implications to nncp usage / feature-set.
        
        - Rafael
        
        
        [-- Attachment #2: OpenPGP digital signature --]
        [-- Type: application/pgp-signature, Size: 840 bytes --]
        
        ^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2026-03-18 19:27 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2025-09-28 10:05 Possible distant future cryptography and format changes Sergey Matveev
2025-10-03  0:11 ` 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