Gentlebeings,

I would like to describe an enhancement to the NNTP protocol, with a view
to peer review.

# Rationale

I began using Usenet in about 1994. It was a remarkable forum -
possessing the property of being both public and yet private, as at that
time no one was archiving posts.

I may be wrong, but I think the property of being public and yet private
nature of Usenet was special and of particular value.

I would like to recreate that property of being public and yet private,
which is exactly to say that posts can be read by and only by a given
group of readers. The news-servers cannot read posts, nor can anyone
outside of that group of readers - so no archiving by Google, or anyone
else.

# Design

The mechanism for this then centers on the use of private-public key
pairs, and the introduction of a new type of moderation.

Moderation exists already in Usenet, and it is at the level of posts being
made to a group. Anyone can read any post in any group, but only those
posts approved by moderators can be posted.

I propose then a second form of moderation, which is and is only
moderation of what is in effect membership of a group - members are able
to read and post, non-members cannot read or post.

We begin with an empty newsgroup, with a moderator of the new type.

For a user to subscribe, they create a private-public key pair and provide
the *public* key to the moderator.

If their application is approved by the moderator, the public key is then
distributed to all current members of the group.

All members hold then the public key of all other members.

It is possible to encrypt messages using more than one public key.

When a member posts, the post is encrypted by the NNTP client with the
public keys of every existing member, and then posted.

As such, the and the only people who can read that post are the existing
members; they can all decrypt the message using their own private key,
which is secret to them.

The news-servers cannot decrypt posts, non-members cannot decrypt posts;
both can see and only see the encrypted text.

As such, when a post is made, only the current group of subscribers can
decrypt the post.

When a new member subscribes, they will be able to read posts only from
the moment of their subscription onwards; they will not have access to
historical posts. A posting could be made into a group to alert all users
of a new subscriber, to allow for care in posting until that subscriber is
trusted by the community.

Killfiles also develop new powers, as a news client can *not* encrypt a
post with the public key of members in the posters killfile. Killfiles
then would stop not only seeing the posts of those in the killfile, but
would also prevent those in the killfile from reading the posters posts.

On Wed, 8 Nov 2023 20:01:59 -0000 (UTC), Bixby wrote:

> I may be wrong, but I think the property of being public and yet private
> nature of Usenet was special and of particular value.

*sigh* =-)

Proof-read all you like, there's always stuff you'll only see once you've
posted.

On 11/8/23 14:01, Bixby wrote:
> Gentlebeings,
>
> I would like to describe an enhancement to the NNTP protocol, with a view
> to peer review.
>
> # Rationale
>
> I began using Usenet in about 1994. It was a remarkable forum -
> possessing the property of being both public and yet private, as at that
> time no one was archiving posts.
>
> I may be wrong, but I think the property of being public and yet private
> nature of Usenet was special and of particular value.
>
> I would like to recreate that property of being public and yet private,
> which is exactly to say that posts can be read by and only by a given
> group of readers. The news-servers cannot read posts, nor can anyone
> outside of that group of readers - so no archiving by Google, or anyone
> else.
>
> # Design
>
> The mechanism for this then centers on the use of private-public key
> pairs, and the introduction of a new type of moderation.
>
> Moderation exists already in Usenet, and it is at the level of posts being
> made to a group. Anyone can read any post in any group, but only those
> posts approved by moderators can be posted.
>
> I propose then a second form of moderation, which is and is only
> moderation of what is in effect membership of a group - members are able
> to read and post, non-members cannot read or post.
>
> We begin with an empty newsgroup, with a moderator of the new type.
>
> For a user to subscribe, they create a private-public key pair and provide
> the *public* key to the moderator.
>
> If their application is approved by the moderator, the public key is then
> distributed to all current members of the group.
>
> All members hold then the public key of all other members.
>
> It is possible to encrypt messages using more than one public key.
>
> When a member posts, the post is encrypted by the NNTP client with the
> public keys of every existing member, and then posted.
>
> As such, the and the only people who can read that post are the existing
> members; they can all decrypt the message using their own private key,
> which is secret to them.
>
> The news-servers cannot decrypt posts, non-members cannot decrypt posts;
> both can see and only see the encrypted text.
>
> As such, when a post is made, only the current group of subscribers can
> decrypt the post.
>
> When a new member subscribes, they will be able to read posts only from
> the moment of their subscription onwards; they will not have access to
> historical posts. A posting could be made into a group to alert all users
> of a new subscriber, to allow for care in posting until that subscriber is
> trusted by the community.
>
> Killfiles also develop new powers, as a news client can *not* encrypt a
> post with the public key of members in the posters killfile. Killfiles
> then would stop not only seeing the posts of those in the killfile, but
> would also prevent those in the killfile from reading the posters posts.
>

Would it be possible to encrypt messages with a key?
--
user <candycane> is generated from /dev/urandom

For your reference, records indicate that
Bixby <bixby@sctb.ch> wrote:

> I began using Usenet in about 1994. It was a remarkable forum -
> possessing the property of being both public and yet private, as at that
> time no one was archiving posts.

Well, you’ve already started out with a false premise. Whenever it was
Google acquired whatever archive they initially seeded Google Groups with,
I was able to find a post of mine from 1991. Just because the data isn’t
widely available doesn’t mean it is “private”, and a good argument could
be made that, in the wrong hands, that kind of data *held in private* is
the very opposite of *private*.

> I would like to recreate that property of being public and yet private,
> which is exactly to say that posts can be read by and only by a given
> group of readers. The news-servers cannot read posts, nor can anyone
> outside of that group of readers - so no archiving by Google, or anyone
> else.

