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 ?
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
The first layer of encryption provides more than enough beautiful padding.
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.
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.
(Don't you guys already have more than enough work ? ;-) )
vedaal
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp