Retro Guy wrote:

> vga256 wrote:

>> Retro Guy wrote:

>>> Now I can get back to very slowly considering the best way to execute the Mail features. I believe I have the structure, now to implement piece by piece in a way that I hopefully don't need to make major changes to it.

>> Awesome. Site-to-site mail will be a game-changer. I'm excited about the technical side of it too, because I can learn a lot about how to properly cryptographically sign stuff, check keys against it, etc.

> I now have rslight setup to automatically create a server key, and make it available (it can be downloaded by a link). This key (not link) will reside in the same keyring as NoCeM keys, so the plan is that all rslight gpg is done in $config_dir/.gnupg . To manually manipulate keys in this keyring, change to the user that runs rslight, then set GNUPGHOME to $config_dir/.gnupg . Now you can work with keys manually using gpg.

> Right now $config_dir/.gnupg is hard coded, but we can change that if necessary.

I've created a config file for gpg (gpg.conf), like letsencrypt.conf. This file now handles GNUPGHOME, domain name, enable/disable creating gpg keys and whatever more is necessary.

Both inter-BBS messaging and nocem.php will depend on this config file.

I do plan to add some web based config in the future, which will really just modify these files, but for now I'm using files. I'd like to watch the direction of tomoBBS for a "look and feel" config system, and consider maintaining that standard.

Now back to working on messaging... (or a nap, not sure which I'll choose atm :)

--
Retro Guy

Awesome. Looking forward to seeing more of the progress you're making with this!

--
Posted on Rocksolid Light

On Sun, 23 Jul 2023 17:57:59 +0000
retro.guy@rocksolidbbs.com (Retro Guy) wrote:

> vga256 wrote:
>
> > LOL. I spoke too soon.
>
> > I *improperly* implemented your changes. If you can believe it, I
> > mistyped: if (!is_numeric($local))
>
> > and put in:
> > if (is_numeric($local))
>
> > which of course broke article numbering. With that stupid typo
> > fixed, it all works perfectly now. Thank you again for the hard
> > work refactoring this function.
>
> YAY! I'm glad it's working!
>
> Now I can get back to very slowly considering the best way to execute
> the Mail features. I believe I have the structure, now to implement
> piece by piece in a way that I hopefully don't need to make major
> changes to it.
>
> > Glad there is some value in these changes. While I'm (selfishly)
> > trying to make tomo its own thing, I hope that some of the
> > front-end stuff eventually makes its way into RSL.
>
> I do plan to implement, but not right away. I'd like to get Mail
> working, then consider the best way to add such features to the
> rslight fork. I'm not opposed to the userbase being in a sqlite db,
> but I do a lot of cross-auth with rslight for things like inn2,
> wordpress, apache2, etc. I have written scripts to allow these
> programs to authenticate against rslight, so I need to be careful to
> make sure they will still work with minor changes.

I would like to offer some thoughts for your consideration.

Consider replicating mixnet envelope encryption but instead of multiple
hops through a chain of random peers, a single hop with multiple
envelopes: sender, sending server, receiving server, recipient, and
optional secondary offline keys for sender and recipient.

This means the sender envelope encrypts the message first using the
recipient's public key, then the receiving server's public key, then
the sending server's public key. The sending server decrypts its
envelope, then re-encrypts and signs this payload of envelopes and
hands it to the receiving server, which decrypts its envelope and
stores the final payload for the recipient.

An option could be in the interface for each sender and recipient to
have two public keys: one public key based on a keypair automatically
generated and managed by the server for each user, and another keypair
generated securely by each user offline, so that the receiving server
cannot decrypt the final envelope, but only identify the recipient of
the envelope. Users would enable the second offline public key simply
by uploading it to the interface. Users choosing this option would be
responsible for operating PGP or some other encryption program for the
final envelope, as the server would actually have nothing to do with
it, just signing the secondary envelope keys.

In this sort of scheme the sending server cannot determine the
recipient user and the receiving server cannot determine the sending
user, but both servers know which server the message originates with,
and their respective user, so spam and harassment can be thwarted while
providing strong encryption and unlinkability in the face of
eavesdroppers.

On another track you could integrate YAMN techniques with the servers
but only allow access from registered user accounts, so that the web
interface would allow messages to be forwarded to the local YAMN
nymserver and mail server, and only exit to other nymservers (not
clearnet). You DO NOT want to enable any email exit to clearnet, as it
WOULD be seriously abused by trolls and cranks.

If there were more than two rslight servers in operation they could do
discovery so clients could do multi-hop payloads through a closed
YAMN-style network for the rslight peers. Instead of exiting to email
servers it could exit to a file queue in each user's account. The
sending server would not know the destination but the destination
server would know the sending server IF the recipient disclosed that
through an abuse report. Otherwise sender and recipient would remain
cryptographically hidden, yet some measure of abuse control would be
available to the user filing an abuse report with the offending payload
copied into the report.

--
SugarBug | https://sybershock.com

Syber Shock wrote:

> On Sun, 23 Jul 2023 17:57:59 +0000
> retro.guy@rocksolidbbs.com (Retro Guy) wrote:

>> vga256 wrote:
>>
>> > LOL. I spoke too soon.
>>
>> > I *improperly* implemented your changes. If you can believe it, I
>> > mistyped: if (!is_numeric($local))
>>
>> > and put in:
>> > if (is_numeric($local))
>>
>> > which of course broke article numbering. With that stupid typo
>> > fixed, it all works perfectly now. Thank you again for the hard
>> > work refactoring this function.
>>
>> YAY! I'm glad it's working!
>>
>> Now I can get back to very slowly considering the best way to execute
>> the Mail features. I believe I have the structure, now to implement
>> piece by piece in a way that I hopefully don't need to make major
>> changes to it.
>>
>> > Glad there is some value in these changes. While I'm (selfishly)
>> > trying to make tomo its own thing, I hope that some of the
>> > front-end stuff eventually makes its way into RSL.
>>
>> I do plan to implement, but not right away. I'd like to get Mail
>> working, then consider the best way to add such features to the
>> rslight fork. I'm not opposed to the userbase being in a sqlite db,
>> but I do a lot of cross-auth with rslight for things like inn2,
>> wordpress, apache2, etc. I have written scripts to allow these
>> programs to authenticate against rslight, so I need to be careful to
>> make sure they will still work with minor changes.

> I would like to offer some thoughts for your consideration.

> Consider replicating mixnet envelope encryption but instead of multiple
> hops through a chain of random peers, a single hop with multiple
> envelopes: sender, sending server, receiving server, recipient, and
> optional secondary offline keys for sender and recipient.

I appreciate the suggestions. I've pretty much planned out by now how
I'd like to implement mail, but always open to hearing other ideas.

> On another track you could integrate YAMN techniques with the servers
> but only allow access from registered user accounts, so that the web
> interface would allow messages to be forwarded to the local YAMN
> nymserver and mail server, and only exit to other nymservers (not
> clearnet). You DO NOT want to enable any email exit to clearnet, as it
> WOULD be seriously abused by trolls and cranks.

> If there were more than two rslight servers in operation they could do
> discovery so clients could do multi-hop payloads through a closed
> YAMN-style network for the rslight peers. Instead of exiting to email
> servers it could exit to a file queue in each user's account. The
> sending server would not know the destination but the destination
> server would know the sending server IF the recipient disclosed that
> through an abuse report. Otherwise sender and recipient would remain
> cryptographically hidden, yet some measure of abuse control would be
> available to the user filing an abuse report with the offending payload
> copied into the report.

My plan is to basically use ideas from the BBS realm of the past, and bring
it somewhat up to date as far as security.

Passing mail along with messages was common with BBS data sharing, but in
some instances, the mail was completely available for all sysops to read, as
long as it passed through their server. I'd like to continue use the same
data network for messages and mail, and just make the mail a bit more private.

What I'm not trying to accomplish is creating a super secure/anonymous network.
If a user has a need for such secure anonymity, there is already better software
out there for them to use than I could ever hope to write.

The level of encryption (what to encrypt/sign) I plan to implement is for
general privacy and security. The use of such should be separated from the user.
I don't want to create a system for only encryption savvy users. I want it to
be generally private for the general user. I wouldn't expect the end user to
even be aware, or care so much about how it works, just use it.

Systems exist such as I2P, Freenet, Tor, mix networks, anon remailers etc., and
there is an audience for these networks. I don't see the general rslight user
being such.

--
Retro Guy

I'm enjoying reading through these different options for cryptographic privacy.

> The level of encryption (what to encrypt/sign) I plan to implement is for
> general privacy and security. The use of such should be separated from the user.
> I don't want to create a system for only encryption savvy users. I want it to
> be generally private for the general user. I wouldn't expect the end user to
> even be aware, or care so much about how it works, just use it.

FWIW, this is exactly the level of privacy sophistication I desire as well for Tomo.

--
Posted on Rocksolid Light

On Mon, 24 Jul 2023 21:38:48 +0000
vga@vga256.com (vga256) wrote:

> I'm enjoying reading through these different options for
> cryptographic privacy.
>
> > The level of encryption (what to encrypt/sign) I plan to implement
> > is for general privacy and security. The use of such should be
> > separated from the user. I don't want to create a system for only
> > encryption savvy users. I want it to be generally private for the
> > general user. I wouldn't expect the end user to even be aware, or
> > care so much about how it works, just use it.
>
> FWIW, this is exactly the level of privacy sophistication I desire as
> well for Tomo.

If you employ YAMN/Mixmaster techniques, you can have two modes
depending on how many peers are available. If only the destination peer
is available then the first suggested idea of a single, direct hop could
be programmatically chosen. If multiple available peers are discovered
and verified as operational, then the YAMN/Mixmaster techniques can be
employed to chain multiple peer hops for better origin/destination
obfuscation.

With at least one non-hostile peer, the first method prevents the
sending server sysop from knowing the specific recipient on the
destination peer. With 3 or more peers, the sending server sysop cannot
even discern which server the message is destined for.

Retro Guy is right to want the whole process to be transparent to the
user. This is why I suggest secondary keys being optional, for advanced
users who want paranoid privacy levels. Everything else should be
automated under the hood, otherwise people won't use it because nobody
likes friction.

All of your envelope encryption and routing can be done with GPG,
OpenSSL, and tools like socat, netcat, ssh, s_client, telnet, nncp,
uucp, torrent, onioncat, garlicat, and the like, so that you do not need
to write a pile of complicated socket and server code. This will allow
you to just focus on the methods of envelope encryption and routing the
payloads from one server to the next.

You can even simplify it by passing encrypted messages via NNTP to a
non-public newsgroup on another peer, then that peer would sync with
other peers. When it finally syncs to the recipient peer, that peer
will try to decrypt it using its public key. If this decrypt is
successful then the destination username and key ID would be discovered
by that server, and it would know which inbox to place the final
envelope. Then the end user would download it and decrypt. This method
is similar to how alt.anonymous.messages is used, except users don't
need to download all the messages. Instead, users are able to download
only the messages destined for their account. This doesn't do much to
unlink parties from sysop view, but it prevents any eavesdropper from
linking them.

I wish I could get serious funding so I didn't have to work for a
living. I would love to make a full-time job out of building some truly
user-friendly and secure, distributed messaging systems. If I had the
time I could design it as simple to use as email but much more secure,
spamless, and censorship resistant. But I have to pay the tax man
and the utility companies and the insurance man, so hi ho, hi ho, off to
work I go.

One more thought: onioncat and garlicat (https://www.onioncat.org/).
They allow building custom network topologies via tor and i2p. Also I
believe nncp has a tor compatibility layer. There are many ways to skin
a onion.

--
SugarBug | https://sybershock.com

Retro Guy wrote:

> Retro Guy wrote:

>> vga256 wrote:

>>> Retro Guy wrote:

>>>> Now I can get back to very slowly considering the best way to execute the Mail features. I believe I have the structure, now to implement piece by piece in a way that I hopefully don't need to make major changes to it.

>>> Awesome. Site-to-site mail will be a game-changer. I'm excited about the technical side of it too, because I can learn a lot about how to properly cryptographically sign stuff, check keys against it, etc.

>> I now have rslight setup to automatically create a server key, and make it available (it can be downloaded by a link). This key (not link) will reside in the same keyring as NoCeM keys, so the plan is that all rslight gpg is done in $config_dir/.gnupg . To manually manipulate keys in this keyring, change to the user that runs rslight, then set GNUPGHOME to $config_dir/.gnupg . Now you can work with keys manually using gpg.

>> Right now $config_dir/.gnupg is hard coded, but we can change that if necessary.

> I've created a config file for gpg (gpg.conf), like letsencrypt.conf. This file now handles GNUPGHOME, domain name, enable/disable creating gpg keys and whatever more is necessary.

> Both inter-BBS messaging and nocem.php will depend on this config file.

> I do plan to add some web based config in the future, which will really just modify these files, but for now I'm using files. I'd like to watch the direction of tomoBBS for a "look and feel" config system, and consider maintaining that standard.

> Now back to working on messaging... (or a nap, not sure which I'll choose atm :)

Here is an example KEY sharing post (to follow). RSLight can now autogenerate the key,
and also autogenerate the posts on a regular schedule. I would think every 30 days, but
it is hardcoded that you can not post to the same newsgroup more than once per day.

A receiving RSLight install will be able to read this post and take action based on
the system admin's configured preferences.

Here's the sample post (It is a real autogenerated message):

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

******************************************************
THIS IS A TEST POST! DO NOT USE THIS FOR A REAL SITE!
******************************************************

You may use this to import the public key for rslight.local.
This message is automatically generated by rslight@rslight.local.

This message was signed using the following key:
9D89 9B3B 8435 2E09 E8D9 D036 E38A BEC3 199A 6E95

The GPG key needed to verify the signature of messages
issued by rslight@rslight.local is available at:
rslight.local/tmp/server_pubkey.txt

For information contact admin@novabbs.com.

@@BEGIN MAILKEY HEADERS
Version: 0.8.5
From: rslight@rslight.local
Notice-ID: 7bf282c17de32e48
@@BEGIN MAILKEY BODY
Key: 9D89 9B3B 8435 2E09 E8D9 D036 E38A BEC3 199A 6E95
Location: rslight.local/tmp/server_pubkey.txt
Domain: rslight.local
@@END MAILKEY BODY

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

iQGzBAEBCgAdFiEEnYmbO4Q1Lgno2dA244q+wxmabpUFAmTANEYACgkQ44q+wxma
bpXtcwv9FSBLJ8vxRxuKq7hh3bkZs+uN1wPW8SbYQD8a7TzEGds9Q8spWHvXB+C3
wsWN/sxREEoF8OZxR0bquyqqm6a1VVredDfz+pl5E8cPegHDWj/vbiqFROvhQmZc
g3F3Q+PCcs0r+ZzPx8XVa/IGv2uYCjvOUOyL88kRPdhBLxUF+Nd5HPx3kM7R83vi
5dFpq5C5OJURMWr73kif866+ERLQH0a+vswdQA99lB6dT6ktPGGqj6HCeZct/hLs
eSH7aKXI9VBvxirFCTr/F1mJbMqTBQigC2aA8xvcpnNZbbDKAYYjVpe46ZeFD2Vu
qjrVngnPfEwtoQMbVxmFTLSBy28DETSLroivnSPlK0ohFODgir/bxPKbGBiWraTy
FSHtko12p3JS29eu8m5fYNnFkpXqcf1jBQLKlub6KRNWjwlrbOb/XyxeTv70NL4F
vR6Nav4BaNmhqcDGIaelpZ3Bp7NNh0bb2tYczv+Tk7EmQIDRbbNRzUjd/sej9yyi
VybBFX9I
=GwWH
-----END PGP SIGNATURE-----

--
Retro Guy

Retro Guy wrote:

> I do plan to add some web based config in the future, which will really just modify these files, but for now I'm using files. I'd like to watch the direction of tomoBBS for a "look and feel" config system, and consider maintaining that standard.

Cool. Working on that more this week. I've been redesigning the admin interface to resemble something more user-friendly, with options for both single and bulk operations. Once I've got a sense for how the messaging stuff works, I'm sure I'll be able to produce some configuration user interfaces.

--
Posted on Rocksolid Light

vga256 wrote:

> Retro Guy wrote:

>> I do plan to add some web based config in the future, which will really just modify these files, but for now I'm using files. I'd like to watch the direction of tomoBBS for a "look and feel" config system, and consider maintaining that standard.

> Cool. Working on that more this week. I've been redesigning the admin interface to resemble something more user-friendly, with options for both single and bulk operations. Once I've got a sense for how the messaging stuff works, I'm sure I'll be able to produce some configuration user interfaces.

Looking forward to that. Your front end skills far surpass mine :)

Currently, I'm doing some tweaking and cleanup on pgp verification, which will also apply to nocem. I'm standardising the code between all gpg related functions and hopefully improving the code.

Once I'm satisified with the gpg mods, I'll continue with Mail features, which are coming along nicely. Slowly, but nicely, it's quite a bit of code addition and trying to get it (almost) right the first time.

--
Retro Guy

Retro Guy wrote:

> vga256 wrote:

>> Retro Guy wrote:

>>> I do plan to add some web based config in the future, which will really just modify these files, but for now I'm using files. I'd like to watch the direction of tomoBBS for a "look and feel" config system, and consider maintaining that standard.

>> Cool. Working on that more this week. I've been redesigning the admin interface to resemble something more user-friendly, with options for both single and bulk operations. Once I've got a sense for how the messaging stuff works, I'm sure I'll be able to produce some configuration user interfaces.

> Looking forward to that. Your front end skills far surpass mine :)

> Currently, I'm doing some tweaking and cleanup on pgp verification, which will also apply to nocem. I'm standardising the code between all gpg related functions and hopefully improving the code.

> Once I'm satisified with the gpg mods, I'll continue with Mail features, which are coming along nicely. Slowly, but nicely, it's quite a bit of code addition and trying to get it (almost) right the first time.

gpg mods are working great. nocem.php is more "accurate" now in verifying signatures. (It leaned false negative before, or false NOT VERIFIED).

All this has let me to tweak some other code in spoolnews.php, not related to gpg, but needing some work. I'll finish that up and commit, then get back to Mail features (next is receiving mail notices).

The commits are in a local branch, so they won't show in github atm.

--
Retro Guy

Retro Guy wrote:

> Passing mail along with messages was common with BBS data sharing, but in
> some instances, the mail was completely available for all sysops to read, as
> long as it passed through their server. I'd like to continue use the same
> data network for messages and mail, and just make the mail a bit more private.

This is the kind of thing I wish to avoid:

> ca> hi, i was wondering what the difference between multi-relay chat and irc
> ca> is? they seem about the same

> MRC's protocol is incredibly poor quality. i would recommend using an IRC door like MannIRC or the one in Synchronet and pointing it at irc.synchro.net

> iirc MRC sends all the private messages to absolutely everyone and the client decides to show them or not. so a custom client could just watch everything everyone says.

https://www.rocksolidbbs.com/computers/article-flat.php?id=1280&group=alt.bbs.synchronet#1280

General privacy. Don't discuss your plans to overthrow your current dictator using it :)

--
Retro Guy

Retro Guy wrote:

> Once I'm satisified with the gpg mods, I'll continue with Mail features, which are coming along nicely. Slowly, but nicely, it's quite a bit of code addition and trying to get it (almost) right the first time.

Finally working out proper decryption and signing for target server to verify who (what server) is the sender accurately.

1. Encrypt for the target only, so only the target can decrypt the post.

2. Sign with source server key, so target can verify who sent it.

Number 1 is complete and working fine.

Number 2 is working, but testing it thoroughly to make sure I'm not missing something.

Posting mail messages is easy and handling the incoming, verified mail is not a problem, as by that point it's just an array to deal with. No problem.

The most difficult parts are what I'm working on now, and I'm about 80% done with them.

I will merge the non-Mail related commits to master hopefully later today, and just leave Mail features in the local branch until more complete.

--
Retro Guy

I have sent two posts to rocksolid.shared.test that demonstrate the format of the two types of post.

@@RSL MAILKEY notice is for distributing your public key so other sites can link with you.

@@RSL BBSMAIL notice is actual Mail being sent. This should only be able to be decrypted by the target site. It is also signed, so it can be checked that it really came from the site it says itt came from.

The format of these posts is important so as to allow rslight to read them and act on the contents automatically.

--
Retro Guy

Encrypted messaging looking great so far.

I'm rewriting the front end for threaded article display for the next few days. This appears to be some of the oldest code in the project, probably from Florian, and it is absolutely gnarly.

--
Posted on Rocksolid Light

vga256 wrote:

> Encrypted messaging looking great so far.

> I'm rewriting the front end for threaded article display for the next few days. This appears to be some of the oldest code in the project, probably from Florian, and it is absolutely gnarly.

Lol, that's exactly right. When I first started with Newsportal, I needed to get it working with php 5, and had to modify code of course. After that, I wasn't sure I wanted to continue :)

I will say that his code does work, it's not bad code, just different than what I'm used to. Some of it I'm still not sure what it does.

--
Retro Guy

vga256 wrote:

> I'm rewriting the front end for threaded article display for the next few days.

There is a var in config.inc.php to sort by threads: $thread_articles=true;

But I think you're probably working on something more useable than that. That var will simply list articles by thread, and you can't find the latest articles, so I don't use it.

Just letting you know it's there, so there is code in Newsportal to do some threading (which I'm sure you already found).

BTW, have you seen Newsportal? rslight is quite different in appearance. Here is a link to yamo's fork, which he's done a nice job keeping it up to date with PHP:
https://news2web.pasdenom.info/thread.php?group=local.general

He does appear to think that using a db in rslight makes it complicated. Most likely thinking of having to setup mysql or something, which of course, sqlite is just transparent:

> I'm using the old NewsPortal (updated for PHP8 and 7) wich is simplier (no database).

Anyway, I'm glad to see him keeping Newsportal alive in it's original form :)

--
Retro Guy

vga256 wrote:

> Encrypted messaging looking great so far.

Here's where we are at right now:

During this process, I have made a few minor, non-critical changes to spoolnews.php and send.php. I will post the mods in the commits thread later, but they are not critical.

For Mail. Some complete, some not:

Done: RSLight now will automatically generate it's PGP key, make the key available via the web, and automatically post a signed message with all the data to import the key for other sites.

Partial: RSLight can now automatically generate an encrypted and signed message including a mail post for another site, and only that other site should be able to decrypt the post. Generation of the post is complete, as well as automatically posting it, but linking that task to mail.php is not complete yet.

Done: RSLight will see the incoming posts as they arrive, and copy them to where they can be dealt with. The messages are then inspected, signatures checked, checked for integrity, and then prepared for import. Just as with the previous, mail.php is not yet linked to actually post the mail to the user. That is still to be completed. Incoming KEY notices are checked against the existing keyring, and "handled" based on whether we already have the key or not.

A couple of questions on how we might agree on the best way to handle a couple of things:

I hesitate to make target addresses look like 'user@www.rocksolidbbs.com', as it looks too much like an email address. We can do this, but do we want to?

I'm considering a drop down list to the right of 'To: ' when sending a message, where the list contains all the 'target' sites we know about. This also avoids the problem of typos in server names.

I'm avoiding the use of aliases for sites, as this opens the door to spoofing. My thinking is that the actual domain MUST be part of the target name, and that domain MUST be where the key is available online. They must match.

Next, importing a key from a newsgroup message post '@@RSL MAILKEY notice' can easily be done automatically. I'm at the point in the code to write that right now, but do I want to?