Again, false premise. Encrypted messages can be archived the same as any
other data. Whether or not there is *value* in that is another question,
and may depend very much on how long it takes for the encryption algorithm
to be broken or otherwise compromised. The most likely scenario is that
some side-channel attack will allow the plaintext message to be gotten
from one of the “given group”.

> The mechanism for this then centers on the use of private-public key
> pairs, and the introduction of a new type of moderation.

It’s not clear where you’re going here. I mean, you have yet to say
what will actually change about NNTP protocol itself. Encrypted
messages are nothing new or special; I recall encountering more than
one post to binary newsgroups back in the day that was encrypted, and
presumably that still happens today.

> I propose then a second form of moderation, which is and is only
> moderation of what is in effect membership of a group - members are able
> to read and post, non-members cannot read or post.

Not sure how that fits your initial definition of “public”.

> It is possible to encrypt messages using more than one public key.
>
> When a member posts, the post is encrypted by the NNTP client with the
> public keys of every existing member, and then posted.

I’m no cryptography expert, but my understanding is that things aren’t
generally done that way. Rather, the message is encrypted only once with
a strong symmetric cipher, and then just that key is encrypted with the
public keys of the intended recipients.

> The news-servers cannot decrypt posts, non-members cannot decrypt posts;
> both can see and only see the encrypted text.
>
> As such, when a post is made, only the current group of subscribers can
> decrypt the post.

Still not seeing the “public” aspect of this. Still not seeing any change
to the NNTP protocol.

> When a new member subscribes, they will be able to read posts only from
> the moment of their subscription onwards; they will not have access to
> historical posts. A posting could be made into a group to alert all users
> of a new subscriber, to allow for care in posting until that subscriber is
> trusted by the community.

What’s the point? What do the existing members get out of having to deal
with a stream of untrusted newcomers? What would new members expect to
be getting out of a group that has no other history than a bunch of
random data? Why is anybody participating in any of that?

> Killfiles also develop new powers, as a news client can *not* encrypt a
> post with the public key of members in the posters killfile. Killfiles
> then would stop not only seeing the posts of those in the killfile, but
> would also prevent those in the killfile from reading the posters posts.

I assure you that, despite my intensive use of filtering, I still see the
posts of *far* too many people I’m trying to ignore because other people
continue to feed the trolls. Your scheme doesn’t change that.

Everything you suggest still seems like it could be layered on top of the
NNTP protocol as it already exists. People aren’t already regularly doing
that because the result is far less useful than the existing public forum.

--
"Also . . . I can kill you with my brain."
River Tam, Trash, Firefly

On Wed, 8 Nov 2023 20:01:59 -0000 (UTC)
Bixby <bixby@sctb.ch> wrote:

<snip>

What you describe already exists in a well-designed form: Bitmessage.

Bitmessage has chans, which are similar to newsgroups. You can subscribe
and unsubscribe to chans by keyword. Bitmessage also has:

- public chans
- secret chans
- distributed mailing lists
- encrypted private messaging
- mailchuck remailer forwarding
- whitelisting and blacklisting
- uncensorable broadcasts

Homepage: https://bitmessage.org

Downloads:

- Binary (64bit, no separate installation of dependencies required)
- Windows: https://download.bitmessage.org/snapshots/
- Linux AppImages: https://artifacts.bitmessage.at/appimage/
- Linux snaps: https://artifacts.bitmessage.at/snap/

Detailed install instructions:
https://github.com/Bitmessage/PyBitmessage/blob/v0.6/INSTALL.md

Instead of a central moderator, users moderate by using the whitelist
or blacklist functions. The whitelist is useful for blocking all
messages by default except for those coming from addresses added to the
whitelist.

It also has uncensorable broadcasts, which are very useful for at-risk
persons who need to get information out on the wire without doxing
themselves. Communicants can share secret broadcast addresses or secret
private addresses for high-security messaging. Secret chans can also be
created using strong passphrases for discussing sensitive topics.

Some Usenetizens already chat via Bitmessage. The chan
'alt.anonymous.messages' has been in continuous use for years.

Here is copypasta of some public chans:

# Categorical List of Bitmessage Chans

### usual chans:

bitmessage general hello

### app chans:

bitboard freshmeet

### protocol chans:

fediverse tildeverse bbs usenet gopher

### usenet chans:

alt.anonymous.messages alt.privacy.anon-server sci.crypt

### encryption chans:

PGP alt.anonymous.messages insurance crypto

### hacker chans:

blackhat dump hamburglar hispagatos leaks linux

### crypto-currency chans:

Bitcoin Monero

### crypto-anarchy chans:

Crypto-Anarchist Federation cypherpunk

### shitposter chans

helicoptarian

### number chans:

0 1776 19 1984
33 3301 411 711
8200 9 911 numberstation

--
Baggy Jeans Mafia | https://syfershock.com/users/syfershock

Doc O'Leary , <droleary@2017usenet1.subsume.com> writes:
> For your reference, records indicate that
> Bixby <bixby@sctb.ch> wrote:

>> For a user to subscribe, they create a private-public key pair and provide
>> the *public* key to the moderator.
>>
>> If their application is approved by the moderator, the public key is then
>> distributed to all current members of the group.
>>
>> All members hold then the public key of all other members.
[...]
>> It is possible to encrypt messages using more than one public key.
>>
>> When a member posts, the post is encrypted by the NNTP client with the
>> public keys of every existing member, and then posted.
>
> I’m no cryptography expert, but my understanding is that things aren’t
> generally done that way. Rather, the message is encrypted only once with
> a strong symmetric cipher, and then just that key is encrypted with the
> public keys of the intended recipients.

Yes and no - when you’re looking at how asymmetric encryption of a
nontrivial message works, it does involve establishing symmetric session
keys and then encrypting the full message with those. But from a
higher-level viewpoint we’d still say that e.g. ECIES was “encrypting
with the recipient’s public key” rather than breaking it down into its
constituent parts every time we mentioned it.

