From Newsgroup: rocksolid.nodes.help

--Signature=_Sun__15_Sep_2024_21_21_08_-0500_uFiXJVY/ICiJbrTE
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

I am looking at the BBS Mail scheme. This would be a steganographic hack. I=
t seems that two parties could encrypt their messages offline and then form=
at them to look identical to BBS Mail articles and exchange them through th=
e 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 distingui=
sh 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 Rock= solid peers and anonymous registrations. This could be set up to be signifi= cantly more robust and safe than mixmaster-type remailers, and done with th=
e 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 Sylph= eed. Once set up the users would not need to mess around with any command-l= ine or crazy config boo baz, netting pure foo.

One could have anonymous communication with the ease of Thunderbird, Sylphe= ed, 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 protec= tion 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 peer=
s. Then finally, there is another onion network shroud for the recipient cl= ient 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 ra= ndom 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.

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

--Signature=_Sun__15_Sep_2024_21_21_08_-0500_uFiXJVY/ICiJbrTE
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----

iHUEARYIAB0WIQRneuMjkp+P7n1uq4moad1ZYOZmFwUCZueWFAAKCRCoad1ZYOZm F1LIAP9RILU/dhyXpZaMhzd6tr1qkczjXVWyCggepPJnsKm0wwEA/E/VywzFbvjp BnXhECTUNMiqgYhYoXnwn06IwJPl7wM=
=NaCc
-----END PGP SIGNATURE-----

--Signature=_Sun__15_Sep_2024_21_21_08_-0500_uFiXJVY/ICiJbrTE--
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: rocksolid.nodes.help

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
--- Synchronet 3.21a-Linux NewsLink 1.2