Because of vulnerabilities of many mail clients PGP and
S/MIME encrypted messages can be partially read from an
attacker without having the key.
See my article on http://noxan.i2p

Noxan Posted on: def3.i2p

here is a clearnet link to a description: https://efail.de/
Posted on RetroBBS II

  To: guest
guest wrote:

Because of vulnerabilities of many mail clients PGP and
S/MIME encrypted messages can be partially read from an
attacker without having the key.
See my article on http://noxan.i2p

Noxan Posted on: def3.i2p

Thanks for posting this information.

Makes me glad I don't allow HTML in my mail clients, but it's still a concern as the client does have internet access so who knows.

Posted on Rocksolid Light.
--- Synchronet 3.17a-Linux NewsLink 1.108
Posted on RetroBBS

  To: AnonUser
Note that the bug is not concerning PGP itself, but only works in connection with emails (plus some other factors). Posted on Rocksolid Light.
--- Synchronet 3.17a-Linux NewsLink 1.108
Posted on RetroBBS

https://www.eff.org/de/deeplinks/2018/05/attention-pgp-users
-new-vulnerabilities-require-you-take-action-now

"Our advice, which mirrors that of the researchers, is to
immediately disable and/or uninstall tools that
automatically decrypt PGP-encrypted email. Until the flaws
described in the paper are more widely understood and fixed,
users should arrange for the use of alternative end-to-end
secure channels, such as Signal, and temporarily stop
sending and especially reading PGP-encrypted email. "

Posted on: def2.i2p

we are probably fucked again. who knows when the first
discovery of this happened, and by whom ? or if it is in
fact a bug or a feature (like heartbleed) ?

FUCK
Posted on: def2.i2p

seems like we are triple fucked:

https://www.golem.de/news/pgp-smime-thunderbird-update-notwendig-um-efail-zu-verhindern-1805-134472.html

there are other bugs as well, again in connection with html
(link is in german language, but google translate gives ok
results).
Posted on RetroBBS II

If CryptoCat was good enough for Snowden-Guardian
communication why bother with Apple Mail.  This flaw is
exacerbated by the fact that emails are not signed to see if
they were tampered with.   You can decrypt and encrypt from
your file manager (Nautilus has an extension).  You can
check a free account with Zimbra Java at mail.unseen.is
highly recommended for small things 20MB max storage. Posted on: def3.i2p

What Snowden did on the technical side cannot be done by John Doe. It would be nice to have safe-by-default for average people.

Posted on def4.i2p

and the next fuckup, this time not as bad, but without
involvement of html:

https://neopg.io/blog/encryption-spoof/

Not everything that looks encrypted, is encrypted
2018-05-28

I found out that it is possible to create a message that
looks encrypted in GnuPG and many email clients, but where
the plaintext is actually not protected at all.

Thanks to Fabian Ising and Simon Friedberger for
discussions!

Before I start, let's take a look at the problem. The
following image consists of screenshots of:

    Earlybird 52.7.0 with Enigmail 2.0.4 (20180516-1359,
NixOS),
    Evolution 3.28.2 (Fedora),
    Mutt 1.9.5 (NixOS), and
    Outlook 2007/Gpg4win 3.1.1 (Windows 10).

It shows the rendering of a simple text email in the
PGP/Inline format (so no MIME or HTML is involved). It looks
exactly as if the email is encrypted to the recipient. But
in fact everything highlighted red in this image is a total
lie - the result of a willful manipulation of the message by
the sender. Let's call this special message the cake
message, or short: the cake.

Enigmail 2.0.4

Evolution 3.28.2

Mutt 1.9.5

Gpg4win 3.1.1

I promise you that nothing in the cake is encrypted (you
will see later that except for Outlook this is literally
true - the encrypted content of the cake is exactly 0
bytes). I also promise you that this output is exactly the
same as if the content were properly encrypted.

This bug is certainly not in the same category as a serious
security vulnerability, such as a plaintext leak or a
signature spoof. But it is confusing and hazardous, so it
should be fixed. The handling of the cake message also
violates the OpenPGP standard. More importantly, analyzing
the bug helps to understand why OpenPGP is difficult to
implement, and why it is particularly difficult to implement
OpenPGP support using GnuPG.

At the end, I hope that you will understand more about the
OpenPGP standard, the mechanics inside GnuPG, and why the
NeoPG project wants to provide a modern and extensible
programming interface for applications based on OpenPGP.
Investigating the cake

At first glance, the cake message looks perfectly innocent.
But, assuming that somehow your suspicion is raised, let's
play Sherlock Holmes and investigate a bit further what is
going on.

As power users, we turn to the command line and see if we
can get some more information about the ciphertext of the
cake message:

$ cat cake | gpg
gpg: WARNING: no command supplied.  Trying to guess what you
mean ...
gpg: encrypted with 2048-bit RSA key, ID 66489556790B2E8E,
created 2018-03-25
      "twitter://lambdafu"
This is fine!

Nope, the above output is perfectly normal for an encrypted
file. Adding --verbose doesn't change that either. But if we
check out the binary content of the cake message, we can see
that it contains the plaintext in unencrypted form:

$ cat cake | gpg --dearmor | strings
This is fine!

Modifying this string in the cake shows that the
"decryption" output changes as well, proving that it comes
from the unprotected plaintext part of the cake. Maybe we
can find out more by listing the OpenPGP packets in the cake
using a debugging feature of GnuPG:

$ cat msg | gpg --list-packet
gpg: encrypted with 2048-bit RSA key, ID 66489556790B2E8E,
created 2018-03-25
      "twitter://lambdafu"
# off=0 ctb=85 tag=1 hlen=3 plen=268
:pubkey enc packet: version 3, algo 1, keyid
66489556790B2E8E
data: [2048 bits]
# off=271 ctb=d2 tag=18 hlen=2 plen=33 new-ctb
:encrypted data packet:
length: 33
mdc_method: 2
# off=306 ctb=cb tag=11 hlen=2 plen=20 new-ctb
:literal data packet:
mode b (62), created 0, name="",
raw data: 14 bytes

Each packet is introduced with a comment line (#) indicating
the offset in the file, the ctb and tag, as well as the
header and packet length. If you look very carefully here,
you can figure out the solution.

Solution: The encrypted data packet starts at offset 271 and
spans 2+33 bytes, so it ends just before offset 306. The
literal data packet follows at offset 306. This means that
the encrypted data packet is not covering the literal data
packet at all!

In comparison, this would be part of the output of a
properly encrypted file:

... (as before up to the encrypted data packet) ...
# off=271 ctb=d2 tag=18 hlen=2 plen=55 new-ctb
:encrypted data packet:
length: 55
mdc_method: 2
# off=284 ctb=cb tag=11 hlen=2 plen=20 new-ctb
:literal data packet:
mode b (62), created 0, name="",
raw data: 14 bytes

Here, the literal data packet starts at offset 284 and spans
2+20 bytes, so it ends just before 306. It is completely
contained within the encrypted data packet, which goes up to
byte 328.

This solution raises new questions:

    What does the OpenPGP standard require of an encrypted
message? Is the above message well-formed?
    How does GnuPG process the message? What other methods
are there to figure out the solution beside --list-packets?
    Why do the email clients render the message as if it
were encrypted?
    Are there related issues in other parts of the system,
known or unknown?
    How can we craft such a message using standard tools?

The OpenPGP message format

OpenPGP, at its core, is a packet based format. A packet
has:

    a type (tag),
    a length (encoded in one of several formats),
    and some content (of the given length).

The content of a packet can be unstructured (such as plain
text or file data) or structured (with fields of fixed or
variable size). Sometimes, a packet can again contain a
sequence of OpenPGP packets. The encrypted data packet is
such a packet, containing usually a compressed data packet
that itself contains a plaintext data packet, but there are
other possibilities.

Here is the composition of a simple, encrypted message
without compression (compare with the output of
--list-packets above):

offset  content
  0     Public-Key Encrypted Session Key Packet
271     Encrypted Data Packet [
    284 Literal Data Packet ]
306     End of file

In contrast, the composition of the cake is slightly
different, moving the literal data packet from inside the
encrypted packet to the outside following it:

offset  content
  0     Public-Key Encrypted Session Key Packet
271     Encrypted Data Packet []
306     Literal Data Packet
328     End of file

Message composition

In OpenPGP, exported keys, messages, and detached signatures
are all specified as sequences of packets of certain types,
in a particular order. Section 11 of RFC4880 specifies the
composition of a message. For our example, we only need a
small part of the complete specification:

   OpenPGP Message :- Encrypted Message | Literal Data
Packet.

   Encrypted Message :- Public-Key Encrypted Session Key
Packet, Encrypted Data Packet.

   In addition, decrypting an Encrypted Data Packet must
yield a valid
   OpenPGP Message.

If read carefully, the OpenPGP standard actually allows an
arbitrary number of nested Encrypted Data packets, but this
seems to be a sloppy oversight, as there is no indication of
any use case for this possibility. The standard does not
specify any uppper limit on the depth of the recursion
(GnuPG caps it arbitrarily at MAX_NESTING_DEPTH=32), and for
compressed data packets this has lead to problems in the
past).
The cake is not well-formed

