Subject: Re: [openpgp] Disabling compression in OpenPGP

From: Hauke Laging <[email-masked]>
Date: Mon, 14 Apr 2014 00:30:35 +0200

Am Do 20.03.2014, 07:53:22 schrieb Nicholas Cole:

> 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)

Hauke
-- 
Crypto für alle: http://www.openpgp-schulungen.de/fuer/unterstuetzer/
http://userbase.kde.org/Concepts/OpenPGP_Help_Spread
OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5

---

From: Gregory Maxwell <[email-masked]>
Date: Sun, 13 Apr 2014 15:52:53 -0700

> b) have a length which is a multiple of a block size (e.g. 1K, 2K but

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.