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, Peter. [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 <http://digitalbrains.com/2012/openpgp-key-peter> _______________________________________________ Gnupg-users mailing list [email protected] http://lists.gnupg.org/mailman/listinfo/gnupg-users