Would it be safer to log this info somewhere for the admin to easily find and deal with manually?

Do we make either of these methods available by a config option?

Thoughts? Ideas? Criticisms? (nah, just thoughts and ideas :)

--
Retro Guy

> Just letting you know it's there, so there is code in Newsportal to do some threading (which I'm sure you already found).

Yup, found all those earlier. As you suspected I'm working on something a little more robust. The implementation I'm working on comes out of Stephan Soller's NNTP-Forum, which has some fantastic UI choices. Here's how it works:
https://tomo.dialup.cafe/threading_example.png

Each article is itself visibly threaded with a 'hide/show all replies in this part of the tree' button on the left. This is closer to reddit's style of threading, and makes it easier for users to understand what part of the tree they're in (i've never liked tree maps).

Unfortunately, the threading code and the article code are in two separate places, and were never meant to co-exist. I'm rewriting parts of threads.php to allow it to pump out articles as it traverses the three. I *hate* recursive functions D:

> BTW, have you seen Newsportal? rslight is quite different in appearance. Here is a link to yamo's fork, which he's done a nice job keeping it up to date with PHP:
> https://news2web.pasdenom.info/thread.php?group=local.general

Wow! This is my first time seeing it. It almost replicates the late 2000's experience of reading a www listserv :)

> He does appear to think that using a db in rslight makes it complicated. Most likely thinking of having to setup mysql or something, which of course, sqlite is just transparent:

I can understand the hesitation myself. I was all for flat-files, until I realized how many relational calls I wanted to make to handle user privileges and let them do things like "delete only my messages" or "delete only messages that came from people with role X".

--
Posted on Rocksolid Light

Retro Guy wrote:

> I hesitate to make target addresses look like 'user@www.rocksolidbbs.com', as it looks too much like an email address. We can do this, but do we want to?

This is a tough one, and I totally appreciate the potential UX pitfalls here. After using mastodon and lemmy and a bunch of other activitypub stuff that uses the server.name/@user convention, I really, really dislike it. (The same can be said for reddit's reddit.com/u/username convention). It's confusing for people, difficult to remember, and runs against about 40 years of computer history. I honestly think user@server.com is the right choice - it's simple, it's clear, and everyone already understands the syntax.

There's nothing wrong with letting users accidentally e-mail someone with an RSL address and getting back an undeliverable message :)

> I'm considering a drop down list to the right of 'To: ' when sending a message, where the list contains all the 'target' sites we know about. This also avoids the problem of typos in server names.

I need to give this one some more thought, but my immediate suspicion is that this might be overly restrictive. I'm thinking of the situation where the person gets an e-mail/discord/facebook/usenet message that says "send me a message on RSL, user@someplace.com". The user goes to hammer out a message on the server, and that domain isn't in the dropdown list, and there's no way of adding new target sites to it. I say - leave it as a textbox, and let users make typos on their own.

(That in itself brings up a technical problem, target site discovery, that we can figure out later of course!)

> I'm avoiding the use of aliases for sites, as this opens the door to spoofing. My thinking is that the actual domain MUST be part of the target name, and that domain MUST be where the key is available online. They must match.

100% agreement.

> Next, importing a key from a newsgroup message post '@@RSL MAILKEY notice' can easily be done automatically. I'm at the point in the code to write that right now, but do I want to?
> Would it be safer to log this info somewhere for the admin to easily find and deal with manually?

Are there any actual risks to importing keys, aside from having a massive keychain?

> Do we make either of these methods available by a config option?

Seems reasonable to me. My suggestion is - make key import automatic, but provide the admin with an easy way of listing target sites and deleting any keys they don't want on the keychain. Or better - a blocklist for keys from target sites they do not ever want to grab keys from?

--
Posted on Rocksolid Light

vga256 wrote:

> Retro Guy wrote:

>> I hesitate to make target addresses look like 'user@www.rocksolidbbs.com', as it looks too much like an email address. We can do this, but do we want to?

> This is a tough one, and I totally appreciate the potential UX pitfalls here. After using mastodon and lemmy and a bunch of other activitypub stuff that uses the server.name/@user convention, I really, really dislike it. (The same can be said for reddit's reddit.com/u/username convention). It's confusing for people, difficult to remember, and runs against about 40 years of computer history. I honestly think user@server.com is the right choice - it's simple, it's clear, and everyone already understands the syntax.

> There's nothing wrong with letting users accidentally e-mail someone with an RSL address and getting back an undeliverable message :)

Ok, I agree... I had considered user/www.rocksolidbbs.com and such, but I think you are correct that it's better to use something people are already used to.

The file 'gpg.conf' is where domain name and such is configured, so I'll need to add a good bit of comments in there to help an admin pick the best name they can (if rocksolidbbs.com has the key accessible, then use that without the www. Stuff like that)

The important part is that the domain '@example.com' must have the key available at 'example.com/pubkey/server_pubkey.txt'.

>> I'm considering a drop down list to the right of 'To: ' when sending a message, where the list contains all the 'target' sites we know about. This also avoids the problem of typos in server names.

> I need to give this one some more thought, but my immediate suspicion is that this might be overly restrictive. I'm thinking of the situation where the person gets an e-mail/discord/facebook/usenet message that says "send me a message on RSL, user@someplace.com". The user goes to hammer out a message on the server, and that domain isn't in the dropdown list, and there's no way of adding new target sites to it. I say - leave it as a textbox, and let users make typos on their own.

> (That in itself brings up a technical problem, target site discovery, that we can figure out later of course!)

Yes. The more time I thought about it, the more I lean toward automated. If a user, for example tries to send to 'user@example.com', and we don't have the key, we can automatically try to fetch it and send the mail. This would be transparent to the user and the mail should succeed. Once that happens, we now have this key in our keyring for future use, and we can now also receive from that site.

We would log all this stuff so the admin knows what is going on.

>> Next, importing a key from a newsgroup message post '@@RSL MAILKEY notice' can easily be done automatically. I'm at the point in the code to write that right now, but do I want to?
>> Would it be safer to log this info somewhere for the admin to easily find and deal with manually?

> Are there any actual risks to importing keys, aside from having a massive keychain?

The more I thought about it, the more I think automation is the way to go. We can add an option to disable this, but by default let it just happen. If retrieving or installing a key fails, send a notification to the admin.

--
Retro Guy

On Sat, 29 Jul 2023 17:13:17 +0000
vga@vga256.com (vga256) wrote:

> Are there any actual risks to importing keys, aside from having a
> massive keychain?

Yes, there are risks, but aside from using a certificate authority or
letsencrypt there are other simpler options.

1. At your registrar or DNS server add a TXT record with the public
signing key of the server. Don't set the DNS TTL too low since that key
should rarely if ever change. Peers can $> dig for that record with DNS
over https or and that is a strong method of authentication for the key.
Paranoids can $> dig multiple DNS servers to see if they all match.
This way you avoid trusting a certificate authority and instead are
trusting your DNS server or registrar. This would probably be more
secure if your DNS is with a third party such as your registrar. If
your DNS is on the same server as your rslight install, any breach pwns
your DNS and the attacker can replace the TXT record with his key.

2. You can use the signing key in the DNS TXT record to sign and
authorize sub keys and other datas besides keys. Then cold store the
private key half of the DNS TXT key so it is not even on the server.
This way if a server-side signing key gets revoked you can revoke it
over the air gap and never expose your base private key to possible
exfiltration.

3. You can use letsencrypt, then sign your lets encrypt key with a DNS
TXT record, or just push a copy of the letsencrypt public key to replace
the TXT record each time letsencrypt updates the keys.

3. I would go the extra mile by either skipping certificate authorities
or using them as a backup method only. Then I would encrypt the DNS TXT
private key, and cold store it encrypted only. Then I would print out a
unencrypted version of it, and store the printout in a safe, or even a
mason jar buried under a cow patty in the back 40.

It is gratifying to see some serious work being done on the secure
messaging front. Sadly now that things got bumping on development I had
to get busy with work and now I don't have time to play! If any ideas
occur to me I will jot them down until next time I check messages.
Happy hacking!

--
SugarBug | https://sybershock.com

Syber Shock wrote:

> On Sat, 29 Jul 2023 17:13:17 +0000
> vga@vga256.com (vga256) wrote:

>> Are there any actual risks to importing keys, aside from having a
>> massive keychain?

> Yes, there are risks, but aside from using a certificate authority or
> letsencrypt there are other simpler options.

> 1. At your registrar or DNS server add a TXT record with the public
> signing key of the server.

The idea of using a DNS TXT record is a good one. I have considered it,
but wonder how many admins will have access to modifying their DNS.
Also, if the key is only available via the domain, is it more secure, as
you are still depending on the domain name.

> 3. I would go the extra mile by either skipping certificate authorities
> or using them as a backup method only. Then I would encrypt the DNS TXT
> private key, and cold store it encrypted only. Then I would print out a

Do you really mean putting the private key in a TXT record? Why would you
place the private key anywhere that is available, even encrypted?

> It is gratifying to see some serious work being done on the secure
> messaging front. Sadly now that things got bumping on development I had
> to get busy with work and now I don't have time to play! If any ideas
> occur to me I will jot them down until next time I check messages.
> Happy hacking!

Don't you hate when work gets in the way of things?

Anyway, glad to see you here and hope you get the chance to check in soon!

--
Retro Guy

On Sun, 30 Jul 2023 04:09:02 +0000
retro.guy@rocksolidbbs.com (Retro Guy) wrote:

> Syber Shock wrote:
>
> > On Sat, 29 Jul 2023 17:13:17 +0000
> > vga@vga256.com (vga256) wrote:
>
> >> Are there any actual risks to importing keys, aside from having a
> >> massive keychain?
>
> > Yes, there are risks, but aside from using a certificate authority
> > or letsencrypt there are other simpler options.
>
> > 1. At your registrar or DNS server add a TXT record with the public
> > signing key of the server.
>
> The idea of using a DNS TXT record is a good one. I have considered
> it, but wonder how many admins will have access to modifying their
> DNS. Also, if the key is only available via the domain, is it more
> secure, as you are still depending on the domain name.

I actually trust my registrar more than the cert authorities. I trust
user-managed openssl and PGP ed25519 keys more than the cert authority
chain, if properly managed. Of course part of that is the fact that my
registrar has three-factor authentication so it would require a
nation-state actor with serious motivation and a warrant to get the
registrar to tamper with that and insert a malicious record. And the
moment they did my monitor scripts would detect the change and I would
know about it PDQ.

As for admins modifying their DNS, I would strongly suggest they get
and manage their own domain. I've seen a project go south because
someone else owned the domain and provided free hosting for it, only to
lock people out on a whim.
> > 3. I would go the extra mile by either skipping certificate
> > authorities or using them as a backup method only. Then I would
> > encrypt the DNS TXT private key, and cold store it encrypted only.
> > Then I would print out a
>
> Do you really mean putting the private key in a TXT record? Why would
> you place the private key anywhere that is available, even encrypted?

No, I mean the corresponding private key. The private key corresponding
to the DNS TXT record key is what I am referring to. In the DNS TXT
record is a public key, and it has a private key. That key pair should
be generated offline, then the private key should be encrypted on a
encrypted sneakernet box.

The private key goes in cold storage and is not on any network
connected device, except one air-gapped box strongly encrypted. It is
the public key that goes in the TXT record. This way the root signing
key never rests on a network-connected device, so if any subkey is
compromised, or record or certificate gets spoofed, the root key can be
used to send revokes to the network and establish new public sub-keys.

You could even go full bonzo and use a Shamir-like scheme with multiple
root keys and require a percentage of signatures for a change to be
valid. Then store those private keys in cold storage in separate
locations. It depends on the level of paranoia required. For a
discussion forum that amount of paranoia is unnecessary. But if you
were using it to organize world domination or a coup against Caesar or
collaborate with moon men to overthrow the earth dictatorship, then
paranoid would be good.
> > It is gratifying to see some serious work being done on the secure
> > messaging front. Sadly now that things got bumping on development I
> > had to get busy with work and now I don't have time to play! If any
> > ideas occur to me I will jot them down until next time I check
> > messages. Happy hacking!
>
> Don't you hate when work gets in the way of things?

Amen. When I became a man I learned that I can still play with rubber
ducky. His beak goes in the slot on computer.
> Anyway, glad to see you here and hope you get the chance to check in
> soon!

I will see you on the flip-flop.

FYI: nostr has some ideas for secure message exchange.

Downside: Public key linked to IP at the peer level. Using Tor solves
this.

https://nostr-resources.com/

[copypasta]

nostr’s design is very basic:

There are two components: clients and relays. Each user runs a client.
Anyone can run a relay. Every user is identified by a public key. Every
post is signed. Every client validates these signatures. Clients fetch
data from relays of their choice and publish data to other relays of
their choice. A relay doesn’t talk to another relay, only directly to
users.

To use nostr, you need a key and a client.

Everybody runs a client. It can be a native client, a web client, etc.
To publish something, you write a post, sign it with your key and send
it to multiple relays (servers hosted by someone else, or yourself).

To get updates from other people, you ask multiple relays if they know
anything about these other people.

Anyone can run a relay. A relay is very simple and dumb. It does
nothing besides accepting posts from some people and forwarding to
others.

Relays don’t have to be trusted. Signatures are verified on the client
side.

Relays are dumb servers that you can leave behind at any time (so they
can’t turn evil). You need to connect your client to a relay for it to
work. There are many relays & you can run your own.

Privacy #
There are multiple privacy issues when it comes to using nostr.

Your IP address is exposed to the relays you connect to, so consider
using a VPN or similar. Some clients also support connecting via Tor.
Tor nostr relays exist, but not all clients support Tor nostr relays.

Relays also know which public keys you are requesting, meaning your
public key will be tied to your IP address.

[/copypasta]

--
SugarBug | https://sybershock.com

Syber Shock wrote:

> On Sun, 30 Jul 2023 04:09:02 +0000
> retro.guy@rocksolidbbs.com (Retro Guy) wrote:

>> Syber Shock wrote:
>>
>> > On Sat, 29 Jul 2023 17:13:17 +0000
>> > vga@vga256.com (vga256) wrote:
>>
>> >> Are there any actual risks to importing keys, aside from having a
>> >> massive keychain?
>>
>> > Yes, there are risks, but aside from using a certificate authority
>> > or letsencrypt there are other simpler options.
>>
>> > 1. At your registrar or DNS server add a TXT record with the public
>> > signing key of the server.
>>
>> The idea of using a DNS TXT record is a good one. I have considered
>> it, but wonder how many admins will have access to modifying their
>> DNS. Also, if the key is only available via the domain, is it more
>> secure, as you are still depending on the domain name.

> I actually trust my registrar more than the cert authorities. I trust
> user-managed openssl and PGP ed25519 keys more than the cert authority
> chain,

I agree with that. Cert authorities are reasonable for website SSL for
non-critical sites, but I wouldn't trust them with anything important.

We've already seen over the years cert auth errors and gov't hijacking
private keys, etc.

> As for admins modifying their DNS, I would strongly suggest they get
> and manage their own domain. I've seen a project go south because
> someone else owned the domain and provided free hosting for it, only to
> lock people out on a whim.

Again, I agree, but some may just find this too complicated. It's not
complicated, but can seem that way if you've never been exposed to it.

I really don't know what hosted servers offer for that. I do use hosted
servers, but just for plain OS installs, and I handle everything that way,
no panels, or whatever, just ssh in and do my thing. DNS management is
offerred, and I use it. I just don't know what types of services are
offerred from other types of providers.

> I will see you on the flip-flop.

I'll be here.

--
Retro Guy