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
signature.asc
Description: OpenPGP digital signature
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp