11 ms·

Opmsg – A GPG Alternative

121 points by bellinom 7y ago

cwyers 7y ago
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.
- masklinn 7y ago
  Indeed, from Latacora's recent "The PGP Problem": > Encrypting Email > Don’t. > Email is insecure. Even with PGP, it’s default-plaintext, which means that even if you do everything right, some totally reasonable person you mail, doing totally reasonable things, will invariably CC the quoted plaintext of your encrypted message to someone else (we don’t know a PGP email user who hasn’t seen this happen). PGP email is forward-insecure. Email metadata, including the subject (which is literally message content), are always plaintext. > If you needed another reason, read the Efail paper. The GnuPG community, which mishandled the Efail disclosure, talks this research down a lot, but it was accepted at Usenix Security (one of the top academic software security venues) and at Black Hat USA (the top industry software security venue), was one of the best cryptographic attacks of the last 5 years, and is a pretty devastating indictment of the PGP ecosystem. As you’ll see from the paper, S/MIME isn’t better. > This isn’t going to get fixed. To make actually-secure email, you’d have to tunnel another protocol over email (you’d still be conceding traffic analysis attacks). At that point, why bother pretending? > Encrypting email is asking for a calamity. Recommending email encryption to at-risk users is malpractice. Anyone who tells you it’s secure to communicate over PGP-encrypted email is putting their weird preferences ahead of your safety.
  - DarkWiiPlayer 7y ago
    If you know what you're doing, PGP can improve security. The real problem is that, the moment you're sending information to someone, you're giving that information away, out of your control. If I understand it correctly, all the above points seem to address mostly the technical aspect, that someone who means well may too easily leak previously encrypted information out of ignorance. A possible counter argument could be this: You already need to trust a recipient that they won't leak the data you send them willingly and with harmful intent, so it's not that much to ask that people also trust the competence of the recipient. What Opmsg really seems to be about is cases where you don't trust the recipient to not betray you, intentionally or unintentionally.
    - tptacek 7y ago
      No. Secure Messengers are designed to be hard to use unsafely. Nobody accidentally sends plaintext to a counterpart with Signal, because there's no feature in Signal that does that.
      - hiq 7y ago
        You can still send text messages (including to Signal contacts by long-pressing the send button). Obviously it is harder than just sending an encrypted message.
      - chacha2 7y ago
        Strange example. Signal does support unencrypted sms which would make it easy for someone to forward a previously encrypted message as plain text.
        cwyers 7y ago
        If you can't trust the recipient, there's nothing you can do. The point isn't to protect yourself from an untrustworthy recipient, it's to protect yourself from inadvertent disclosure.
    - jcranmer 7y ago
      Email is really difficult-to-impossible to secure correctly. Take metadata. Because of how email works, it's effectively impossible to hide the To, From, and Date (or more accurately, the Received) headers. If you're worried about three-letter agencies, that's the only metadata they need, so you're screwed before you started. Theoretically, S/MIME allows you to encrypt additional headers (including the venerable Subject header), and has done so for 15 years, but I'm unaware of any email client that actually supports this feature, and the downgrade mode is pretty UX-hostile. Another very challenging problem is that the flow of email pretty much destroys any chance of using a good secure cryptosystem. The email sender is not necessarily able to establish a direct, synchronous contact with the email recipient, even on a server basis. That makes protocol negotiation and perfect forward secrecy difficult. Not to mention that users generally expect to be able to open up email clients on unknown machines (especially webmail clients), which means practical key distribution tends to amount to "give your provider your keys," at which point the security advantage over the current state of all-connections-are-wrapped-in-TLS is negligible. There's also the point that email's main advantage as a messaging system is its universality. But any new protocol is going to suffer from being supported in a small section of clients at first. If you can't get major email clients on board--and that includes webmail clients--then the universality of email is no longer an advantage in your proposed protocol. And if you're going to have to use a different client already, why bother with doing all the crap you have to deal with email syntax, MIME, SMTP, and IMAP? About the only use case I can reasonably see for encrypting emails is in workflows like Bugzilla's "secure email" feature: the system is already relying on email for communication, there is a clear way to handle the recipient's key and protocol negotiation, and the metadata is irrelevant to secure.
  - tinus_hn 7y ago
    Well that settles it. Better do nothing then!
