On Thu 2015-06-11 16:25:48 -0400, Werner Koch wrote:
On Thu, 11 Jun 2015 20:27, dkg(_at_)fifthhorseman(_dot_)net said:
An interesting approach would be to look at the existing standard and
common implementations to see whether there is a way to provide a more
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.
hmm... just brainstorming, and all within RFC 4880...
What if you did:
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
How would this be interpreted byexisting implementations?
Alternately, what if C was an entirely new packet type (e.g. "Padding
packet", with a new type assignment). How do existing implementations
deal with such a sequence? Could updated implementations be designed to
ignore/discard the contents of C ? What are the risks of the hidden
channel here? the hidden channel could be constrained by requiring that
padding packets contain a certain required sequence of octets (e.g. all
0s), though that still leaves the hidden channel that is just the size
of the padding used.
Actually, you can't solve that on the OpenPGP protocol level because it
is application specific. In contrast to transport encryption we can't
use filler traffic.
This is similar to meta data and should be solved in that context (or at
the application level).
Certainly the application layer is going to have a better understanding
of the general characteristics of similar messages, and so can make a
better guess at what kinds/patterns of padding make sense in this
context. 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.
--dkg
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp