Deniability

Ingo Klöcker kloecker at kde.org
Wed Mar 23 20:32:05 CET 2011


On Tuesday 22 March 2011, David Shaw wrote:
> On Mar 21, 2011, at 12:13 PM, Jerome Baum wrote:
> > Hauke Laging <mailinglisten at hauke-laging.de> writes:
> >> You know that. And the archive of this mailinglist now knows that
> >> you have once claimed to do that. So one may assume that the only
> >> recipient is you but that is not a strong technical conclusion
> >> from the message itself.
> > 
> > When I throw-keyids,  what's actually left over? Would  there be
> > any way to match the keys from several messages, besides key size
> > and type? Also if one (size, type) appears in all messages, I'd
> > say the conclusion that I'm using encrypt-to-self is pretty safe.
> 
> In addition to the size and type information, there is also an
> interesting attack that can be done against speculative key IDs.  It
> doesn't (directly) help a third party know who the recipients are,
> but it does let any recipient try to confirm a guess as to who
> another recipient might be.
> 
> Let's say you encrypt a message to Alice and Baker and hide the key
> IDs.  Alice gets the message and knows there is one other recipient
> aside from herself.  She considers who the message came from and
> what the message was about and makes an educated guess that the
> other recipient is Baker.  To confirm her guess, all Alice needs to
> do send a specially rigged speculative key ID message to Baker.  If
> Baker responds, then Alice knows he was the other recipient.
> 
> Throw-keyids has some good usages (posting a message for pickup in a
> public place, for example), but it's just a tool.  It's important
> not to rely solely on it.

Exactly. The obvious solution to this problem would be to send n copies 
of the message to the n recipients each time encrypted to exactly one 
recipient. In fact, that's exactly what KMail does for all BCC'd 
recipients of an encrypted message.


Regards,
Ingo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20110323/4d66f409/attachment-0001.pgp>


More information about the Gnupg-users mailing list