I am looking at the BBS Mail scheme. This would be a steganographic hack. It seems that two parties could encrypt their messages offline and then format them to look identical to BBS Mail articles and exchange them through the newsgroup.

Would there be any tells or formatting from the Rocksolid Light server that would give this away or break the scheme or allow an observer to distinguish between a BBS Mail article composed offline?

If the offline encrypted articles are indistinguishable from those made by the server that would be useful, especially in a Tor network with many Rocksolid peers and anonymous registrations. This could be set up to be significantly more robust and safe than mixmaster-type remailers, and done with the ease of an email client. And a small CLI formatting and encryption script could be automated in some GUI email clients, such as Claws-Mail and Sylpheed. Once set up the users would not need to mess around with any command-line or crazy config boo baz, netting pure foo.

One could have anonymous communication with the ease of Thunderbird, Sylpheed, etc. yet very strong anonymity and unlinkability. The sender hop to the hidden onion service of the Rocksolid Peer is one layer of protection. The Rocksolid Peer's hop to another TOR hidden peer is another layer of protection from eavesdropping, and so on, to however many peers it takes to reach the recipient's peer--and the recipient could pull from any number of peers. Then finally, there is another onion network shroud for the recipient client pulling the messages from the encrypted BBS Mail newsgroup.

If the Message-ID and headers are sanitized and generic to not identify the origin peer, that would be even more crazy anonymous. The message could go from origin and be injected to multiple remote peers in random order at random timings, obfuscating origin even more.

Such a scheme is simpler than remailers with indistinctness of the offline BBS Mail compositions. Tell me if I lack something in this muse.

--
Byrl Raze Buckbriar . OCTADE . < https://octade.net >
Hacker Hotline . voice & SMS . (781) OCT-AGON
KeyOxide . < https://keyoxide.org/keyoxide0@octade.net >

On Mon, 16 Sep 2024 2:20:56 +0000, Byrl Raze Buckbriar wrote:

> I am looking at the BBS Mail scheme. This would be a steganographic
> hack. It seems that two parties could encrypt their messages offline and
> then format them to look identical to BBS Mail articles and exchange
> them through the newsgroup.
>
> Would there be any tells or formatting from the Rocksolid Light server
> that would give this away or break the scheme or allow an observer to
> distinguish between a BBS Mail article composed offline?

I see no reason a message could not be generated that would look exactly
like the rslight BBS Mail message.

> If the offline encrypted articles are indistinguishable from those made
> by the server that would be useful, especially in a Tor network with
> many Rocksolid peers and anonymous registrations. This could be set up
> to be significantly more robust and safe than mixmaster-type remailers,
> and done with the ease of an email client. And a small CLI formatting
> and encryption script could be automated in some GUI email clients, such
> as Claws-Mail and Sylpheed. Once set up the users would not need to mess
> around with any command-line or crazy config boo baz, netting pure foo.
>
> One could have anonymous communication with the ease of Thunderbird,
> Sylpheed, etc. yet very strong anonymity and unlinkability. The sender
> hop to the hidden onion service of the Rocksolid Peer is one layer of
> protection. The Rocksolid Peer's hop to another TOR hidden peer is
> another layer of protection from eavesdropping, and so on, to however
> many peers it takes to reach the recipient's peer--and the recipient
> could pull from any number of peers. Then finally, there is another
> onion network shroud for the recipient client pulling the messages from
> the encrypted BBS Mail newsgroup.

Rslight will just post the BBS Mail message to one particular group. How
it propagates depends on what it's 'remote' server does with it. Rslight
does not add or append to the Path: header, but it does add headers to
identify that it is a rslight server. These headers could of course be
added by anyone wanting to impersonate a rslight server.

> If the Message-ID and headers are sanitized and generic to not identify
> the origin peer, that would be even more crazy anonymous. The message
> could go from origin and be injected to multiple remote peers in random
> order at random timings, obfuscating origin even more.

By default a rslight messsage-id is a has of part of the message. This
can be changed in the code (not by config files). Same with headers
(requires code changes, which are not difficult).

You probably would enjoy discussing this with SugarBug here. Seems
similar to his interests.

If you come up with something you want to pursue specifically, we can
discuss code changes to handle it, but for now I just maintain what we
have (fix bugs, etc.). I never intended rslight to be a highly secure,
highly encrypted system, just a web interface to Usenet, but we have
grown to include BBS Mail (which is encrypted), so why not :)

We will always maintain the current system, which is accessible and
useful to the average web user, but no reason we can't add some more
secure comms underneath for other use cases.

--
Retro Guy