On Friday 18 July 2014 21:01:54 Peter Lebbing wrote: > On 18/07/14 15:40, Ingo Klöcker wrote: > > OpenPGP keys are created and uploaded to some key server > > automatically, and they are looked up and used automatically > > This creates a privacy issue with key lookup. It exposes > correspondents to the keyserver, including time-of-use.
Sure. But the NSA already knows the correspondents of all of our mail anyway. Keyserver lookups do not add any additional data (except of the information that you are trying to look up a key resp. that you are talking to a keyserver). Okay, the keyserver owner may collect data. But the keyserver (owner) has to be trustworthy anyway. > Also, you need to define some negative-acknowledge time to live > (terminology borrowed from DNS). If on first contact an address does > not exist at the keyserver, when do you re-check? And since it can, > in unfavourable circumstances, take a while for a public key to > propagate through the keyserver network, if somebody just created an > e-mail address and key and uploaded it, then starts communicating, > people will check a keyserver and not see the key. Now their client > will wait the defined period before re-checking, adding even more to > the propagation delay. So what? My scheme is not supposed to work instantaneously. It is supposed to work eventually, i.e. it will work after the propagation delay has passed. This is way better than our current status quo: No encryption at all for almost all email. > Thirdly, if this is the default mode of operation, I think you need > automatic decryption before storing the mail, because searching mail > is an important feature, and searching encrypted mails a big > usability issue. Good point. Automatic decryption should be possible for those that want it. My scheme is mostly meant as in-transit encryption which again is way better than our current status quo. > An e-mail system with a default big usability issue > will get swapped out for a more pleasant to use one. Exactly. > Finally, I think people might take issue with their e-mail address > automatically being posted to a public keyserver. And if it catches > wind, and many, many people use it, I think spammers might look again > at harvesting addresses versus generating them. Now it's a small pool > to fish from, but if most people have their address on the keyserver > network, the odds might change. How exactly does one harvest email addresses from the keyservers? Can I ask keyservers to give me all keys it has in storage? Or do I need to search for keys matching a certain substring? I honestly don't know. Anyway, if this really becomes a problem than key lookup probably needs to be made as inconvenient as trying to send email probes to randomly generated email addresses. For my scheme to work the keyservers would only need to return keys where the email address part of a uid exactly matches the recipient's email address. Moreover, for my scheme to work no key certification is necessary, i.e. crawling from one key to the next via certification signatures wouldn't be possible. The scheme has more issues: For example, there's no message integrity protection (via signing) whatsoever. But that's the current status quo anyway. Regards, Ingo
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