- wongarsu 7y ago
  >It implements RSA, which nobody should be using anymore Can someone elaborate a bit? My impression was that RSA is fine with long keys, elliptic curves mainly provide shorter keys, and no decent quantum resistant algorithm emerged?
  - kzrdude 7y ago
    I'm just interested but it reminds me of https://facthacks.cr.yp.to/ https://facthacks.cr.yp.to/ which is a horizontal attack, finding the weakest keys in a big set of them, and batch factorization attacks. This seems more developed for RSA keys?
  - zaarn 7y ago
    RSA is hard to implement and requires a lot of key material to change hand. On the flipside, a Ed25519 or Ed448 key can be reasonably dictated over phone (though you might need three minutes) and put into small low-res QR codes. Additionally, Ed25519/448 are dead simple to implement; following the reference from the RFC documentation, you can implement a safe cryptographic method (encrypt/decrypt/sign/verify). You actually have to go out of your way and do things the standard doesn't include to make it unsafe. Compare with RSA, where such a naive implementation will make you suffer through atleast 30 CVEs of the "padding oracle" or "leak private key" type. While RSA is fine from a mathematical standpoint, Ed25519/448 are much simpler to implement with much less code and are designed to be reasonably safe. They provide the same security as a ~3500 bit (or about 4500 bit for 448) RSA key, so it's on the safe side of things. There is no Post-QC algorithm yet, atleast none that made it through the NIST competition, some of them do involve using RSA with absurd key sizes and they'll likely fail the competition.
    - phicoh 7y ago
      I don't understand the argument of dictating a key over the phone. If you care about that use case, you can just a well dictate the hash of an RSA public key. Nobody knowns of the NIST curves have backdoors. Nobody know s if Dan Bernstein's curve has issues. The advantage of RSA, is that we actually know how it works. I continue to be amazed that so many people advocate curves that we don't undertstand. Of course, the big problem with RSA, is that is seems simple enough that people try to implement it themselves and get it wrong. With EC, you basically have to use one of the standard libraries.
- petre 7y ago
  It implements EC with _fallback_ to RSA if EC is not available. Blame OpenSSL, I guess, because this relies on it. Even its CLI seems to be inspired by the atrocious OpenSSL CLI.
  - cwyers 7y ago
    Fallback in crypto is wrong. Either succeed or fail. I don't need to sit there guessing how secure my secure messenger is.
- claudius 7y ago
  > 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".
  - phicoh 7y ago
    I think that one of the really bad problems with gpg and openssl is that for a long time there was effectively only one implementation. So the key thing for matrix is to create a healthy ecosystem that has multiple implementations of the protocol and make sure that the protocol can actually evolve. Note that the 'identity server' is an optional component. As long as you stick to matrix native user IDs, there is no need to use one.
  - maxerickson 7y ago
    Most people really don't care. They use Whatsapp because that's where their friends are and they will move to whatever their friends start using next.
    - brokenkebab 7y ago
      'People' is a poorly defined notion here, and cannot be really used for any sane conclusions. Users have different practical, and security needs, therefore different priorities which define their behavior. PGP (and its alternatives) is to Whatsapp (and its alternatives) as apples to oranges.
      - maxerickson 7y ago
        Okay, the vast majority of the general population, the billions of people using apps like Whatsapp. Note that the comment I replied to started from the rather categorical "nobody".
- tdj 7y ago
  This screenshot of an Ars Technica journalist with Phil Zimmerman, PGP author (yes, not the same as GPG), is very telling: https://arstechnica.com/information-technology/2016/12/op-ed-im-giving-up-on-pgp/?comments=1&post=32447753 https://arstechnica.com/information-technology/2016/12/op-ed...
  - dewyatt 7y ago
    I'm not sure what you're implying, but without context, the screenshot is meaningless. It could be that Phil has a policy of not storing private keys on his iPhone or something. Is that so unusual? Anyways, maybe you're privy to context that I'm missing.
    - Goronmon 7y ago
      My interpretation is that even if the people who are technically savvy in that specific area, if they have times they won't deal with encrypted information, how often are non-technical people going to want to deal with it?
      - sucrose 7y ago
        According to the screenshot, it's not the he won't, it's that he can't.
    - bscphil 7y ago
      I would say the implication is that PGP is useless for general secure communications purposes. You can be secure with it when you have very specific needs and have knowledgeable contacts, but it doesn't solve the need for communications privacy that most people have.
      - brokenkebab 7y ago
        It's not a problem to be blamed on PGP though. A solution to shield an Average Joe's private life from his internet provider's snooping will always have its own deficiencies, exactly because of its generality.
