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

[Ximin Luo <[e-mail]>]

On 16/07/13 12:31, Ben Laurie wrote:
> On 3 July 2013 00:22, Ximin Luo <[e-mail]> wrote:
>> To [e-mail],
>>
>> 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.)

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!

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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/openpgp
>>
> _______________________________________________
> openpgp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/openpgp
>