German ct magazine postulates death of pgp encryption

[Christoph Anton Mitterer]

On Fri, 2015-02-27 at 20:56 +0100, Werner Koch wrote: 
> There is no trust in keyservers by design.  As soon as you start
> changing this you are turning PGP into a centralized system.
Well not necessarily - at least not in the sense of exactly one power
having control over the whole key network (as it would be the case in
X.509).

IMHO the current situation with keyservers isn't perfect:
- Usually (AFAIK), only one of them is used for queries/submissions...
  if that one is evil, that you have a problem (at least until the next
  submission/query).
- Nothing is authenticated (well there is hkps, but the problem here is,
  that one single person holds the control over the effectively only
  used CA... and while I don't think that Kristian is evil ;-) ... it's
  a conceptual problem).
  => thus an attacker can easily do downgrade/blocking attacks... like
  filtering out any revocation certs.
- Nothing is encrypted (so everyone eavesdropping will know that I just
  downloaded the key for nsa-whistleblowers at wikileaks.org... and five
  minutes later I'd be beaten to death).


Ideally, every keyserver would sign his responses (with OpenPGP of
course ;) )... and GnuPG/etc. would ship the keys of (at least some of)
these servers.
This is of course some effort to collect/verify and even then Werner&Co
wouldn't know whether can for example trust me as a keyserver operator
or whether I'm secretly paid by the BND.
But(!) when each request (queries / submissions) would be made to a
handful of randomly chosen keyservers (say 20?), there are good chances
that at least some of them are not evil and any forgery would be at
least noted.

Ideally, gnupg.org would then also run a keyserver, which is always
included in the list.
Why? Well most people don't audit the code of GnuPG, so when they trust
them already with respect to that, they can also trust them with respect
to a keyserver.
And people should be able to specify additional always-in-the-list
keyservers,.. like I would specify my own or ubuntu employees would
specify the one from canonical - if it's running ;) ).


As for the privacy component: The above schema obviously makes
encryption for privacy useless... (an other issues, like keyservers
doing caching, could also make it defeatable).
So I think the way to go here would be Tor.



Cheers,
Chris.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5313 bytes
Desc: not available
URL: </pipermail/attachments/20150227/960c89c4/attachment.bin>