RFE: --update-before-use

David Shaw dshaw at jabberwocky.com
Sun Jun 17 22:18:04 CEST 2012

On Jun 17, 2012, at 7:36 AM, Michel Messerschmidt wrote:

> On Sat, Jun 16, 2012 at 05:32:36PM -0400, David Shaw wrote:
>> Yes, I understand that spreading out keyserver requests can help avoid this sort of tracking, but remember that the keyserver URL feature allows the keyholder to bypass the keyserver chosen by the user, and send the requests anywhere they like.  I don't care how the keyserver round-robins are run if I can get a target GPG to not use them.
>> To really combat tracking, you need to route your keyserver requests through TOR or something similar.
> Even that addresses not all issues. 
> The target keyserver still receives a connection whenever the public 
> key is used by someone. A keyholder may set the keyserver URL to a 
> server under his control to monitor the usa of its public key.

Yes, hence the suggestion to route keyserver requests through TOR.  Then the keyholder knows that someone is requesting his key (and can probably make a fairly good guess matching the request up to a given encrypted message if there are a small number of requests and after each request he gets an encrypted message), but does not know the real IP of the person making the request.

> If that is a good or bad idea certainly depends on your point of view.
> But is does not seem to be a wise default configuration in my mind.

It's the default because without it, the person encrypting to the key may not know that the key has been compromised and should not be used.  If someone does not keep their key on the keyserver network, without a keyserver URL there is no (in band) way for people to know where to get updates from.

Users of course have the ability to turn it off:

  keyserver-options no-honor-keyserver-url

But then of course, the user is responsible for finding updates themselves.

> If such an "automatic update" is added, I'd like to have an additional 
> option to define the maximum update interval. This allows everybody to 
> define his own tradeoff. With a default value of for example 24 hours, 
> public keys are still kept fairly up to date while frequent key usage  
> will not trigger a keyserver request for most crypto operations.

Yes.  I suggested this as well - a "update on each use, but no more often than once a day/week/etc".  It cuts down on the leakage.


More information about the Gnupg-users mailing list