There are some challenges to work through.

First in the design as stated, the number of public key operations for
each message (point multiplications, modexps, or stranger PQC
operations) scales according to the number of recipients. Modern
computers are fast enough that with small groups of recipients this
isn’t a big deal but at some point your computer is spending rather a
lot of its time on the cryptography; latency will suffer too.

Second the security of the whole system depends both on the
trustworthiness of the moderator and their competence in selecting
recipients. Even assuming the moderator is trustworthy, as the number of
recipients grows, the probability that one of them is one of the group’s
adversaries grows with it.

In that case the value of the cryptography starts to fall (although not
necessarily to zero, depending on the priorities of the group members,
the nature of the adversary, etc).

--
https://www.greenend.org.uk/rjk/

On Thu, 09 Nov 2023 10:25:16 +0000, Richard Kettlewell wrote:

> First in the design as stated, the number of public key operations for
> each message (point multiplications, modexps, or stranger PQC
> operations) scales according to the number of recipients. Modern
> computers are fast enough that with small groups of recipients this
> isn’t a big deal but at some point your computer is spending rather a
> lot of its time on the cryptography; latency will suffer too.

Yes. This is an open question. How long would it take to encrypt a post
to a group with a hundred subscribers? or a thousand? or ten thousand?
could it be there must be limits to the number of subscribers?

> Second the security of the whole system depends both on the
> trustworthiness of the moderator and their competence in selecting
> recipients. Even assuming the moderator is trustworthy, as the number of
> recipients grows, the probability that one of them is one of the group’s
> adversaries grows with it.

Yes. Moderators as they exist now must be trusted in much the same way.
With regard to the inadvertant acceptance of subscription from an
adversary, there is some protection in that posts can be read only from
the time of subscription onwards. When there is a new subscriber, there
can be a post to the group, and users can moderate their posting until
trust is built up, and also individuals can at their own discretion choose
not to encrypt using the public key of any given member, and so if they
are unsure, they can hold off until they are more comfortable - perhaps
here we can imagine a feature, where-by users indicate to their client a
post is sensitive, and then it encrypts using the public keys only of
members who have subscribed for a given period of time, or a particular
subset of subscribers.

Bixby <bixby@sctb.ch> writes:
> On Thu, 09 Nov 2023 10:25:16 +0000, Richard Kettlewell wrote:

>> Second the security of the whole system depends both on the
>> trustworthiness of the moderator and their competence in selecting
>> recipients. Even assuming the moderator is trustworthy, as the number of
>> recipients grows, the probability that one of them is one of the group’s
>> adversaries grows with it.
>
> Yes. Moderators as they exist now must be trusted in much the same way.

Not reallty, moderators in the present system have no impacted on
privacy (because there isn’t any).

> With regard to the inadvertant acceptance of subscription from an
> adversary, there is some protection in that posts can be read only from
> the time of subscription onwards. When there is a new subscriber, there
> can be a post to the group, and users can moderate their posting until
> trust is built up, and also individuals can at their own discretion choose
> not to encrypt using the public key of any given member, and so if they
> are unsure, they can hold off until they are more comfortable - perhaps
> here we can imagine a feature, where-by users indicate to their client a
> post is sensitive, and then it encrypts using the public keys only of
> members who have subscribed for a given period of time, or a particular
> subset of subscribers.

So:
- every participant must somehow decide whether every other participant
is really an attacker, not just the moderator
- discussion is inherently fragmented

--
https://www.greenend.org.uk/rjk/

On Thu, 09 Nov 2023 13:40:03 +0000, Richard Kettlewell <invalid@invalid.invalid> wrote:
>Bixby <bixby@sctb.ch> writes:
>> On Thu, 09 Nov 2023 10:25:16 +0000, Richard Kettlewell wrote:
>>> Second the security of the whole system depends both on the
>>> trustworthiness of the moderator and their competence in selecting
>>> recipients. Even assuming the moderator is trustworthy, as the number of
>>> recipients grows, the probability that one of them is one of the group�s
>>> adversaries grows with it.
>>
>> Yes. Moderators as they exist now must be trusted in much the same way.
>
>Not reallty, moderators in the present system have no impacted on
>privacy (because there isn�t any).
>
>> With regard to the inadvertant acceptance of subscription from an
>> adversary, there is some protection in that posts can be read only from
>> the time of subscription onwards. When there is a new subscriber, there
>> can be a post to the group, and users can moderate their posting until
>> trust is built up, and also individuals can at their own discretion choose
>> not to encrypt using the public key of any given member, and so if they
>> are unsure, they can hold off until they are more comfortable - perhaps
>> here we can imagine a feature, where-by users indicate to their client a
>> post is sensitive, and then it encrypts using the public keys only of
>> members who have subscribed for a given period of time, or a particular
>> subset of subscribers.
>
>So:
>- every participant must somehow decide whether every other participant
> is really an attacker, not just the moderator
>- discussion is inherently fragmented

in active unmoderated public newsgroup forums, lurkers probably outnumber
contributors (discounting spammers), thus increasing trust levels because
even the slightest error, intentional or otherwise, is more likely to get
noticed and elicit helpful replies from less partial more objective users;
whereas secluded discussions are less scrutinized and more prone to error

On Thu, 9 Nov 2023 01:17:10 -0600, Sugar Bug <3883@sugar.bug> wrote:
>On Wed, 8 Nov 2023 20:01:59 -0000 (UTC)
>Bixby <bixby@sctb.ch> wrote:
><snip>
>What you describe already exists in a well-designed form: Bitmessage.
>Bitmessage has chans, which are similar to newsgroups. You can subscribe
>and unsubscribe to chans by keyword. Bitmessage also has:
> - public chans
> - secret chans
> - distributed mailing lists
> - encrypted private messaging
> - mailchuck remailer forwarding
> - whitelisting and blacklisting
> - uncensorable broadcasts
>Homepage: https://bitmessage.org

