Skimmed through the GPG & S/MIME paper. Some good theory w/decent outlined attack scenarios. Currently involves a lot of work by the attacker, including getting the target to open and decrypt new malicious emails.

Not terribly worried about it. It’s low risk for both my personal and my client’s Threat Scenario. But still cool!

Side issue: I’m going to have to explain this to my C-Lvl... when did I get co-opted by blue team?! This is what I get for pushing purple team all these years.

#infosec

So after a couple meetings and going through more of the links, including the GPG response, etc.

My thoughts on the #efail vuln:

1) The core requirement is that an attacker needs to get ahold of an encrypted email first. This is axiomatic. This is the thing that they need to decrypt.

The attacker can do either by:
a) Sniffing the encrypted email in transit
b) Stealing the encrypted email at rest.

For an attacker to sniff an encrypted email in transit (a), the attacker can get it either:
i) In a targeted Man-in-the-Middle attack
ii) As a systemic attacker (e.g. NSA, GCHQ, Compromised ISP, etc)

A couple things make this difficult:
- Many encrypted emails using S/MIME are sent within a corporate enterprise and never leave the perimeter. (You'd have to breach the corporate perimeter)
- Emails are often protected via TLS in transit. (either need to break TLS or attack the endpoint)

#efail

For an attacker to steal encrypted email at rest (b), they need to breach a datastore of email archives. Maybe a company's Exchange server, for example.

If an attacker has access to an Exchange server, they probably have access to other things, including the Domain Controller and individual workstations (after dumping NTDS or with Domain Admin creds, for example)

#efail

As such, #efail is not a very good attack for a person targeting corporate emails.
- Much of the encrypted email is internal.
- If an attacker has access to internal data stores, they probably have access to the cleartext emails from the employee's own endpoint of client anyways.

As such, the real Attack Scenario here is a Nation State attempting to decrypt old emails it sniffed in transit at the systemic level.

If they were able to get access to an end point of someone in a shared key thread, they probably can decrypt it with the stored private key on the endpoint, etc.

A nation state actor could feasibly break TLS or sniff traffic at the email provider, etc.

Their target would be activists, journalists, or military / other nation states.

#efail

With all this in mind, from a Corporate Standpoint the risk is minimal. There are other more prevalent, less esoteric attacks that will get an attacker access to clear text emails than #efail.

From a privacy standpoint of folks who may be targeted by systemic attackers, there is an issue. The risk is minimized in that it is still a targeted attack (they have to send an email to *you* with an old encrypted message buried in it).

So this boils down to, don't worry unless you're a *target* (not mass surveillance, but a targeted attack) of a nation state.

If that's the case, make sure your OpSec is good. Plan to fail. Fail gracefully. Don't use PGP in the mail client. Copy and paste the message into a separate app.

And good luck. Because fuck being a target of a Nation State.

#efail

@tinker I think that absolutely is the context to see the EFF statement in: They do support a clientele that fits into the "endangered by nation state attackers or large criminal organizations" category (one of the SANS blogs occasionally had glimpses into the kind of attacks on email communications being used in that sphere).
For those people, sending a "if you rely on PGP encrypted mail for vital interests, stop opening mails NOW" warning is a valid reaction.