On 12/16/2013 6:11 PM, adrelanos wrote: > When I searched for this on search engines, I haven't found one in a > project's character. (I.e. were it's open for debate/pull > requests/changes.)
Perhaps not, but you *did* find them. Your original email referenced, for instance, the Debian GnuPG migration guide, which makes its own recommendations for what one's gpg.conf file should contain. Websites with their own recommendations for "how to *really* make GnuPG secure" are a dime a dozen; most of them are put up by people who deeply misunderstand GnuPG. (The Debian guide is, fortunately, among the better ones.) > That's the point. I argue, that "we" [hopefully soon telling you the > other name and if not, other supporters sharing my standpoint] > prioritize working solutions which are as secure as possible rather > than waiting for some RFC to finish. Then you need to use some other tool. Alternately, you could create your own GnuPG distribution which installs a gpg.conf file tweaked the way you want it -- but I personally find it unlikely that the changes you seek will be incorporated into GnuPG's master branch. > I'd also suppose [okay, I am risking false consensus here] that > users of other messengers with security in mind... After Richard Nixon was re-elected President in 1972, the _New York Times_ film critic Pauline Kael exploded. "Nixon? Re-elected? That's impossible! Nobody I know voted for Nixon!" Nothing is less trustworthy than our supposition about the feeling of a community far, far larger than we are. > In my opinion, training users to get accustomed to insecure things > and then expecting them to do the right thing when necessary seems > likely to result in many users doing the wrong thing. This is not a vulnerability. Assume, for sake of argument, that my friend has a long key ID of 0xDECAFBADDEADBEEF. I verify the fingerprint, sign the certificate, and thus validate it. Someone else tries to trick me into a collision by sending me a certificate signed with 0xBADD00D5DEADBEEF. My email client automatically downloads the certificate from the server. I now have two certificates with the shortID of 0xDEADBEEF... ... and absolutely zero risk. My email client tells me whether a message is signed by a validated key or an invalid key, so no one can use the (invalid) 0xBADD00D5DEADBEEF key to trick me into believing it comes from the (valid) 0xDECAFBADDEADBEEF key. And when encrypting a message for my friend, GnuPG won't let me encrypt to 0xBADD00D5DEADBEEF because it's an invalid certificate. When certificates are properly verified and validated, the risk from shortID (or even longID) collisions is effectively zero. It's only when one disables key validation checking, or improperly validates certificates, that an attack surface becomes manifest. > Too short for me. Then use something other than GnuPG. PGP was originally "Pretty Good Privacy." Phil Zimmerman named it that for a reason: it's pretty good. It's not perfect and it won't be secure forever. GnuPG is built in that mold. If you need perfect privacy, or forever privacy, you need to look elsewhere. GnuPG offers neither. > So what is the criteria here to say what the minimum system > requirements should be? I imagine it's something like, "If enough people complain to Werner about how GnuPG is no longer usable on their system, Werner will know the system requirements should be lowered." >>> Let's imagine, someone finds a vulnerability in RSA being able >>> to reduce the difficulty for brute force by 1024 bit. >> >> This would be a science-fiction level breakthrough in mathematics. > > Or just just someone having a clever idea no one else had before? > Happens? At some point they're the same thing. The point remains, though, that we can't defend against science-fiction level attacks, nor is it productive for us to try. Because once you start imagining science-fiction level attacks, where does it stop? > I don't know. Why where there 2 bit breakthroughs (happened for some > other algorithm) and not 4 bit? A 2-bit reduction is not a science-fiction breakthrough. A 1024-bit reduction would be. > What about liberating ourselves by forgetting about compatibility at > some point and starting fresh and most secure? In 2000 I was a young software engineer living in San Francisco. I was considering applying for a job at a major, internationally-recognized bank. Before I sent in my resume, though, I talked to a friend who worked there to ask about what kind of work I'd be doing. My friend told me the bank was undertaking a massive clean-slate project to get rid of all their legacy COBOL code and replace it with modern, well-designed, object-oriented Java. I passed on the job. To the managers at that bank, starting over from a clean piece of paper sounded like the sort of thing that really should be done. To a software engineer, it sounds suicidal. Those ancient COBOL applications have been running with near-100% uptime for 50+ years and last had a bug 20 years ago. Getting rid of that is not the sort of thing one does lightly, and never just because it seems like a good time to do a clean-slate rewrite. I think that if you consider this story, you will come up with what I think of the idea of discarding RFC4880 and starting over from a clean slate. :) > Robert, Werner, let me say that I value a lot, that you're discussion > these matters in public without taking offense even though our > standpoints are quite different. (Most likely due to our different > histories, knowledge, believes, etc.) > > Please tell me, what kind of argument would you accept? My father is a federal judge who was asked to join FISA. (He declined.) I believe that, given my close association with the United States government, a lot of people would stop trusting GnuPG if I were to ever take a leadership or development role in GnuPG. For that reason "what kind of argument I would accept" is really kind of irrelevant -- you're trying to convince Werner, not me. All I do is answer questions, dude. :) (Also, it should follow that I am not speaking for Werner, nor for GnuPG! This email contains nothing except my own rambling opinions.) _______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