such open encryption might work for "public yet private" purposes?
as a casual user of remailers for posting to newsgroups, "privacy"
is a simple matter, because none of the plain text content posted
to these unmoderated newsgroup forums requires decryption to read;
but some users may have more serious concerns about prevention of
"unauthorized" access to unencrypted content regardless of format
or function, in such cases "whole message encryption" is strongly
recommended . . . see https://www.danner-net.de/omom/tutorwme.htm

>OmniMix * Tutorial * Whole Message Encryption (WME) PreviousTopNext
>It's obvious to prevent your normal e-mail correspondence from being
>spied on by encrypting it with PGP. If the messages include attachments,
>you have to encrypt those as well. But there are parts of your message
>you can't hide this way, like its size, the subject, some language
>specific characteristics, and last, not least the fact of sending a
>multi-part message. That's where OmniMix's 'Whole Message Encryption'
>comes to your aid.
>Different from PGP frontends, which only allow to manipulate your
>message before being sent by the mail client, a proxy server like
>OmniMix is able to alter it as a whole, as long as the result remains
>a compatible mail. Provided that the PGP keys of all recipients of a
>mail are available, OmniMix can be advised to encrypt the entire
>message, including the complete header section and some random dummy
>data to disguise its real size, into one single PGP message block and
>send it by means of a rudimentary header, which has to contain nothing
>but the mail addresses and maybe some 'X-Hashcash' tokens. If it's sent
>via a nym server an existing 'Nym-Commands' directive is also moved
>outside the WME encryption block, but for reasons of security this
>doesn't matter, as the message in any case is additionally encrypted
>with the server's key. For an adversary, who's allowed to become
>acquainted with the identity of the correspondents, the result of this
>procedure is nearly worthless.
>Moreover OmniMix even supports sending WME messages anonymously, which
>usually isn't done to hide your identity from the recipients within
>your WME community, but to prevent external observers from figuring
>out the communication partners. Keep in mind, that the data within the
>WME block aren't anonymized, but, though maybe shortened dependent on
>an active 'Mail Permits' header filter list, handled like normal mail.
>In order to allow an unrestricted, transparent communication without
>adverse effects for the participants, among other things there's still
>your 'From' address - which may be bogus - and the 'Message-ID'. If
>the former can be found on the WME recipients list with 'Sign'
>activated, the resulting signature may also expose your identity to
>those who are able to decrypt the message. So check what gets
>encrypted at the 'Data for Whole Message Encryption' section of the
>'Raw Data' list as well as the 'Log' entries to assure yourself that
>no sensitive data are unintentionally revealed to the addressees!
>Caution: Don't send an anonymous mail to several addressees at a time
>if you don't want them to become linked! In this case send a separate
>one to each of them.
>The recipients then either have to decrypt the PGP block manually and
>import the result into their mail user agents, which certainly can
>only be accepted in exceptional cases. On the other hand OmniMix can
>automatically translate the messages back into their original state
>in the course of its retrieval from the POP3 server, as far as the
>corresponding secret PGP key and the correct passphrase are placed
>at its disposal.
>At the 'Dummy Load' page of the 'WME' section you're able to randomly
>increase the size of your mail. This measure prevents adversaries
>from estimating the kind of message, whether it's about a usually
>shorter text or a more voluminous data transfer. Request a message-
>specific dummy load by sending the desired block size range
>('O-Wme-Dummy-Size-Min' and 'O-Wme-Dummy-Size-Max' header entry)
>with your message. Values higher than the maximum block size defined
>within OmniMix are refused, as the processing of a message extreme
>in size may knock out your system. OmniMix now appends a random text
>block to your message introduced by a line with a unique character
>sequence. The contents of that indicator line is added to the message
>header as the argument of an 'X-Wme-Dummy-Separator' entry in order
>to allow the recipient's system to restore the original message by
>removing the dummy load. It's important, that the dummy separator
>header is named equally at the sender and recipient, as otherwise
>the addressee won't be able to restore the original message.
> Pros and cons of different communication methods
> Ordinary PGP WME Remailing Remailing Nym Nym
> Mail + WME + WME
>Contents Protection No Reduced* Complete* No Complete* No Complete*
>Reply Capability Yes Yes Yes No Yes Yes Yes
>Anonymity towards an external observer No No No Yes Yes Yes Yes
>Anonymity between the correspondents No No No Yes No Yes Yes
>Latency Low Low Low Medium Medium High High
>Reliability High High High Medium Medium Low Low
> * Reduced: Net data only / Complete: Data + structure
>The first step to set up WME is to add all required keys to the 'WME'
>keyring ('WME' tab within the 'Nym Configurator'). You have to import
>public keys for your correspondents and one or more public / secret
>keypairs for yourself. Don't use any of your very secret PGP keys for
>that transmission purpose, as its passphrase has to be stored on your
>computer and both can be stolen by anyone who gets access! Better
>create new keys and mark them with names, that point out their low-
>security use, e.g. by adding the character sequence '(WME)' to the
>User-ID. As decryption problems can't be ruled out otherwise, it's
>recommended to create your keys within OmniMix itself.
>You may notice that the WME section offers a greater variety of
>partly more secure encryption and hash algorithms than allowed for
>nym accounts. That's because there's no need to consider the
>capabilities of remailers and nym servers.
>Next is to go to the 'WME' tab of the main window and add the mail
>addresses of all participants in your WME network to the list along
>with the corresponding key and - if it's a private key of your own -
>the passphrase. Based on this list, if WME is active, all mails,
>whether sent normally or by one of your nyms, are examined for the
>presence of corresponding encryption keys. If OmniMix finds keys for
>all 'To:' and 'Cc:' recipients and there are no 'Bcc:' recipients
>(who would be uncovered by an encryption using their keys), the mail
>gets encrypted and only header data mandatory for delivery are left
>outside the protected block. At request the sender's signature is
>added in the course of the encryption to prove the authenticity of
>the sent mail.
>Finally you have to tell OmniMix, who's allowed to use the single
>private key / password combinations to sign outgoing and decrypt
>incoming WME mails. Therefore go to the 'User' tab and mark for
>every user the 'WME' mail addresses that belong to that account.
>Now you've finished. All outgoing mails are processed dependent on
>the WME mode ('WME' tab, 'disabled' / 'enabled' / 'required'). If a
>message has to depart from that rule, then use the according header
>directive. 'O-WmeSend-Mode: required' e.g. rejects a message that
>can't be WME encrypted, with 'O-WmeSend-Mode: disabled' you would
>even be allowed to send a usual anonymous mail to someone whose key
>is present at the WME keys list. The 'Sign' setting within the WME
>participants list is binding in any case. Therefore, if signatures
>are requested, the WME encryption has to fail as long as the
>password isn't properly set for the WME key or the WME item isn't
>assigned to the user account.
[end quote]

