Re: [openpgp] signed/encrypted emails vs unsigned/unencrypted headers

Ben Laurie <ben@links.org> Wed, 17 July 2013 09:43 UTC

Return-Path: <benlaurie@gmail.com>
X-Original-To: openpgp@ietfa.amsl.com
Delivered-To: openpgp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97FFA21F9A1D for <openpgp@ietfa.amsl.com>; Wed, 17 Jul 2013 02:43:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.678
X-Spam-Level:
X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_47=0.6, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dcgkIIF9zlHm for <openpgp@ietfa.amsl.com>; Wed, 17 Jul 2013 02:43:23 -0700 (PDT)
Received: from mail-qc0-x22c.google.com (mail-qc0-x22c.google.com [IPv6:2607:f8b0:400d:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 6A86E21F9963 for <openpgp@ietf.org>; Wed, 17 Jul 2013 02:43:23 -0700 (PDT)
Received: by mail-qc0-f172.google.com with SMTP id j10so970669qcx.17 for <openpgp@ietf.org>; Wed, 17 Jul 2013 02:43:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=LpBKzWGQ0UTeK+W4imMMYSka8tNB8XvQakhhbjDg5Gg=; b=gvydzoCVEXwE82JcwS5wW03rGr9PLHN0gHHlwZ4Y/NQAl5Jccggi1jZL5ncm3hNKH+ UH2UX1kGr766BqsCzBy9dN/x6FxB3G1OE7VtDOQUFgLZNlvLeBrZrYm2j4FlHFwJi0qX kuJ+8HU3w15Ki4a67g84kCStqNxAnoGZWzlYIIculgsd29g4kLk65+LRhJvuuFXiRkkF CvlhIilUeF4fiW+1aYei7bAUV4oaWRkqcXyqElbxT9XcXf2frV4yPwfVusxg5llRSSD0 V11k+FCSUyyulSdFTgo7BClVRHVeLwHqu4Uz1Q2t0ia/Olz8iK425KgaP6WY3oxUsCOL pLLQ==
MIME-Version: 1.0
X-Received: by 10.224.127.137 with SMTP id g9mr8094773qas.4.1374054200556; Wed, 17 Jul 2013 02:43:20 -0700 (PDT)
Sender: benlaurie@gmail.com
Received: by 10.49.19.73 with HTTP; Wed, 17 Jul 2013 02:43:20 -0700 (PDT)
In-Reply-To: <51E5BFFC.1040505@gmx.com>
References: <51D360B2.1070709@gmx.com> <CAG5KPzybcunUE3wO90icgQK5EpWecGa1e5LzL+-57aCWPrqUsw@mail.gmail.com> <51E5BFFC.1040505@gmx.com>
Date: Wed, 17 Jul 2013 10:43:20 +0100
X-Google-Sender-Auth: xXsfFMA_JZpUBZ-LLGh8qM17hXM
Message-ID: <CAG5KPzz-xmGOV8p9h0ho1WKNdEez4M0VvdsQ5JafBpWYntJo3Q@mail.gmail.com>
From: Ben Laurie <ben@links.org>
To: Ximin Luo <infinity0@gmx.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: openpgp@ietf.org
Subject: Re: [openpgp] signed/encrypted emails vs unsigned/unencrypted headers
X-BeenThere: openpgp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Ongoing discussion of OpenPGP issues." <openpgp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/openpgp>, <mailto:openpgp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/openpgp>
List-Post: <mailto:openpgp@ietf.org>
List-Help: <mailto:openpgp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/openpgp>, <mailto:openpgp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Jul 2013 09:43:24 -0000

On 16 July 2013 22:49, Ximin Luo <infinity0@gmx.com>; wrote:
> On 16/07/13 12:31, Ben Laurie wrote:
>> On 3 July 2013 00:22, Ximin Luo <infinity0@gmx.com>; wrote:
>>> To openpgp@ietf.org,
>>>
>>> As per [1] and [2], sign-then-encrypt is only really secure as long as you do
>>> it on *all* the information that forms the message, some of which might be
>>> external to the message data itself. Crucially, this includes the recipient.
>>>
>>> What's the current status of this in the PGP/MIME standard? Is it still a
>>> problem? I notice that email subject headers are in a similar situation, and
>>> users have complained about it.[3] The problem of unencrypted/unauthenticated
>>> recipient is less obvious, so I haven't seen user complaints, but potentially
>>> it is more serious.
>>
>> Not clear why this is an issue? Surely the fact the message is
>> encrypted to the recipient is sufficient?
>>
>
> The signed part does not explicit say who the recipient is. When the initial recipient decrypts the message, they remove this implicit information (the intended recipient). They are then free to encrypt the signed message to a different, *unintended*, recipient. (See [2] I linked previously.)

Ah, I see. I am sure I remember this being discussed before. But I
can't remember where.

> It is possible that I missed something, that PGP sign+encrypt actually does already implicitly add this information to the inner signed (non-forgeable) data. But this is not consistent with my research - I do not see anything in RFC 4880 that would prevent the attack described. I haven't read it in full, so I could be wrong, but the sources I cited previously agree with this, and that's why I emailed this list about it. Please correct me if I am wrong!

I'm not sure what you think the attack is. I get that you end up with
a signed blob that is sent to someone other than the intended
recipient. So what?

You might find sections 3 and 4 of
http://www.apache-ssl.org/tech-legal.pdf helpful.

>
> X
>
> P.S. The GnuPG CLI does not let you decrypt a sign+encrypted file, without also verifying the signature. So, I hoped that it was actually transparently adding the list of encryption recipients to the inner signed data. However this appears not to be the case, which means in theory someone could write a tool to do the surreptitious forwarding attack. I did an experiment, using "a.txt" containing 6 bytes "12345\n". Let's see the results:
>
> # Signed and encrypted data, using gpg --sign --encrypt
> $ gpg --list-packets a.txt.siggpg
> :pubkey enc packet: version 3, algo 1, keyid 68AE6913E59091EC
>         data: [2048 bits]
> :encrypted data packet:
>         length: unknown
>         mdc_method: 2
> :compressed packet: algo=2
> :onepass_sig packet: keyid 860DEF3B8F650B79
>         version 3, sigclass 0x00, digest 8, pubkey 1, last=1
> :literal data packet:
>         mode b (62), created 1373995055, name="",
>         raw data: 6 bytes
> :signature packet: algo 1, keyid 860DEF3B8F650B79
>         version 4, created 1373995055, md5len 0, sigclass 0x00
>         digest algo 8, begin of digest de 4e
>         hashed subpkt 2 len 4 (sig created 2013-07-16)
>         subpkt 16 len 8 (issuer key ID 860DEF3B8F650B79)
>         data: [4096 bits]
>
> None of the inner decrypted packets contain any To: information about any encryption recipients
> - onepass_sig http://tools.ietf.org/html/rfc4880#section-5.4
> - literal data (6 bytes cannot possibly contain To: info)
> - signature packet, version 4 http://tools.ietf.org/html/rfc4880#section-5.2.3
>
> For more evidence, compare this to a non-encrypted signed file, of the same data. The signature-relevant packets are the same in both the encrypted/cleartext versions, and contain no additional information on the encryption recipient.
>
> # Signed clear data, using gpg --sign
> $ gpg --list-packets a.txt.sig
> :compressed packet: algo=1
> :onepass_sig packet: keyid 860DEF3B8F650B79
>         version 3, sigclass 0x00, digest 8, pubkey 1, last=1
> :literal data packet:
>         mode b (62), created 1373994966, name="",
>         raw data: 6 bytes
> :signature packet: algo 1, keyid 860DEF3B8F650B79
>         version 4, created 1373994966, md5len 0, sigclass 0x00
>         digest algo 8, begin of digest ef 3a
>         hashed subpkt 2 len 4 (sig created 2013-07-16)
>         subpkt 16 len 8 (issuer key ID 860DEF3B8F650B79)
>         data: [4095 bits]
>
>>> Although not explicitly mentioned in the previous citations, these are
>>> conceptually the same problem - i.e. you are only executing sign-then-encrypt
>>> on *part* of the data that should be secured. So, I believe that it's possible
>>> to work towards a single clean solution that fixes both problems.
>>>
>>> (Sorry if this has been asked before already, or if the problem has already
>>> been fixed; I did check the list archives but couldn't find anything on a quick
>>> scan, nor a quick session of web searching.)
>>>
>>> X
>>>
>>> [1]
>>> http://crypto.stackexchange.com/questions/5458/should-we-sign-then-encrypt-or-encrypt-then-sign
>>> [2] http://world.std.com/~dtd/sign_encrypt/sign_encrypt7.html#CITEpgp
>>> [3] http://www.mozilla-enigmail.org/forum/viewtopic.php?f=9&t=328
>>>
>>> --
>>> GPG: 4096R/5FBBDBCE
>>> https://github.com/infinity0
>>> https://bitbucket.org/infinity0
>>> https://launchpad.net/~infinity0
>>>
>>>
>>> _______________________________________________
>>> openpgp mailing list
>>> openpgp@ietf.org
>>> https://www.ietf.org/mailman/listinfo/openpgp
>>>
>> _______________________________________________
>> openpgp mailing list
>> openpgp@ietf.org
>> https://www.ietf.org/mailman/listinfo/openpgp
>>
>
>
>
> _______________________________________________
> openpgp mailing list
> openpgp@ietf.org
> https://www.ietf.org/mailman/listinfo/openpgp
>