MFPA wrote: > On Monday 23 January 2012 at 3:04:45 PM, Holger wrote: > >> Please simply accept that it's an issue for me as well as many others. >> Harvesting is supereasy: full keydumps are readily available.
Yep, Full keydumps are readily available. http://www.keysigning.org/sks/ Yep, harvesting is is easy. Anyone with a journeyman knowledge of perl and can Google a regexp to match mail email addresses can do it. While a case can be made that harvesting does occur. Several friends believe it occurs as do I. However, testing I did a few years ago found the amount of SPAM attributable to a key on a keyserver was not significantly different from that received as just random SPAM noise from an unused ISP account. I've seen no volume of SPAM since then to challenge that conclusion. Sending a message to an email list such as this will likely result in at least an order of magnitude more SPAM than that attributable to the, IMO apocryphal, bogeyman of keyserver harvesting. > It sounds like you value the flavour of privacy that could be afforded by a scheme involving the use of hashes in UIDs to protect names and email addresses. Such a scheme would (for example) allow somebody with one of your email addresses to locate your key, but would not allow somebody to devine your names or email addresses by inspecting your key. An extension would be required to allow GnuPG to locate keys using both the hash and the plaintext string simultaneously. I wondered when this regular exercise in sadoequinecrophilia would appear. :-( The same issues remain untouched just like the countless other times you've brought up this idea. What are it specifications? Is there any support from the IETF OpenPGP working group? Is there an implementation of your idea? Endlessly and tirelessly repeating the same "Wouldn't it be nice if...," without addressing the issues posed and the questions asked only marks one as a crank or a bore. While we're at it, I'd like low-priced dark beer, a smart good-looking gingerbear boyfriend, and, of course, whirled peas. > Suggestions like this tend to get lambasted because they do not > enhance security, and privacy appears to be seen as unimportant. The ceaseless implication that those who do not agree with your ideas believe that privacy is unimportant is insulting to those who actively work producing code to enhance individual and corporate privacy. Just stop it. Changes to security software that do not increase security are to be examined under heightened scrutiny -- complicating the codebase allows errors to hide. I don't presently support this idea because the questions I've asked about it have yet to be answered. I'm skeptical that I'm ever going to get the details. The idea may have merit -- but most of us have yet to see that merit. I as others are unconvinced that this idea will work, the interoperability and user impact questions remain unanswered. -John (Replies _ONLY_ to the list, please.) -- John P. Clizbe Inet:John (a) Mozilla-Enigmail.org FSF Assoc #995 / FSFE Fellow #1797 hkp://keyserver.gingerbear.net or mailto:pgp-public-k...@gingerbear.net?subject=HELP Q:"Just how do the residents of Haiku, Hawai'i hold conversations?" A:"An odd melody / island voices on the winds / surplus of vowels" _______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users