On Thu, 09 Nov 2023 13:40:03 +0000, Richard Kettlewell wrote:
> Bixby <bixby@sctb.ch> writes:

>> Yes. Moderators as they exist now must be trusted in much the same
>> way.

> Not reallty, moderators in the present system have no impacted on
> privacy (because there isn’t any).

I mean in the sense that trust has to be placed in the moderators. Not
the particular purpose of that trust.

>> With regard to the inadvertant acceptance of subscription from an
>> adversary, there is some protection in that posts can be read only from
>> the time of subscription onwards. When there is a new subscriber,
>> there can be a post to the group, and users can moderate their posting
>> until trust is built up, and also individuals can at their own
>> discretion choose not to encrypt using the public key of any given
>> member, and so if they are unsure, they can hold off until they are
>> more comfortable - perhaps here we can imagine a feature, where-by
>> users indicate to their client a post is sensitive, and then it
>> encrypts using the public keys only of members who have subscribed for
>> a given period of time, or a particular subset of subscribers.
>
> So:
> - every participant must somehow decide whether every other participant
> is really an attacker, not just the moderator
> - discussion is inherently fragmented

For the first point, by and large, I imagine users posting to all
subscribers - trusting the moderator. What I note here is that
subscribers control the privacy of their own posts, and so would have the
option should they come to disagree with the moderator to themselves
prevent the subscriber in question from reading their posts.

For the second, yes, but when and only when such behaviour occurs. I
would think by and large it would not be common. Thinking back to when I
posted regularly, to unmoderatored groups, I can think of one person I
would have blocked in that way (someone who was abusing the group, and I
suspect who was in most killfiles).

There are many problems which can occur, but most never do.

On Thu, 9 Nov 2023 15:22:38 +0100 (CET), D wrote:

> in active unmoderated public newsgroup forums, lurkers probably
> outnumber contributors (discounting spammers),

Regarding this, of course, we can still have public posts, unencrypted, or
encrypted with a generally available key.

Bixby <bixby@sctb.ch> writes:

> I propose then a second form of moderation, which is and is only
> moderation of what is in effect membership of a group - members are able
> to read and post, non-members cannot read or post.

> We begin with an empty newsgroup, with a moderator of the new type.

> For a user to subscribe, they create a private-public key pair and
> provide the *public* key to the moderator.

> If their application is approved by the moderator, the public key is
> then distributed to all current members of the group.

> All members hold then the public key of all other members.

> It is possible to encrypt messages using more than one public key.

> When a member posts, the post is encrypted by the NNTP client with the
> public keys of every existing member, and then posted.

> As such, the and the only people who can read that post are the existing
> members; they can all decrypt the message using their own private key,
> which is secret to them.

If I understand this correctly, you have a forum with the following
properties:

1. A forum with a limited audience, requiring people to join before they
are able to receive the messages.

2. A central point of authority who decides who should receive the
messages.

3. An automatic system for distributing new messages to all current known
recipients.

This is indeed a useful system, but I'm not sure why you would use NNTP to
implement it, since at first glance it sounds like a mailing list. NNTP's
flood-fill algorithm is incredibly wasteful in this system, since it would
send the messages to loads of people who can't read them.

Encrypted mailing lists that work roughly the way that you describe are
already a thing, although instead of encrypting at the NNTP client, they
usually decrypt and re-encrypt at the mailing list host. I realize you
may view that as undesirable and want to instead encrypt at the client,
and that makes sense given your use case, but at the point that you're
already expecting a client to track user public keys, tracking email
addresses to which to send the messages is a trivial amount of additional
work.

I'm guessing that the appeal of NNTP in your design may be that you feel
like email addresses expose too much personal information about the
recipients? I'm a bit dubious of that belief, but I realize this is a
dearly-held belief in some quarters. So maybe the role of NNTP in this
model is something akin to the old anonymous remailer network? I guess
that would make sense; there are some systems like that where the point is
to waste so much resources that it's hard to find the signal in the noise,
as a way of defeating metadata analysis.

There have been a lot of proposals somewhat similar to this over the
years, and I've heard (but have never looked for myself) that this sort of
encrypted message stream is used from time to time in the binary groups.
It never sounded like something I would want to support as a server
administrator, so I've always been happy that normal binary filtering
discards all such messages.

