Re: [Sks-devel] Making keys unusable with spamming similar uids

2016-09-16 Thread Daniel Kahn Gillmor
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

Re: [Sks-devel] Making keys unusable with spamming similar uids

2016-09-16 Thread Brian Minton
-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

Re: [Sks-devel] Making keys unusable with spamming similar uids

2016-09-15 Thread Valentin Sundermann
> 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

Re: [Sks-devel] Making keys unusable with spamming similar uids

2016-09-14 Thread Michael Jones
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