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