On Thu 2015-06-11 18:45:24 -0400, vedaal(_at_)nym(_dot_)hush(_dot_)com wrote:
On 6/11/2015 at 5:28 PM, "Daniel Kahn Gillmor"
<dkg(_at_)fifthhorseman(_dot_)net> wrote:
On Thu 2015-06-11 16:25:48 -0400, Werner Koch wrote:
OpenPGP does not define any _content_ padding rules and thus this
can't be implemented. Without a strict standard on this we would
also open a large hidden channel.
.....
A Sym. Encrypted Integrity Protected Data Packet
containing three packets:
B Literal Data packet (message)
C Literal Data packet (padding)
D Modification Detection Code packet
.....
But we can define a padding mechanism within OpenPGP that
application layers could operate, leaving the policy of the padding
mechanism to the layer that knows most about it.
=====
But could it be made backward compatible ?
My proposal above might actually be backward compatible -- have you
tried it with existing implementations? i haven't, i'm just suggesting
it as a possible mechanism. It may turn out that part C needs to be
something other than a Literal Data packet to make it work, but that
might *still* be backward compatible with many OpenPGP implementations,
i haven't checked.
Another possible workaround that would be both backward compatible,
and not tamper at all with the plaintext content, would be to simply
do:
Encrypt, then Sign and Encrypt
this is backward-compatible only in the sense that existing tools can
process it -- but it wouldn't produce the cleartext with:
gpg --decrypt foo.pgp
because you'd need an extra layer of decryption to make that work.
The first layer of encryption provides more than enough beautiful padding.
It's not a question of "enough" padding -- if the padding size is
constant each time, you'll still see the offset. Have you actually
tried this scheme with your "pardon" and "execute" examples? the
difference in size is still visible:
0 dkg@alice:~$ echo pardon | gpg --encrypt -r $PGPID | gpg --sign --encrypt -r
$PGPID > x.pgp
0 dkg@alice:~$ echo execute | gpg --encrypt -r $PGPID | gpg --sign --encrypt -r
$PGPID > y.pgp
0 dkg@alice:~$ ls -l
total 8
-rw-r--r-- 1 dkg dkg 1843 Jun 12 11:19 x.pgp
-rw-r--r-- 1 dkg dkg 1844 Jun 12 11:20 y.pgp
0 dkg@alice:~$
Any analysis of the Sym. Encrypted Integrity Protected Data Packet of
the final [S&E ( E)] message would show a large enough length to be
infeasible to determine the original plaintext length and content.
If you know how many layers of encryption have been done, the length is
still computable.
It's not necessary to change any standards, only to mention it in the
security considerations, with possible simple workarounds, and leave
it up to the user.
If that turns out to be the best way forward, i'm fine with that too.
--dkg
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp