-- RSLIGHT DAT START
c3lpR09vY1lXWGdOYjNEZlRZa3dVcFFKOWNiay9KNkdtSUVsZ24rRDdpZz06Oi+wtI7mwYKnInN6
bsr/hmQ=
-- RSLIGHT DAT END

-- RSLIGHT DAT START
cGw0aDhkalBHem1zTVJKRE9PNXovcGpOMU5tVUEvT3ZWVHVSY0dVa2VPbz06OllIGDK0ZVSj81G0
6ks06+s=
-- RSLIGHT DAT END

Encrypted messages seem to be working reasonably well, so going live with
it.

There could still be plenty of bugs, we'll just have to see how well it
works (works well for me, but I'm just one person testing)

Encrypted messages should be able to be sent to any other user on the same
rslight site. The recipient needs to enter their password to read the
message. It's very important to enter the recipents username correctly, or
no one can read the message. For example, to send me a message, don't
forget the space between Retro and Guy.

It is also not possible to read message you have sent (unless you sent
them to yourself). Quoting is not complete yet, so copy/paste is the best
way to quote at this time.

Encrypted messages are currently restricted to the group 'encryption'.

Retro Guy
--
Posted on Rocksolid Light

if we federate the auth data, this should also work across nodes, right ?

cheers

trw
Posted on def2

anonymous wrote:

> if we federate the auth data, this should also work across nodes, right ?

There is a concern with that. I tried to put a lot of effort into security
to avoid leaking security data (keys, etc). The message (should be) tied
tightly to the correct user.

I initially thought (before starting) that sharing auth data with other
nodes would make it easy, but then realized that any new node would
suddenly have all the keys, which I'm not sure is a good idea. I sync this
info between my sites, but I'm the admin of all of them (so I trust myself
lol).

I still want to make this possible, so I plan to tie the message to the
site key for the destination site. Then that site can have the same
username as another site, but a different key. If a message isn't destined
for a site an admin manages, that admin has no access to the decrypt key.
The task right now is that the site the sender is using does not have
access to the destination user key, so can't encrypt for that user, but
they can encrypt for the destination site (sites would share keys specific
to each peer). Then when the site "receives" it (finds it in an article),
the site encrypts it for the target user.

This is my current thinking on how to do that, and I'd appreciate any
thoughts/comments.

But for right now, it seems to be working fine for local encrypted
communication.

