Re: riseup.net OpenPGP Best Practices article
This will be my last on the thread. You've said several times that your interest is in making sure crypto isn't the weak link in the chain. Well, it's not. We know it's not. (And not just because of XKCD, either.[*]). Roughly one in four desktop PCs is already exploited. Applications are a seething morass of Metasploit targets. Physical access trumps all and that the government is skilled at using Van Eyck devices, black bag teams, subpoenas, national security letters, and more to get what they want. Organized crime has even fewer scruples and nothing's off the table for them, including field expedient dentistry. Given what a target-rich environment the net is, the difference between a 3DES level of keyspace and an AES256 level of keyspace does not matter a tinker's damn to whether your communications are safe. I want to emphasize this: the changes that you are passionately arguing about *do* *not* *matter*. And passionate argument about things that don't matter is... bikeshedding. No more bikeshedding. My final statements about this thread: * I've seen very little support from the list for your proposed best practices document, * I conclude the community's sentiment is that the defaults are good, * The FAQ will continue to recommend people use the defaults. [**] [*] http://xkcd.com/538/ [**] as always, Werner gets final say! signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: riseup.net OpenPGP Best Practices article
On 06/28/2014 12:09 AM, Robert J. Hansen wrote: When faced with that, it's only a matter of time until Alice decides to put 3DES first in her own preference list. And then all her communications to Bob have 112 bits of keyspace, not the 256 Bob demands. I think you're talking about personal-cipher-preferences here, which Alice uses to govern the cipher she uses. Note that she could even put IDEA first here. Are you suggesting that she *removes* all other cipher algorithms from her advertised preference list as well, or does she actually advertise all ciphers her openPGP implementation is capable of? And unless Bob is paranoid enough to check the symmetric algorithm used on every single encrypted message, Bob will never know that Alice's communications to him have been degraded. well, OK. Alice could also publish the cleartext on her blog, and Bob would never know it if he doesn't read her blog. Bob can't control what Alice does; what he can do is to advertise his preferences in a cryptographically-verifiable way, and set *his own* personal-cipher-preferences to prefer stronger ciphers. then, unless Alice has actively removed all ciphers from her advertised preferences except for 3DES, Bob's personal-cipher-preferences will take precedence in the messages that he sends. I feel like i shouldn't have to point this out, but: * This is what the best practices page we've been discussing is suggesting. This is the right thing to do, and Bob should do it, regardless of whatever bad advice Alice has bought into. Arguing that it's hopeless/pointless/harmful to prefer stronger ciphers yourself because one of your correspondents might be tricked into disabling stronger ciphers makes no sense from either a security or interoperability perspective. I'm really sorry to hear about your graduate student debt, Rob, but this is not the best way to pay it off :P Werner and others are absolutely right: there is no *technical* way to degrade things to 3DES. But given that cipher preference lists are fundamentally a *human* decision, well... the human being is always exploitable. Of course. And we should make our defaults better and encourage stronger mechanisms for everyone, instead of trying to claim that using well-known, widely-adopted, clearly-specified, longstanding algorithms is somehow breaking the spec. I'm sure you're not trying to claim that AES is actually a worse cipher than DES, or that members of the SHA-2 family are actually worse digests than SHA-1. So i think the scenario you paint above reinforces the points made by the riseup best practices document. --dkg signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: riseup.net OpenPGP Best Practices article
I think you're talking about personal-cipher-preferences here, which Alice uses to govern the cipher she uses. Correct. Note that she could even put IDEA first here. Sure, but it wouldn't take unless Bob had IDEA in his preference list. If Bob's preference list is AES256 CAMELLIA256 3DES, then if Alice's choice of IDEA will be ignored. The choice of 3DES won't be, which is why 3DES is relevant here. actually advertise all ciphers her openPGP implementation is capable of? I'm saying only that she puts 3DES ahead of Bob's preferred 256-bit ciphers in her personal-cipher-preferences. Bob is all about I must have at least 256 bits of keyspace in all my email! But Bob can't do that, because Alice can *always* degrade him to 112 bits by choosing 3DES. And since Bob is the target, and since we're assuming the enemy is well-financed and professional and capable of tricking people, Bob needs to stop thinking he can somehow guarantee 256 bits of keyspace in his emails. Bob can guarantee 256 bits of keyspace in *what he generates*. Bob cannot guarantee 256 bits of keyspace in *what he receives*. Telling people to use extremely large keys because then your correspondents will be using RSA-ungodly, which has an effective something-ridiculous keyspace sounds nice, but it's not true. Bob can only guarantee up to 112 bits of keyspace in the traffic that gets sent to him, because Bob can't prohibit his correspondents from using 3DES. Anyone who simply, glibly, says use long certificates because they give a larger effective keyspace, is committing fraud, IMO. You're making promises that aren't true and which you can't back up. Using long certificates *may* give a larger effective keyspace, but really, you can only ever be certain of 112 bits of keyspace, so you should design your security model such that it only relies on 112 bits of keyspace is accurate. But I think if long certificates were to be marketed that way, a lot of people would blink a few times and ask, well, what's the point, then? signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: riseup.net OpenPGP Best Practices article
On 07/04/2014 12:08 AM, Robert J. Hansen wrote: Bob is all about I must have at least 256 bits of keyspace in all my email! But Bob can't do that, because Alice can *always* degrade him to 112 bits by choosing 3DES. Of course. And Alice can always send Bob cleartext too. does that mean that Bob shouldn't offer any encryption key at all because there's no guarantee that it will be used? And since Bob is the target, and since we're assuming the enemy is well-financed and professional and capable of tricking people, Bob needs to stop thinking he can somehow guarantee 256 bits of keyspace in his emails. stronger keys are not about guaranteeing any particular level of security -- they are about *permitting* that level of security (or, more likely, about providing that much larger of a buffer against unknown mathematical advances), should the other actors in the game do something different. GnuPG's current default of a 2048-bit RSA key is roughly 103-bit symmetric equivalent. When using keys of that size, breaking the key is more likely to be accessible to a well-funded attacker than breaking the symmetric cipher itself. And consider the value of the different parts of the cryptosystem: breaking the asymmetric key lets you break all the ciphertexts ever encrypted to that key, whereas breaking the symmetric cipher only allows access to a single ciphertext... Using long certificates *may* give a larger effective keyspace, but really, you can only ever be certain of 112 bits of keyspace, so you should design your security model such that it only relies on 112 bits of keyspace is accurate. Except that you can't even rely on 112 bits of keyspace at all. even if alice doesn't just send cleartext, she could select bad keys for 3DES, or have a compromised RNG, or lots of other failure modes. You can't be certain of any of it. What you *can* do is offer stronger keys so that the buffer against attack is able to be larger should the other aspects hold up. But I think if long certificates were to be marketed that way, a lot of people would blink a few times and ask, well, what's the point, then? let's look at it the other way: if you do assume that the symmetric ciphers in use give you 112-bit security, wouldn't a lot of people blink a few times and ask well, why would use an asymmetric key with 1/500th the resistance to brute force attack? --dkg signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: riseup.net OpenPGP Best Practices article
Of course. And Alice can always send Bob cleartext too. does that mean that Bob shouldn't offer any encryption key at all because there's no guarantee that it will be used? It means Bob should have a line item for that in his security model. Alice may send me cleartext. It also means Bob should have a line in his security model, Even if Alice correctly uses OpenPGP to encrypt her email to me, I can only rely on 112 bits of keyspace. stronger keys are not about guaranteeing any particular level of security -- they are about *permitting* that level of security (or, more likely, about providing that much larger of a buffer against unknown mathematical advances), should the other actors in the game do something different. I love this idea: permits. Who permits it? When designing a system, you must assume that anything that's not a game-over is under the enemy's control. You're relying on *the enemy permitting it*. If I'm trying to break your traffic, Daniel, the last thing I'll do is tackle even 80-bit crypto. Seriously. Life's too short. But if I have to, the very first thing I'll do is find a way to degrade you into using an inferior level than your model expects. I'll go after Alice. I'll find some way to convince her to shift to 3DES. And just like that, I, the enemy, will revoke your permission to have 256-bit crypto on the Alice-you link. You'll have 112, because that's what I'll allow. GnuPG's current default of a 2048-bit RSA key is roughly 103-bit symmetric equivalent. According to one group; according to NIST, it's 112. That's quibbling, though: a factor of 2**9 is irrelevant. Except that you can't even rely on 112 bits of keyspace at all. even if alice doesn't just send cleartext, she could select bad keys for 3DES, or have a compromised RNG, or lots of other failure modes. Sure, but this requires me to compromise Alice's box and violates the game-over assumption that the endpoints are secure. let's look at it the other way: if you do assume that the symmetric ciphers in use give you 112-bit security, wouldn't a lot of people blink a few times and ask well, why would use an asymmetric key with 1/500th the resistance to brute force attack? Because (a) according to NIST they're equivalent, (b) nine bits is irrelevant, and (c) if you check the archives you'll discover I've been rather kind to RSA-3072; it's beyond that where I've always said oh, give me a break already. signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: On the advisability of stronger digests than SHA-1 in OpenPGP certifications [was: Re: riseup.net OpenPGP Best Practices article]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi On Friday 27 June 2014 at 11:35:00 PM, in mid:a2f8dba9-1da7-47a6-bc79-cfaea3b02...@jabberwocky.com, David Shaw wrote: Incidentally, since subkeys have come up in this thread, I seem to recall a few strange bugs with 8.x (8.0? 8.1?) that make it difficult to use if the key you are encrypting to has a signing subkey. 8.x didn't always handle signing subkeys properly, so could end up failing to encrypt (it wasn't 100% of the time - it depended on which subkey was dated first). If anyone is curious, I'll dig out my notes for this. I submitted the bug to PGP, and I know it was fixed in a later version. My recollection is that PGP 8.x would always try to encrypt to the newest subkey, and encryption would fail if the newest was a signing subkey. I had 8.0.3 and 8.1; if memory serves, both had this issue - signing subkeys were fairly new at the time. - -- Best regards MFPAmailto:2014-667rhzu3dc-lists-gro...@riseup.net Never lean forward to push an invisible object. -BEGIN PGP SIGNATURE- iPQEAQEKAF4FAlOuiQVXFIAALgAgaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldEJBMjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0 N0VDQTAzAAoJEKipC46tDG5pkWMD/Rcv4i/MDuEQ5gujWhAjiKQimX9K0gZ8XaqZ 0zHcyHUDdUGkKHhaV9c4C3vkTkPKpZpTLhv6n5ADTHf4f1ggaZiwo48sI3aJ34O+ egbYC0AIyl8sw+aj/o54/bH6z+tsYH9pEH9dSl8Z/9NPi/vsjQpf/nK4bT+PAVnW KbUR8+Vr =Vmtp -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: On the advisability of stronger digests than SHA-1 in OpenPGP certifications [was: Re: riseup.net OpenPGP Best Practices article]
On Jun 28, 2014, at 5:20 AM, MFPA 2014-667rhzu3dc-lists-gro...@riseup.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi On Friday 27 June 2014 at 11:35:00 PM, in mid:a2f8dba9-1da7-47a6-bc79-cfaea3b02...@jabberwocky.com, David Shaw wrote: Incidentally, since subkeys have come up in this thread, I seem to recall a few strange bugs with 8.x (8.0? 8.1?) that make it difficult to use if the key you are encrypting to has a signing subkey. 8.x didn't always handle signing subkeys properly, so could end up failing to encrypt (it wasn't 100% of the time - it depended on which subkey was dated first). If anyone is curious, I'll dig out my notes for this. I submitted the bug to PGP, and I know it was fixed in a later version. My recollection is that PGP 8.x would always try to encrypt to the newest subkey, and encryption would fail if the newest was a signing subkey. I had 8.0.3 and 8.1; if memory serves, both had this issue - signing subkeys were fairly new at the time. Yes, that was it. It got particularly strange when someone was using an RSA signing subkey or auth key (as they would do if they had a smartcard). In that case, the PGP encryption would actually succeed (after all, RSA is capable of it, despite what the key flags instructed for use) but the GnuPG recipient would be unable to decrypt as from their perspective, that key was sign or auth only. I put a limited workaround in GnuPG at the time - that's why the encryption key is always written to the card after the auth key (so the encryption key would always be the newest. Of course, that didn't handle existing keys. The real fix was needed in PGP, and it was fixed. David ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: riseup.net OpenPGP Best Practices article
On Thu, 26 Jun 2014 23:36, r...@sixdemonbag.org said: on the key. For any OpenPGP certificate, you can send it 3DES-encrypted traffic and be in complete accordance with the spec and the recipient's preferences. Assuming the sender uses a decent implementation, the attacker must have been able to modify the senders system by changing the code or the config files. This requires write access to the machine; with that an attacker has thousands of ways to tap the communication. Degrading to the still good 3DES is an option which is even not very promising. 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
Re: On the advisability of stronger digests than SHA-1 in OpenPGP certifications [was: Re: riseup.net OpenPGP Best Practices article]
Robert J. Hansen: On 6/26/2014 5:57 PM, Daniel Kahn Gillmor wrote: PGP 8 was released over a decade ago, that's hardly a modern implementation: And yet, it still conforms (largely) to RFC4880. Methinks you're objecting because it's a largely-conforming implementation that doesn't have good support for SHA256. ;) In what ways is its support for SHA-256 limited? I'm having a hard time finding documentation for it. If I recall correctly, it can understand SHA-256 but not generate SHA-256. SHA-256 generation support was added late in the 8.x series, but earlier 8.x releases could understand it. How many people use it? It's not as if there are Nielsen ratings for these things. All I can do is say that I still regularly encounter it when I talk to people about PGP. For instance, I know of one law firm that purchased a site license for 8.x and refuses to upgrade, since the more recent editions cost a fortune in per-seat licenses and have very little in the way of new functionality. i think the point daniel is making is that there is freely available software which is actively maintained and receives security updates and is not a decade old any modern OS can utilise thunderbird + enigmail as an example there's great work done to bring gnupg to windows with gpg4win why *wouldn't* you use it ? is it really a case of obdurateness, if it ain't broke don't fix it, or an unwillingness to use and get accustomed to something new and/or different, perhaps a new gui - look, i completely sympathise with the latter especially for older people if i may generalise if you're a windows user you'll have to upgrade after 10 years if you want to keep safe or pay ($) for it; ok, now i sympathise with people not wanting a new gui with windows 8 Why should anyone cater to users of PGP 8.x in 2014 when we have an opportunity to provide a stronger cryptographic baseline for everyone else? Because there are still people using it. see above the don't *have* to but, sure, they *can* Remember, GnuPG also supports most of RFC1991 because we've got a large base of PGP 2.6 users who are refusing to upgrade... ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: On the advisability of stronger digests than SHA-1 in OpenPGP certifications [was: Re: riseup.net OpenPGP Best Practices article]
On 6/27/2014 at 9:59 AM, shm...@riseup.net wrote: is it really a case of obdurateness, if it ain't broke don't fix it, or an unwillingness to use and get accustomed to something new and/or different, perhaps a new gui - look, i completely sympathise with the latter especially for older people if i may generalise if you're a windows user you'll have to upgrade after 10 years if you want to keep safe or pay ($) for it; ok, now i sympathise with people not wanting a new gui with windows 8 Why should anyone cater to users of PGP 8.x in 2014 when we have an opportunity to provide a stronger cryptographic baseline for everyone else? Because there are still people using it. = And it supports/promotes wider cryptography usage ... We, (the Cryptography community in general, and the GnuPG community in particular) want to encourage more widespread cryptography use, and to have newbies who finally take the step of using it, to then find problems in e-mailing other users of different programs because of incompatibilities it could be discouraging enough to just stop using it before one has had a chance to appreciate what it can do, and come to love it. Many thanks to WK and the GnuPG development team for taking the trouble to provide backward compatibility even as GnuPG grows better and more robust. vedaal ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: On the advisability of stronger digests than SHA-1 in OpenPGP certifications [was: Re: riseup.net OpenPGP Best Practices article]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 06/27/2014 03:54 PM, shm...@riseup.net wrote: Robert J. Hansen: On 6/26/2014 5:57 PM, Daniel Kahn Gillmor wrote: PGP 8 was released over a decade ago, that's hardly a modern implementation: And yet, it still conforms (largely) to RFC4880. Methinks you're objecting because it's a largely-conforming implementation that doesn't have good support for SHA256. ;) In what ways is its support for SHA-256 limited? I'm having a hard time finding documentation for it. If I recall correctly, it can understand SHA-256 but not generate SHA-256. SHA-256 generation support was added late in the 8.x series, but earlier 8.x releases could understand it. How many people use it? It's not as if there are Nielsen ratings for these things. All I can do is say that I still regularly encounter it when I talk to people about PGP. For instance, I know of one law firm that purchased a site license for 8.x and refuses to upgrade, since the more recent editions cost a fortune in per-seat licenses and have very little in the way of new functionality. i think the point daniel is making is that there is freely available software which is actively maintained and receives security updates and is not a decade old any modern OS can utilise thunderbird + enigmail as an example there's great work done to bring gnupg to windows with gpg4win why *wouldn't* you use it ? You won't convince a corporate IT department in a Law firm (or for that matter Financial world) about it. They want SLAs and support, and who knows what custom addons they have for their Outlook setup for various functions that makes it impractical to switch to Thunderbird (does it support Exchange these days?) - -- - Kristian Fiskerstrand Blog: http://blog.sumptuouscapital.com Twitter: @krifisk - Public PGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 - Aut disce aut discede Either learn or leave -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJTrYZRAAoJEPw7F94F4TagJ9oP/iLH583l4fsswhnqPx74u5kg 2Z5OaKzHdqbIza7o3mIoUQ0Y5UF06ipDkQT0YnBz6kVKrwdtbfKvETgz7DndYUyu BfdXHgF0WfMiupdrAz0mqt5nBaD8JCcnwkKkHK5fas1rXHzopzjwp738GPw6gbF2 29QtUFMNYbs/vP7PmKFQStJhVPxYr8w86EbjgAAlM4/q2QPxYUkL3fTTLWLB41ar hVt1vtRKUXzZP1WM3QGeqlCNHJVL7o3PwyUWGlAGz+HCgucPsfosYZSLAzW7ApLq 1oOlbJyxp5W19O5EQhbb3fN+sovy4tpJjnYYsmXztcLaqZRZO8U+q8GcFAMYJY0T +AQmJhpCdntYbCGQQJJdty+LlS9YYt07Ei/CIOAPssLowHWVzUplU/ZdtB5jLAue Tp/9uTHUudZg1OtZXkxYhKTNfTCj8QiGS0wBv1YCGqXe9XUq4xvkHgRaQCa7YDJg AMfLZxGSJfF35HWs21AP+NbMs24QUY1Med66lq30wJjJt9/FaoHlk7nT9OUU3Eu/ 7CEL56wiwHBdrf8jpuqiMoWBa7H4uj6+5+WgKph4ZLWsHaqslkGxp6S4uvUsN7mC 0W2TYK+xzztKhpFq+H0IWe87oxM98svM+rtck1rabRjnjkMZRGH70m6C5Z9PelRc Bz7nkPUpqiPbU5YISumS =Fath -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: On the advisability of stronger digests than SHA-1 in OpenPGP certifications [was: Re: riseup.net OpenPGP Best Practices article]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi On Friday 27 June 2014 at 3:57:25 PM, in mid:53ad8655.4090...@sumptuouscapital.com, Kristian Fiskerstrand wrote: You won't convince a corporate IT department in a Law firm (or for that matter Financial world) about it. They want SLAs and support, and who knows what custom addons they have for their Outlook setup for various functions that makes it impractical to switch to Thunderbird (does it support Exchange these days?) I'm sure somebody is more than willing to sell them these things. - -- Best regards MFPAmailto:2014-667rhzu3dc-lists-gro...@riseup.net Ultimate consistency lies in being consistently inconsistent -BEGIN PGP SIGNATURE- iPQEAQEKAF4FAlOtwUlXFIAALgAgaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldEJBMjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0 N0VDQTAzAAoJEKipC46tDG5pIv8EAJJHPI9KCl2/qnHnMvsUq3FXEqfQXoFUlcSm M9bZh1OApER1c5Lz6SPKk6nX9XitmYRPckJF6Z3QZ/708vh3p5yKjs12a4VEF13D +2Hmx1DzF7odyc1s2/VKrneyEpMnkg1wz1aezFmToepyLvDVvjb0p9DrwupxYKgg tqe1iYfz =I+/f -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: riseup.net OpenPGP Best Practices article
On 26.06.2014 23:28, Paul R. Ramer wrote: On June 26, 2014 8:26:16 AM PDT, Daniel Kahn Gillmor d...@fifthhorseman.net wrote: As for arguments about use on smartcards -- if you plan to get a smartcard, and you have a primary key that is too large for it, you can always generate and publish new subkeys that will fit in your smartcard. If that's the tradeoff that seems the most secure for you, that's fine, and the fact that you were using stronger keys in your non-smartcard implementation doesn't hurt you at all. Smartcards are not a good reason to object to larger keysizes for people who don't use smartcards. Actually, it is for those of us who prefer smartcards. I was once newbie trying to use a smartcard. Repeated emphasis on having only a 4k key can create the impression that a smartcard is not strong enough, that it is weaker because it can only go up to 3072 bits (depending on the card). The reason for me to have a smartcard was to physically separate the key from the computer. Using a key that is too large for the smartcard does not fit my purpose for having one. I got an FSFE Fellowhip card and an OpenPGP SmartCard V2 from kernelconcepts.de (both were received early this year) and they both happily support 4096-bit keys. I do not know about YubiKey NEO an experimental OpenPGP applet though. signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: riseup.net OpenPGP Best Practices article
On Jun 27, 2014, at 6:45 AM, Viktar Siarheichyk v...@eq.by wrote: On 26.06.2014 23:28, Paul R. Ramer wrote: On June 26, 2014 8:26:16 AM PDT, Daniel Kahn Gillmor d...@fifthhorseman.net wrote: As for arguments about use on smartcards -- if you plan to get a smartcard, and you have a primary key that is too large for it, you can always generate and publish new subkeys that will fit in your smartcard. If that's the tradeoff that seems the most secure for you, that's fine, and the fact that you were using stronger keys in your non-smartcard implementation doesn't hurt you at all. Smartcards are not a good reason to object to larger keysizes for people who don't use smartcards. Actually, it is for those of us who prefer smartcards. I was once newbie trying to use a smartcard. Repeated emphasis on having only a 4k key can create the impression that a smartcard is not strong enough, that it is weaker because it can only go up to 3072 bits (depending on the card). The reason for me to have a smartcard was to physically separate the key from the computer. Using a key that is too large for the smartcard does not fit my purpose for having one. I got an FSFE Fellowhip card and an OpenPGP SmartCard V2 from kernelconcepts.de (both were received early this year) and they both happily support 4096-bit keys. I do not know about YubiKey NEO an experimental OpenPGP applet though. My understanding is that the YubiKey Neo applet supports up to 2048 bit RSA. Thus there are some keys that will work with the V2 SmartCard but not on the Neo. I do admire the Neo form factor though. David ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: On the advisability of stronger digests than SHA-1 in OpenPGP certifications [was: Re: riseup.net OpenPGP Best Practices article]
Kristian Fiskerstrand wrote: On 06/27/2014 03:54 PM, shm...@riseup.net wrote: Robert J. Hansen: On 6/26/2014 5:57 PM, Daniel Kahn Gillmor wrote: PGP 8 was released over a decade ago, that's hardly a modern implementation: And yet, it still conforms (largely) to RFC4880. Methinks you're objecting because it's a largely-conforming implementation that doesn't have good support for SHA256. ;) In what ways is its support for SHA-256 limited? I'm having a hard time finding documentation for it. If I recall correctly, it can understand SHA-256 but not generate SHA-256. SHA-256 generation support was added late in the 8.x series, but earlier 8.x releases could understand it. That is as I remember it, Rob. I don't recall if there was a difference between 8.0 and 8.1 with respect to SHA-256. JM3 probably would. any modern OS can utilise thunderbird + enigmail as an example Any? Maybe for the Windows/Linux/Mac case. there's great work done to bring gnupg to windows with gpg4win why *wouldn't* you use it ? In the US? Sarbanes-Oxley or any other retention/retrieval laws and regulations. [see below] Those requirements have a way of spreading internationally within a corporation or business sector. You won't convince a corporate IT department in a Law firm (or for that matter Financial world) about it. They want SLAs and support, and who knows what custom addons they have for their Outlook setup for various functions that makes it impractical to switch to Thunderbird (does it support Exchange these days?) HR, and Compliance/Legal are some other departments that would veto the move. PGP 8.x has a couple non-RFC extensions that make it quite popular in the corporate world: ADKs, and X.509 certifications on PGP keys. The accompanying LDAP-based PGP Keyserver is also often found in this environment, if they haven't added the keyserver functionality to their corporate directories. PGP also had plugins for GroupWise and Notes, in addition to Outlook. -John -- John P. Clizbe Inet: John (a) Gingerbear DAWT net SKS/Enigmail/PGP-EKP or: John ( @ ) Enigmail DAWT net 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
Re: riseup.net OpenPGP Best Practices article
My understanding is that the YubiKey Neo applet supports up to 2048 bit RSA. Thus there are some keys that will work with the V2 SmartCard but not on the Neo. Yes limitation is physical, the ship cannot have key size more than 2048 bit RSA on Yubikey, for the V2 SmartCard GnuPG, it's different, limitation was software (by GnuPG) but not hardware, so now it works with 4096 bit RSA. Best Regards ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: riseup.net OpenPGP Best Practices article
On 6/27/2014 3:14 AM, Werner Koch wrote: Assuming the sender uses a decent implementation, the attacker must have been able to modify the senders system by changing the code or the config files. Nope. It took me about fifteen seconds to come up with a way to do this with acceptable (if not-100%) probability of success and acceptable (but extremely low) probability of intercept. Tomorrow I'll post my method to the list. If I can come up with a method to degrade things to 3DES in fifteen seconds, then I believe the people who do this stuff professionally have spent at least a few weeks inventing and perfecting other methods. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: On the advisability of stronger digests than SHA-1 in OpenPGP certifications [was: Re: riseup.net OpenPGP Best Practices article]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 06/27/2014 10:24 PM, John Clizbe wrote: Kristian Fiskerstrand wrote: On 06/27/2014 03:54 PM, shm...@riseup.net wrote: Robert J. Hansen: On 6/26/2014 5:57 PM, Daniel Kahn Gillmor wrote: PGP 8 was released over a decade ago, that's hardly a modern implementation: And yet, it still conforms (largely) to RFC4880. Methinks you're objecting because it's a largely-conforming implementation that doesn't have good support for SHA256. ;) In what ways is its support for SHA-256 limited? I'm having a hard time finding documentation for it. If I recall correctly, it can understand SHA-256 but not generate SHA-256. SHA-256 generation support was added late in the 8.x series, but earlier 8.x releases could understand it. That is as I remember it, Rob. I don't recall if there was a difference between 8.0 and 8.1 with respect to SHA-256. JM3 probably would. My recollection is that SHA256 was added read-only in 8.1 - -- - Kristian Fiskerstrand Blog: http://blog.sumptuouscapital.com Twitter: @krifisk - Public PGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 - Veni vidi velcro I came, I saw, I got stuck -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJTrd1tAAoJEPw7F94F4TagqMMP/3AZUe8laiv/P83Za9qlyyy0 9eh4VJNQI5VeeUMvabl9MyUP6eY8RzZcMfTod12NlQy3+Y1aprWtSisUNnWK/6MV 7mnF1iCPZaynhIa5qdU0D/jeczLT7XTXPX5ReZjE+xCWk6lRynHr+owwF6S0YalS qgUz6Cnem2EqXuzl/rQeLRSc9nijGVyTuk/YHJTQ1ykHCC+8h5G4ZgzHG2EwiyJc FC6V3JqtoWmn4Pv0nxQW/JFR6z8a7/kINFqeQ0eUUyQY0C9/EuckVSTch8ZpYVZn oWaF2b2lTuR0JkfcHpyPmRxhk8wBaeJkt+zrpIa6Xq3ssXhbnGSnTk43NuOsMGf+ JdzQePG+9iU/f9VmZhHGpyDvSKYgY3avAQ3n192fVFxMDvv3ruPAytZz/zUAR7IA c2bOPrQ2qo8nrZAY7SptXsIvEcXujLXSVwFsPQMWBeqAXh01y4gAgcxW/DGaeitD AwWYyg453EBsLkgnUXM5O6Ry+KbP0Z8J7QqyIFsdCjamVq5Q7UCZC5WpIa0KMIx6 B/4hI8oLwJDtZmMzKeu6tquLD/wWJwz3w2U1Mu5gijDBdyrhH0UF2MdABCi8Yx60 lGCT4hxv0du4R53p+dQj1Y5GvLtrc5ugQygbcmiY3j01EwmIX3iOOypqvnlzUx+p qvXHhqO4irBA5jO0rsI3 =LgOx -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: On the advisability of stronger digests than SHA-1 in OpenPGP certifications [was: Re: riseup.net OpenPGP Best Practices article]
On Jun 27, 2014, at 4:24 PM, John Clizbe j...@enigmail.net wrote: Kristian Fiskerstrand wrote: On 06/27/2014 03:54 PM, shm...@riseup.net wrote: Robert J. Hansen: On 6/26/2014 5:57 PM, Daniel Kahn Gillmor wrote: PGP 8 was released over a decade ago, that's hardly a modern implementation: And yet, it still conforms (largely) to RFC4880. Methinks you're objecting because it's a largely-conforming implementation that doesn't have good support for SHA256. ;) In what ways is its support for SHA-256 limited? I'm having a hard time finding documentation for it. If I recall correctly, it can understand SHA-256 but not generate SHA-256. SHA-256 generation support was added late in the 8.x series, but earlier 8.x releases could understand it. That is as I remember it, Rob. I don't recall if there was a difference between 8.0 and 8.1 with respect to SHA-256. JM3 probably would. My notes say that PGP 8.1 can verify sigs made with SHA-256, but won't generate it. I'm afraid I don't have a copy of 8.1 handy any longer to check. Incidentally, since subkeys have come up in this thread, I seem to recall a few strange bugs with 8.x (8.0? 8.1?) that make it difficult to use if the key you are encrypting to has a signing subkey. 8.x didn't always handle signing subkeys properly, so could end up failing to encrypt (it wasn't 100% of the time - it depended on which subkey was dated first). If anyone is curious, I'll dig out my notes for this. I submitted the bug to PGP, and I know it was fixed in a later version. David ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: riseup.net OpenPGP Best Practices article
Since it looks as if I'm going to be out of contact for the next few days (traveling), I figured I'd share the degradation a little early -- Alice and Bob are communicating. Bob insists on using extremely large keyspaces: his certificate is RSA-16384 and his preference list is AES256 CAMELLIA256. Alice does not. She's not naive or clueless: she's a competent user who understands that Bob insists everything be encrypted with an RSA-16384 certificate. Charlene wants to degrade Bob to 112 bits of effective keyspace. (Why? Beats me. Let's say she's working for the Zarbnulaxian Intelligence Service, and ZIS has tasked her with preparing the Earth for its eventual domination. To further this goal, ZIS has given her a quantum computer one of them got from their kid's breakfast cereal box. It doesn't provide enough qubits to break RSA, but can attack 3DES.) Charlene can't do anything to Bob. She *can* do something to Alice. The next conference Alice goes to, the next OpenPGP Birds of a Feather, Charlene makes sure people there are talking about how 3DES is really the most-trusted cipher in all of OpenPGP.[*] Charlene makes sure a few well-written webpages get put up talking about how 3DES is really a superior choice to AES256 because Cortois[**]. Ultimately, Charlene arranges for Alice to meet someone else who's privacy-paranoid and insists that Alice only use 3DES to communicate, because that's the only MUST algorithm in OpenPGP, it's the most interoperable, and because it's been turning brilliant young cryptanalysts into burned-out alcoholic wrecks for 30 years [***]. When faced with that, it's only a matter of time until Alice decides to put 3DES first in her own preference list. And then all her communications to Bob have 112 bits of keyspace, not the 256 Bob demands. And unless Bob is paranoid enough to check the symmetric algorithm used on every single encrypted message, Bob will never know that Alice's communications to him have been degraded. Werner and others are absolutely right: there is no *technical* way to degrade things to 3DES. But given that cipher preference lists are fundamentally a *human* decision, well... the human being is always exploitable. [*] ... which is probably true. [**] ... of which I've seen several. [***] ... okay, yes, Charlene paid me to hook up with Alice. YOU DON'T UNDERSTAND HOW CRUSHING GRADUATE STUDENT DEBT IS, OKAY? ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: riseup.net OpenPGP Best Practices article
On Wed, 25 Jun 2014 21:53, joh...@vulcan.xs4all.nl said: While important I don't loose a night's sleep over a DOS attack. It's annoying but it doesn't reveal any confidential information. Nor do I. However, such a simple DoS is generally consideres a security bug and thus you should better update. Perhaps a better safe than sorry approach after remembering that RSA-768 was once (in the pgp 2.0 days) advertised as futureproof military-grade encryption? Attacks only get better in time, never worse. Back then it was. Unless you used any computer. Back then almost all boxes were vulnerable to several FOO root/supervisor exploit of the month. 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
Re: riseup.net OpenPGP Best Practices article
MFPA: Hi On Tuesday 24 June 2014 at 8:37:30 PM, in mid:53a9d37a@vulcan.xs4all.nl, Johan Wevers wrote: Al Quaida use horse couriers who memorise the message, the American's could not intercept them. Even if they did intercept them, are the Americans any good at interrogating a horse? might be ok if they ask why the long face ;-) could be difficult if slang was used since that was always an issue for US intelligence trying to decipher radio comms with, literally, slang from particular farms, communities i always keep this is mind; the fact that you can throw all possible resources you have and decrypt something, then don't understand the decryption -- Best regards MFPAmailto:2014-667rhzu3dc-lists-gro...@riseup.net Wisdom is a companion to age; yet age may travel alone. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: riseup.net OpenPGP Best Practices article
Robert J. Hansen wrote: Even if they did intercept them, are the Americans any good at interrogating a horse? Yes. We are world champions at beating dead horses. To interrogate a horse, first simply shoot it in the head, and then we can leverage our dead-horse-beating skills in order to do enhanced equine interrogation. Ah, yes... the fetish of equinonecroflagellation. It has an strikingly common rate of incidence with maxicryptosizism[*], along with Internet posts labeling the author[s]'s opinions vis-a-vis cryptography usage as Best Practices. I have found the best way to handle best practice cryptography posts is to look for the writer[s]'s academic and/or professional qualifications and act accordingly. Recommendations of RSA-4096 for general use allow me to bypass that step. Security is a system, a chain. Fixating on a single, unlikely to be attacked, link in that chain often ignores the other more easily attacked links. Think of it as installing a bank vault door on a Bedouin tent. -J [*] Rob, I believe you can guess the argot I use for practitioners of this dubious rite. -- John P. Clizbe Inet: John (a) Gingerbear DAWT net SKS/Enigmail/PGP-EKP or: John ( @ ) Enigmail DAWT net 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 signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: riseup.net OpenPGP Best Practices article
Ah, yes... the fetish of equinonecroflagellation. It has an strikingly common rate of incidence with maxicryptosizism... Although I'm going to be (almost wholly) agreeing with John here, I'm speaking just for myself. If anyone wants to chime in with a d'accord, that's on them. :) What gets me about the RSA-2048/-3072/-4096 debate is how (largely) pointless it is. Per NIST, RSA-2048 has about a 112-bit effective keyspace and -3072 has about a 128-bit effective keyspace. There is no official NIST recommendation for RSA-4096, but the cryppies I've spoken with at conferences ballpark it at somewhere around 140 bits of effective keyspace. Now for the kicker: *no one* is guaranteed more than 112 bits of effective keyspace in the emails they receive. No one. Even if you use a hacked-up GnuPG and RSA-16384, you're deluding yourself if you think you're guaranteed your emails will have an effective keyspace of 256 bits. The reason why is four letters long: 3DES. 3DES, which is an always-accept algorithm, has a keyspace of 112 bits[*]. Someone can use your RSA-16384 key with 3DES and bam, the effective protection of your email is down to 112 bits. So in a very real sense, anything past RSA-2048 is at best a you *might* get some additional security, depending on what symmetric algorithm your correspondent uses. Oh, and you can't forbid your correspondent from using 3DES, either. I think it's funny how the people who advocate moving to RSA-4096 by default generally don't talk much about how it is impossible to guarantee more than 112 bits of effective encryption keyspace for an email message. Will it give you a stronger signature? Maybe. But it very possibly won't give you any stronger encryption. Now, this isn't to say there's no purpose in RSA-3072 or -4096. Some organizations have requirements that say any encryption key we use must provide 128 effective bits of keyspace. In that case, if them's the rules, then sure, use RSA-3072, it meets your requirements. But for the people who advocate let's shift to RSA-4096, it gives us about an effective 32 bits more than RSA-2048!, well... I really wish they'd talk about the drawbacks (can't use on a smartcard, may cause problems for mobile devices, etc.) and the inherent limitations of OpenPGP (can't guarantee more than 112 effective bits of encryption keyspace). So, in summation: I think the RSA-2048/-3072/-4096 debate is utterly pointless. To the extent I have any strong feelings on it at all, it is this: you are less likely to delude yourself about the strength of the system if you use RSA-2048. [*] ... against an adversary with access to more computing power than is likely to ever exist in the world, true; but 112 bits nevertheless. signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: riseup.net OpenPGP Best Practices article
On 06/26/2014 04:26 PM, Robert J. Hansen wrote: Ah, yes... the fetish of equinonecroflagellation. It has an strikingly common rate of incidence with maxicryptosizism... Although I'm going to be (almost wholly) agreeing with John here, I'm speaking just for myself. If anyone wants to chime in with a d'accord, that's on them. :) What gets me about the RSA-2048/-3072/-4096 debate is how (largely) pointless it is. Per NIST, RSA-2048 has about a 112-bit effective keyspace and -3072 has about a 128-bit effective keyspace. There is no official NIST recommendation for RSA-4096, but the cryppies I've spoken with at conferences ballpark it at somewhere around 140 bits of effective keyspace. Now for the kicker: *no one* is guaranteed more than 112 bits of effective keyspace in the emails they receive. No one. Even if you use a hacked-up GnuPG and RSA-16384, you're deluding yourself if you think you're guaranteed your emails will have an effective keyspace of 256 bits. The reason why is four letters long: 3DES. 3DES, which is an always-accept algorithm, has a keyspace of 112 bits[*]. Someone can use your RSA-16384 key with 3DES and bam, the effective protection of your email is down to 112 bits. So in a very real sense, anything past RSA-2048 is at best a you *might* get some additional security, depending on what symmetric algorithm your correspondent uses. Oh, and you can't forbid your correspondent from using 3DES, either. I think it's funny how the people who advocate moving to RSA-4096 by default generally don't talk much about how it is impossible to guarantee more than 112 bits of effective encryption keyspace for an email message. Will it give you a stronger signature? Maybe. But it very possibly won't give you any stronger encryption. Now, this isn't to say there's no purpose in RSA-3072 or -4096. Some organizations have requirements that say any encryption key we use must provide 128 effective bits of keyspace. In that case, if them's the rules, then sure, use RSA-3072, it meets your requirements. But for the people who advocate let's shift to RSA-4096, it gives us about an effective 32 bits more than RSA-2048!, well... I really wish they'd talk about the drawbacks (can't use on a smartcard, may cause problems for mobile devices, etc.) and the inherent limitations of OpenPGP (can't guarantee more than 112 effective bits of encryption keyspace). So, in summation: I think the RSA-2048/-3072/-4096 debate is utterly pointless. To the extent I have any strong feelings on it at all, it is this: you are less likely to delude yourself about the strength of the system if you use RSA-2048. [*] ... against an adversary with access to more computing power than is likely to ever exist in the world, true; but 112 bits nevertheless. While in principle I agree that 2048 bit key is strong enough for most uses, comparing 3DES keys space (or any other symmetric encryption algorithm) and RSA (or some other public key system) key space is a bit like comparing apples and oranges. If you crack the 3DES encryption of a message you have cracked that particular message. If you crack the RSA key, you have cracked all messages. So the effective key space of your public key should be larger then the key space of the session key(s). Kind regards, Martijn Brinkers -- CipherMail email encryption Open source email encryption gateway with support for S/MIME, OpenPGP and PDF encryption. www.ciphermail.com ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: riseup.net OpenPGP Best Practices article
While in principle I agree that 2048 bit key is strong enough for most uses, comparing 3DES keys space (or any other symmetric encryption algorithm) and RSA (or some other public key system) key space is a bit like comparing apples and oranges. If you crack the 3DES encryption of a message you have cracked that particular message. If you crack the RSA key, you have cracked all messages. So the effective key space of your public key should be larger then the key space of the session key(s). This is, IMHO, a complete nonissue. If your adversary has the ability to brute-force a 112-bit keyspace, then you are now living in a world where crypto cannot protect you. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: riseup.net OpenPGP Best Practices article
On 06/25/2014 02:25 AM, Werner Koch wrote: This misunderstanding is actually an indication of the problem. You are talking 4096 vs. 2048 while the more important case is to read the security announcements and update your gpg. That's a great point. I've just proposed a pull request on that page to emphasize keeping your GnuPG implementation up-to-date. however, if you *do* keep your software up-to-date, it would be a shame for the crypto itself to be flawed enough to be broken by a well-resourced attacker. So standardizing on stronger crypto by default seems reasonable to me. The point is to ensure that the math itself is not the weak point. I wonder why the keysize triggers bikeshedding discussions in all security groups. After all the majority of us (including me) has not the education and experience to select the color (i.e. crypto math) on their own. These choices are not pulled out of thin air or made up out of arbitrary fancy. There are people who do have the education and experience to determine reasonable keysizes, like the ECRYPT project. http://www.ecrypt.eu.org/ http://www.ecrypt.eu.org/documents/D.SPA.20.pdf suggests (on pages 30-32) that the current GnuPG default of 2048-bit RSA provides roughly 103-bit-equivalent security, which falls in the middle of legacy standard level (≈10 years of protection) and medium-term protection (≈20 years of protection). ECRYPT's Good, generic application-indep. recommendation is at the 128-bit level, which they note for RSA keys is 3248 bits. The Riseup guide suggests a marginally more conservative 4096-bit RSA keysize. In practice, i've never found a modern cryptographic system that can't handle 4096-bit RSA keys. I have, however, found modern systems that *can't* deal with 3248-bit RSA keys (X.509 certificate authorities who expect the bitlength of any key to be a power of two for some unknown and probably stupid reason). So if we want to make a good, generic recommendation, the riseup recommendation doesn't seem to be a bad one to me based on my reading of ECRYPT II. Regards, --dkg signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: riseup.net OpenPGP Best Practices article
On 06/26/2014 10:26 AM, Robert J. Hansen wrote: So in a very real sense, anything past RSA-2048 is at best a you *might* get some additional security, depending on what symmetric algorithm your correspondent uses. Oh, and you can't forbid your correspondent from using 3DES, either. Of course you can't, but this is a terrible argument. You can't forbid your correspondent from sending you mail in the clear either. At any rate, the document under discussion also encourages people to advertise preferences for stronger ciphers, so correspondents using tools which respect those advertised preferences (like GnuPG) *will* get the increase in strength described. The goal of this document is to encourage people to make sure that crypto is not the weak point in their communications. brute forcing anything at a 2^103 security level [0] is likely infeasible, yes, but brute-force isn't the only possible means of attack. we don't know what cryptanalytic improvements are known privately, but if anyone has a speedup on the order of 2^30 (about a billion), then increasing the keysize by about the same amount seems like a pretty reasonable safeguard. Please read Bernstein's paper suggesting larger keysizes as a defense against common parallel constructions (one form of speedup): http://cr.yp.to/snuffle/bruteforce-20050425.pdf As for arguments about use on smartcards -- if you plan to get a smartcard, and you have a primary key that is too large for it, you can always generate and publish new subkeys that will fit in your smartcard. If that's the tradeoff that seems the most secure for you, that's fine, and the fact that you were using stronger keys in your non-smartcard implementation doesn't hurt you at all. Smartcards are not a good reason to object to larger keysizes for people who don't use smartcards. The pushback of don't bother using stronger crypto, something else will be your problem seems silly to me. It's like saying don't bother fighting sexism, people are going hungry! We can (and should) push on all of these fronts concurrently. Regards, --dkg [0] 2048-bit RSA is roughly equivalent to 103-bit symmetric crypto according to ECRYPT-II: page 30 of http://www.ecrypt.eu.org/documents/D.SPA.20.pdf signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: riseup.net OpenPGP Best Practices article
The goal of this document is to encourage people to make sure that crypto is not the weak point in their communications. If that's your criteria, RSA-1024 is sufficient. Real systems are so exploitable that crypto is never the weak point. Please read Bernstein's paper suggesting larger keysizes as a defense against common parallel constructions (one form of speedup): I have. We can (and should) push on all of these fronts concurrently. It must be nice to live in a world where you have unlimited resources to direct to such efforts. Pick and choose your battles. At even RSA-1024, crypto is not going to be the weak link in your system. If your criteria is truly, make sure that crypto is not the weak link, then this entire discussion is moot: any certificate GnuPG creates will do. signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
On the advisability of stronger digests than SHA-1 in OpenPGP certifications [was: Re: riseup.net OpenPGP Best Practices article]
On 06/24/2014 07:28 AM, Gabriel Niebler wrote: I consider myself quite the amateur (I haven't even read most of RFC 4880 yet), but I do take issue with one point in the riseup.net Best Practices page, namely the bit where it says self-signatures must not use SHA1. I find that statement too strong. AFAICS this will lead to keys which may not be understood by some perfectly standards-compliant OpenPGP implementations, since SHA-1 is the _only_ hashing algorithm that MUST be supported by all implementations of that standard. Everything else is up to the implementer. I do not know that there are any such implementations out there, but there seem to be a lot of people rolling their own who occasionally post to this very list. Possibly breaking OpenPGP compatibility does not seem like a Best Practice to me. I raised this concern in a comment on the _original_ page at https://we.riseup.net/riseuplabs+paow/openpgp-best-practices but it didn't garner any interest. I believe additional self-signatures can always be added to existing UIDs and subkeys later and I presume (someone correct me, if I'm wrong, please) they can use other hashing algos. That might be a way to get the best of both worlds: Not breaking standards compliant clients (which would hopefully just ignore the selfsigs they can't understand and focus on those they can) AND strong hashing. to be clear: clients that support stronger digests than SHA-1 are *also* standards-compliant. I don't know of any modern OpenPGP client that doesn't support SHA-256 or SHA-512. Pretty much anything built today should be using libraries for their digest algorithms, and all reasonable libraries that support SHA-1 also support SHA-256 and SHA-512. If you know of a modern OpenPGP implementation that supports SHA-1 but not SHA-256 or SHA-512, please point it out (and no, creating one just to be able to point to it doesn't count :P) What you're proposing would indeed be slightly more widely-compatible, and it would work like this: 0) every self-certification made by GnuPG would be issued twice: once using SHA-1 (selfsig A), and once using a stronger digest algorithm (e.g. SHA-512) (selfsig B). 1) selfsig A should probably have a timestamp that is strictly earlier (probably by 1 second, since that's the quantum that the OpenPGP spec recognizes) than selfsig B, so that implementations that prefer the most recent self-sig and support the stronger digest algorithm will know to prefer it. (this works around any buggy clients that might get confused by two self-sigs with the same timestamp -- if we want to be widely compatible, we should probably cater to them too) 2) While you're at it, you could create selfsigs with each supported digest algorithm, rather than just 2 -- that would make the signature even more widely-compatible, because it would work for clients who implement, for example, RIPEMD-160 but not SHA-256. But i don't think the additional complexity and bulk (these OpenPGP certs would be larger) are worth the tradeoff, because (a) any OpenPGP implementation that only supports SHA-1 in 2014 should be upgraded and fixed, not coddled (they're probably vulnerable to implementation errors at least if they're that out of date) and (b) i don't think they exist. SHA-1 is within range of collision attacks by sophisticated attackers. By the time someone decides it is unreliable (that is, that they will not rely on certifications made using SHA-1), people should have *already* moved on. It's conceivable that someone who wants to reject SHA-1 certifications in general could make an exception for selfsigs (as distinct from third-party certifications) since the worst thing that an attacker can do if they can forge a selfsig is to make you assert an identity for your key that you don't actually control. But this is still an attack, however silly, and the complexity of splitting out what digests you'll accept in self-certifications from what digests you'll accept in third-party certifications smells like trouble to me. So i think that the simplest practice is best: use a single self-sig, made over a single strong, widely-supported digest algorithm. SHA-512 meets that requirement. I hope this analysis is useful. --dkg signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: riseup.net OpenPGP Best Practices article
On 6/26/2014 11:26 AM, Daniel Kahn Gillmor wrote: The pushback of don't bother using stronger crypto, something else will be your problem seems silly to me. It's like saying don't bother fighting sexism, people are going hungry! We can (and should) push on all of these fronts concurrently. I've been writing and rewriting this several times now: I'm not sure if I've found diplomacy here, but there comes a point where you have to say screw it and hit send. Four of the best guiding principles I've found are: 1. Design the system as if the bad guys control everything that is not an immediate game-over. 2. Assume the bad guys will degrade your system in the most damaging ways possible (subject only to #1). 3. Your level of protection is defined by your resistance to the enemy's worst skulduggery, not your performance in the absence of skulduggery. 4. Just because you define something to be an immediate game-over doesn't mean the enemy can't do it -- it just means you can't defend against it and for that reason aren't covering it. One of the justifications you give for your faith in increased key lengths is [RFC4880] also encourages people to advertise preferences for stronger ciphers, so correspondents using tools which respect those advertised preferences (like GnuPG) *will* get the increase in strength described. But see #2 above, though. The bad guys will degrade your system in the most damaging ways possible, subject to the assumptions we make in #1. Since it's possible to degrade the cipher preference to 3DES, we need to assume that's exactly what will happen. (Your next objection is How?. That's a non-sequitur right now. I believe serious adversaries can do this because (a) there's no mechanism to prevent them from doing it, and (b) system degradation is such a bog-standard attack vector that I can't believe they haven't already thought up ways. Whether *I* have thought up ways is irrelevant.) People should feel free to use cipher preferences, but they shouldn't have any expectation that it matters a damn. The most you can guarantee out of it is 3DES with 112 bits of keyspace: everything beyond that is a gift from your enemy. If your security model depends on using Camellia256, then you need to use something other than OpenPGP, because #3. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: riseup.net OpenPGP Best Practices article
Am Do 26.06.2014, 16:06:25 schrieb Robert J. Hansen: Since it's possible to degrade the cipher preference to 3DES, we need to assume that's exactly what will happen. (Your next objection is How?. That's a non-sequitur right now. I believe serious adversaries can do this because (a) there's no mechanism to prevent them from doing it, You mean except for that you must be capable of forging a mainkey signature (if you don't control the sending system anyway in which case you don't need the key any more)? I would say that if you think it's OK to just assume that signing is really broken why not also just assume that encryption is really broken (i.e. not offering those 112 bit by far)? But I strongly support your main point. Whether anyone cares or not... ;-) I would like to put it (or one of the consequences) this way: Educating users is much more important than changing default settings. When I teach people I tell them that as a rule of thumb 10% of the overall security they get are provided by technology 60% of it come from their own knowledge and the last 30% come from the discipline to really (not) do what you know you should (not) do. Hauke -- Crypto für alle: http://www.openpgp-schulungen.de/fuer/unterstuetzer/ http://userbase.kde.org/Concepts/OpenPGP_Help_Spread OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 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: riseup.net OpenPGP Best Practices article
On June 26, 2014 8:26:16 AM PDT, Daniel Kahn Gillmor d...@fifthhorseman.net wrote: As for arguments about use on smartcards -- if you plan to get a smartcard, and you have a primary key that is too large for it, you can always generate and publish new subkeys that will fit in your smartcard. If that's the tradeoff that seems the most secure for you, that's fine, and the fact that you were using stronger keys in your non-smartcard implementation doesn't hurt you at all. Smartcards are not a good reason to object to larger keysizes for people who don't use smartcards. Actually, it is for those of us who prefer smartcards. I was once newbie trying to use a smartcard. Repeated emphasis on having only a 4k key can create the impression that a smartcard is not strong enough, that it is weaker because it can only go up to 3072 bits (depending on the card). The reason for me to have a smartcard was to physically separate the key from the computer. Using a key that is too large for the smartcard does not fit my purpose for having one. The pushback of don't bother using stronger crypto, something else will be your problem seems silly to me. It's like saying don't bother fighting sexism, people are going hungry! We can (and should) push on all of these fronts concurrently. On the contrary, shouting, Bigger! Larger! Greater! without a justification based on actual threats posed to that user when the defaults will suffice creates the impression that only the most heavy duty crypto will keep their communications private, and the user will eschew the defaults simply because they aren't big enough. It's bad education. Or worse--the lack thereof. Cheers, -Paul -- PGP: 3DB6D884 ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: riseup.net OpenPGP Best Practices article
On 6/26/2014 4:35 PM, Hauke Laging wrote: You mean except for that you must be capable of forging a mainkey signature (if you don't control the sending system anyway in which case you don't need the key any more)? Nope. :) I meant what I said. The preference list on the key is advisory, not binding. There's nothing requiring an implementation to even look at the preference list on the key. For any OpenPGP certificate, you can send it 3DES-encrypted traffic and be in complete accordance with the spec and the recipient's preferences. A conformant implementation MUST choose a cipher that is listed in the certificate preferences, but (a) the spec is completely silent about *which* preferred cipher should be used, and (b) the spec guarantees 3DES will always be a preferred cipher. This is why I've always pushed to call them capability sets, instead of preference lists. The spec doesn't guarantee they'll be treated as preference lists. The spec only guarantees they'll be treated as a capability set. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: On the advisability of stronger digests than SHA-1 in OpenPGP certifications [was: Re: riseup.net OpenPGP Best Practices article]
On 6/26/2014 2:25 PM, Daniel Kahn Gillmor wrote: If you know of a modern OpenPGP implementation that supports SHA-1 but not SHA-256 or SHA-512, please point it out (and no, creating one just to be able to point to it doesn't count :P) PGP 8.x, which is still in use today by a surprising number of people, has limited support for SHA-256 and none at all for SHA-512. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: On the advisability of stronger digests than SHA-1 in OpenPGP certifications [was: Re: riseup.net OpenPGP Best Practices article]
On 06/26/2014 05:45 PM, Robert J. Hansen wrote: On 6/26/2014 2:25 PM, Daniel Kahn Gillmor wrote: If you know of a modern OpenPGP implementation that supports SHA-1 but not SHA-256 or SHA-512, please point it out (and no, creating one just to be able to point to it doesn't count :P) PGP 8.x, which is still in use today by a surprising number of people, has limited support for SHA-256 and none at all for SHA-512. PGP 8 was released over a decade ago, that's hardly a modern implementation: http://www.pgpi.org/news/ In what ways is its support for SHA-256 limited? I'm having a hard time finding documentation for it. How many people use it? Can you share where you got your surprising number reference? Are there software vulnerabilities in it or any support or maintenance at all? To paraphrase Werner elsewhere in this thread: The more important case is to read security announcements and update your OpenPGP implementation. Why should anyone cater to users of PGP 8.x in 2014 when we have an opportunity to provide a stronger cryptographic baseline for everyone else? --dkg signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: On the advisability of stronger digests than SHA-1 in OpenPGP certifications [was: Re: riseup.net OpenPGP Best Practices article]
On 6/26/2014 5:57 PM, Daniel Kahn Gillmor wrote: PGP 8 was released over a decade ago, that's hardly a modern implementation: And yet, it still conforms (largely) to RFC4880. Methinks you're objecting because it's a largely-conforming implementation that doesn't have good support for SHA256. ;) In what ways is its support for SHA-256 limited? I'm having a hard time finding documentation for it. If I recall correctly, it can understand SHA-256 but not generate SHA-256. SHA-256 generation support was added late in the 8.x series, but earlier 8.x releases could understand it. How many people use it? It's not as if there are Nielsen ratings for these things. All I can do is say that I still regularly encounter it when I talk to people about PGP. For instance, I know of one law firm that purchased a site license for 8.x and refuses to upgrade, since the more recent editions cost a fortune in per-seat licenses and have very little in the way of new functionality. Why should anyone cater to users of PGP 8.x in 2014 when we have an opportunity to provide a stronger cryptographic baseline for everyone else? Because there are still people using it. Remember, GnuPG also supports most of RFC1991 because we've got a large base of PGP 2.6 users who are refusing to upgrade... ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: riseup.net OpenPGP Best Practices article
On Tue, 24 Jun 2014 21:35, joh...@vulcan.xs4all.nl said: Finally upgrade that 286 to DOS 3.0? If you have a system that can't handle 4k keys you have very specific needs. Sending a lot of messages This misunderstanding is actually an indication of the problem. You are talking 4096 vs. 2048 while the more important case is to read the security announcements and update your gpg. Over the last two days I release 1.4.17 and 2.0.24 just to fix a simple regression introduced 15 years ago: Create an OpenPGP packet from these bytes: a3 01 5b ff. Put it into an ascii armor and sent it by mail. The MUA will lock up while trying to decrypt it. This is a naked compressed data packet, you may need to embed it into a regular encrypted packet. I wonder why the keysize triggers bikeshedding discussions in all security groups. After all the majority of us (including me) has not the education and experience to select the color (i.e. crypto math) on their own. 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
Re: riseup.net OpenPGP Best Practices article
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi On Tuesday 24 June 2014 at 8:37:30 PM, in mid:53a9d37a@vulcan.xs4all.nl, Johan Wevers wrote: Al Quaida use horse couriers who memorise the message, the American's could not intercept them. Even if they did intercept them, are the Americans any good at interrogating a horse? - -- Best regards MFPAmailto:2014-667rhzu3dc-lists-gro...@riseup.net Wisdom is a companion to age; yet age may travel alone. -BEGIN PGP SIGNATURE- iPQEAQEKAF4FAlOrKEZXFIAALgAgaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldEJBMjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0 N0VDQTAzAAoJEKipC46tDG5poXQD/RIv2b7sKzFIYFB86UF3O5vXQO3wHt0C6TNn JIwdQcHTRVBHWKi09HL0hU33WW1jM54MjAzwbb0bVNBYHbjh/76U21Kgp6UUuHzy e9wmrwNGrJ8f/P9Sp7edDSQ8un4m8jNhYeSREYW0w+iL4ocxcmKp0S6r+2i9s8x6 94LNaxVm =9RXa -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: riseup.net OpenPGP Best Practices article
On 25-06-2014 8:25, Werner Koch wrote: This misunderstanding is actually an indication of the problem. You are talking 4096 vs. 2048 while the more important case is to read the security announcements and update your gpg. While important I don't loose a night's sleep over a DOS attack. It's annoying but it doesn't reveal any confidential information. I wonder why the keysize triggers bikeshedding discussions in all security groups. Perhaps a better safe than sorry approach after remembering that RSA-768 was once (in the pgp 2.0 days) advertised as futureproof military-grade encryption? Attacks only get better in time, never worse. -- ir. J.C.A. Wevers PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: riseup.net OpenPGP Best Practices article
On 25-06-2014 21:51, MFPA wrote: Even if they did intercept them, are the Americans any good at interrogating a horse? I don't know, but torturing the courtier turned out to be unreliable at best. -- ir. J.C.A. Wevers PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: riseup.net OpenPGP Best Practices article
Even if they did intercept them, are the Americans any good at interrogating a horse? Yes. We are world champions at beating dead horses. To interrogate a horse, first simply shoot it in the head, and then we can leverage our dead-horse-beating skills in order to do enhanced equine interrogation. signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: riseup.net OpenPGP Best Practices article
On Tue, 24 Jun 2014 05:55, fr...@frase.id.au said: rounds today. Quite a lot of good info, especially regarding key strength and expiry, and digest preferences. Just for the records: _I_ do not consider the use of a 4096 bit RSA key and a preference for SHA-512 a best practice. For a secure system it is important to make the system stronger and not parts of the system which will never be attacked in real life. Granted, there are user with a need for non default algorithms, but those users have the resources to develop a security policy which fits their use case. How does a help 4096 key help if I can send you an encrypted mail which will lock up your MUA until you kill it (unless your MUA has some kind of timeout mechanism). There are more important things to be made stronger than the key size. 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
Re: riseup.net OpenPGP Best Practices article
I was going to create a new PGP key myself by following that article. Werner, do you have any more input or comments to add regarding that article? I am curious to hear input from multiple sources/people. On 6/24/14, Werner Koch w...@gnupg.org wrote: On Tue, 24 Jun 2014 05:55, fr...@frase.id.au said: rounds today. Quite a lot of good info, especially regarding key strength and expiry, and digest preferences. Just for the records: _I_ do not consider the use of a 4096 bit RSA key and a preference for SHA-512 a best practice. For a secure system it is important to make the system stronger and not parts of the system which will never be attacked in real life. Granted, there are user with a need for non default algorithms, but those users have the resources to develop a security policy which fits their use case. How does a help 4096 key help if I can send you an encrypted mail which will lock up your MUA until you kill it (unless your MUA has some kind of timeout mechanism). There are more important things to be made stronger than the key size. 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 ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: riseup.net OpenPGP Best Practices article
On Tue, 24 Jun 2014 11:42, p...@heypete.com said: Would SHA-256 be a better (in the context of being more compatible) choice if one preferred using a non-SHA-1 hash? At least on 32 bit machines SHA-256 is faster than SHA-512. Some CPUs have hardware support for SHA-256 but not for SHA-512. With DSA and ECDSA a SHA-512 digest is anyway truncated (to 256 bit for dsa3072). 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
Re: riseup.net OpenPGP Best Practices article
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Am 24.06.2014 09:36, schrieb Cpp: I was going to create a new PGP key myself by following that article. Werner, do you have any more input or comments to add regarding that article? I am curious to hear input from multiple sources/people. I consider myself quite the amateur (I haven't even read most of RFC 4880 yet), but I do take issue with one point in the riseup.net Best Practices page, namely the bit where it says self-signatures must not use SHA1. I find that statement too strong. AFAICS this will lead to keys which may not be understood by some perfectly standards-compliant OpenPGP implementations, since SHA-1 is the _only_ hashing algorithm that MUST be supported by all implementations of that standard. Everything else is up to the implementer. I do not know that there are any such implementations out there, but there seem to be a lot of people rolling their own who occasionally post to this very list. Possibly breaking OpenPGP compatibility does not seem like a Best Practice to me. I raised this concern in a comment on the _original_ page at https://we.riseup.net/riseuplabs+paow/openpgp-best-practices but it didn't garner any interest. I believe additional self-signatures can always be added to existing UIDs and subkeys later and I presume (someone correct me, if I'm wrong, please) they can use other hashing algos. That might be a way to get the best of both worlds: Not breaking standards compliant clients (which would hopefully just ignore the selfsigs they can't understand and focus on those they can) AND strong hashing. Maybe other people can weigh in on this, notably those involved with that document. I would be especially interested to hear dkg's opinion. Cheers gabe -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTqWDJAAoJEO7XEikU4kSzTHwH/RDpwO5DI71kEMm5MwgH05yi lO91dlfO8RZygbHZGGN0TaxckqG2OgwXB6ItBZkJumjlXpU5rP6Z4UmrHbUyTTmp KZYqv98UFLunZ9W784gel1fbI3pCycTs+yaODanHFIsGOapqiW14DnWhJVLFY6Zj M+SuIz9t+x9f15x1jdhUGz8FlKp5+3ptYapMNaFgeruUPNHCD6lRIdFGjSc1MV7r PLC7s9yWpOBVmw0n5vlkL5uiRRryrTYkuU3/66sOgtSzCT9EEyAmFkSp6P0sztcl CitahspXrCiT8KHxd9w8gsOHSKwGT+EY4g9UFUciC1ED0F9HP55hcJSsfL1U/oU= =gMvc -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: riseup.net OpenPGP Best Practices article
Just for the records: _I_ do not consider the use of a 4096 bit RSA key and a preference for SHA-512 a best practice. I'll go one step further: I think the article is going to do more harm than good. When young people ask me where to begin programming, I tell them to just begin. Don't worry about whether Javascript is better than Python or C or anything else: just find something they think is neat and start. The most important thing for them is to begin, and the second-most important thing is for them to finish what they begin. Only later, once they're well and truly on their way, should they start worrying about technical details. The same applies here. The most important thing in using GnuPG is that people begin using it; the second-most important thing is that they keep on using it. Guides such as these may ultimately do more harm than good, in that they tend to lead new users into thinking they *have* to do all these things, daunting and maybe even scary things (and let's be clear: there's a lot of opaque terminology and technical jargon there!), in order to effectively use GnuPG. Which just isn't true. The best practice for GnuPG: --gen-key and find a plugin for your email client. Everything after that needs to be relegated to an advanced class. There's nothing wrong with advanced material: advanced material is great. But let's not go about scaring newcomers by making them think they need to do and understand all of that. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: riseup.net OpenPGP Best Practices article
I recently, generated a new keypair (GPG4win), and the defaults presented where RSA/2048. I did, some digging around on the RSA vs DSA thing and RSA still seems to be the recommended way to go, the only thing I did was up my key size to 4096 I left all the other defaults. On Monday, June 23, 2014 11:52 PM, Werner Koch w...@gnupg.org wrote: On Tue, 24 Jun 2014 05:55, fr...@frase.id.au said: rounds today. Quite a lot of good info, especially regarding key strength and expiry, and digest preferences. Just for the records: _I_ do not consider the use of a 4096 bit RSA key and a preference for SHA-512 a best practice. For a secure system it is important to make the system stronger and not parts of the system which will never be attacked in real life. Granted, there are user with a need for non default algorithms, but those users have the resources to develop a security policy which fits their use case. How does a help 4096 key help if I can send you an encrypted mail which will lock up your MUA until you kill it (unless your MUA has some kind of timeout mechanism). There are more important things to be made stronger than the key size. 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 ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: riseup.net OpenPGP Best Practices article
I just finished reading the article, I don't know anyone who does all of those things. most people I know who are advid GPG users, gen a key, maybe a revoke, upload it to a keyserver sometimes. and that's about it. using subkeys, offline keys etc, adds way more complexity to something arguably that's already complex. anykind of best practice, should be simple, so that it encourages a sane baseline for people. things like RSA vs DSA, key size etc, should be in it. not a long doc that that has you doing primary and secondary keys On Tuesday, June 24, 2014 9:24 AM, Robert J. Hansen r...@sixdemonbag.org wrote: Just for the records: _I_ do not consider the use of a 4096 bit RSA key and a preference for SHA-512 a best practice. I'll go one step further: I think the article is going to do more harm than good. When young people ask me where to begin programming, I tell them to just begin. Don't worry about whether Javascript is better than Python or C or anything else: just find something they think is neat and start. The most important thing for them is to begin, and the second-most important thing is for them to finish what they begin. Only later, once they're well and truly on their way, should they start worrying about technical details. The same applies here. The most important thing in using GnuPG is that people begin using it; the second-most important thing is that they keep on using it. Guides such as these may ultimately do more harm than good, in that they tend to lead new users into thinking they *have* to do all these things, daunting and maybe even scary things (and let's be clear: there's a lot of opaque terminology and technical jargon there!), in order to effectively use GnuPG. Which just isn't true. The best practice for GnuPG: --gen-key and find a plugin for your email client. Everything after that needs to be relegated to an advanced class. There's nothing wrong with advanced material: advanced material is great. But let's not go about scaring newcomers by making them think they need to do and understand all of that. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: riseup.net OpenPGP Best Practices article
I recently, generated a new keypair (GPG4win), and the defaults presented where RSA/2048. I did, some digging around on the RSA vs DSA thing and RSA still seems to be the recommended way to go, the only thing I did was up my key size to 4096 I left all the other defaults. This depends on what you mean by recommended, and why. The last time I checked it wasn't possible to use DSA2 keys to sign a Linux RPM file, for instance. Likewise, there are smartcards that don't support DSA2, and so on. But if you're not using one of those niche applications then there's really not much difference worth mentioning between RSA2048 and DSA2048. :) ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: riseup.net OpenPGP Best Practices article
Am Di 24.06.2014, 09:50:04 schrieb Nex6|Bill: anykind of best practice, should be simple, so that it encourages a sane baseline for people. That depends on it whether you need security or the illusion of security is enough for you. IMHO it is one of the main problems that hardly anyone cares about telling protection levels apart. Security is a really wide spectrum, for some beginning at random six letter passwords. You cannot say in a useful sense what is a good recommendation without looking at what is needed in the respective situation. Thus I advocate a standardized set of security levels for data, keys and systems. And authentication on the other hand: http://www.crypto-fuer-alle.de/wishlist/securitylevel/ (German only) Hauke -- Crypto für alle: http://www.openpgp-schulungen.de/fuer/unterstuetzer/ http://userbase.kde.org/Concepts/OpenPGP_Help_Spread OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 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: riseup.net OpenPGP Best Practices article
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 6/24/2014 10:52 AM, Robert J. Hansen wrote: I recently, generated a new keypair (GPG4win), and the defaults presented where RSA/2048. I did, some digging around on the RSA vs DSA thing and RSA still seems to be the recommended way to go, the only thing I did was up my key size to 4096 I left all the other defaults. This depends on what you mean by recommended, and why. The last time I checked it wasn't possible to use DSA2 keys to sign a Linux RPM file, for instance. Likewise, there are smartcards that don't support DSA2, and so on. But if you're not using one of those niche applications then there's really not much difference worth mentioning between RSA2048 and DSA2048. :) yea, compatibility is a big issue from what I understand RSA is far more compatible than DSA is. which is why i use an RSA key, though a larger key -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTqcVvAAoJEBr/3kncCBhngAUQAJpQEC6EeIT3+Krid4cJw8V5 yP7GdbY/8KryB+azI5usZ0AIsSJLJpQiNK1OlqDvWJohUv6GXcymnO5f0LnUj4Hx fAdCD7vTDrt55G41rLf+EQAkJz41Cvub/psjErdAerzv8T9Ij7CilAos29iuXv3f 5yRYbsr/uo/65bXFAi+9+2/caAdcXpSVV3y87JWwIVizVQtz1q4lu4AT0IItLTE6 ZC/+gbXe9rlCr0Mkm54rV/aaj9OuWNwDxTl1w3PAfZ1LJx2AijHWtKqfcQ5Rq0Sf 4a4l9TAMg9UqO1sYmXl/331sqNXu7PyVSNKAzDsO+5qAa//1oUgHmsHeFS1ufNp1 LoeqpN5oT8+AkwGGYjEi+tbQQg20fk0Yp+o9SX3tvXt+1TLRf2I1EOUNcG30cRyF a27xgz7o1nSqqFTjkDLKHzDm7sKvkJBMoKsC5dJM5qGBVahQr1a1+8rCrgoFmFd/ MJFWHc2dSUNHuRzAe8CZdkX6RasHyjHjHSpdoumDAYBJ7/DTOl6OjRUgHqn6hiW8 432UoC/AnUf4lLu9LZFIJNJyeGvF2tq8mYM29wYxFJgdL9yPKMGW7rc1cBtVZATF KG4HQ3pHe3KAP6HU36svic+n3GOzxrfNY8B1SCga3GhnyJaiJASyA21zSJmHQva7 EM0rNArXQ4xD2vrz+o0H =upNz -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: riseup.net OpenPGP Best Practices article
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 6/24/2014 10:57 AM, Hauke Laging wrote: Am Di 24.06.2014, 09:50:04 schrieb Nex6|Bill: anykind of best practice, should be simple, so that it encourages a sane baseline for people. That depends on it whether you need security or the illusion of security is enough for you. IMHO it is one of the main problems that hardly anyone cares about telling protection levels apart. Security is a really wide spectrum, for some beginning at random six letter passwords. You cannot say in a useful sense what is a good recommendation without looking at what is needed in the respective situation. Thus I advocate a standardized set of security levels for data, keys and systems. And authentication on the other hand: http://www.crypto-fuer-alle.de/wishlist/securitylevel/ (German only) Hauke how did you get, security vs illusionary security from that? and while I agree that security is not well defined, in a way that a user or admin can tell what level of security an object or configuration will give him. that does not mean we should get all hyper paranoid on all of our best practices and guidelines to a point where only advanced geeks can understand it. for things, like encryption we, should make an effort for the baselines to be sane, and simple. leave the more advanced stuff to the advanced users. I have found that, when something is complex and or hard to use users will not use it, or will find ways around it. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTqcTsAAoJEBr/3kncCBhnOJoQAI48wKO5tJOfkvcQ0FNeVoy8 STr4QtRSl9wk7xV0d/xXHcJ8qJcv3PfxrgVHFawca3V6hoPflUJBH2iVV2IxAXB/ x2+3AL3yerEQIt/H24dz94MMqwp9MxWGDdZmruaWB7zyrNQLmxicOLecRtSZ8e5d WdxpnpwQipZQun+7NljzVLD3tkHksEvwSnpXMa8A1qFVTlJEjhB8tspOGE/JU7I3 Mqp8vSwpDK9dRjVcLNpMZPRLt1q/KCBNoxfpWzqEFNOgYKMBQSqcYjsgipxQrNT0 xk9gnBv9cMLO+X/fXUxoEFreoEKGEXxxF08N+vX7Sptii6clBSux2g5uX1e9MqqG vX4bROQZN6H6vPXnofHsC8jzS+Fh51YE5E5Xn2vali8IUcVjL6Rsh3pVJl4/Z4+T dNCXydFU4DaDl4vFMGTsOeavZ3yO5N6lFjCveKBMBe8BwwbUj3LIaZJW9XfqeBab jyaCWyz02NfpfasqCpyAHzNubD2/rIktCesetPtDquLDviZyM3mVvs8PoyhsINIA D+jDd6Y5UJ5sq0Hfd92s8CgP7suKfh0lyr7xmKrMY5hblugdveF6teNsr0IcDPPv I//WpIj69CBFzCrUi0JZBEiNOx9ksJNIyMGs/qurSxV/7ChYll6mV1NUx0Ph9geC lgwmmBPdDA1hibFCd7Kk =JUaP -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: riseup.net OpenPGP Best Practices article
On 24-06-2014 8:47, Werner Koch wrote: How does a help 4096 key help if I can send you an encrypted mail which will lock up your MUA until you kill it Finally upgrade that 286 to DOS 3.0? If you have a system that can't handle 4k keys you have very specific needs. Sending a lot of messages through some embedded system perhaps, but if you need do that I assume you know what you're doing. -- ir. J.C.A. Wevers PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: riseup.net OpenPGP Best Practices article
On 24-06-2014 11:42, Pete Stephenson wrote: ObXKCD: http://xkcd.com/538/ The problem with that method is that it only works once, after that other communication methods will be used. Al Quaida use horse couriers who memorise the message, the American's could not intercept them. -- ir. J.C.A. Wevers PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