- brokenkebab 7y ago
  accidentally replying without encrypting There are automated solutions for this in existence for many-many years.
pferde 7y ago
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.
mikorym 7y ago
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?
- _pmf_ 7y ago
  Exactly. The "PGP is bad because public key infrastructure management is hard" meme should please die already. The idea of a dedicated package signing and encrypting tool detached from this problem is maybe not a bad idea in that regard, because it removes this stigma.
- masklinn 7y ago
  > 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. You're apparently asserting that Latacora's "The PGP Problem" states PGP is only bad for email. I can only assume you didn't even bother the article? Because it states that PGP is bad: * period and in its entirety, in fact most of the article (section 1 "The Problems") is the various ways PGP and GnuPG are broken at the core, specific scenarios are only mentioned (in section 2 "The Answers") to provide alternatives, because Latacora's assertion is that in cryptography one size does not fit all, and each scenario needs its own toolset * for securing messenging * for securing email messages * for signing files and packages * for encrypting files, whether to send, backups, application data, … What it does state with respect to email is that encrypting emails is a fool's errand not just that using PGP to do so is a mistake. It does note that GnuPG is also specifically bad at it, but very clearly state the issue is not limited to PGP: > This isn’t going to get fixed. To make actually-secure email, you’d have to tunnel another protocol over email (you’d still be conceding traffic analysis attacks). At that point, why bother pretending? > Encrypting email is asking for a calamity. Recommending email encryption to at-risk users is malpractice.
jively 7y ago
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 7y ago
  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 7y ago
    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 7y ago
      Email is based on open, federated protocols. Every successful instant messaging service (sorry XMPP) as been a single closed provider.
- deleted 7y ago
  [deleted]
- NikkiA 7y ago
ape4 7y ago
The "MITM on all HTTPS traffic in Kazakhstan" issue suggests that relying on STARTTLS for email encryption isn't that great.
- Avamander 7y ago
  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 7y ago
    How about MTA-STS? I guess that improves the situation a bit, no?
    - tatersolid 7y ago
      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.
upofadown 7y ago
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...
SimplyUnknown 7y ago
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 7y ago
  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.

121 points by bellinom 7y ago

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.

