Serious question. Serious and direct answers only, please.

If there were available open source server software for a new protocol
similar to NNTP, with optional moderated and secret hierarchies, and a
built-in mixnet for secret, encrypted hierarchies, which of you would
install and run the server?

The protocol design would use special cryptographic primitives to enable
secret hierarchies without revealing the content of the groups therein.
All peers would route encrypted mix messages by default, unless
specifically disabled by admin. All mix messages would be broken up into
standard-size packets and delay switch routed randomly to obfuscate origin.

Initially I would not be shipping with a specialized client. That would
come later. The initial server would respond to some usenet commands
from newsreaders like Thunderbird, Pan, etc. But those clients would not
be able to use the encrypted mix features.

Client proof-of-work would be used to mitigate spam and flood attack.
Optional signup and authentication would be available for admins who
don't want random anonymous users and the spam headaches.

The protocol would not interoperate with NNTP servers, which would be
totally incompatible with the cryptography and routing architecture.

It would be designed for zero-configuration setup and automatic peering
of public text groups out of the box. Just copy the binary to path, set
a cron or init script to run it, and done. It would automatically sync
with randomly-chosen peers and switch to a new peer every few minutes.

How many people would actually run such server? Would there be a demand
to justify polishing it for production use in the wild?

--

G.K.

Il 14/09/22 20:05, G.K. ha scritto:
> If there were available open source server software for a new protocol
> similar to NNTP, with optional moderated and secret hierarchies, and a
> built-in mixnet for secret, encrypted hierarchies, which of you would
> install and run the server?

i may consider to run that service not before having seen that program

[This ended up being kinda long...]

"G.K." <gk@g.k> writes:
> If there were available open source server software for a new protocol
> similar to NNTP, with optional moderated and secret hierarchies, and a
> built-in mixnet for secret, encrypted hierarchies, which of you would
> install and run the server?

If the servers know a hierarchy exists, then it's not really secret,
just maybe not publicized or maybe hidden from a search or list. If
they don't, then it's impossible for the server to specify which
hierarchies it carries, impossible for users to ask the server for
articles in the group, etc. Users would have to recieve the entire
encrypted feed and use something like hashtags (though, yes, there have
in the past been people who proposed using hashtags instead of newsgroup
names for USENET).

Absent more details, I'd be concerned such a system would be used for
distributing child pornography or for other illegal or unsavory
activities.

If the secrecy is at user level (unreadable on the server or by anyone
else without the appropriate key), I wouldn't trust the content was safe
to carry. If the encryption is only between servers, then I don't see
how it's useful since one could simply read the articles from the
server, and governments or other entities need only run a server to see
everything.

If anyone can join any group, then the keys are widely available, so
such a protocol would just be extra work to distribute articles. If
not, then you're asking for a new, secure, essentially private
communication channel for unknown groups of users, and (IMHO) secure,
private, end-to-end communication is paid for and handled adequately by
existing services, not a business I'd expect USENET admins to add (and
certainly not for free).

Just my initial reaction... Continuing to specifics:

> The protocol design would use special cryptographic primitives to
> enable secret hierarchies without revealing the content of the groups
> therein.

This sounds like you're saying the servers would know the names of the
secret hierarchies and maybe the newsgroup names, but the articles would
be encrypted. OK.

> All mix messages would be broken up into standard-size packets and
> delay switch routed randomly to obfuscate origin.

This sounds like your goal is to make senders anonymous and thus unable
to be held responsible for their actions if, for example, they posted
child pornography.

> Client proof-of-work would be used to mitigate spam and flood attack.
> Optional signup and authentication would be available for admins who
> don't want random anonymous users and the spam headaches.

Signup and authentication hasn't prevented spam and floods in USENET.

If I'm reading right, your protocol requires every node on the network,
for every (mix?) article, to reassemble the articles from the pieces
transmitted via randomized distribution, which requires being able to
determine when one has all the pieces, and then run a time consuming
verification test for every article. Distribution is of fragments, not
whole articles as USENET does.

Article floods with invalid encryption could still be injected into the
flow, but now it's expensive to determine that there's a flood.
Verification can't be skipped: no server can be certain their peer of
the moment is trustworthy and has authenticated its traffic because
peers are randomized and the current peer might be injecting trash.
Unless the server has some way of checking and does check every article
in its feed, it's at risk of passing on a bogus article or fragment,
meaning the origin could be successfully obfuscated and you won't know
what server was responsible.

If a server can and does check the incoming feed from its peer, it could
at least detect if the peer is untrustworthy, but if the cryptographic
verification requires the entire article and articles are broken up into
standard size packets (fragments) distributed via various servers, then
the receiving peer can't immediately detect whether the sending peer is
submitting flood fragments.

Suppose the server could immediately detect a flood from a peer. What
would it do with that information? Discarding everything that peer just
submitted is probably reasonable. Tell other servers? If you create a
mechanism to ban a server, how do you know that the ban request isn't an
unjustified attack on that server?

In conclusion, based solely on the details you posted, it sounds like
posting an encrypted article to USENET and using standard NNTP
distribution would be better if such articles are propagated. Similar
reasoning decades ago was the primary incentive for creating end-to-end
encryption in which the data packets would flow over insecure Internet
links.
-WBE

On Wed, 14 Sep 2022 21:24:55 +0200, Aioe wrote:

> Il 14/09/22 20:05, G.K. ha scritto:
>> If there were available open source server software for a new protocol
>> similar to NNTP, with optional moderated and secret hierarchies, and a
>> built-in mixnet for secret, encrypted hierarchies, which of you would
>> install and run the server?
>
> i may consider to run that service not before having seen that program

Always down for trying new tech but like messages before me would have to
see the server and maybe a demo server to see how it actuly works.

Hi Stefan!

> If there were available open source server software for a new protocol
> similar to NNTP, with optional moderated and secret hierarchies,

What's the use of secret hierarchies?

> How many people would actually run such server?

A fraction of the people who run NNTP servers.

> Would there be a demand

No.

["Followup-To:"-huvud satt till news.groups.]
Den 2022-09-14 skrev G.K. <gk@g.k>:
> Serious question. Serious and direct answers only, please.
>
> If there were available open source server software for a new protocol
> similar to NNTP, with optional moderated and secret hierarchies, and a
> built-in mixnet for secret, encrypted hierarchies, which of you would
> install and run the server?
>
> The protocol design would use special cryptographic primitives to enable
> secret hierarchies without revealing the content of the groups therein.
> All peers would route encrypted mix messages by default, unless
> specifically disabled by admin. All mix messages would be broken up into
> standard-size packets and delay switch routed randomly to obfuscate origin.
>
> Initially I would not be shipping with a specialized client. That would
> come later. The initial server would respond to some usenet commands
> from newsreaders like Thunderbird, Pan, etc. But those clients would not
> be able to use the encrypted mix features.
>
> Client proof-of-work would be used to mitigate spam and flood attack.
> Optional signup and authentication would be available for admins who
> don't want random anonymous users and the spam headaches.
>
> The protocol would not interoperate with NNTP servers, which would be
> totally incompatible with the cryptography and routing architecture.
>
> It would be designed for zero-configuration setup and automatic peering
> of public text groups out of the box. Just copy the binary to path, set
> a cron or init script to run it, and done. It would automatically sync
> with randomly-chosen peers and switch to a new peer every few minutes.
>
> How many people would actually run such server? Would there be a demand
> to justify polishing it for production use in the wild?
>

Except for the part about moderated secret hierarchies, I think what
you describe sounds a lot like FMS, Freenet Message System. It is an
NNTP implementation that uses the distributed Freenet [0] network as a
storage back-end.

You create a pseudonym and introduce it on the network by solving
captchas. Moderation is handled by users rating other users and
publishing trust lists.

[0]: https://freenetproject.org/