Re: FAQ? Re: please give us safer defaults for gnupg
On Wed, 18 Dec 2013 16:09, bernh...@intevation.de said: > What about placing this as an FAQ in the wiki.gnupg.org? We have a FAQ which answers a lot of questions around key sizes in “Advanced Topics” section. If something is missing it can easily be added. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
FAQ? Re: please give us safer defaults for gnupg
Am Montag, 16. Dezember 2013 20:42:54 schrieb Werner Koch: > May I suggest to read the archives of just a few weeks to collect the > reasons why suggestions of using SHA-512 are missing the point. Some > folks here must have bleeding fingertips from repeating the arguments > over and over. What about placing this as an FAQ in the wiki.gnupg.org? I believe we can then refine the argument, so it can be understood more easily. signature.asc Description: This is a digitally signed message part. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: please give us safer defaults for gnupg
ved...@nym.hush.com: > On Tuesday, December 17, 2013 at 12:49 PM, "adrelanos" > wrote: > >> >The person who agreed with me: >> >carlo von lynX >> > >> >Also the autor of "15 reasons not to start using PGP". [1] >> > >> >Cheers, >> >adrelanos >> > >> >[1] http://secushare.org/PGP > = > > All of his reasons are easily countered. I don't want to discuss them here in this thread to avoid distraction. My topic: "please give us safer defaults for gnupg" I only provided that as a reference so you're sure which one I am talking about should there be multiple persons with that name. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: please give us safer defaults for gnupg
All of his reasons are easily countered. Looking over it, my impression is that his principal criticism is, "It is not all things to all people." To which my response is -- nothing in this world is, so why should OpenPGP be any different? OpenPGP provides a useful set of capabilities and tools, but if you need it to do something that it clearly doesn't then you need to look elsewhere. To return to the racing metaphor -- my Mustang GT is a hardtop. If I feel like putting the top down and enjoying the wind through my hair, I need to get a different car. This doesn't make my Mustang GT inferior or inadequate, nor does it mean I shouldn't drive my Mustang GT. It just means I need to acknowledge the fact my car is a hardtop. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: please give us safer defaults for gnupg
On Tuesday, December 17, 2013 at 12:49 PM, "adrelanos" wrote: >The person who agreed with me: >carlo von lynX > >Also the autor of "15 reasons not to start using PGP". [1] > >Cheers, >adrelanos > >[1] http://secushare.org/PGP = All of his reasons are easily countered. In the interests of time and space, I'll just address the following ones: 2. The OpenPGP Format: You might aswell run around the city naked. 3. Transaction Data: Mallory knows who you are talking to. 8. PGP conflates non-repudiation and authentication First, as a general approach to encryption and authentication, it's important to recognize that there are several levels why a user may want to encrypt and/or authenticate. The simplest level: [a] It's not really important, but it's nobody else's business either. This is equivalent to sending a message in an envelope rather than a post-card, except that in PGP, it's easier for users to confirm that the sender and the recipient are who they are, than in the case of snail-mail through an envelope, or ordinary e-mail. The next level: [b] It's important, and the sender stands behind the information, and is willing to have the receiver vouch for the signature or send it on with the signature intact, to whoever needs to take action on the information. A more serious level: [c] It's very important, and needs to be kept confidential as to who sent it, who received it, and needs repudiation as to who signed it. There are several ways that, with a little effort, open-pgp can be used to do this. Here is one suggestion: (i) The sender and receiver each generate a key of typical size (2048 or 4096) but do not ever post it to a key server. Instead they exchange it, either in person, or by having it posted encrypted to the intended recipient's key, using the throw-keyid option, to a website or newsgroup that allows encrypted postings. (The reason 'typical size' is mentioned, is that the throw-keyid option does not hide the 'size' of the key, so if you happen to be the only one on the internet who decided to generate a cool atypical key of 3693, it will be pretty obvious who is behind the message, even with the throw-keyid used. It's also possible for someone to intentionally 'frame' you for the message ;-) ). (ii) The sender and receiver also generate a separate signing key that they give to each other, that they can each use, and post it as in (i). (iii) Messages can now be signed with the key generated in (ii), hidden-encrypted to the key generated in (i), put on a small clean usb, and posted anonymously from a public place to the website or newsgroup, and then physically destroy the usb. Depending on how serious the requirements are, the more precautions need to be taken. i.e. generating and decrypting pgp messages only on a machine never connected to the internet and under physical security at all times; posting from different public wifi sites with different laptops, etc. depending on the threat model. To borrow from the racing car analogy used earlier in this thread: GnuPG provides an extremely high performance sturdy vehicle that can be used for ordinary shopping as well as high speed off road chases ... ;-) There are enough capabilities and workarounds in GnuPG, to do almost anything a user wants to do in terms of storing, sending or authenticating any messages or files. Thanks again, to WK and the GnuPG team. vedaal ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: please give us safer defaults for gnupg
Robert J. Hansen: >> We think... > > If you're writing on behalf of a group, I would love to know the name of > the group and the names of its members. Otherwise, I can only assume > you are suffering a mental illness and are speaking for the multiple > voices in your head -- either that or else perhaps you're fighting off a > parasitic infestation and are speaking on behalf of your guests. :) Okay, I've got confirmation to lift the "secret". (I would have had it beforehand, but I am a careful person.) The person who agreed with me: carlo von lynX Also the autor of "15 reasons not to start using PGP". [1] Cheers, adrelanos [1] http://secushare.org/PGP ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: please give us safer defaults for gnupg
On Tue, 17 Dec 2013 00:11, adrela...@riseup.net said: > compatibility, you can never reduce complexity. Less complexity means > more simplicity, thus perhaps more usability. In my experience, projects [ You may want to start getting rid of software which is run on your computer without you being in control of it (noscript seems to be the Anti-virus software counterpart for the Web) ] > Please tell me, what kind of argument would you accept? I guess you'd > like to see loads of happy gpg users, gpg for the masses, etc. Would > numbers convince you? I mean, What if alternative projects such as The next step will be the move to ECC which increases the security while at the same time reducing the computation load and allowing for really short keys (e.g. 32 bytes) > Bitmessage etc. managed to get far more users while gpg passes into > oblivion [while they objectively provide more/less security]? There are many systems with more users than gpg. Actually most systems have more users. Think of Skype, Bittorrent, or even Jabber. I believe GnuPG is still a useful tool, much like zip or tar. As with many infrastructure systems you will notices it only if it stops working. No more off-line credit card processing, hardware supply chains breaks, no way to detect tampered software distributions etc, no way to send account data. It is easy for centralized or semi-centralized systems to get usage statistics, for PGP (and to a less degree for S/MIME) it is much harder to get the figures. There are may keyservers running inside of many companies. Shalom-Salam, Werner ps. As a minor data point that OpenPGP is getting more attention might be the fact that the German Home Office has come around to prominent publish a PGP key at their contact page (576D4411C9AD3034). Funnily wrapped into a ZIP file, though. No hints for S/MIME or other encryption methods. -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: please give us safer defaults for gnupg
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 runnin
Re: please give us safer defaults for gnupg
Robert J. Hansen:>> We think... > > If you're writing on behalf of a group, I would love to know the name of > the group and the names of its members. Understandable. At the moment it's just one person sharing that opinion. [Didn't ask many more yet.] I asked if I am allowed to tell names, probably yes, soon. > Otherwise, I can only assume > you are suffering a mental illness and are speaking for the multiple > voices in your head -- either that or else perhaps you're fighting off a > parasitic infestation and are speaking on behalf of your guests. :) :) >> gnupg still is the most used and most important encryption tool >> in the Free Software community. [1] > > It is definitely not the most-used, and it is likely not the > most-important. OpenSSL is free software, and is used orders of > magnitude more often than GnuPG. I routinely go days without using > GnuPG, but I rarely go even a few hours without accessing an > OpenSSL-secured webpage. > > GnuPG is great, don't get me wrong -- but let's keep the hype in > perspective. :) We don't use OpenSSL to encrypt our mails. I'd suppose, OpenSSL is mostly used by users not being aware of it. While OpenSSL is probably great, the CA implementation is not. And that's another story. I'd always trust gnupg more than OpenSSL, but that's mostly for usability reasons and because no contacts I know are waiting for OpenSSL encrypted messages. >> it is a somewhat usable >> racing car but it unfortunately comes with a limiter and you need to >> find out how to get rid of the limiter first. > > Although you chose this metaphor, I'm not sure that it's a metaphor you > really want to use. I agree, it's not a good analogy. I'll try harder next time. However, I trust you got my point. >> gnupg comes with poor defaults... > > If GnuPG's defaults lead it to being subverted, then I agree it is a > serious problem that will need remedy. However, as near as I can tell > that is not the situation. >> We even have a recommended gpg.conf in torbird's git repo. [2] [3] The >> fact that we even need such a thing is bad. > > For as long as GnuPG has existed people have been saying "use this > gpg.conf file that I wrote in order to get the most security." 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.) > Very > often these 'recommended' gpg.conf files are in conflict with someone > else's 'recommended' gpg.conf file. > >> For example cert-digest-algo why is it in gpg still sha1 and not sha256 >> or sha512? > > Interoperability. SHA-1's long-term prospects are not particularly > good, but for now it is the only MUST digest algorithm in RFC4880. The > people developing RFC4880 are well aware of this problem and the choice > of digest algorithms will be addressed in the next revision of the > standard. 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. [Let's forget about the we until I maybe finished the letter after clearing up some points.] I'd also suppose [okay, I am risking false consensus here] that users of other messengers with security in mind, such as bitmessage, pond, retroshare, OTR [and probably others I am not aware of or have forgotten] have a similar view on this. > Until that new revision is published, GnuPG is choosing to > maximize interoperability. This is very unfortunate. >> Now that a few people know, that short key ids can be easily >> forged [4], why isn't the keyid-format set to 0xlong by default? > > Convenience. You should always use a long key ID to retrieve a key, but > there's nothing wrong with using a short ID to refer to an > already-validated key. The main risk of short ID collisions comes from > people pulling the wrong certificate off the keyservers and mistakenly > using that one; but when it comes to using keys you have already > downloaded and validated the risk is minimal. 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. >> Update: now that long key ids can also be forged [8], why not show the >> full fingerprint by default? > > Convenience. See above. >> And why does gpg still create 2048 bit keys, if creating 4096 keys >> just takes a few seconds longer and virtually make no difference when >> using >> these keys? > > NIST's recommendation is that a 2048-bit key will be sufficient for the > next 30 years. Too short for me. I don't want anyone to dig up what I did 30 years ago. Stuff that hasn't been deliberately stored in meanwhile should be forgotten. > ENISA concurs in this judgment (although they recommend > 3072-bit keys for reasons that are not particularly relevant here). RSA > Data Security also
Re: please give us safer defaults for gnupg
Werner Koch: > On Mon, 16 Dec 2013 18:37, adrela...@riseup.net said: > >> [This was originally planed as an open letter, but I thought it might >> be better to hear your arguments beforehand.] > > May I suggest to read the archives of just a few weeks to collect the > reasons why suggestions of using SHA-512 are missing the point. I'll do. > Some > folks here must have bleeding fingertips from repeating the arguments > over and over. I apologize if I haven't searched thoroughly enough in past and have missed the thread suggesting to crank up the default. I can imagine that running a project as this requires nerves of steel. > Having said this, I like to appreciate that you have such a trust in us > GnuPG hackers in that our coding practice and development environment is > bug free at a level that only cracking algorithms is the danger to your > data. I think Adi Shamir was it who said: "Nobody breaks crypto > algorithms; they work around the crypto". ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: please give us safer defaults for gnupg
We think... If you're writing on behalf of a group, I would love to know the name of the group and the names of its members. Otherwise, I can only assume you are suffering a mental illness and are speaking for the multiple voices in your head -- either that or else perhaps you're fighting off a parasitic infestation and are speaking on behalf of your guests. :) gnupg still is the most used and most important encryption tool in the Free Software community. [1] It is definitely not the most-used, and it is likely not the most-important. OpenSSL is free software, and is used orders of magnitude more often than GnuPG. I routinely go days without using GnuPG, but I rarely go even a few hours without accessing an OpenSSL-secured webpage. GnuPG is great, don't get me wrong -- but let's keep the hype in perspective. :) it is a somewhat usable racing car but it unfortunately comes with a limiter and you need to find out how to get rid of the limiter first. Although you chose this metaphor, I'm not sure that it's a metaphor you really want to use. I am an amateur racer. (My suicide ride of choice is my Mustang GT.) This is exactly the behavior I want in a race car and exactly what I *don't* want a novice driver to do. A novice driver should be put behind the wheel of a limited vehicle, and those limitations should not be removed until such time as the driver demonstrates his or her skill behind the wheel. I will not share a track with you at 225kph without first seeing you demonstrate your skills at 150kph. The idea of giving a powerful and non-limited tool to a new user is sort of like putting a new driver behind the wheel of a Jaguar XJ220. Within an hour you'll have a dead driver and a smoking wreck that used to be worth half a million quid. What you call "limits" are, in reality, carefully chosen behaviors meant to keep new users safe from their own mistakes. I do not believe it is wise or ethical to tell new users they need to erase their margin for error. gnupg comes with poor defaults... If GnuPG's defaults lead it to being subverted, then I agree it is a serious problem that will need remedy. However, as near as I can tell that is not the situation. We even have a recommended gpg.conf in torbird's git repo. [2] [3] The fact that we even need such a thing is bad. For as long as GnuPG has existed people have been saying "use this gpg.conf file that I wrote in order to get the most security." Very often these 'recommended' gpg.conf files are in conflict with someone else's 'recommended' gpg.conf file. For example cert-digest-algo why is it in gpg still sha1 and not sha256 or sha512? Interoperability. SHA-1's long-term prospects are not particularly good, but for now it is the only MUST digest algorithm in RFC4880. The people developing RFC4880 are well aware of this problem and the choice of digest algorithms will be addressed in the next revision of the standard. Until that new revision is published, GnuPG is choosing to maximize interoperability. Now that a few people know, that short key ids can be easily forged [4], why isn't the keyid-format set to 0xlong by default? Convenience. You should always use a long key ID to retrieve a key, but there's nothing wrong with using a short ID to refer to an already-validated key. The main risk of short ID collisions comes from people pulling the wrong certificate off the keyservers and mistakenly using that one; but when it comes to using keys you have already downloaded and validated the risk is minimal. Update: now that long key ids can also be forged [8], why not show the full fingerprint by default? Convenience. See above. And why does gpg still create 2048 bit keys, if creating 4096 keys just takes a few seconds longer and virtually make no difference when using these keys? NIST's recommendation is that a 2048-bit key will be sufficient for the next 30 years. ENISA concurs in this judgment (although they recommend 3072-bit keys for reasons that are not particularly relevant here). RSA Data Security also concurs. Given the vast majority of cryptologic think-tanks in the world believe 2048-bit RSA will be secure for the next 30 years, GnuPG has taken the reasonable position of defaulting to 2048-bit RSA. With respect to "if creating 4096-bit keys just takes a few seconds longer and virtually make no difference when using these keys," as several people here have attested to in the past it makes a big difference for many users. Mobile devices... embedded systems... sites that do bulk encryption... mailing lists... the list goes on. For the sake of argument, let's take it for granted, that 2048 bit is still secure enough and can not be broken with brute force. It is not necessary to take it for the sake of argument. Compelling thermodynamic arguments exist that say we will not break 2048-b
Re: please give us safer defaults for gnupg
On Mon, 16 Dec 2013 18:37, adrela...@riseup.net said: > [This was originally planed as an open letter, but I thought it might > be better to hear your arguments beforehand.] May I suggest to read the archives of just a few weeks to collect the reasons why suggestions of using SHA-512 are missing the point. Some folks here must have bleeding fingertips from repeating the arguments over and over. Having said this, I like to appreciate that you have such a trust in us GnuPG hackers in that our coding practice and development environment is bug free at a level that only cracking algorithms is the danger to your data. I think Adi Shamir was it who said: "Nobody breaks crypto algorithms; they work around the crypto". Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