masklinn 7y ago
Indeed, from Latacora's recent "The PGP Problem": > Encrypting Email > Don’t. > Email is insecure. Even with PGP, it’s default-plaintext, which means that even if you do everything right, some totally reasonable person you mail, doing totally reasonable things, will invariably CC the quoted plaintext of your encrypted message to someone else (we don’t know a PGP email user who hasn’t seen this happen). PGP email is forward-insecure. Email metadata, including the subject (which is literally message content), are always plaintext. > If you needed another reason, read the Efail paper. The GnuPG community, which mishandled the Efail disclosure, talks this research down a lot, but it was accepted at Usenix Security (one of the top academic software security venues) and at Black Hat USA (the top industry software security venue), was one of the best cryptographic attacks of the last 5 years, and is a pretty devastating indictment of the PGP ecosystem. As you’ll see from the paper, S/MIME isn’t better. > This isn’t going to get fixed. To make actually-secure email, you’d have to tunnel another protocol over email (you’d still be conceding traffic analysis attacks). At that point, why bother pretending? > Encrypting email is asking for a calamity. Recommending email encryption to at-risk users is malpractice. Anyone who tells you it’s secure to communicate over PGP-encrypted email is putting their weird preferences ahead of your safety.
- DarkWiiPlayer 7y ago
  If you know what you're doing, PGP can improve security. The real problem is that, the moment you're sending information to someone, you're giving that information away, out of your control. If I understand it correctly, all the above points seem to address mostly the technical aspect, that someone who means well may too easily leak previously encrypted information out of ignorance. A possible counter argument could be this: You already need to trust a recipient that they won't leak the data you send them willingly and with harmful intent, so it's not that much to ask that people also trust the competence of the recipient. What Opmsg really seems to be about is cases where you don't trust the recipient to not betray you, intentionally or unintentionally.
  - tptacek 7y ago
    No. Secure Messengers are designed to be hard to use unsafely. Nobody accidentally sends plaintext to a counterpart with Signal, because there's no feature in Signal that does that.
    - hiq 7y ago
      You can still send text messages (including to Signal contacts by long-pressing the send button). Obviously it is harder than just sending an encrypted message.
    - chacha2 7y ago
      Strange example. Signal does support unencrypted sms which would make it easy for someone to forward a previously encrypted message as plain text.
      - cwyers 7y ago
        If you can't trust the recipient, there's nothing you can do. The point isn't to protect yourself from an untrustworthy recipient, it's to protect yourself from inadvertent disclosure.
  - jcranmer 7y ago
    Email is really difficult-to-impossible to secure correctly. Take metadata. Because of how email works, it's effectively impossible to hide the To, From, and Date (or more accurately, the Received) headers. If you're worried about three-letter agencies, that's the only metadata they need, so you're screwed before you started. Theoretically, S/MIME allows you to encrypt additional headers (including the venerable Subject header), and has done so for 15 years, but I'm unaware of any email client that actually supports this feature, and the downgrade mode is pretty UX-hostile. Another very challenging problem is that the flow of email pretty much destroys any chance of using a good secure cryptosystem. The email sender is not necessarily able to establish a direct, synchronous contact with the email recipient, even on a server basis. That makes protocol negotiation and perfect forward secrecy difficult. Not to mention that users generally expect to be able to open up email clients on unknown machines (especially webmail clients), which means practical key distribution tends to amount to "give your provider your keys," at which point the security advantage over the current state of all-connections-are-wrapped-in-TLS is negligible. There's also the point that email's main advantage as a messaging system is its universality. But any new protocol is going to suffer from being supported in a small section of clients at first. If you can't get major email clients on board--and that includes webmail clients--then the universality of email is no longer an advantage in your proposed protocol. And if you're going to have to use a different client already, why bother with doing all the crap you have to deal with email syntax, MIME, SMTP, and IMAP? About the only use case I can reasonably see for encrypting emails is in workflows like Bugzilla's "secure email" feature: the system is already relying on email for communication, there is a clear way to handle the recipient's key and protocol negotiation, and the metadata is irrelevant to secure.
- tinus_hn 7y ago
  Well that settles it. Better do nothing then!
wongarsu 7y ago
>It implements RSA, which nobody should be using anymore Can someone elaborate a bit? My impression was that RSA is fine with long keys, elliptic curves mainly provide shorter keys, and no decent quantum resistant algorithm emerged?
- kzrdude 7y ago
  I'm just interested but it reminds me of https://facthacks.cr.yp.to/ https://facthacks.cr.yp.to/ which is a horizontal attack, finding the weakest keys in a big set of them, and batch factorization attacks. This seems more developed for RSA keys?
- zaarn 7y ago
  RSA is hard to implement and requires a lot of key material to change hand. On the flipside, a Ed25519 or Ed448 key can be reasonably dictated over phone (though you might need three minutes) and put into small low-res QR codes. Additionally, Ed25519/448 are dead simple to implement; following the reference from the RFC documentation, you can implement a safe cryptographic method (encrypt/decrypt/sign/verify). You actually have to go out of your way and do things the standard doesn't include to make it unsafe. Compare with RSA, where such a naive implementation will make you suffer through atleast 30 CVEs of the "padding oracle" or "leak private key" type. While RSA is fine from a mathematical standpoint, Ed25519/448 are much simpler to implement with much less code and are designed to be reasonably safe. They provide the same security as a ~3500 bit (or about 4500 bit for 448) RSA key, so it's on the safe side of things. There is no Post-QC algorithm yet, atleast none that made it through the NIST competition, some of them do involve using RSA with absurd key sizes and they'll likely fail the competition.
  - phicoh 7y ago
    I don't understand the argument of dictating a key over the phone. If you care about that use case, you can just a well dictate the hash of an RSA public key. Nobody knowns of the NIST curves have backdoors. Nobody know s if Dan Bernstein's curve has issues. The advantage of RSA, is that we actually know how it works. I continue to be amazed that so many people advocate curves that we don't undertstand. Of course, the big problem with RSA, is that is seems simple enough that people try to implement it themselves and get it wrong. With EC, you basically have to use one of the standard libraries.
petre 7y ago
It implements EC with _fallback_ to RSA if EC is not available. Blame OpenSSL, I guess, because this relies on it. Even its CLI seems to be inspired by the atrocious OpenSSL CLI.
- cwyers 7y ago
  Fallback in crypto is wrong. Either succeed or fail. I don't need to sit there guessing how secure my secure messenger is.