In any case, the normal message above is well-formed, given
the following productions for the message:

OpenPGP Message
-> Encrypted Message
-> Public-Key Encrypted Session Key Packet, Encrypted Data
Packet

And the following productions for the decrypted data
packet:

OpenPGP Message
-> Literal Data Packet

However, the cake is not well-formed, and there are two
reasons for that.

First, there is no production that creates both an encrypted
data packet and a literal data packet from a single OpenPGP
Message at the same level of nesting.

Second, the Encrypted Data Packet must form a valid OpenPGP
Message after decryption, but in fact it is the zero-length
string, which is not a valid OpenPGP Message at all.
GnuPG should do more input validation

As we have seen, the cake message is not well-formed, and
that would be a good reason for GnuPG to reject it with an
error and reject the decryption result. Instead, it will
happily process what we identified as a sequence of two
OpenPGP messages: one encrypted message, which is
responsible for creating the perception of a fully encrypted
message, and a plaintext message for the actual unprotected
payload.

The truth is that GnuPG already tries to protect against
this kind of problem. Since version 1.4.7, GnuPG is supposed
to stop processing when encountering more than one message
in the input, unless the option --allow-multiple-messages is
given. Unfortunately, the option is a bit of a misnomer. The
actual implementation does not check the number of messages,

Click here to read the complete article

  To: Guest
Guest wrote:

and the next fuckup, this time not as bad, but without
involvement of html:

https://neopg.io/blog/encryption-spoof/

Not everything that looks encrypted, is encrypted
2018-05-28

...

It looks like this allows someone to send a message that appears to be encrypted, but is not. Am I reading that right? Or is there more to it than that?

Not that it's not a problem just wonder if I'm missing something beyond that.



Posted on RetroBBS.
--- Synchronet 3.17a-Linux NewsLink 1.108
Posted on RetroBBS

no, that is it. the problem is smaller than the others, but
still bad for somebody who really needs encryption.
Posted on RetroBBS II

and a third hole, this time in gpg:

" By using a made up file name in the message it is possible
to fake status messages.
Using this technique it is for example possible to fake the
verification status of a signed mail."

Ok, so it is not the apocalypse, but still annoying.

https://lists.gnupg.org/pipermail/gnupg-announce/2018q2/000425.html
Posted on RetroBBS II

  To: Guest
Guest wrote:

and a third hole, this time in gpg:

" By using a made up file name in the message it is possible
to fake status messages.
Using this technique it is for example possible to fake the
verification status of a signed mail."

Ok, so it is not the apocalypse, but still annoying.

https://lists.gnupg.org/pipermail/gnupg-announce/2018q2/000425.html
Posted on RetroBBS II

Annoying and could be deceptive to some users. There will always be bugs but it's good to see them be addressed.

Posted on RetroBBS
--- Synchronet 3.17a-Linux NewsLink 1.108
Posted on RetroBBS

for this case you are right, in the version (2.2.8) this is
fixed. fast reaction.
Posted on RetroBBS II