The Mandelbear's Musings

If your mail client automatically decrypts mail, read this!

There's no need to panic, but you should immediately disable and/or uninstall plugins that automatically decrypt PGP-encrypted or S/MIME email. The linked article tells you how.

The vulnerability is called EFAIL (the obligatory website with clever name), and allows an attacker to read your encrypted email, in effect "over your shoulder", by sending you a modified version of the encrypted message. They can do this by evesdropping, compromising an email account or server, etc. The attack is based on the way active content, such as images, is handled in HTML email.

Short term: No decryption in email client. The best way to prevent EFAIL attacks is to only decrypt S/MIME or PGP emails in a separate application outside of your email client. Start by removing your S/MIME and PGP private keys from your email client, then decrypt incoming encrypted emails by copy&pasting the ciphertext into a separate application that does the decryption for you. That way, the email clients cannot open exfiltration channels. This is currently the safest option with the downside that the process gets more involved.

Short term: Disable HTML rendering. The EFAIL attacks abuse active content, mostly in the form of HTML images, styles, etc. Disabling the presentation of incoming HTML emails in your email client will close the most prominent way of attacking EFAIL. Note that there are other possible backchannels in email clients which are not related to HTML but these are more difficult to exploit.

Links below:

  @ EFAIL Paper [PDF]
  @ Critical PGP and S/MIME bugs can reveal encrypted emails—uninstall now [Updated]
  @ Attention PGP Users: New Vulnerabilities Require You To Take Action Now | EFF
  @ Not So Pretty: What You Need to Know About E-Fail and the PGP Flaw | EFF

This has been a public service announcement from The Computer Curmudgeon.

According to this paper [pdf], AES encryption may be much easier to crack using linear cryptography than is commonly thought. The paper is, however, non-constructive: it makes a plausible case but doesn't actually demonstrate a solution.

The attack's runtime is comparable to performing 64^w encryptions where w is the (unknown) minimum Hamming weight in certain binary linear error-correcting codes (BLECCs) associated with AES-256. If w < 43 then our attack is faster than exhaustive key search; probably w < 10. (Also there should be ciphertext-only attacks if the plaintext is natural English.)

It also gives a construction for a family of encryption algorithms that avoid the problem. The attack does rely on having a large number of plaintext/ciphertext pairs encrypted with the same key, or an even larger amount of ciphertext with known statistics.

The workaround for now would appear to be to use a different random or pseudorandom key for each document (and of course to compress each document before you encrypt it, and use CBC mode encryption). You're left with a key-management problem, but managing that many ID/key pairs is no worse than managing all the document IDs in a hash-based version control system like git. Similarly, systems that use one-time random session keys should be safe as long as they're using compression and CBC mode, and renegotiate their keys frequently.

(From cryptome.)