claudius 7y ago
> 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".
- phicoh 7y ago
  I think that one of the really bad problems with gpg and openssl is that for a long time there was effectively only one implementation. So the key thing for matrix is to create a healthy ecosystem that has multiple implementations of the protocol and make sure that the protocol can actually evolve. Note that the 'identity server' is an optional component. As long as you stick to matrix native user IDs, there is no need to use one.
- maxerickson 7y ago
  Most people really don't care. They use Whatsapp because that's where their friends are and they will move to whatever their friends start using next.
  - brokenkebab 7y ago
    'People' is a poorly defined notion here, and cannot be really used for any sane conclusions. Users have different practical, and security needs, therefore different priorities which define their behavior. PGP (and its alternatives) is to Whatsapp (and its alternatives) as apples to oranges.
    - maxerickson 7y ago
      Okay, the vast majority of the general population, the billions of people using apps like Whatsapp. Note that the comment I replied to started from the rather categorical "nobody".
tdj 7y ago
This screenshot of an Ars Technica journalist with Phil Zimmerman, PGP author (yes, not the same as GPG), is very telling: https://arstechnica.com/information-technology/2016/12/op-ed-im-giving-up-on-pgp/?comments=1&post=32447753 https://arstechnica.com/information-technology/2016/12/op-ed...
- dewyatt 7y ago
  I'm not sure what you're implying, but without context, the screenshot is meaningless. It could be that Phil has a policy of not storing private keys on his iPhone or something. Is that so unusual? Anyways, maybe you're privy to context that I'm missing.
  - Goronmon 7y ago
    My interpretation is that even if the people who are technically savvy in that specific area, if they have times they won't deal with encrypted information, how often are non-technical people going to want to deal with it?
    - sucrose 7y ago
      According to the screenshot, it's not the he won't, it's that he can't.
  - bscphil 7y ago
    I would say the implication is that PGP is useless for general secure communications purposes. You can be secure with it when you have very specific needs and have knowledgeable contacts, but it doesn't solve the need for communications privacy that most people have.
    - brokenkebab 7y ago
      It's not a problem to be blamed on PGP though. A solution to shield an Average Joe's private life from his internet provider's snooping will always have its own deficiencies, exactly because of its generality.
brokenkebab 7y ago
accidentally replying without encrypting There are automated solutions for this in existence for many-many years.

pferde 7y ago

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.

mikorym 7y ago

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?

_pmf_ 7y ago
Exactly. The "PGP is bad because public key infrastructure management is hard" meme should please die already. The idea of a dedicated package signing and encrypting tool detached from this problem is maybe not a bad idea in that regard, because it removes this stigma.
masklinn 7y ago
> 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. You're apparently asserting that Latacora's "The PGP Problem" states PGP is only bad for email. I can only assume you didn't even bother the article? Because it states that PGP is bad: * period and in its entirety, in fact most of the article (section 1 "The Problems") is the various ways PGP and GnuPG are broken at the core, specific scenarios are only mentioned (in section 2 "The Answers") to provide alternatives, because Latacora's assertion is that in cryptography one size does not fit all, and each scenario needs its own toolset * for securing messenging * for securing email messages * for signing files and packages * for encrypting files, whether to send, backups, application data, … What it does state with respect to email is that encrypting emails is a fool's errand not just that using PGP to do so is a mistake. It does note that GnuPG is also specifically bad at it, but very clearly state the issue is not limited to PGP: > This isn’t going to get fixed. To make actually-secure email, you’d have to tunnel another protocol over email (you’d still be conceding traffic analysis attacks). At that point, why bother pretending? > Encrypting email is asking for a calamity. Recommending email encryption to at-risk users is malpractice.

jively 7y ago

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 7y ago
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 7y ago
  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 7y ago
    Email is based on open, federated protocols. Every successful instant messaging service (sorry XMPP) as been a single closed provider.
deleted 7y ago
[deleted]
NikkiA 7y ago

ape4 7y ago

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

Avamander 7y ago
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 7y ago
  How about MTA-STS? I guess that improves the situation a bit, no?
  - tatersolid 7y ago
    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.

upofadown 7y ago

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...

SimplyUnknown 7y ago

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 7y ago
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.