--
Russ Allbery (eagle@eyrie.org) <https://www.eyrie.org/~eagle/>

Please post questions rather than mailing me directly.
<https://www.eyrie.org/~eagle/faqs/questions.html> explains why.

On Thu, 09 Nov 2023 09:11:12 -0800, Russ Allbery wrote:
> Bixby <bixby@sctb.ch> writes:

> If I understand this correctly, you have a forum with the following
> properties:
>
> 1. A forum with a limited audience, requiring people to join before they
> are able to receive the messages.

Yes.

Also, once joined, people can read only messages posted after they joined.

> 2. A central point of authority who decides who should receive the
> messages.

Yes and no.

There is a central point of authority who decides who can join - receive
messages - but once joined, the central point of authority is out of the
picture.

> 3. An automatic system for distributing new messages to all current
> known recipients.

This being NNTP.

> This is indeed a useful system, but I'm not sure why you would use NNTP
> to implement it, since at first glance it sounds like a mailing list.

Couldn't you say newsgroups are like mailing lists and question why
newsgroups exist?

The advantage is that NNTP is global and places a large number of groups/
mailing lists in one place. Accessibility and convenience.

> NNTP's flood-fill algorithm is incredibly wasteful in this system, since
> it would send the messages to loads of people who can't read them.

All news-servers would receive copies of all messages, but people (in the
sense of end-users of NNTP) would not; why subscribe to a group you cannot
read?

This I think though is a good point, and one I had not thought of.

On the other hand, most choices are about cost and benefit. Would adding
this functionality to NNTP contribute to a revival of use? in this day
and age of ubiquitous surveillance, perhaps it has considerable value.
Perhaps these costs are necessary to regain privacy, in its various forms
(such as privacy within a group, as posited here).

> I'm guessing that the appeal of NNTP in your design may be that you feel
> like email addresses expose too much personal information about the
> recipients?

No. I'm motivated by remembering how Usenet used to be, before it was
tracked. Public and private. That's the goal; to be able to emit
messages which only a given group can read.

> There have been a lot of proposals somewhat similar to this over the
> years,

I cannot imagine I'm the first to think of this, since I can think of it.

Hello Bixby,

I am not a very good reader/writer of English, so it will take time for
me to read all the discussion. Then, maybe my questions were already asked
and I apologize for that -- if that is the case, feel free to not respond
because I will read the answer later when I read all of the discussion.

Le 08/11/2023 21:01, Bixby a écrit :
>
> I would like to describe an enhancement to the NNTP protocol, with a view
> to peer review.
>
> # Rationale
>
> I began using Usenet in about 1994. It was a remarkable forum -
> possessing the property of being both public and yet private, as at that
> time no one was archiving posts.

I doubt that no one was archiving posts at that time, be it for their
private use.

However, for a publicly accessible archive, I am sure that it existed
already in 1995 :
<https://en.wikipedia.org/wiki/Google_Groups#Deja_News>
§
The Deja News Research Service was an archive of messages posted to Usenet
discussion groups, started in March 1995
§

> I may be wrong, but I think the property of being public and yet private
> nature of Usenet was special and of particular value.

In my humble opinion, the particular value of Usenet was (and still is)
its public and not centralized nature : as soon as an article is posted
on Usenet, it may be spread all over the world for anyone to see it.

> I would like to recreate that property of being public and yet private,
> which is exactly to say that posts can be read by and only by a given
> group of readers. The news-servers cannot read posts, nor can anyone
> outside of that group of readers - so no archiving by Google, or anyone
> else.

Because of what I said before, I disagree with the word "recreate" about
that very new property you are wanting to give to Usenet. In my (again)
humble opinion, a private mailing list would best suit your needs.

> # Design
>
> [...]>
> For a user to subscribe, they create a private-public key pair and provide
> the *public* key to the moderator.
>
> If their application is approved by the moderator, the public key is then
> distributed to all current members of the group.
>
> All members hold then the public key of all other members.

Ok.

> It is possible to encrypt messages using more than one public key.

You mean that a message encrypted with say 100 public keys could be decrypted
by the only knowing of *one* of the 100 corresponding private keys?

I am very curious of that. Do you have a web page which explains this mechanism?

Of course, you will not ask any newsreader to implement it, so it will be the
task of the moderator to receive the message in clear and encrypt it using the
100 public keys, before posting.

--
Olivier Miakinen

Le 09/11/2023 05:55, Doc O'Leary responded to Bixby :
>
>> It is possible to encrypt messages using more than one public key.
>>
>> When a member posts, the post is encrypted by the NNTP client with the
>> public keys of every existing member, and then posted.
>
> I’m no cryptography expert, but my understanding is that things aren’t
> generally done that way. Rather, the message is encrypted only once with
> a strong symmetric cipher, and then just that key is encrypted with the
> public keys of the intended recipients.

Ok, so each and every message would be sent in two parts, one being the
message itself encrypted with one key, the other being the list of
couples (member identity, key encrypted with its public key).

I don't think that I would ever be a member of such a group, where every
little message is completed with hundreds of useless stuff, just because
I will find one little information in this bunch of garbage... and where
I will have to decrypt each of these messages before even knowing if I am
interested by its contents!

A mailing list would much better do the task.

> [...]
>
> Everything you suggest still seems like it could be layered on top of the
> NNTP protocol as it already exists. People aren’t already regularly doing
> that because the result is far less useful than the existing public forum.

+1

--
Olivier Miakinen

Le 09/11/2023 11:25, Richard Kettlewell a écrit :
>
> [...] Even assuming the moderator is trustworthy, as the number of
> recipients grows, the probability that one of them is one of the group’s
> adversaries grows with it.

