Encryption on Mailing lists sensless?

[Schlacta, Christ]

On Nov 21, 2014 8:55 PM, "Ingo Klöcker" <kloecker at kde.org> wrote:
>
> On Thursday 20 November 2014 14:36:35 Schlacta, Christ wrote:
> > On Nov 20, 2014 1:58 PM, "Ingo Klöcker" <kloecker at kde.org> wrote:
> > > On Tuesday 18 November 2014 22:43:18 MFPA wrote:
> > > KMail encrypts an individual copy for each BCC recipient. I thought
> > > Thunderbird+Enigmail would also do this.
> > >
> > > Any mail client not doing this completely subverts BCC (unless
> >
> > --throw-keyids
> >
> > > or --hidden-recipient is used, but even throwing the key IDs still
leaks
> >
> > the
> >
> > > number of hidden recipients).
> >
> > There's nothing preventing a list server or mail client from
intentionally
> > adding a pseudo random quantity of invalid or junk keys to the recipient
> > list, thus obfuscating the number of additional recipients, only
providing
> > an upper bound to the estimate.
>
> Adding additional junk keys doesn't help if the recipient (or the
recipients)
> expect a certain number of recipients. If the message is encrypted to more
> than (expected number of recipients)+1 (for encrypt to sender) then the
> recipients most likely will wonder who the other recipients are. You'll
have a
> hard time convincing them that the "other recipients" are just fakes to
> confuse a third party intercepting the messages.

Perhaps a future version of the pgp specification should say something akin
to gpg should always add a number of junk keys, perhaps to pad the key list
out to one from a list of constant sizes, just to ensure that nobody can
know for sure how many recipients there are (except the sender), and can at
best place an upper bound. Perhaps the valid keys should be placed
pseudorandomly throughout the constant sized key table
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20141121/19a4cab5/attachment-0001.html>