User experience of --hidden-recipient encryption

Peter Lebbing peter at
Sun Jan 31 14:03:08 CET 2016

On 31/01/16 13:20, Andrey Utkin wrote:
> Leakage of exact number of hidden recipients can be mitigated by
> adding random number of pseudo-recipients

There is a lot of literature on masking the length of packets with
random padding. It's not as straightforward as it seems. I think this
has anologues, and should not generally be considered a good idea. But
in general, the kind of statistics that go into this kind of research is
beyond me, at least without a serious refresher course. So I don't think
I'm qualified to actually say much about it, other than that I've heard
that it's not generally considered a good idea.

> (e.g. generate some more keys on your localhost and add them to
> recipients).

Is it possible to differentiate between MPI's[1] that are the result of
encryption proper and random noise?[2] I think you can get away with
simple random data. And if not, it seems more economical to just add a
few packets encrypted to one of the public keys used. Each time you
generate a PKESK, it will come out differently, even for the same public
key. The PKCS#1 EME-PKCS1-v1_5 encoding makes use of random padding. So
you could simply include the same public key multiple times as hidden
recipients. I don't see any problem with that, but if there is, you
could include PKESK packets with intentionally malformed data such that
the decrypting application will reject it as "okay, must have used the
wrong key for this packet", even though it was actually the correct key.
I don't know if the architecture of GnuPG would allow for such a
procedure (intentional malformation), and more importantly, I don't
think this is something that should be done anyway. I was just going
with the hypothetical situation that we need dummy PKESK packets, and
observing that dummy public keys seems a bit heavyweight for that purpose.

My 2 rather hyptothetical cents,


[1] Multiple Precision Integers, the base encoding blocks of public key
cryptography for at least many common cryptosystems.

[2] Some situations are impossible: in RSA, a ciphertext greater than
the modulus is obviously impossible, or at least, an invalid encoding.
But! Since this is a hidden recipient, we don't know what the modulus is
since we don't know what the recipient key is. So we can't identify a
too great ciphertext MPI!

I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at <>

More information about the Gnupg-users mailing list