Yes, and as soon as such a member exists, he/she may decide to re-publish any
message he/she has received so far on a completely public alt.* newsgroup.

--
Olivier Miakinen

On Fri, 10 Nov 2023 12:38:38 +0100, Olivier Miakinen <om+news@miakinen.net> wrote:
>Le 09/11/2023 11:25, Richard Kettlewell a ecrit :
>> [...] Even assuming the moderator is trustworthy, as the number of
>> recipients grows, the probability that one of them is one of the group's
>> adversaries grows with it.
>
>Yes, and as soon as such a member exists, he/she may decide to re-publish any
>message he/she has received so far on a completely public alt.* newsgroup.

like a whistleblower... perhaps posting anonymously under a nom de guerre,
albeit that doesn't seem likely among peers discussing nntp server issues

For your reference, records indicate that
Bixby <bixby@sctb.ch> wrote:

> For the first point, by and large, I imagine users posting to all
> subscribers - trusting the moderator.

But why? Or, put another way, what real purpose does the moderator serve?
What real purpose does the encryption serve? With everyone just trusting
everyone, it seems like you’re introducing a lot of overhead that doesn’t
materially matter.

> prevent the subscriber in question from reading their posts.

But only directly. The very nature of discussion threads means messages
get quoted in whole or in part.

> There are many problems which can occur, but most never do.

By that same measure, I struggle to see the occurrences of the problem
you’re trying to solve for in this encryption scheme. Regardless, no
change is necessary in the NNTP protocol to accomplish it, nor does
“moderation” seem necessary. You’re welcome to experiment with a client
that posts encrypted messages and manages public keys to decrypt them.
Let us know how the interpersonal dynamics play out with those technical
measures in place.

--
"Also . . . I can kill you with my brain."
River Tam, Trash, Firefly

On Fri, 10 Nov 2023 12:31:16 +0100, Olivier Miakinen <om+news@miakinen.net> wrote:
>Le 09/11/2023 05:55, Doc O'Leary responded to Bixby :
>>> It is possible to encrypt messages using more than one public key.
>>> When a member posts, the post is encrypted by the NNTP client with the
>>> public keys of every existing member, and then posted.
>>
>> I'm no cryptography expert, but my understanding is that things aren't
>> generally done that way. Rather, the message is encrypted only once with
>> a strong symmetric cipher, and then just that key is encrypted with the
>> public keys of the intended recipients.
>
>Ok, so each and every message would be sent in two parts, one being the
>message itself encrypted with one key, the other being the list of
>couples (member identity, key encrypted with its public key).
>I don't think that I would ever be a member of such a group, where every
>little message is completed with hundreds of useless stuff, just because
>I will find one little information in this bunch of garbage... and where
>I will have to decrypt each of these messages before even knowing if I am
>interested by its contents!
>A mailing list would much better do the task.
>> [...]
>> Everything you suggest still seems like it could be layered on top of the
>> NNTP protocol as it already exists. People aren't already regularly doing
>> that because the result is far less useful than the existing public forum.
>+1

""

For your reference, records indicate that
Bixby <bixby@sctb.ch> wrote:

> Also, once joined, people can read only messages posted after they joined.

I have yet to hear why this is a desirable feature. There are indeed
certain contexts where “no history” is a feature, but topical discussions
that Usenet encourages benefit from FAQs and memes and other “timeless”
content.

I mean, you still need to chart out the use cases for these encrypted
groups. I’m hard pressed to imagine why I would join a group that has
I can’t “binge” in order to understand what it’s all about. For people
already in a group, it sounds like the ultimate form of Eternal September.

> Couldn't you say newsgroups are like mailing lists and question why
> newsgroups exist?

You absolutely could, and many do, and many no longer even know about
Usenet and still use mailing lists. The fundamental feature Usenet
provided was discoverability. That is less needed these days, and is
absolutely destroyed by using encryption.

> The advantage is that NNTP is global and places a large number of groups/
> mailing lists in one place. Accessibility and convenience.

Nah. The Internet has made the world small in a digital sense. Social
media has made a business out of putting information (and misinformation)
in everyone’s pockets. Usenet is already a hard sell. Usenet with
encryption is not an easier sale.

> All news-servers would receive copies of all messages, but people (in the
> sense of end-users of NNTP) would not; why subscribe to a group you cannot
> read?

But that’s the same reason that server admins would give for not accepting
those messages at all. Encryption is all the problems of binary groups on
steroids. This is actually where a change in the NNTP protocol would be
generally beneficial. Store-and-forward is inherently wasteful, and
really should be replaced by a demand-driven distribution of messages.
But other protocols already do that, so NNTP simply playing catch up isn’t
going to bring in a lot of new users.

> Perhaps these costs are necessary to regain privacy, in its various forms
> (such as privacy within a group, as posited here).

Certainly true, and I’m sure everyone here uses encryption in many other
contexts. But I still don’t see a compelling use case for a public forum
like Usenet.

> No. I'm motivated by remembering how Usenet used to be, before it was
> tracked. Public and private. That's the goal; to be able to emit
> messages which only a given group can read.

It was never private. Some messages simply got “lost” over time. That
still happens, but it happens less and less because storage has gotten so
cheap and spying on people has gotten so profitable. Encryption would
help “lose” messages to a certain degree, but it’s a tricky thing to make
usable on a system like Usenet. You can already dead-drop encrypted
messages in newsgroups, though, so nothing inherently needs to change
above the client level.

--
"Also . . . I can kill you with my brain."
River Tam, Trash, Firefly

On Fri, 10 Nov 2023 12:31:16 +0100, Olivier Miakinen wrote:

> Ok, so each and every message would be sent in two parts, one being the
> message itself encrypted with one key, the other being the list of
> couples (member identity, key encrypted with its public key).

No. Each message would be encrypted with every public key - such that the
private key of each of those public keys can decrypt the message - and the
encrypted text would be posted.

> I don't think that I would ever be a member of such a group, where every
> little message is completed with hundreds of useless stuff, just because
> I will find one little information in this bunch of garbage... and where
> I will have to decrypt each of these messages before even knowing if I
> am interested by its contents!

Decryption would be performed automatically by the news client. It would
hold your private key, and so would be able to do so.

On 2023-11-10 12:18, Olivier Miakinen wrote:
> Hello Bixby,
>
>> For a user to subscribe, they create a private-public key pair and provide
>> the *public* key to the moderator.
>>
>> If their application is approved by the moderator, the public key is then
>> distributed to all current members of the group.
>>
>> All members hold then the public key of all other members.
>
> Ok.
>
>> It is possible to encrypt messages using more than one public key.
>
> You mean that a message encrypted with say 100 public keys could be decrypted
> by the only knowing of *one* of the 100 corresponding private keys?
>
> I am very curious of that. Do you have a web page which explains this mechanism?

This is the basic behavior of most mail encryption systems, including
PGP and S/MIME, all he is really proposing could be done by integrating
them into NNTP clients such that there is a UI and database for
remembering the public keys of other members +/- personal distrusts.

>
> Of course, you will not ask any newsreader to implement it, so it will be the
> task of the moderator to receive the message in clear and encrypt it using the
> 100 public keys, before posting.
>

No, point was to add logic to newsreaders and use the UseNet servers for
distribution of encrypted posts and moderator announcements of
membership changes.

Personally, I find the entire plan counterproductive to the traditional
use of UseNet, though it may make sense as a means of keeping past
correspondence out of view of future meatspace contacts (such as future
employers).

One simplification would be for clients that trust the moderator's
invitations to encrypt to a group-wide public key, then a moderator run
bot will decrypt and re-encrypt everything to the known member public
keys. If posts contain a traditional expiry date, the reencryption bot
would also mail those articles directly to new members that join before
that date, but not to any later members (This is to give new members the
same view of recent discussions they would have gotten from plain text
newsgroups, but still get rid of "Google remembers everything forever").

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

Bixby <bixby@sctb.ch> writes:
> On Thu, 09 Nov 2023 09:11:12 -0800, Russ Allbery wrote:

>> This is indeed a useful system, but I'm not sure why you would use NNTP
>> to implement it, since at first glance it sounds like a mailing list.

> Couldn't you say newsgroups are like mailing lists and question why
> newsgroups exist?

Yes, exactly. Netnews has always been a weird way of distributing mailing
lists, if looked at from a particular angle.

What netnews provides over mailing lists is local caching and local
archiving using a much more convenient protocol than mailing list archives
(which are not standardized). Each site pays the cost of message
transmission and reception only once, no matter how many local users want
to read the message, and any local user can see all the recent messages,
as opposed to the normal mailing list situation where you can only see the
messages sent after you joined. That also gives you distributed
infrastructure, so that no one site is responsible for keeping the
"mailing list" going.

Netnews therefore makes sense primarily for topics that would otherwise be
very large mailing lists, which benefit from those features. Otherwise,
the message format is essentially identical and both mediums support
roughly the same features. (For example, the news reader I use is also my
email client; its handling of news and email is almost identical.)

Your system is getting rid of the two big advantages of netnews: the
people receiving the messages is limited, and archives are useless since
you can't read them until after you join. So it doesn't benefit from the
two primary features of NNTP.

It *does* arguably benefit from the distributed infrastructure, although
you still have the moderator point of failure. But I can see the argument
that the moderator is more easily replacable than a mailing list host.

I suppose the other advantage I can think of is that running a mail server
in this day and age is a giant pain in the ass because of spam filtering,
and running a news server is arguably easier, so you might get more people
willing to run news servers for an encrypted message network.

> On the other hand, most choices are about cost and benefit. Would
> adding this functionality to NNTP contribute to a revival of use? in
> this day and age of ubiquitous surveillance, perhaps it has considerable
> value.

It just feels simpler to use encrypted mail if you're not worried about
exposing email messages, although I suppose the flipside of netnews and
email being so similar is that you can pretty easily implement anything
with either. But the floodfill approach only seems warranted if it's
moderately likely that any site will have some readers.

--
Russ Allbery (eagle@eyrie.org) <https://www.eyrie.org/~eagle/>

Please post questions rather than mailing me directly.
<https://www.eyrie.org/~eagle/faqs/questions.html> explains why.

Olivier Miakinen <om+news@miakinen.net> writes:

> You mean that a message encrypted with say 100 public keys could be
> decrypted by the only knowing of *one* of the 100 corresponding private
> keys?

> I am very curious of that. Do you have a web page which explains this
> mechanism?

You generate a random symmetric encryption key (probably AES), and you
encrypt the body of the message in that. Then, for every recipient public
key, you perform a public key encryption of the symmetric encryption key
and append that block to the end (or start, whatever) of the message.

Any recipient with a matching private key of one of those public keys then
finds the block encrypted to their public key, does a public key
decryption of that block with their private key to recover the symmetric
key, and then uses the symmetric key to decrypt the message.

The size of the message therefore increases by the number of recipients,
but not by that much since the symmetric key is short. Usually the more
important bottleneck is that public key encryption is slow, so encrypting
to a whole bunch of public keys potentially gets a bit slow. However, for
the typical number of netnews posts someone sends, I doubt anyone would
really notice. Modern computers are very fast.

--
Russ Allbery (eagle@eyrie.org) <https://www.eyrie.org/~eagle/>

Please post questions rather than mailing me directly.
<https://www.eyrie.org/~eagle/faqs/questions.html> explains why.