On Sun, Apr 13, 2014 at 3:30 PM, Hauke Laging
<mailinglisten(_at_)hauke-laging(_dot_)de> wrote:
There are many cases where the size of the message reveals something
about the content, compression or no compression.
Would it help to have to possibility to add a certain amount of
(ignored) random data to an encrypted packet?
In that case an OpenPGP application could – regardless of compression –
be configured (in appropriate situations) to create packets which e.g.
a) have a certain minimum length
b) have a length which is a multiple of a block size (e.g. 1K, 2K but
not 1234 bytes)
Yes, I believe many of the most devastating cases would be addressed
by quantizing the sizes. There may still be cases where the user is
compromised— where the revealing data is only a single bit and where
the sizes put it near a quantization threshold, but the number of
cases where the user's privacy is quietly compromised would be fewer.
I continue to hold the view that an implementation which expects
perfectly informed users to be aware of and avoid subtle,
unadvertised, and format specific information leaks will (and, as I
pointed out, has) fail to produce real users with the advertised and
expected level of security. The great challenge of a general tool is
that you cannot assume a narrow threat model or a sophisticated user.
In some cases the attacker may even be the party specifying the
protocol, relying on subtle behavior the underlying trusted components
(like openpgp) to compromise the system. As a result perfect security
is almost certantly impossible, but there are implementation
optimizations like disabling compression for small messages, where it
is never very useful and sometimes actively harmful, and quantizing
sizes which can provide a practical improvement in a world where users
aren't perfect and attackers don't play nice. I think these
optimizations should be well specified and recommended at the SHOULD
level.
As an aside, I note that RFC6562 SHOULD NOTs variable rate compression
for the application of secure VoIP for highly sensitive information.
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp