[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
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)