Re: [Sks-devel] Making keys unusable with spamming similar uids
On Fri 2016-09-16 16:17:41 -0400, Brian Minton wrote: > One possibility would be to have the keyserver sort by the time the > key was first seen. That way, there'd be a slightly lower chance of > getting an impostor's key. Going by the creation date is not very > useful, since impostors could create their key with whatever creation > date they like. It would still be insecure without fingerprint > verification, but it would perhaps provide a modicum of security. This goes back to asking the keyservers to operate as trusted parties, though, which is not something we've traditionally asked of keyserver operators. It is also unclear what this means for a new keyserver. When i set up a new keyserver, it sees all existing keys at the same time. and when new keys are introduced, they propagate through the network in different orders. Should the ordering i get back differ from keyserver to keyserver? --dkg signature.asc Description: PGP signature ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] Making keys unusable with spamming similar uids
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 One possibility would be to have the keyserver sort by the time the key was first seen. That way, there'd be a slightly lower chance of getting an impostor's key. Going by the creation date is not very useful, since impostors could create their key with whatever creation date they like. It would still be insecure without fingerprint verification, but it would perhaps provide a modicum of security. -BEGIN PGP SIGNATURE- iF4EARYIAAYFAlfcU0MACgkQN7lQes/yAW5deAD7B0tNzA2BH99qVWvpllWCXP+I Wye6DpjVO+SedSPDwOABAPJoq+x6bepsME8wnvHq5wkaFxJT+hCVkcmzissRoeMK iF4EAREIAAYFAlfcU0QACgkQa46zoGXPuqlsWQD7BiQuUWAqUr7/ueLjwTKoCTKC 32+/S81Tyl5V7rFp9TYA/1Hjk8kfgVnGdVBwf6RROsOm7Ai4nE+f7xZx+4TcFAqt =SQiM -END PGP SIGNATURE- ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] Making keys unusable with spamming similar uids
> as per evil32's demo of 32bit key dupes it's possible to flood these, > but it costs cpu, and even so you can search the keyid-format long value > > eg; > 0x1992274E129BAF74 I only thought of same name, email and comment. Searching with the short/long id and the fingerprint would be still possible. And yeah, if one wants to make the short id unusable too, it's possible to generate keys with that id (although it costs more cpu as you already stated). signature.asc Description: OpenPGP digital signature ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] Making keys unusable with spamming similar uids
On 14/09/16 15:27, Valentin Sundermann wrote: > Hey sks-devel, > > when searching for common terms (i.e. "test") on a keyserver, I > hit a limit of matches sometimes. > > Assumed that I'd be a bad person, I should be able to make a > choosen key unusable by creating and uploading keys with similar > name, email address and so on. If somebody searches for that email > address, he should hit the limit and cannot get the key. (And > yeah, it's still possible to get the key with the exact fingerprint > but I guess it's inconvenient for "normal people".) > > Do I miss something or is it actually possible to make keys > unusable with such an approach? as per evil32's demo of 32bit key dupes it's possible to flood these, but it costs cpu, and even so you can search the keyid-format long value . eg; 0x1992274E129BAF74 > > If it should be possible: I think something like a pagination > should solve it on a simple level (although the user has to scroll > through the pages and identify the right key). And another thing > would be how client implementation would treat pagination... pagination is an interesting idea, and even more so key ordering which is currently ordered by key creation date... changing the search results order would be hard and have politics... as search results order can't be easily changed, pagination does not solve the issue (valid keys will be at the bottom of the pile). the issue being a topic that comes up often enough, what to do with spam... Kind Regards, Mike ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
