ietf-openpgp
[Top] [All Lists]

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

2013-07-16 16:50:02
On 16/07/13 12:31, Ben Laurie wrote:
On 3 July 2013 00:22, Ximin Luo <infinity0(_at_)gmx(_dot_)com> wrote:
To openpgp(_at_)ietf(_dot_)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.)

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
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp

_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp



Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp