mailinglisten at hauke-laging.de
Fri Jun 18 09:13:52 CEST 2010
Am Freitag 18 Juni 2010 02:10:22 schrieb MFPA:
> I don't know how common or uncommon it might be. I just know that, of
> the keys in my keyring of about 400 keys, I have noticed more
> deviations away from my default keyserver to key.asc files than to
> alternate keyservers.
but this is about the share of file URLs in the keyring not the number of file
URLs against the number of alternative key servers.
Another point: With a good auto refresh infrastructure less people might feel
the need to use such a file URL.
> > If your keyservers don't support TLS (I have no idea
> > whether the important ones use it) then you are open to
> > a MitM attack when checking them. If the response is
> > signed then you are not (if you are sure about the
> > signing key :-) ).
> OK, up to a point. But the web of trust should thwart this MitM
> attack. Or am I missing something?
You are missing the kind of attack. The WoT prevents you from being attacked
by modified keys. It does not prevent you from being "attacked" by non-updated
keys. The attacker can send you the file you already have. This is more a DoS
attack with security implications for revoked and added keys and
organizational implications if you need more signatures to verify a key.
> A user with several systems could use common keyrings. Or his own
> local keyserver. Or just export all keys from the keyring he has just
> updated and import them into each of his other keyrings.
Yes but it seems to me that none of that is equally convenient to simply
passing the timestamp file to the other systems. OK, I admit that I have just
considered the case that no keys have to be updated. It makes sense to create
a singed bulk download option, too. First you request the timestamps, next you
request all keys you need to update. That would allow to avoid server accesses
completely by simply passing both signed files (timestamp list and key
> > Several users might
> > even combine their ID wishlist so that only one of them
> > has to ask the keyserver.
> Possibly in a corporate or group setting, where one person could
> refresh the keyring and push the update to his colleagues?
Yes. That would be kind of a caching proxy service. Privacy protection could
be reached by taking "secret" IDs off the list for the "proxy guy". Unrevealed
IDs would be checked directly. If gpg was to be extended by an option to
create an ID list I would suggest the feature to mark keys as not to be
revealed by such update lists.
> I guess there is a risk if the change was a revocation because the key
> has been compromised, and it only reached the bad guy but not the real
> keyserver, and you had only tried to send it to that one server.
Sending to several keyservers does not help if the MitM attack point is on
> > Look at it the other way round: The more keys there are
> > in the keyring the more bandwith is saved. I am
> > convinced that users with large keyrings have enough
> > local storage for that...
> And if they are using a mobile device with limited storage they
> probably aren't using a large keyring?
How large is your keyring file? I assume that for ten checked keyservers the
file for storing the last timestamp for each key and keyserver would not even
have the size of the keyring.
And if there are only 40 KiB of space left on the device then IMHO you simply
have to face the truth: That the wrong device it used for the application
PGP: D44C 6A5B 71B0 427C CED3 025C BD7D 6D27 ECCB 5814
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 555 bytes
Desc: This is a digitally signed message part.
More information about the Gnupg-users