jerome at jeromebaum.com
Mon Mar 21 06:48:07 CET 2011
I am looking into the "plausible deniability" issue again that was
discussed here in the past. My problem definition:
Configure gpg in such a way that when I encrypt a file, be it to
someone else or to myself, the recipient(s) can deny being able to
decrypt the file in question. An adversary should also be unable to
derive information about the recipient(s) -- including their number
-- from the encrypted message. Assume I like encrypt-to-self and
have it enabled.
The obvious way to start is with throw-keyids. Problems:
1. The number of recipients is revealed.
2. If I encrypt to only myself, this is revealed.
I could generate some bogus keys and throw out the secrets, effectively
making them "encryption-only" keys. Then to solve #2, I just encrypt to
such a bogus key in addition to my actual key. I could also set the
encrypt-to option for several bogus keys to make the adversary's life
more difficult in determining the number of recipients.
After seeing a number of encrypted messages, the adversary will know for
how many bogus keys I have encrypt-to set. #1 appears again. This could
be solved by randomly picking a subset of the bogus keys, possibly as a
wrapper around gpg. So, both problems can be solved this way, although
it would be annoying to have to put randomly-pick-some-bogus-keys.sh in
I can imagine there are going to be some relatively simple statistical
attacks on this scheme (by looking at algorithms and key-sizes of the
recipients). What do you guys think? What problems and solutions are
Jerome Baum <jerome at jeromebaum.com> 0xC58C753A
Key fingerprint = A0E4 B2D4 94E6 20EE 85BA E45B 63E4 2BD8 C58C 753A
Jerome Baum 0x215236DA
Key fingerprint = 2C23 EBFF DF1A 840D 2351 F5F5 F25B A03F 2152 36DA
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 880 bytes
Desc: not available
More information about the Gnupg-users