I plan to work on some code cleanup, then trying to write a script to pull
articles and write to a flat file (then move to db). Then can get back on
this task after that. (I'll work on bugs if/when I find them of course).

Retro Guy
--
Posted on Rocksolid Light

> There is a concern with that. I tried to put a lot of effort into
>security to avoid leaking security data (keys, etc).
>The message (should be) tied tightly to the correct user.

Yeah, that's kind of neccessary for _private_ messages.

>I initially thought (before starting) that sharing auth data with other
> nodes would make it easy, but then realized that any new node would
>suddenly have all the keys, which I'm not sure is a good idea.

Have to agree, I did not think of that when I posted.

>I sync this info between my sites, but I'm the admin of all of them
>(so I trust myself lol). I still want to make this possible, so I plan
> to tie the message to the site key for the destination site.

Not sure I understand this "tying to the site keys".
Anyway, for actual private messaging, I believe there are only two basic
approaches:
-either you only use trusted sites, in this case keys must not be shared
with untrusted sites (Captain Obvious says hello, but I did not think of
it at first...)
-or you use public key encryption, in which case the private key has to
be on the users computer anyway. But then you need to have some user side
client to do the decryption.

The problem is similar to the one I had to solve for boxs.i2p:
-federation of this service would be easy for shared boxes, because
the encryption is symmetrical, and the key is handled and stored by the
user (in the form of links)
-for private boxes, federation would mean to export the private key
(because those are done with public key encryption), and that would
of course would mean to trust the other server operator.

>Then that site can have the same username as another site,
>but a different key. If a message isn't destined for a site an admin
>manages, that admin has no access to the decrypt key.
>The task right now is that the site the sender is using does not have
>access to the destination user key, so can't encrypt for that user,
>but they can encrypt for the destination site (sites would share keys
>specific to each peer). Then when the site "receives" it (finds it in
>an article), the site encrypts it for the target user. This is my
current thinking on how to do that, and I'd appreciate any
>thoughts/comments.

As far as I understand, somewhere along the way the message would have
to be decrypted between servers operated by different parties.
So you still need to trust the other admin, right ?

Or maybe I just misunderstand.

cheers

trw

Posted on def4

On Mon, 22 Jul 2019 12:14:40+0000
trw <trw@anon.com> wrote:

>
> >Then that site can have the same username as another site,
> >but a different key. If a message isn't destined for a site an admin
> >manages, that admin has no access to the decrypt key.
> >The task right now is that the site the sender is using does not
> >have access to the destination user key, so can't encrypt for that
> >user, but they can encrypt for the destination site (sites would
> >share keys specific to each peer). Then when the site "receives" it
> >(finds it in an article), the site encrypts it for the target user.
> >This is my
> current thinking on how to do that, and I'd appreciate any
> >thoughts/comments.
>
> As far as I understand, somewhere along the way the message would have
> to be decrypted between servers operated by different parties.
> So you still need to trust the other admin, right ?
>
> Or maybe I just misunderstand.
>

Currently, if you post an ecrypted message to a username, it is assumed
to be on the same site where you are posting.

Your message header will contain a value that identifies the site it's
posted to (the site it's posted to can read the identification, other
sites should not be able to.

It will also contain a header of who the message is for 'X-Rslight-To:'
This is the user who can decrypt it because their key was used to
encrypt the message.

If an encrypted message is found by rslight in a group that your
install allows to contain encrypted messages (configured in a text
file), and is from the same site (as per message header), the message
will display who the message is for, and ask for their password. If you
know the user's password, you can read the message.

This is working fine (it seems) for a single site, but other sites
should ignore the message(just display the message encrypted).

My current thinking is that a message could be targeted to another
site using the site's key, then re-encrypted with the local user's key.
This can be done during viewing in rslight. The issue to be cautious
about is avoiding the problem of someone copy/pasting the encrypted
data, sending it to themself on the other site and reading it. A bit
more work needs to be done targeting another site to avoid this. On the
same site, I believe I've handled this possibility.

Of course it's important for all users to remember that server side
encryption is just a convenience, and fine for non-critical matters.
Never trust any site's encryption if the site holds the keys, including
any rslight sites, including mine.

I'll continue working (thinking) on this, but as of now I believe same
site user to user encryption is working well enough for people to share
data/info that won't get you killed or locked up if someone finds it.

Retro Guy

--
Posted via novabbs

>Of course it's important for all users to remember that
>server side encryption is just a convenience, and fine for
>non-critical matters. Never trust any site's encryption if
>the site holds the keys, including any rslight sites,
>including mine. I'll continue working (thinking) on this, but
>as of now I believe same site user to user encryption is
>working well enough for people to share data/info that won't
>get you killed or locked up if someone finds it.

well said, and this is also true for dropbox and boxs. end-to-end is the only way for serious stuff.

nice to have this extra option on rslight. i will be a late adopter with def2, i think.

will start working on flarum now.

cheers

trw

cheers

trw

Posted on def4

Retro Guy wrote:

> Encrypted messages seem to be working reasonably well, so going live with
> it.

> There could still be plenty of bugs, we'll just have to see how well it
> works (works well for me, but I'm just one person testing)

> Encrypted messages should be able to be sent to any other user on the same
> rslight site. The recipient needs to enter their password to read the
> message. It's very important to enter the recipents username correctly, or
> no one can read the message. For example, to send me a message, don't
> forget the space between Retro and Guy.

> It is also not possible to read message you have sent (unless you sent
> them to yourself). Quoting is not complete yet, so copy/paste is the best
> way to quote at this time.

> Encrypted messages are currently restricted to the group 'encryption'.

> Retro Guy

Posted on def2

hmmm nice post keep sharing this one

Keep sharing The information's...