
Opmsg – A GPG Alternative - bellinom
https://github.com/stealth/opmsg
======
cwyers
I am not qualified to review how it implements forward security, for instance.

But this shares a lot of the problems that GPG has. It relies on existing mail
standards, so it leaks metadata all over the place, and security can easily be
defeated by "accidentally replying without encrypting." It's configurable --
every choice you have to make is a chance to make the wrong one. It implements
RSA, which nobody should be using anymore.

~~~
claudius
> It relies on existing mail standards

This is a feature, not a bug. Nobody actually wants to rely on a single entity
(for or non-profit) for their communication. Nobody wants to be stuck in
crappy Electron and mobile clients.

I had some hope that Matrix may be able to alleviate those concerns and
provide a modern, federated chat solutions. Unfortunately their quality of
implementation seems to be rather low with slow, laggy and resource-hungry
clients and ridiculously resource-hungry servers and their current setup still
apparently include a single "identity server".

~~~
zucker42
Have you used Riot on mobile recently? Sure it's not perfect, but it
consistently outperforms FB Messenger on my very poor phone.

~~~
claudius
No, mostly because the Matrix homeserver still needs ridiculous amounts of
memory. Apparently 1GB if you want to join one of the more crowded channels –
what for could a chat server actually use 1GB of memory?! That's a billion
characters you can store in there, even at hundreds of messages per second
(which I suppose would make the channel unusable anyways?) you don't get to a
billion characters very quickly.

------
SimplyUnknown
Forgive me if I can't read but I couldn't quickly find the following. Is it
possible to use Opmsg as a library?

If you want to use GPG as library in your application right now, you can't.
The best thing you can do is parse GPG output which is ... less-than-ideal at
best and downright wrong and dangerous at worst. If one can use this as a
library rather GPG that would be a huge win.

~~~
SibLiant
I've been reading about crypto lately and
[https://download.libsodium.org/doc/](https://download.libsodium.org/doc/)
seems to be the goto library for what you're pointing out.

------
upofadown
The perfect forward secrecy here seems to involve deleting a "persona". I an
not sure how that is any different from doing PFS by deleting a PGP subkey.
Like with PGP if you do this you lose email archived under that persona. There
is no automation to re-encrypt the archive with a different key.

So I am not really sure if this has a killer feature that would make anyone
want to go to the bother of abandoning PGP...

------
mikorym
I think a perhaps unclear part of the recent post "The PGP Problem" is that
PGP is bad _for email_.

If you don't use it for email, I don't see it as really a problem. Unless,
maybe, you are a reporter or otherwise not clear on the principles behind
using something like GPG. I think personally that the point about all the
discussion is that for laypeople PGP and email is just too complicated (even
for myself as a programmer and evidently for others it is complicated).

In that same vein, I can see how PGP has fundamental limitations with email,
e.g.: Having someone's email address does not imply that you have their public
key. Is it possible to state in simple terms whether OP's program does to
improve this?

~~~
lifeisstillgood
My understanding is quite different. _Email_ is inherently _insecure_ and
there is nothing you can do about it.

PGP is insecure for everything else _as well_

The Latacora article was eye-opening for me on the email problem - quite
simply if I send an encrypted mail to a friend / collegue - which I intend
them to read, and they read it and quote it to someone else in plain text then
that's it - my plaintext and my cipher are available in the wild and my key
(my _long term_ key) is effectively broken.

I simply never thought it through that way. But that's how email is _supposed_
to be used - it will be used that way.

Mind Blown.

~~~
tptacek
Wait, what? No. Leaking plaintext doesn't reveal your long term key. I
definitely didn't write that.

~~~
lifeisstillgood
I finally got that when someone pointed out that the long term key is not used
to encrypt the mail content - i made that leap incorrectly and went from
there.

I made the change down thread - was too late to edit the original - and i hope
clearly pointed out that your article did not say that

It takes me several run ups to understand most security issues and I got all
excited before having my coffee that day.

------
jively
The reality of the situation is that you can't remove the human factor from
security. So someone copying your email to someone else is a human problem
that can't be fixed - someone could just as easily photograph the screen.

The reality is email will continue to be used, and there is a use case for
being able to send an email securely to another person.

EFail was pretty bad, but only affected HTML email.

Having a modicum of backwards compatibility is how to encourage transitioning
to new tech, so the RSA implementation makes sense.

I must say this is the first decent alternative I've seen for GPG instead of
rants about Signal and specialised tooling that just ignore the issue that
folks want to be able to send secure emails to each other.

~~~
cpach
I would love to see a sound implementation of secure e-mail, but I also
believe that such a system should not be built on top of SMTP.

Signal’s cryptography seems stellar, but to me it feels a bit weird to use
instant messaging as a full replacement for electronic _letters_. I’m guessing
here, but it would probably not be impossible to build a more traditional
e-mail client on top of the Signal Protocol.

~~~
maxnoe
I don't see why this should not be possible.

Isn't this mainly about adding a a subject metadata field an a client that
just displays messages differently, enables sorting into directories and so
on?

Is there a real technical difference between messaging and long form emails
that I don't see?

~~~
ForHackernews
Email is based on open, federated protocols. Every successful instant
messaging service (sorry XMPP) as been a single closed provider.

------
ape4
The "MITM on all HTTPS traffic in Kazakhstan" issue suggests that relying on
STARTTLS for email encryption isn't that great.

~~~
Avamander
To be fair e-mail is garbage trough-and-trough. You can't even use SNI,
nothing cares about certificate validity, even less about Staple and CT.

~~~
cpach
How about MTA-STS? I guess that improves the situation a bit, no?

~~~
tatersolid
Not really. Until MTA-STS is deployed in “hard fail” mode by almost everybody
it doesn’t matter.

Similarly, SPF/DKIM did not solve spam because nobody was willing to _really
drop incoming mail_ with bad or missing signatures.

Email is an “ossified” protocol. It should fade away, and be replaced with
something else modern and secure like a “federated Signal”.

If that something else allows anyone to send to anyone without permission, it
too will be killed by spam.

------
pferde
Slightly off-topic, but having the donate button placed first on the page,
even before I can read what I'd be donating to, seems a bit greedy.

