A prig is a fellow who is always making you a present of his opinions. -- George Eliot

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

Subject	Author
PGP is not longer safe!	guest
Re: PGP is not longer safe!	Guest
Re: PGP is not longer safe!	AnonUser
Re: PGP is not longer safe!	AnonUser
Re: PGP is not longer safe!	Guest
Re: PGP is not longer safe!	Guest
Re: PGP is not longer safe!	Guest
Re: PGP is not longer safe!	guest
Re: PGP is not longer safe!	anon
Re: PGP is not longer safe!	Guest
Re: PGP is not longer safe!	AnonUser
Re: PGP is not longer safe!	Guest
Re: PGP is not longer safe!	Guest
Re: PGP is not longer safe!	AnonUser
Re: PGP is not longer safe!	Guest

A prig is a fellow who is always making you a present of his opinions. -- George Eliot

rocksolid / Encryption / Re: PGP is not longer safe!