Re: SSH Agent keys 4096 bit?
On Fri, 4 May 2012 21:47, do...@dougbarton.us said: only use 1.4 as a result already. The thing that will kill 2.1 for me is the removal of the multiple public keyring functionality. Frankly I doubt that we will be able to remove the latter for 2.1 ;-). 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: SSH Agent keys 4096 bit?
On Sat, 5 May 2012 20:27, gn...@oneiroi.net said: Hm, shouldn't authentication happen before exchanging key for symmetric part of encryption during the SSH session? No, DH is commonly (and by SSH) used as a key agreement protocol. This means that N and only N communication peers agree on a shared session key. It can't avoid a MitM attack and thus an additional authentication step is required. 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: SSH Agent keys 4096 bit?
On Sat, 5 May 2012 12:08, pe...@digitalbrains.com said: Why should the GnuPG authors include a feature they don't believe in? If it's in GnuPG official, it will need to be supported. What if there is It is marketing again. PGP started to use AES-256 for marketing reasons and thus we more or less forced to do include support for AES-256. We initially even did not put AES-256 on top of the cipher preferences, but we even had to change even this: /* The rationale why we use the order AES256,192,128 is for compatibility reasons with PGP. If gpg would define AES128 first, we would get the somewhat confusing situation: gpg -r pgpkey -r gpgkey ---gives-- AES256 gpg -r gpgkey -r pgpkey ---gives-- AES Note that by using --personal-cipher-preferences it is possible to prefer AES128. */ And you seem to forget that when you use GnuPG with (for example) 4k keys, the 4k key is simply not the weakest link! This has been said already. Exactly. data is that valuable, keep it to yourself. Don't give even the encrypted variant to your enemy. Because your formidable enemy will know of a way to decrypt it without breaking your 8k key. Well, even the former option is subject to a pretty cheap rubber hose cryptanalysis. It all depends on your threat model. 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: SSH Agent keys 4096 bit?
On 05/07/2012 04:13 AM, Werner Koch wrote: It is marketing again. PGP started to use AES-256 for marketing reasons and thus we more or less forced to do include support for AES-256. Minor correction: PGP first started using Twofish-256 for marketing reasons. The AES competition was in full swing and PGP Security believed Twofish was going to be the winner, so Twofish-256 was introduced for marketing reasons. This was in PGP 7.0, if memory serves. Once Rijndael was selected, it was introduced in PGP 7.1. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: SSH Agent keys 4096 bit?
On 05/07/2012 00:47, Werner Koch wrote: On Fri, 4 May 2012 21:47, do...@dougbarton.us said: only use 1.4 as a result already. The thing that will kill 2.1 for me is the removal of the multiple public keyring functionality. Frankly I doubt that we will be able to remove the latter for 2.1 ;-). Awesome. :) Doug -- If you're never wrong, you're not trying hard enough ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: SSH Agent keys 4096 bit?
On 06/05/12 01:42, Hubert Kario wrote: But it's the size of prime used that sets the security level, which just happens to share security evaluation with RSA as far as number of bits is concerned (IOW: n-bit DH is considered to be as hard to attack as n-bit RSA). Ah, yes, I misunderstood your point. But the DH protects the session. Cracking DH will get you the session contents. RSA is only used to authenticate. If it weren't for the symmetric encryption of the session, you can probably even get a (plaintext,ciphertext) pair. I've quickly snooped through the RFC's. RSA is used by the client to sign the session identifier, which is determined by DH. Determining the (plaintext, ciphertext) pair from RSA gets you nothing in this case. Which is fortunate, because the server you log into also has the (plaintext, ciphertext) pair after you authenticate. Actually factoring the semiprime is obviously something completely different. But we were talking about keeping confidential messages confidential for decades. There is nothing confidential about an authentication challenge. Confidentiality is encryption. Authentication is a form of signing[1]. With signatures, the plaintext is not confidential. DH without authentication is useless (trivial to MITM). You need to authenticate the DH params you recieve from the other party before you do anything with them. The /server/ is authenticated during key exchange. The /client/ can also be authenticated with a plaintext password sent over the encrypted connection to the server. I don't think the client is authenticated until after key exchange, whether you use RSA or a password (or another form of authentication). Peter. [1] Signing a challenge, which is still quite different in nature from signing data. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at http://wwwhome.cs.utwente.nl/~lebbing/pubkey.txt ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: SSH Agent keys 4096 bit?
On 05/05/2012 10:42 AM, Milo wrote: Obviously it's not. It's for example inappropriate to call single run of DES 3DES... At this point I genuinely can't tell if I'm being trolled. I'm going to assume that I am not, and this will be my last statement on this entire thread. Two functions may operate quite differently, and yet be considered completely identical from a computational perspective. If I ask you to add the numbers from 1 to 100, you might solve it the long way by doing one hundred additions or you might do it the quick way by computing (101*100)/2 or you might do it the fastest possible way by making a lucky guess of 5,050. Doesn't matter. They're all equivalent. If Function A and Function B accept the same domain, output the same range, and have identical surjections from domain onto range, then they can be said to be identical. DES is an example of this. Nowhere in the DES validation tests does it specify, your code must look like this. The DES validation tests only say, given this input and this key, you must generate this output. If your implementation passes the DES validation tests, then congratulations, you can be certified as a FIPS-compliant DES implementation. One-key 3DES is quite capable of passing the DES validation tests. This means that for all intents and purposes it is a DES implementation. As I said, I don't know if I'm being trolled or if you're just thoroughly misinformed. If the former, please stop. If the latter, it can be corrected. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: SSH Agent keys 4096 bit?
On 05/05/2012 01:57 AM, Robert J. Hansen wrote: On 05/04/2012 04:35 PM, Milo wrote: Yes - niche, proof-of-concept, poorly analyzed ciphers. Let's talk about those widely used and considered mainstream. Those are our biggest concern. McEliece is almost as old as RSA. Generations of graduate students have tackled it in cryptanalysis courses. Almost a thousand academic papers have been published on it. None have shown any significant weaknesses in McEliece. Its inventor, Robert McEliece, received the Claude E. Shannon Award a few years ago. What the Fields Medal is to mathematics, or the Turing Prize is to pure computer science, the Shannon Award is to information theory. On the one hand, we have a cipher designed by a Shannon recipient which has had almost a thousand papers published about it without any really significant results. On the other hand, we have you calling it a niche, proof-of-concept, poorly-analyzed cipher. This is futile. I'm reminding you that you are giving one example of rarely used algo (so _niche_ and _out_of_mainsteam_) to back your statement that there is good amount of them. I'm not suggesting that longer key for asymmetric ciphers is a cure for quantum computing backed cryptanalysis. I wrote about possible, future way of circumventing need of sucking nova's energy to successfully attack cipher(text). (...) Any of the four puts us back into the realm of science fiction. If you're advocating making keys larger, I'd like to know which of the four science fiction breakthroughs you expect might happen. And no matter which of the four you choose, I'll point out that should your chosen breakthrough come to pass, we will all have much bigger things to worry about than whether our 20-year-old communications are still safe. This is possibly really big thing to worry. Especially in countries where pizza is vegetable... But again - you are doing another try to revalue data which isn't yours with your value system. Thanks for pointing that but in considered situations this is slight difference. Halving the strength of a 128-bit cipher leaves you with 127 effective bits of security. Rooting the strength of a 128-bit cipher leaves you with 64 effective bits of security. The former is still well beyond our ability to brute-force: the latter is well within our ability to brute force. I don't consider this to be a slight difference. (...) Thus in the presence of large quantum computers an n-bit key can provide at least n/2 bits of security. Slight difference. I don't have more comments. You can't tell consumer or end-user that he can't use 256-bit, symmetric cipher for his (even!) porn stash because this is some kind of faux pas and he is iconoclast because of this. I cannot force someone to not use a 256-bit cipher, true. I can certainly point and laugh at people who believe using one makes them more secure, though. Nobody has the right to be taken seriously. That's a privilege that must be earned. In context of this discussion your statement is ridiculous. At one point you even agreed on using 256-bit symmetric cipher for 50+ years confidentiality (not guaranteed but at least assumed or expected) and now you are turning all things around. You are not able to understand that people can get better security margin dirt-cheap and some stuff can be worth for them of securing for long, long years. Calling them not serious because of picking 256-bit symmetric cipher is... Well I don't have more comments here. Really? Then what's the reason behind 256-bit hw-supproted crypto (e.g. AES instructions for amd64 and x86), widely accessible on consumer market which has nothing to do with nuclear weapons? Marketing. No. Healthy security margin. The dirty little secret of crypto is that we've had a *great* symmetric cipher ever since the mid-1970s: 3DES. It's big. It's ungainly. It's slow. It has all the aesthetics of the Soviet Realism school of art. It's very hard to code up because there are so many fiddly bits. And yet, 3DES has been turning the best minds in crypto into burned-out alcoholic wrecks for the last 35 years. It has been undergoing constant attack for 35 *years*. Entire new branches of cryptanalysis have been invented just to try and dent it. These approaches have all failed miserably. There are a few niches where 3DES doesn't work very well. If you need a cipher that can encrypt a 1000baseT connection, you're better off using something faster. If you need it on a smartcard, you're better off using something more space-efficient. But for the rest of the problem space, 3DES has been rocking the house for almost as long as I've been alive. So here's the question: why isn't 3DES used in more places? Marketing. Because people -- both in the private sector and in the Free Software world -- want to be able to say they support the latest and greatest and best thing. 3des is old
Re: SSH Agent keys 4096 bit?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 El 04-05-2012 10:17, Milo escribió: Hello Robert, Hello all. ... How many petabytes are sent across the wire each day? Do you really think people will be storing all of today's traffic for twenty years, just so some analyst not even born yet will someday be able to say, wow, I really want to see what's in this random guy's porn stash!? Yeah, then leave your home open because Wow, who want to check every door in the world. So many of them. The difference is you don't need to store doors before checking them. Best Regards -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBCAAGBQJPpOEmAAoJEMV4f6PvczxAONUH/jIkisFOFHc/soX+uiqfWbU1 GUOVjo+kFqRmXxAZy4BM1+k50fI2DGekwTgOinTnu4T+EymPUsdIHC7RVTTvwak7 fKqCJ8HWhLeZxBxguiicfeYELBHbcXqODdQDl5UqEC3jLxhhHClFpi5nTigyjv0c fm1QmwoiHHM/J2G6rKo2dEwB3uTUuysf4jsublONE+x1NKYgW7y7UfpUjLK47Pzf 6OfJSB5gM+3LObnuj4blZTiQcWWMeAe/Wu250S0xme7EWnLrAXK2Qk/ZJEFx03kG 8VIQ2aEbEqTfHCFk8dYuXkbeIboLJ1LR4DtIi6vdUst7s0msIrU129LV/MbD4F8= =w0rK -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: SSH Agent keys 4096 bit?
On 04/05/12 22:35, Milo wrote: You can't tell consumer or end-user that he can't use 256-bit, symmetric cipher for his (even!) porn stash because this is some kind of faux pas and he is iconoclast because of this. It's up to him. Why should the GnuPG authors include a feature they don't believe in? If it's in GnuPG official, it will need to be supported. What if there is some bug that only rears its ugly head with 8k keys? They'll need to spend more time on it, time better spent elsewhere. And especially, why should they add something they simply don't believe in. The use of 8k keys is bothersome to others. In the GnuPG case for certifications and signatures, and in the SSH case for the owner of the server you're logging in to and burning unnecesary CPU cycles. One more time - this is not up to you or software authors to decide what's the value behind encrypted data. Even if reason of encrypting it is silly. I don't think it's up to you to decide that the GnuPG authors need to officially support something they find silly. And you seem to forget that when you use GnuPG with (for example) 4k keys, the 4k key is simply not the weakest link! This has been said already. It's an interesting take on things, that the GnuPG authors somehow think your data must be invaluable, because they don't offer 8k RSA. If your data is that valuable, keep it to yourself. Don't give even the encrypted variant to your enemy. Because your formidable enemy will know of a way to decrypt it without breaking your 8k key. Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at http://wwwhome.cs.utwente.nl/~lebbing/pubkey.txt ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: SSH Agent keys 4096 bit?
On 05/05/2012 10:13 AM, Faramir wrote: El 04-05-2012 10:17, Milo escribió: Hello Robert, Hello all. ... How many petabytes are sent across the wire each day? Do you really think people will be storing all of today's traffic for twenty years, just so some analyst not even born yet will someday be able to say, wow, I really want to see what's in this random guy's porn stash!? Yeah, then leave your home open because Wow, who want to check every door in the world. So many of them. The difference is you don't need to store doors before checking them. Do you see any technical problem with this? http://www.wired.com/threatlevel/2008/01/feds-must-exami/ http://www.wired.com/science/discoveries/news/2006/04/70619 http://defensetech.org/2005/12/24/nsa-tapping-into-telecoms-main-arteries/ https://www.eff.org/issues/nsa-spying Even if it requires some effort is becoming more possible then ever (especially with such amount of resources...). Best Regards -- Regards, Milo ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: SSH Agent keys 4096 bit?
On 05/05/2012 12:08 PM, Peter Lebbing wrote: On 04/05/12 22:35, Milo wrote: You can't tell consumer or end-user that he can't use 256-bit, symmetric cipher for his (even!) porn stash because this is some kind of faux pas and he is iconoclast because of this. It's up to him. Why should the GnuPG authors include a feature they don't believe in? If it's in GnuPG official, it will need to be supported. What if there is some bug that only rears its ugly head with 8k keys? They'll need to spend more time on it, time better spent elsewhere. 1) You are responding to citation regarding symmetric crypto with widely used key length. 2) Proponents of approach you are commenting on gave some arguments here already. If not sure check thread and other sources. And especially, why should they add something they simply don't believe in. The use of 8k keys is bothersome to others. In the GnuPG case for certifications and signatures, and in the SSH case for the owner of the server you're logging in to and burning unnecesary CPU cycles. One more time - this is not up to you or software authors to decide what's the value behind encrypted data. Even if reason of encrypting it is silly. I don't think it's up to you to decide that the GnuPG authors need to officially support something they find silly. This is open discussion about free software's value and (expected by some) functionality. Discussion and judging on value of private data is something totally different you know. No offence but I don't think that GnuPG is only to address 100% authors' needs. And you seem to forget that when you use GnuPG with (for example) 4k keys, the 4k key is simply not the weakest link! This has been said already. I'm not forgetting about this. But you are forgetting you are using symmetric crypto with 256-bit key length (e.g. HTTPS) and you don't have any problem with this security overkill (but yes - symmetric ciphers are computationally to use cheaper). For RSA you'll get similar security with ~15k key! Simply for some 4k isn't enough here. Can you imagine your own, private data which should be encrypted for more years then 4k asymmetric key is able to secure? If not you are including into discussion your own needs (or lack of them) as universal and only truth. It's an interesting take on things, that the GnuPG authors somehow think your data must be invaluable, because they don't offer 8k RSA. This is your flawed conclusion. If your data is that valuable, keep it to yourself. Don't give even the encrypted variant to your enemy. Because your formidable enemy will know of a way to decrypt it without breaking your 8k key. Give people in need reasonable way of providing comparable level of security in physical means (with at least same costs as with cryptography). You'll become rich, rich man. Peter. -- Regards, Milo ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: SSH Agent keys 4096 bit?
On 05/05/12 12:49, Milo wrote: 1) You are responding to citation regarding symmetric crypto with widely used key length. Well it's not my fault someone else went off-topic is it? If you are here to persuade the GnuPG authors to include AES256 you're too late. I think you can perfectly discern what message I was intending to get across. 2) Proponents of approach you are commenting on gave some arguments here already. If not sure check thread and other sources. I am very well aware of that. They don't convince, because they don't tackle the problem of the weakest link. One more time - this is not up to you or software authors to decide what's the value behind encrypted data. Even if reason of encrypting it is silly. I don't think it's up to you to decide that the GnuPG authors need to officially support something they find silly. This is open discussion about free software's value and (expected by some) functionality. Discussion and judging on value of private data is something totally different you know. Please read these three quotes again carefully. You are saying you yourself are off-topic; discussing something totally different. I agree. I'm not forgetting about this. But you are forgetting you are using symmetric crypto with 256-bit key length (e.g. HTTPS) and you don't have any problem with this security overkill (but yes - symmetric ciphers are computationally to use cheaper). GnuPG should include 8k RSA because I didn't go through the trouble of disabling AES256 in my browser, risking breakage when an oddball webserver administrator disables all algorithms but AES256? You also indicate yourself where this goes askew: RSA 8k is immensely more CPU intensive than AES256 v AES128. It's an interesting take on things, that the GnuPG authors somehow think your data must be invaluable, because they don't offer 8k RSA. This is your flawed conclusion. I was replying to: One more time - this is not up to you or software authors to decide what's the value behind encrypted data. I read that as: GnuPG authors decide your data is not valuable enough for RSA 8k. I'm unsure how else to read it, but it certainly isn't /my/ conclusion, it's what I read as /your/ conclusion. Please don't make it my conclusion, I would have to severely disagree with myself, and I hate it when that happens. A large error I made: I wrote invaluable when I meant not valuable at all. Is this the source of the confusion? Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at http://wwwhome.cs.utwente.nl/~lebbing/pubkey.txt ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: SSH Agent keys 4096 bit?
On 05/05/2012 01:09 PM, Peter Lebbing wrote: On 05/05/12 12:49, Milo wrote: 1) You are responding to citation regarding symmetric crypto with widely used key length. (...) One more time - this is not up to you or software authors to decide what's the value behind encrypted data. Even if reason of encrypting it is silly. I don't think it's up to you to decide that the GnuPG authors need to officially support something they find silly. This is open discussion about free software's value and (expected by some) functionality. Discussion and judging on value of private data is something totally different you know. Please read these three quotes again carefully. You are saying you yourself are off-topic; discussing something totally different. I agree. No. Discussion was at some point about reasons of using strong crypto. And at some point idea that it's not worth to use it against data which has no value appeared. My point is you are not in the position to say what's the value of the data someone is encrypting. You weren't reading carefully enough to see this and you are suggesting me that I'm trying to force GnuPG authors to do something which is - almost offensive - rubbish. This is discussion Peter, nothing else. I'm not forgetting about this. But you are forgetting you are using symmetric crypto with 256-bit key length (e.g. HTTPS) and you don't have any problem with this security overkill (but yes - symmetric ciphers are computationally to use cheaper). GnuPG should include 8k RSA because I didn't go through the trouble of disabling AES256 in my browser, risking breakage when an oddball webserver administrator disables all algorithms but AES256? In overall I agree with this but disabling all stuff but AES256 is silly and overdrawn try to devaluate my statement. You also indicate yourself where this goes askew: RSA 8k is immensely more CPU intensive than AES256 v AES128. If you can't afford this immense expense - don't use 8k RSA. It's an interesting take on things, that the GnuPG authors somehow think your data must be invaluable, because they don't offer 8k RSA. This is your flawed conclusion. I was replying to: One more time - this is not up to you or software authors to decide what's the value behind encrypted data. I read that as: GnuPG authors decide your data is not valuable enough for RSA 8k. I'm unsure how else to read it, but it certainly isn't /my/ conclusion, it's what I read as /your/ conclusion. Please don't make it my conclusion, I would have to severely disagree with myself, and I hate it when that happens. You are following idea that people who are using strong crypto to things which are in your opinion worthless aren't serious. Looks like at best you replied to piece of thread without knowing its context. There is a difference between your overdrawn (again) interpretation that all this data is without value in eyes of GnuPG authors. I'm just saying that it's not for them do evaluate value of this data. Simple as this. And yes - by using extremely cheap rhetoric tricks you made this opinion yours. I'm really sorry because of you but this is not my problem. A large error I made: I wrote invaluable when I meant not valuable at all. Is this the source of the confusion? As above. Peter. At some point discussion was quite constructive but it's not anymore. -- Regards, Milo ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: SSH Agent keys 4096 bit?
Milo, I am sorry if I somehow offended you. That's the feeling I get from your latest mail. It was not the intention. I do want to note that no matter how careful you read, English is multi-interpretable and ambiguous. So when someone interprets a statement differently than you do, it does not necessarily mean they must not have read carefully enough. Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at http://wwwhome.cs.utwente.nl/~lebbing/pubkey.txt ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: SSH Agent keys 4096 bit?
On 5/5/12 4:37 AM, Milo wrote: This is futile. I'm reminding you that you are giving one example of rarely used algo (so _niche_ and _out_of_mainsteam_) to back your statement that there is good amount of them. Rarely used is not the same as proof of concept. Your statement did not mention out of the mainstream. No moving the goalposts, please. You were also arguing that QC would shred all or most asymmetric systems. It turns out that no, QC doesn't, can't, won't: it will only shred the discrete logarithm problem or problems isomorphic to it, such as integer factorization. Other systems, whether multivariate, lattice or Goppa code-based systems, won't be. (Well -- lattice systems might: right now they're only conjectured to be outside of BQP. But Goppa codes are well-known for being NP-hard.) If you're now claiming that I've only presented one system, well, that's because I wasn't aware you were looking for the kitchen sink. Do some reading on post-quantum cryptography. As I read the tea leaves the new hotness is in the lattice-based systems, but I think systems based on Goppa codes will continue to surprise us. In context of this discussion your statement is ridiculous. At one point you even agreed on using 256-bit symmetric cipher for 50+ years confidentiality (not guaranteed but at least assumed or expected) and now you are turning all things around. Not at all. If you're securing nuclear weapon release codes and you ask me, is it okay if I use 256-bit crypto?, I will blink a few times and back away slowly from the thermonuclear weapon while nodding vigorously and making noises about how they must be secure for fifty years or more, oh and is that thing releasing radiation right now and where do you plan on storing this so I can live far away from it. If you're securing your recipe book and you ask me, is it okay if I use 256-bit crypto?, I will smile and pleasantly explain that, really, past about 112 bits it's just an exercise in paranoia. Use whatever you like, but managing your keys will be a much more important task than deciding between 3DES and AES256. And if you're telling everyone that AES256 will give them a larger security margin than 3DES, well... at that point I'm going to start pointing and laughing. There is enough misinformation and half-truths floating around the crypto-hobbyist's world: I consider it to be a polite act towards the community to challenge this when I encounter it. 3des is old Old software engineering joke: legacy code (n): code that hasn't crashed in the last 40 years. You call 3DES old. I call it quite well tested in demanding production environments. More often than not when you swipe a credit card, 3DES is being used to secure the transaction at various critical points. and it's providing something like 80-112 bits of security. The best attack against three-key 3DES requires almost 10^27 bytes of RAM. This is completely impractical, as even the inventor of the attack has said. To the best of our knowledge there is no effective way to reduce three-key 3DES, which is the only NIST-approved version, below 168 bits of key space. It has ugly history of keying hacks and some aren't back compatible - ... I have absolutely no idea what you're talking about here. None. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: SSH Agent keys 4096 bit?
On 05/05/2012 02:20 PM, Robert J. Hansen wrote: On 5/5/12 4:37 AM, Milo wrote: This is futile. I'm reminding you that you are giving one example of rarely used algo (so _niche_ and _out_of_mainsteam_) to back your statement that there is good amount of them. Rarely used is not the same as proof of concept. Your statement did not mention out of the mainstream. No moving the goalposts, please. I mentioned some attributes of ciphers which are generally out of concern because - e.g. - they aren't widely used. I understand term niche cipher as somehow overlapping and with similar meaning as out of mainstream. And I used `,' logical disjunction. Hope my intention is clear now ;) You were also arguing that QC would shred all or most asymmetric systems. It turns out that no, QC doesn't, can't, won't: it will only shred the discrete logarithm problem or problems isomorphic to it, such as integer factorization. Other systems, whether multivariate, lattice or Goppa code-based systems, won't be. (Well -- lattice systems might: right now they're only conjectured to be outside of BQP. But Goppa codes are well-known for being NP-hard.) after Wikipedia: Derivatives of Shor's algorithm are widely conjectured to be effective against all mainstream public-key algorithms including RSA, Diffie-Hellman and elliptic curve cryptography. I'm not considering all of them. I used more general expression. If you're now claiming that I've only presented one system, well, that's because I wasn't aware you were looking for the kitchen sink. Do some reading on post-quantum cryptography. As I read the tea leaves the new hotness is in the lattice-based systems, but I think systems based on Goppa codes will continue to surprise us. Thanks for this tip. In context of this discussion your statement is ridiculous. At one point you even agreed on using 256-bit symmetric cipher for 50+ years confidentiality (not guaranteed but at least assumed or expected) and now you are turning all things around. Not at all. If you're securing nuclear weapon release codes and you ask me, is it okay if I use 256-bit crypto?, I will blink a few times and back away slowly from the thermonuclear weapon while nodding vigorously and making noises about how they must be secure for fifty years or more, oh and is that thing releasing radiation right now and where do you plan on storing this so I can live far away from it. If you're securing your recipe book and you ask me, is it okay if I use 256-bit crypto?, I will smile and pleasantly explain that, really, past about 112 bits it's just an exercise in paranoia. Use whatever you like, but managing your keys will be a much more important task than deciding between 3DES and AES256. And if you're telling everyone that AES256 will give them a larger security margin than 3DES, well... at that point I'm going to start pointing and laughing. There is enough misinformation and half-truths floating around the crypto-hobbyist's world: I consider it to be a polite act towards the community to challenge this when I encounter it. And again we are going through field of evaluating data's value. I don't think I have something more to add here. I understand your point and possibly person who will ask you such question(s) can follow your advice without harm. But I don't think that biggest proponents of longer asymmetric keys are such kind of guys. Your approach advised to this hypothetical person is more like tao of using encryption then set of objective rules. 3des is old Old software engineering joke: legacy code (n): code that hasn't crashed in the last 40 years. You call 3DES old. I call it quite well tested in demanding production environments. More often than not when you swipe a credit card, 3DES is being used to secure the transaction at various critical points. But lacking bigger margin of security because of limited key space. See NIST advisories for 3des keying methods (see: 50 years+ security problem; yeah, some people are quite suspicious about them). and it's providing something like 80-112 bits of security. The best attack against three-key 3DES requires almost 10^27 bytes of RAM. This is completely impractical, as even the inventor of the attack has said. To the best of our knowledge there is no effective way to reduce three-key 3DES, which is the only NIST-approved version, below 168 bits of key space. It has ugly history of keying hacks and some aren't back compatible - ... I have absolutely no idea what you're talking about here. None. Check 3des history for details ( https://en.wikipedia.org/wiki/3des#Keying_options ). -- Regards, Milo ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: SSH Agent keys 4096 bit?
On 5/5/12 8:57 AM, Milo wrote: Derivatives of Shor's algorithm are widely conjectured to be effective against all mainstream public-key algorithms including RSA, Diffie-Hellman and elliptic curve cryptography. I'm not considering all of them. I used more general expression. In that case, everything you're advocating is confusing me. Yes, if and when QC comes along many existing systems will need to be considered suspect. However, if you're concerned about QC you will get far more mileage from switching to a QC-resistant asymmetric algorithm than from adding a few bits to your RSA key. Why all this focus on longer RSA keys as a response to QC? It makes no sense at all. But I don't think that biggest proponents of longer asymmetric keys are such kind of guys. Your approach advised to this hypothetical person is more like tao of using encryption then set of objective rules. That's because there are very few objective rules. Computer security is dominated by the human element, and human beings do not tend to strictly follow objective rules. When it comes to crypto, yes, we can say certain things with great mathematical certainty. The instant that crypto gets fielded, though, the math becomes the least important part of the equation. The human element becomes overwhelmingly dominant. But lacking bigger margin of security because of limited key space. NIST has certified 3DES until 2030: it is quite likely that in 2030 3DES will be certified for another couple of decades. Check 3des history for details ( https://en.wikipedia.org/wiki/3des#Keying_options ). I did, and I don't see anything in there that are ugly hacks or backwards-incompatible. Choose your keying option (three-key being preferred), stick with it and you're done. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: SSH Agent keys 4096 bit?
On Friday 04 of May 2012 21:41:25 Peter Lebbing wrote: On 04/05/12 20:54, Ali Lown wrote: Might I point out that discussion is with respect to an 8k RSA SSH key for SSH authentication, not for email. A 2 second delay during the initialization of an SSH connection is not a problem. And here is precisely something interesting: 8k RSA is discussed as a method to keep messages confidential for decades. I haven't looked into it, but I'm under the impression RSA is used purely for authentication in SSH, not for key exchange[1]. What are you protecting decades against here? A server reusing a random challenge? That seems quite far fetched. Oh, by the way, only the computational load for the client was discussed. There's also the server (although the public side of the computation is quicker than the private side). The server gets logins from potentially a lot of clients. Peter. [1] I get this impression because there is a configuration option for OpenSSH sshd that selects which key exchange methods to use, and they all have DH (Diffie-Helmann) in their name. As far as I know, OpenSSH uses DH parameters of the same size as the RSA keys: for 8k DH you need 8k RSA or (which is unmaintainable) manually force use of 8k DH. Regards, -- Hubert Kario QBS - Quality Business Software 02-656 Warszawa, ul. Ksawerów 30/85 tel. +48 (22) 646-61-51, 646-74-24 www.qbs.com.pl ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: SSH Agent keys 4096 bit?
On Friday 04 of May 2012 08:40:31 Robert J. Hansen wrote: On 05/04/2012 06:07 AM, Hubert Kario wrote: It still doesn't change the overall picture: 1. migrating to ECC is hard and complicated 2. using 8k RSA is easy Nor does it change 3. using 8K RSA gives a modest increase to an already formidable margin of security Breaking a 128-bit keyspace is hard. Like, really, really hard. The power analysis on that one is eye-popping: to break a 128-bit keyspace in anything approaching a reasonable length of time requires an energy output on the level of a hypernova. If you want to break a 128-bit keyspace, please do it in a galaxy far, far away. So why do we need to increase a 128-bit keyspace (RSA-3K) to a 192-bit-plus-a-small-amount keyspace (RSA-8K)? The obvious response is to defend against enhanced attacks against RSA, such as quantum computing and Shor's Algorithm. But that's just crazy. Shor's Algorithm requires 2N qubits to break an N-bit key. Right now we've got quantum computers that have, what, eight qubits? Any RSA modulus smaller than sixteen is in trouble now, let me tell you. Reading about cryptography history I noticed one thing, when NSA said don't do something it meant that this thing did break the crypto entirely or allowed for far easier attacks. Considering that they tell us don't use RSA (in Crypto suite B), would suggest that they have an attack on RSA that considerably limits its security. So whatever 4k RSA really does have a large margin of security is questionable. We've already established that telling everybody to use 8k or greater keys is infeasible because of computational problems (in phones and web servers, let alone smartchips). The only solution for that problem is to tell everybody to use ECC (which has lower computational requirements). This does not mean that long RSA keys are useless for all use cases. SSH certainly isn't one of them. Regards, -- Hubert Kario QBS - Quality Business Software 02-656 Warszawa, ul. Ksawerów 30/85 tel. +48 (22) 646-61-51, 646-74-24 www.qbs.com.pl ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: SSH Agent keys 4096 bit?
On 05/05/2012 03:13 PM, Robert J. Hansen wrote: On 5/5/12 8:57 AM, Milo wrote: Derivatives of Shor's algorithm are widely conjectured to be effective against all mainstream public-key algorithms including RSA, Diffie-Hellman and elliptic curve cryptography. I'm not considering all of them. I used more general expression. In that case, everything you're advocating is confusing me. Yes, if and when QC comes along many existing systems will need to be considered suspect. However, if you're concerned about QC you will get far more mileage from switching to a QC-resistant asymmetric algorithm than from adding a few bits to your RSA key. Why all this focus on longer RSA keys as a response to QC? It makes no sense at all. You are mixing two topics: Need of security margin better then provided by one of common, widely used asymmetric algorithms using 4k key and/with possible impact of QC on asymmetric ciphers in general. Second topic was started indirectly by you with tap on nova's energy output and my reply to this part has not much too do with first part. But I don't think that biggest proponents of longer asymmetric keys are such kind of guys. Your approach advised to this hypothetical person is more like tao of using encryption then set of objective rules. That's because there are very few objective rules. Computer security is dominated by the human element, and human beings do not tend to strictly follow objective rules. Hmm. Not sure if I can agree with you here. This is something I must think about. When it comes to crypto, yes, we can say certain things with great mathematical certainty. The instant that crypto gets fielded, though, the math becomes the least important part of the equation. The human element becomes overwhelmingly dominant. But lacking bigger margin of security because of limited key space. NIST has certified 3DES until 2030: it is quite likely that in 2030 3DES will be certified for another couple of decades. Guesswork. Check 3des history for details ( https://en.wikipedia.org/wiki/3des#Keying_options ). I did, and I don't see anything in there that are ugly hacks or backwards-incompatible. Choose your keying option (three-key being preferred), stick with it and you're done. (...) This improves the strength of the algorithm when using keying option 2, and _provides_ _backward_compatibility_ with DES with keying option 3. If you aren't OK with this view - fine. Can't help it. The fact is the simpler and more transparent cipher is, the easier its security evaluation is. Simplicity in cryptography is often practical. -- Regards, Milo ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: SSH Agent keys 4096 bit?
On 5/5/12 10:17 AM, Milo wrote: (...) This improves the strength of the algorithm when using keying option 2, and _provides_ _backward_compatibility_ with DES with keying option 3. One-key 3DES *is* DES. It's a DES encryption, decryption with that same key, then re-encryption with that same key. One-key 3DES existed to allow institutions to bootstrap their infrastructure out of DES. First they instituted one-key 3DES, which let them transparently upgrade their infrastructure without impacting business operations. Once they were convinced their new 3DES infrastructure was working correctly, they switched to using two-key or three-key 3DES. One-key 3DES was never meant to be used as anything more than an upgrade path. The backwards compatibility of one-key 3DES was necessary for upgrade purposes, but once fully deployed 3DES has never had a problem with backwards compatibility. What you said earlier was that 3DES had a bunch of keying hacks and backwards incompatibilities. Neither is true. All the various forms have been scrutinized quite closely and found to be solid. One-key 3DES has the benefit of backwards compatibility with DES, which is useful for upgrade purposes, but it's a gross misstatement of fact to claim that 3DES has a problem with backwards incompatibility. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: SSH Agent keys 4096 bit?
On 05/05/2012 04:26 PM, Robert J. Hansen wrote: On 5/5/12 10:17 AM, Milo wrote: (...) This improves the strength of the algorithm when using keying option 2, and _provides_ _backward_compatibility_ with DES with keying option 3. One-key 3DES *is* DES. Obviously it's not. It's for example inappropriate to call single run of DES 3DES... It's a DES encryption, decryption with that same key, then re-encryption with that same key. One-key 3DES existed to allow institutions to bootstrap their infrastructure out of DES. First they instituted one-key 3DES, which let them transparently upgrade their infrastructure without impacting business operations. Once they were convinced their new 3DES infrastructure was working correctly, they switched to using two-key or three-key 3DES. One-key 3DES was never meant to be used as anything more than an upgrade path. The backwards compatibility of one-key 3DES was necessary for upgrade purposes, but once fully deployed 3DES has never had a problem with backwards compatibility. And simply, you've just described ugly hack. What you said earlier was that 3DES had a bunch of keying hacks and backwards incompatibilities. Neither is true. All the various forms have been scrutinized quite closely and found to be solid. And nothing changed in my stance. What's more 3DES is one big hack to prolong life of outdated cipher. If you are making such statements as above, try to not do this while commenting heavily edited, original message. One-key 3DES has the benefit of backwards compatibility with DES, which is useful for upgrade purposes, but it's a gross misstatement of fact to claim that 3DES has a problem with backwards incompatibility. I'm not interested (in context of this discussion) in benefits of this mode. -- Regards, Milo ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: SSH Agent keys 4096 bit?
On 05/05/2012 04:17 PM, Milo wrote: (...) You are mixing two topics: Need of security margin better then provided by one of common, widely used asymmetric algorithms using 4k key I was rather thinking about 4k RSA key or security equivalent provided by one of common, widely used asymmetric algorithms here, sorry. and/with possible impact of QC on asymmetric ciphers in general. Second topic was started indirectly by you with tap on nova's energy output and my reply to this part has not much too do with first part. (...) -- Regards, Milo ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: SSH Agent keys 4096 bit?
On 05/05/12 15:49, Hubert Kario wrote: As far as I know, OpenSSH uses DH parameters of the same size as the RSA keys: for 8k DH you need 8k RSA or (which is unmaintainable) manually force use of 8k DH. Okay, going out on a limb here, since all what I say is conjecture. Actually consulting the SSH RFC's seems like too much work, or seems too much like work :). I think it's rather the case that the size of the DH parameters is proportional to the keysize of the symmetric algorithm used to secure the SSH session, because the DH params are used to compute the session key. So you are right that the DH params are proportional in size to a key used, but you've confused the keys, asymmetric vs symmetric. That way it makes sense to me. If I look at the debug messages emitted by the OpenSSH client, I'm under the impression that key exchange is already completed before authentication with RSA starts. Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at http://wwwhome.cs.utwente.nl/~lebbing/pubkey.txt ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: SSH Agent keys 4096 bit?
On 05/05/2012 08:03 PM, Peter Lebbing wrote: On 05/05/12 15:49, Hubert Kario wrote: As far as I know, OpenSSH uses DH parameters of the same size as the RSA keys: for 8k DH you need 8k RSA or (which is unmaintainable) manually force use of 8k DH. Okay, going out on a limb here, since all what I say is conjecture. Actually consulting the SSH RFC's seems like too much work, or seems too much like work :). I think it's rather the case that the size of the DH parameters is proportional to the keysize of the symmetric algorithm used to secure the SSH session, because the DH params are used to compute the session key. So you are right that the DH params are proportional in size to a key used, but you've confused the keys, asymmetric vs symmetric. That way it makes sense to me. If I look at the debug messages emitted by the OpenSSH client, I'm under the impression that key exchange is already completed before authentication with RSA starts. Hm, shouldn't authentication happen before exchanging key for symmetric part of encryption during the SSH session? Peter. -- Regards, Milo ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: SSH Agent keys 4096 bit?
On Saturday 05 of May 2012 20:03:04 Peter Lebbing wrote: On 05/05/12 15:49, Hubert Kario wrote: As far as I know, OpenSSH uses DH parameters of the same size as the RSA keys: for 8k DH you need 8k RSA or (which is unmaintainable) manually force use of 8k DH. Okay, going out on a limb here, since all what I say is conjecture. Actually consulting the SSH RFC's seems like too much work, or seems too much like work :). I think it's rather the case that the size of the DH parameters is proportional to the keysize of the symmetric algorithm used to secure the SSH session, because the DH params are used to compute the session key. So you are right that the DH params are proportional in size to a key used, but you've confused the keys, asymmetric vs symmetric. That way it makes sense to me. The secret being exchanged is, of course, the random session key. Its size is related to size of subgroup in DH. But it's the size of prime used that sets the security level, which just happens to share security evaluation with RSA as far as number of bits is concerned (IOW: n-bit DH is considered to be as hard to attack as n-bit RSA). If I look at the debug messages emitted by the OpenSSH client, I'm under the impression that key exchange is already completed before authentication with RSA starts. DH without authentication is useless (trivial to MITM). You need to authenticate the DH params you recieve from the other party before you do anything with them. Regards, -- Hubert Kario QBS - Quality Business Software 02-656 Warszawa, ul. Ksawerów 30/85 tel. +48 (22) 646-61-51, 646-74-24 www.qbs.com.pl ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: SSH Agent keys 4096 bit?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 El 05-05-2012 7:46, Milo escribió: ... You also indicate yourself where this goes askew: RSA 8k is immensely more CPU intensive than AES256 v AES128. If you can't afford this immense expense - don't use 8k RSA. But if you send a signed message, using RSA 8k, then you force your recipient to use it. GPG choses the symmetric algo and hash algo based on the recipient's preferences, but it can't chose they asymmetric algo. Best Regards -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBCAAGBQJPpfVfAAoJEMV4f6PvczxA8PwIAKD1jSUMQhx+nWrOmTMAfwTp 6XKso4YKlr0eQofnYDywBu8sUW2N1HZvl2u2f/1pp8n63Xifua45a6glZPl5nsGF wouA2OFcQPupDIOZVq6skkp+Dxxr2nvjvvG2HYxSJqtAjWsEezFcUrmFP15/TC4W G7RNAz8bC39O9VNcPCBA5qBLUX/DF2tBKZ22tm9IEE1OTiYREOJNnq0AQcnkro/T xIbZwcVQTz7wuG8TTzy5tQZNJnk0tTVSNbEpPJGEP2D7gVXteaprV+nVhcfwOGkr 1w1VlQiQTRFJBIWJyKES6LTLqtqSkIlTEogAsWLX53k7RyhVCie0iI7qg/8SDNg= =LOro -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: SSH Agent keys 4096 bit?
On Fri, 4 May 2012 00:27, h...@qbs.com.pl said: decision, and that's agreed by basically anybody (NIST, ECRYPT II). Especially when the cost of establishing the link with 8k RSA is insignificant for any session over 5min in length (as is common in SSH). Sorry, but that is plain nonsense. Maybe not with your desktop box, but my N900 takes quite some time to compute with 4k RSA keys. Besides that, Schneier and Ferguson[2] say that basically any RSA based crypto system should support 8k keys. Switching to ECC is not easy, you need to I can't locate my copy right now. Anyway, such suggestions depend largely on the context. It might be true in theory for US or French govt security but not for any practical purposes. Brian Snow of the NSA once told during lunch that they don't care to break the crypto - we cheat. What he meant is that it is way easier and cheaper to exploit software bugs or RNG peculiarities than to build for example Twinkle devices. If the NSA is worth its money, you should assume that they have a bunch of zero day exploits available for all kind of software - including GnuPG. In particular SSH, which by its nature can't be used on a dedicated offline box, the use of even a 4k key is ridiculous. Such use reminds me more of security policies which demand the use of passphrases but allow that the passphrase be stored on the same box in a file. Current practice is the use of 2k RSA keys and you simply do that just because everyone is happy if you follow this rule. Using a lower key size might be justifiable but it is not worth to spend the time to explain the reason why it is okay to use only, say, 1536 bit. 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: SSH Agent keys 4096 bit?
On Fri, 4 May 2012 03:03, j...@enigmail.net said: I suspect WK has ECC ready to go in both GnuPG 1.4 and 2.0 as soon as the ID is approved. I know it's already present in the 2.1 beta code. No, we don't plan to port it back to 1.4. It will actually take years until ECC keys are in wide use and by then 2.1 will be the stable release. I even hope to declare 2.1 stable sometime this year. BTW, the draft is already in the rfc editors's publication queue. 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: SSH Agent keys 4096 bit?
On Friday 04 of May 2012 10:37:21 Werner Koch wrote: On Fri, 4 May 2012 00:27, h...@qbs.com.pl said: decision, and that's agreed by basically anybody (NIST, ECRYPT II). Especially when the cost of establishing the link with 8k RSA is insignificant for any session over 5min in length (as is common in SSH). Sorry, but that is plain nonsense. Maybe not with your desktop box, but my N900 takes quite some time to compute with 4k RSA keys. OK, so the use of 8k RSA keys won't work with low power embedded devices. It still doesn't change the overall picture: 1. migrating to ECC is hard and complicated 2. using 8k RSA is easy Besides that, Schneier and Ferguson[2] say that basically any RSA based crypto system should support 8k keys. Switching to ECC is not easy, you need to I can't locate my copy right now. Anyway, such suggestions depend largely on the context. Quote from the book: The absolute minimum size for n is 2048 bits or so if you want to protect your data for 20 years. This minimum slowly increases as compiters get faster. If you can afford it in your application, let n be 4096 bit long or as close to this size as you can get it. Furthermore, make sure that your software supports values of n up to 8192 bits long. That was written in 2003, nearly 10 years ago. They suggested using current day minimums when GPGPU didn't even exist and FPGAs with large memories were just surfacing. It might be true in theory for US or French govt security but not for any practical purposes. Brian Snow of the NSA once told during lunch that they don't care to break the crypto - we cheat. What he meant is that it is way easier and cheaper to exploit software bugs or RNG peculiarities than to build for example Twinkle devices. If the NSA is worth its money, you should assume that they have a bunch of zero day exploits available for all kind of software - including GnuPG. possibly, still I'd guess that most of them are active, online attacks but now we're in the hypothetical realm of vague possibility, such discussion is useless and suggest more that we just have to throw away cryto as it's useless anyway than anything else. Which, frankly, is bollocks. In particular SSH, which by its nature can't be used on a dedicated offline box, the use of even a 4k key is ridiculous. Such use reminds me more of security policies which demand the use of passphrases but allow that the passphrase be stored on the same box in a file. What has online/offline net connection anything to do with that? Storing acquired information for 20 years is nothing extraordinary as far as intelligence agencies and highly motivated individuals are concerned. Hell, I've got files on my hard drive that are around 15 years old. Computing in 20 years may be very different than it is today. Current practice is the use of 2k RSA keys and you simply do that just because everyone is happy if you follow this rule. Using a lower key size might be justifiable but it is not worth to spend the time to explain the reason why it is okay to use only, say, 1536 bit. Current practice is for data that hardly never has to deal with secrets that have to be kept for 40 years (like I noted before). As regularly the most valuable information being passed over secure links are passwords and http cookies. Which basically never have validity of over 10 years and 1 year respecitvely. Thing is, that is not the only use-case of crypto systems. Regards, -- Hubert Kario QBS - Quality Business Software 02-656 Warszawa, ul. Ksawerów 30/85 tel. +48 (22) 646-61-51, 646-74-24 www.qbs.com.pl ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: SSH Agent keys 4096 bit?
On Fri, 4 May 2012 12:07, h...@qbs.com.pl said: It still doesn't change the overall picture: 1. migrating to ECC is hard and complicated Right, it will take years. But that is not a problem. 2. using 8k RSA is easy I already told my opinion on this. That was written in 2003, nearly 10 years ago. They suggested using current day minimums when GPGPU didn't even exist and FPGAs with large memories were just surfacing. A point that they don't consider is that the weakest link defines the security of the system. They evaluate this only in terms of algorithms but not from a software engineering POV. If you look at this this you see that errors in the software (and hardware) are a far weaker link than any theory on how long it will take to break a certain algorithm. possibly, still I'd guess that most of them are active, online attacks We have been talking about SSH - this is online. Whether active or passive doesn't matter. Email can also be considered online. Backups are often offline and then you won't target the encryption but the plaintext - having access to the hardware (which you need for offline attacks) opens a long list of attack vectors and cryptography is just one of them. but now we're in the hypothetical realm of vague possibility, such discussion is useless and suggest more that we just have to throw away cryto as it's useless anyway than anything else. Which, frankly, is bollocks. Nobody said this. What has online/offline net connection anything to do with that? Storing A lot. Online connections allow for active attacks on the participating software. For off-line it is harder to mount attacks; but still possible (cf. Stuxnet). have to be kept for 40 years (like I noted before). As regularly the most valuable information being passed over secure links are passwords and http cookies. Which basically never have validity of over 10 years and 1 year respecitvely. Well, then I can't follow your arguments - we need 8k RSA despite that the data needs to be protected only for a short term? 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: SSH Agent keys 4096 bit?
On 05/04/2012 06:07 AM, Hubert Kario wrote: It still doesn't change the overall picture: 1. migrating to ECC is hard and complicated 2. using 8k RSA is easy Nor does it change 3. using 8K RSA gives a modest increase to an already formidable margin of security Breaking a 128-bit keyspace is hard. Like, really, really hard. The power analysis on that one is eye-popping: to break a 128-bit keyspace in anything approaching a reasonable length of time requires an energy output on the level of a hypernova. If you want to break a 128-bit keyspace, please do it in a galaxy far, far away. So why do we need to increase a 128-bit keyspace (RSA-3K) to a 192-bit-plus-a-small-amount keyspace (RSA-8K)? The obvious response is to defend against enhanced attacks against RSA, such as quantum computing and Shor's Algorithm. But that's just crazy. Shor's Algorithm requires 2N qubits to break an N-bit key. Right now we've got quantum computers that have, what, eight qubits? Any RSA modulus smaller than sixteen is in trouble now, let me tell you. An effective quantum computer with the 6144 qubits required to break a 3072-bit RSA key is straight out of science fiction. This quantum computer would be more powerful than any conventional computer could ever be: a conventional computer would require 10**1850 bytes of storage -- and no, that is not a typo -- to compete against it: that should give you a sense of the outrageous scale involved. There is no other way to describe this than science fiction. If you want to defend against science fiction, well, go right ahead. But I think you should also defend against other sorts of fiction, and I look forward to hearing how your security model will incorporate G.I. Joe to fight off the hordes of blue-suited terrorists sent by Cobra Commander. And yes, I really do believe that worrying about the development of large-scale quantum computers is on the same level of seriousness as worrying about Cobra Commander. What has online/offline net connection anything to do with that? Storing acquired information for 20 years is nothing extraordinary as far as intelligence agencies and highly motivated individuals are concerned. How many petabytes are sent across the wire each day? Do you really think people will be storing all of today's traffic for twenty years, just so some analyst not even born yet will someday be able to say, wow, I really want to see what's in this random guy's porn stash!? If you have reason to believe you're a person of such interest to such professionals as would be likely to monitor and store your communications for twenty years, here's the only effective way to secure your communications: stop using any technology more sophisticated than a frying pan. bin Laden didn't keep his communications secure by using large RSA keys. He kept his communications secure by abandoning technology and using cut-outs to do his online transactions for him, and making them travel hundreds of kilometers away from Abottabad before checking into an internet cafe to send his traffic. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: SSH Agent keys 4096 bit?
Let me turn things around. Other than providing opportunities to discuss the practicalities of large RSA keys, is there any reason why the agent should care what size key it is storing? -- Mark H. Wood, Lead System Programmer mw...@iupui.edu Asking whether markets are efficient is like asking whether people are smart. pgpeQqGlIhVO2.pgp Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: SSH Agent keys 4096 bit?
Hello Robert, Hello all. On 05/04/2012 02:40 PM, Robert J. Hansen wrote: On 05/04/2012 06:07 AM, Hubert Kario wrote: It still doesn't change the overall picture: 1. migrating to ECC is hard and complicated 2. using 8k RSA is easy Nor does it change 3. using 8K RSA gives a modest increase to an already formidable margin of security Breaking a 128-bit keyspace is hard. Like, really, really hard. The power analysis on that one is eye-popping: to break a 128-bit keyspace in anything approaching a reasonable length of time requires an energy output on the level of a hypernova. If you want to break a 128-bit keyspace, please do it in a galaxy far, far away. So why do we need to increase a 128-bit keyspace (RSA-3K) to a 192-bit-plus-a-small-amount keyspace (RSA-8K)? Well, many expect rise of the quantum computing during lives of most of us. This can trash most (if not all) asymmetric algorithms (Shor's algorithm) and reduce strength of symmetric ciphers in half (with for example Grover's algorithm). Beside this consider widespread usage of 256-bit symmetric ciphers. If things you are writing are all the truth behind key length security we are dealing with huge, mass overkill or even scam perhaps. But I think we aren't. The obvious response is to defend against enhanced attacks against RSA, such as quantum computing and Shor's Algorithm. But that's just crazy. Shor's Algorithm requires 2N qubits to break an N-bit key. Right now we've got quantum computers that have, what, eight qubits? Any RSA modulus smaller than sixteen is in trouble now, let me tell you. An effective quantum computer with the 6144 qubits required to break a 3072-bit RSA key is straight out of science fiction. This quantum computer would be more powerful than any conventional computer could ever be: a conventional computer would require 10**1850 bytes of storage -- and no, that is not a typo -- to compete against it: that should give you a sense of the outrageous scale involved. There is no other way to describe this than science fiction. Just like modern cellphones' CPU/GPUs are s-f from Apollo mission's engineers' perspective, just like 640K ought to be enough for anybody and like 32-bit address space for IP protocol is more then enough. History is showing quite clearly that such speculations despite - ofte high - competencies of the authors are missed. If you want to defend against science fiction, well, go right ahead. But I think you should also defend against other sorts of fiction, and I look forward to hearing how your security model will incorporate G.I. Joe to fight off the hordes of blue-suited terrorists sent by Cobra Commander. And yes, I really do believe that worrying about the development of large-scale quantum computers is on the same level of seriousness as worrying about Cobra Commander. Believe is good term when talking about aesthetics for example. This isn't the same as being convinced about proper approach to technical problems. If you have proper background in genetics, fresh stream of information from covert labs, bio black markets (is there such thing anyway?) its worth to take your opinion into account. Please try to avoid comedic undertone of your statements and comparisons if you want to keep discussion's level sane. What has online/offline net connection anything to do with that? Storing acquired information for 20 years is nothing extraordinary as far as intelligence agencies and highly motivated individuals are concerned. How many petabytes are sent across the wire each day? Do you really think people will be storing all of today's traffic for twenty years, just so some analyst not even born yet will someday be able to say, wow, I really want to see what's in this random guy's porn stash!? Yeah, then leave your home open because Wow, who want to check every door in the world. So many of them. Yeah, let's drop all the crypto (encryption) for common folk because put your arguments from above here. If you have reason to believe you're a person of such interest to such professionals as would be likely to monitor and store your communications for twenty years, here's the only effective way to secure your communications: stop using any technology more sophisticated than a frying pan. bin Laden didn't keep his communications secure by using large RSA keys. He kept his communications secure by abandoning technology and using cut-outs to do his online transactions for him, and making them travel hundreds of kilometers away from Abottabad before checking into an internet cafe to send his traffic. And this isn't proof for anything (especially guy is down now). At the best this can be interesting case study. If someone was never caught driving without driving license (where this is forbidden) this doesn't mean that it doesn't make sens to have such license. This is a common trap - you think it's not worth investing your time and
Re: SSH Agent keys 4096 bit?
On 05/04/2012 01:45 AM, Werner Koch wrote: On Fri, 4 May 2012 03:03, j...@enigmail.net said: I suspect WK has ECC ready to go in both GnuPG 1.4 and 2.0 as soon as the ID is approved. I know it's already present in the 2.1 beta code. No, we don't plan to port it back to 1.4. It will actually take years until ECC keys are in wide use and by then 2.1 will be the stable release. I even hope to declare 2.1 stable sometime this year. I hope you reconsider backporting ECC to 1.4. Given some of the changes you've announced for 2.1 I think there are a non-trivial number of users who will be dropping 2.x altogether. Doug ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: SSH Agent keys 4096 bit?
On 05/04/2012 10:17 AM, Milo wrote: Well, many expect rise of the quantum computing during lives of most of us. This can trash most (if not all) asymmetric algorithms (Shor's algorithm) No. It can trash *some* asymmetric algorithms. There are a good number of asymmetric algorithms whose decision problem exists outside of BQP. (McEliece, for instance. For those wondering what BQP is, it's the quantum computing analogue to P: it describes those problems you can solve in a reasonable time with a quantum computer.) I do not understand how, if you're concerned about quantum computing, you can believe it will all be better if we just use larger keys!, rather than it will be better if we use algorithms that cannot be efficiently solved by a quantum computer. and reduce strength of symmetric ciphers in half (with for example Grover's algorithm). Not half, reduce the strength of symmetric ciphers by a square root. A 128-bit cipher's strength is not halved (which would make it 127-bit); it's reduced to the equivalent of 64 bits (the square root of 128 bits). Beside this consider widespread usage of 256-bit symmetric ciphers. If things you are writing are all the truth behind key length security we are dealing with huge, mass overkill or even scam perhaps. But I think we aren't. It's worth noting that, per Suite B, 256-bit crypto is only required for material that's at the top of the classification pyramid: things like nuclear weapon release codes and other things that might cause 300 million people to have a really bad day. 128-bit crypto is considered quite sufficient for the rest of the nation's secrets. Also, some people are using symmetric crypto for secrets that must be preserved for 50+ years -- census data, for instance. If you're concerned about 50+ years of confidentiality, then yes, it makes sense to go hog-wild on key lengths. But for the rest of us, the confidentiality of our communications will be better-served by many other measures than just adding more bits to the key. Just like modern cellphones' CPU/GPUs are s-f from Apollo mission's engineers' perspective, just like 640K ought to be enough for anybody and like 32-bit address space for IP protocol is more then enough. History is showing quite clearly that such speculations despite - ofte high - competencies of the authors are missed. An Apollo engineer would be unlikely to view a tablet PC as something indistinguishable from magic. Nothing about it would be unknown to them: only the size, the power and the integration would be new. This is pretty much the norm in the field: from a pure computer science perspective there's almost no difference between a Burroughs 5000 and a modern x86_64. Introduce quantum algorithms, though, and suddenly quite respectable computer scientists suddenly start sweating bullets and saying, uh, I don't quite know about this, umm, *in theory* it will be kind of like this, but the practical ramifications are ... hey, look at the time, gotta go. 6000-qubit quantum computers are a magic so subtle they are indistinguishable from high technology. They might, if we are fortunate, be invented in our lifetimes -- but let's not go about saying we need 8K RSA keys to defend against 6000-bit quantum computers. If quantum computers bother you that much, use McEliece. Please try to avoid comedic undertone of your statements and comparisons if you want to keep discussion's level sane. The discussion was already profoundly silly: the overt comedic statements drew attention to this. Successfully, apparently. Yeah, then leave your home open because Wow, who want to check every door in the world. So many of them. Non sequitur. Yeah, let's drop all the crypto (encryption) for common folk because put your arguments from above here. Non sequitur. Giving users easier-then-hacking-through-sources way of setting bigger key size isn't a crime. No, but there's no point in it, either. Frankly, I'd rather the GnuPG developers spent their time on pursuits that are more reasonable and will give a better return on investment. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: SSH Agent keys 4096 bit?
On Fri, 4 May 2012 16:59, do...@dougbarton.us said: I hope you reconsider backporting ECC to 1.4. Given some of the changes It would be a lot of work and I doubt that we can find anyone to finance that. In fact, finding financial support for any kind of work on GnuPG is very hard. you've announced for 2.1 I think there are a non-trivial number of users who will be dropping 2.x altogether. Really? The only major change users might notice is the dropping of secring.gpg - something I am announcing for more than 10 years (Please always use --export or --import and don't use the keyring files directly). 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: SSH Agent keys 4096 bit?
On Fri, 4 May 2012 14:53, mw...@iupui.edu said: Let me turn things around. Other than providing opportunities to discuss the practicalities of large RSA keys, is there any reason why the agent should care what size key it is storing? The OpenPGP parser has a limit on the size of the MPI which is at 16k bits. This is required to avoid DoS attacks. Key generation is limited in the way we allocate memory for prime generation and well, the arbitrary limit of 4k RSA modulus. 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: SSH Agent keys 4096 bit?
On Fri, 4 May 2012 16:17, gn...@oneiroi.net said: I think I should give Werner much faster phone now ;) (on my own using 8192-bit RSA key takes about 2-4 seconds to successfully auth; phone was 2 seconds are way too long. I look at most mails not even for a second; if I need to wait 2 seconds for decryption and another 2 for verifying the signature, this will be a very noticeable delay. From a UI design point of view, any noticeable delay is a no go. And for sure I need to make sure a power socket is close to me if my device is constantly crunching numbers. 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: SSH Agent keys 4096 bit?
I think I should give Werner much faster phone now ;) (on my own using 8192-bit RSA key takes about 2-4 seconds to successfully auth; phone was 2 seconds are way too long. I look at most mails not even for a second; if I need to wait 2 seconds for decryption and another 2 for verifying the signature, this will be a very noticeable delay. From a UI design point of view, any noticeable delay is a no go. Might I point out that discussion is with respect to an 8k RSA SSH key for SSH authentication, not for email. A 2 second delay during the initialization of an SSH connection is not a problem. And for sure I need to make sure a power socket is close to me if my device is constantly crunching numbers. Find one with a better battery/more-efficient processor if these sorts of calculations would really be an issue, compared to the general radio use of the phone. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: SSH Agent keys 4096 bit?
On Fri, 4 May 2012 20:54, a...@lown.me.uk said: Might I point out that discussion is with respect to an 8k RSA SSH key for SSH authentication, not for email. A 2 second delay during the initialization of an SSH connection is not a problem. The delay with SSH would even be longer. Again, it is plain stupid to assume that you can reach any security improvments on mobile phone (or to a lttle lesser degree on servers) by increasing the key sizes. The security gain is bug bound and not bound to the key size. Find one with a better battery/more-efficient processor if these sorts of calculations would really be an issue, compared to the general radio use of the phone. Radios are very well optimized. CPUs also very energy efficient - but only if they are idle. On most smartphones you can already notice that by playing a Vorbis file compared to playing a MP3 file; the latter use the DSP (instead of the general purpose CPU) and will play a lot more music before charging is required. Right, you may gain a similar battery life boost by using a crypto accelerator - however they are only designed for 2048 bit and I don't know whether they are available on SoCs 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: SSH Agent keys 4096 bit?
On 04/05/12 20:54, Ali Lown wrote: Might I point out that discussion is with respect to an 8k RSA SSH key for SSH authentication, not for email. A 2 second delay during the initialization of an SSH connection is not a problem. And here is precisely something interesting: 8k RSA is discussed as a method to keep messages confidential for decades. I haven't looked into it, but I'm under the impression RSA is used purely for authentication in SSH, not for key exchange[1]. What are you protecting decades against here? A server reusing a random challenge? That seems quite far fetched. Oh, by the way, only the computational load for the client was discussed. There's also the server (although the public side of the computation is quicker than the private side). The server gets logins from potentially a lot of clients. Peter. [1] I get this impression because there is a configuration option for OpenSSH sshd that selects which key exchange methods to use, and they all have DH (Diffie-Helmann) in their name. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at http://wwwhome.cs.utwente.nl/~lebbing/pubkey.txt ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: SSH Agent keys 4096 bit?
On 05/04/2012 10:08 AM, Werner Koch wrote: On Fri, 4 May 2012 16:59, do...@dougbarton.us said: I hope you reconsider backporting ECC to 1.4. Given some of the changes It would be a lot of work and I doubt that we can find anyone to finance that. In fact, finding financial support for any kind of work on GnuPG is very hard. Understood. you've announced for 2.1 I think there are a non-trivial number of users who will be dropping 2.x altogether. Really? The only major change users might notice is the dropping of secring.gpg - something I am announcing for more than 10 years (Please always use --export or --import and don't use the keyring files directly). I think a lot of people are frustrated with the agent generally, and only use 1.4 as a result already. The thing that will kill 2.1 for me is the removal of the multiple public keyring functionality. Doug ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: SSH Agent keys 4096 bit?
Might I point out that discussion is with respect to an 8k RSA SSH key for SSH authentication, not for email. A 2 second delay during the initialization of an SSH connection is not a problem. And here is precisely something interesting: 8k RSA is discussed as a method to keep messages confidential for decades. I haven't looked into it, but I'm under the impression RSA is used purely for authentication in SSH, not for key exchange[1]. What are you protecting decades against here? A server reusing a random challenge? That seems quite far fetched. I created the 8k keys prior to understanding the full effects reasoning behind a 1k/2k key simply because it was't particularly computationally expensive for me to do, and I saw no harm in being overly cautious with a longer key than average. I see no purpose though (at this stage, with my public key spread around a variety of locations without issue) in generating a new 'smaller' key for the sole purpose of being able to use GPG's SSH agent, requiring me to change the public key in every location. Oh, by the way, only the computational load for the client was discussed. There's also the server (although the public side of the computation is quicker than the private side). The server gets logins from potentially a lot of clients. I think this is fairly irrelevant to the discussion. Yes there is an overhead, but performing the calculations is not a significant concern. (If a server is getting lots of fake logon attempts, you need to sort out your firewall instead). ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: SSH Agent keys 4096 bit?
On 05/04/2012 12:54 PM, Ali Lown wrote: I see no purpose though (at this stage, with my public key spread around a variety of locations without issue) in generating a new 'smaller' key for the sole purpose of being able to use GPG's SSH agent, requiring me to change the public key in every location. So then your choices are to use 1.4, or patch the agent code to use 8k keys. Doug ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: SSH Agent keys 4096 bit?
On 05/04/2012 05:13 PM, Robert J. Hansen wrote: On 05/04/2012 10:17 AM, Milo wrote: Well, many expect rise of the quantum computing during lives of most of us. This can trash most (if not all) asymmetric algorithms (Shor's algorithm) No. It can trash *some* asymmetric algorithms. There are a good number of asymmetric algorithms whose decision problem exists outside of BQP. (McEliece, for instance. For those wondering what BQP is, it's the quantum computing analogue to P: it describes those problems you can solve in a reasonable time with a quantum computer.) Yes - niche, proof-of-concept, poorly analyzed ciphers. Let's talk about those widely used and considered mainstream. Those are our biggest concern. I do not understand how, if you're concerned about quantum computing, you can believe it will all be better if we just use larger keys!, rather than it will be better if we use algorithms that cannot be efficiently solved by a quantum computer. I'm not suggesting that longer key for asymmetric ciphers is a cure for quantum computing backed cryptanalysis. I wrote about possible, future way of circumventing need of sucking nova's energy to successfully attack cipher(text). and reduce strength of symmetric ciphers in half (with for example Grover's algorithm). Not half, reduce the strength of symmetric ciphers by a square root. A 128-bit cipher's strength is not halved (which would make it 127-bit); it's reduced to the equivalent of 64 bits (the square root of 128 bits). Thanks for pointing that but in considered situations this is slight difference. Beside this consider widespread usage of 256-bit symmetric ciphers. If things you are writing are all the truth behind key length security we are dealing with huge, mass overkill or even scam perhaps. But I think we aren't. It's worth noting that, per Suite B, 256-bit crypto is only required for material that's at the top of the classification pyramid: things like nuclear weapon release codes and other things that might cause 300 million people to have a really bad day. You can't tell consumer or end-user that he can't use 256-bit, symmetric cipher for his (even!) porn stash because this is some kind of faux pas and he is iconoclast because of this. It's up to him. Especially he can get this for almost same price (We can easily count CPU cycles, electricity used and so on, but from practical point of view difference is slight). 128-bit crypto is considered quite sufficient for the rest of the nation's secrets. Really? Then what's the reason behind 256-bit hw-supproted crypto (e.g. AES instructions for amd64 and x86), widely accessible on consumer market which has nothing to do with nuclear weapons? Also, some people are using symmetric crypto for secrets that must be preserved for 50+ years -- census data, for instance. If you're concerned about 50+ years of confidentiality, then yes, it makes sense to go hog-wild on key lengths. But for the rest of us, the confidentiality of our communications will be better-served by many other measures than just adding more bits to the key. One more time - this is not up to you or software authors to decide what's the value behind encrypted data. Even if reason of encrypting it is silly. Just like modern cellphones' CPU/GPUs are s-f from Apollo mission's engineers' perspective, just like 640K ought to be enough for anybody and like 32-bit address space for IP protocol is more then enough. History is showing quite clearly that such speculations despite - ofte high - competencies of the authors are missed. (...) Introduce quantum algorithms, though, and suddenly quite respectable computer scientists suddenly start sweating bullets and saying, uh, I don't quite know about this, umm, *in theory* it will be kind of like this, but the practical ramifications are ... hey, look at the time, gotta go. 6000-qubit quantum computers are a magic so subtle they are indistinguishable from high technology. They might, if we are fortunate, be invented in our lifetimes -- but let's not go about saying we need 8K RSA keys to defend against 6000-bit quantum computers. If quantum computers bother you that much, use McEliece. Please try to avoid comedic undertone of your statements and comparisons if you want to keep discussion's level sane. The discussion was already profoundly silly: the overt comedic statements drew attention to this. Successfully, apparently. (...) Giving users easier-then-hacking-through-sources way of setting bigger key size isn't a crime. No, but there's no point in it, either. Frankly, I'd rather the GnuPG developers spent their time on pursuits that are more reasonable and will give a better return on investment. Well, this could be won-won approach for both camps because of the outcome/effects of devs' work. -- Regards, Milo ___ Gnupg-users mailing list
Re: SSH Agent keys 4096 bit?
On 05/04/2012 04:35 PM, Milo wrote: Yes - niche, proof-of-concept, poorly analyzed ciphers. Let's talk about those widely used and considered mainstream. Those are our biggest concern. McEliece is almost as old as RSA. Generations of graduate students have tackled it in cryptanalysis courses. Almost a thousand academic papers have been published on it. None have shown any significant weaknesses in McEliece. Its inventor, Robert McEliece, received the Claude E. Shannon Award a few years ago. What the Fields Medal is to mathematics, or the Turing Prize is to pure computer science, the Shannon Award is to information theory. On the one hand, we have a cipher designed by a Shannon recipient which has had almost a thousand papers published about it without any really significant results. On the other hand, we have you calling it a niche, proof-of-concept, poorly-analyzed cipher. I'm not suggesting that longer key for asymmetric ciphers is a cure for quantum computing backed cryptanalysis. I wrote about possible, future way of circumventing need of sucking nova's energy to successfully attack cipher(text). The power and time requirements for computation are well-known. Circumventing either would require (a) invention of completely adiabatic computing (b) repeal of the Heisenberg Uncertainty Principle (c) repeal of the Second Law of Thermodynamics (d) ridiculously large quantum computers running at unheard-of efficiencies Any of the four puts us back into the realm of science fiction. If you're advocating making keys larger, I'd like to know which of the four science fiction breakthroughs you expect might happen. And no matter which of the four you choose, I'll point out that should your chosen breakthrough come to pass, we will all have much bigger things to worry about than whether our 20-year-old communications are still safe. Thanks for pointing that but in considered situations this is slight difference. Halving the strength of a 128-bit cipher leaves you with 127 effective bits of security. Rooting the strength of a 128-bit cipher leaves you with 64 effective bits of security. The former is still well beyond our ability to brute-force: the latter is well within our ability to brute force. I don't consider this to be a slight difference. You can't tell consumer or end-user that he can't use 256-bit, symmetric cipher for his (even!) porn stash because this is some kind of faux pas and he is iconoclast because of this. I cannot force someone to not use a 256-bit cipher, true. I can certainly point and laugh at people who believe using one makes them more secure, though. Nobody has the right to be taken seriously. That's a privilege that must be earned. Really? Then what's the reason behind 256-bit hw-supproted crypto (e.g. AES instructions for amd64 and x86), widely accessible on consumer market which has nothing to do with nuclear weapons? Marketing. The dirty little secret of crypto is that we've had a *great* symmetric cipher ever since the mid-1970s: 3DES. It's big. It's ungainly. It's slow. It has all the aesthetics of the Soviet Realism school of art. It's very hard to code up because there are so many fiddly bits. And yet, 3DES has been turning the best minds in crypto into burned-out alcoholic wrecks for the last 35 years. It has been undergoing constant attack for 35 *years*. Entire new branches of cryptanalysis have been invented just to try and dent it. These approaches have all failed miserably. There are a few niches where 3DES doesn't work very well. If you need a cipher that can encrypt a 1000baseT connection, you're better off using something faster. If you need it on a smartcard, you're better off using something more space-efficient. But for the rest of the problem space, 3DES has been rocking the house for almost as long as I've been alive. So here's the question: why isn't 3DES used in more places? Marketing. Because people -- both in the private sector and in the Free Software world -- want to be able to say they support the latest and greatest and best thing. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: SSH Agent keys 4096 bit?
On 05/03/2012 01:14 PM, Ali Lown wrote: Does anyone know why the limit is set at 4096 bits The consensus of the cryptographic community is that beyond 3K keys you really need to be switching to elliptical-curve cryptography. A 3K RSA or Elgamal key is roughly as difficult to break by brute-force as AES128, and that one's so hard that nobody with two brain cells to rub together is going to try it. Although I am not a GnuPG developer, I have never heard anything from the core devs which would make me think they are planning on revisiting this limit to allow for extraordinarily large keys. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: SSH Agent keys 4096 bit?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 03.05.2012 21:09, Robert J. Hansen wrote: On 05/03/2012 01:14 PM, Ali Lown wrote: Does anyone know why the limit is set at 4096 bits The consensus of the cryptographic community is that beyond 3K keys you really need to be switching to elliptical-curve cryptography. A 3K RSA or Elgamal key is roughly as difficult to break by brute-force as AES128, and that one's so hard that nobody with two brain cells to rub together is going to try it. Although I am not a GnuPG developer, I have never heard anything from the core devs which would make me think they are planning on revisiting this limit to allow for extraordinarily large keys. Although GnuPG won't allow generation for larger keys than 4096 bits without some hacking it will actually import and use such keys without any modifications being needed (could try to import e.g. [1] from [2]). So in that sense there seems to be some difference to the reported behavior to ssh-agent. Now, whether such a large key is really useful, that is indeed another question. [1] https://www.kfwebs.net/pgp/pubkey-large.txt [2] http://www.kfwebs.net/news/603/15360-bit-OpenPGP-key - -- - Kristian Fiskerstrand http://www.sumptuouscapital.com Twitter: @krifisk - Corruptissima re publica plurimæ leges The greater the degeneration of the republic, the more of its laws - This email was digitally signed using the OpenPGP standard. If you want to read more about this The book: Sending Emails - The Safe Way: An introduction to OpenPGP security is now available in both Amazon Kindle and Paperback format at http://www.amazon.com/dp/B006RSG1S4/ - Public PGP key 0xE3EDFAE3 at http://www.sumptuouscapital.com/pgp/ -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJPotthAAoJEBbgz41rC5UIdSkQAIZ7h8aRF+pYjeOC1coPcnnP 6ZzU8gbYHlxD8V5nqgv09eQZ8R7iqSz2nXCW3uT4SYrNFs4dLQWqC64IGW419mfv 3RD66lEZx0iKukzmzSWeLhjGBECyhbQfSoKG8i78OXZPP8eUFziddheQMQix7yyK wRcMNl1Rk0FoytlL7/DJOIzVrGJkwMeeZ+kgYunNlk+KokavW66eH0F837y3TmNi M08JAgSXbogoDTP4y8opmnRjES8WdkvZHaOUkYN3YSPpMet7hCX8uyfGyJXDV+gi l79f0ltLiEFj7IYYSXVKsJ2c28tEkDBMcz/meYoy4W0kEReuAKM5Kn+OJoSrMTHI 8pfNeBMiYmvpJjHptvxtQNT8G/OEsXQfzsJl34FrWxrHFqHH8v445L+yryDRJzNd Xy/AWPqpz51RuLYpcLnYmBKt4630hdmnCJf5DSPh4mrnpDFry/ekL5nFXjKPTEq8 AdsyK9JVGKtxerS+OEGeHc6zKIcM6edZNiByyDMwwf8SsJeoq92N/4fO839FapZj nmlow5lqGPMotrO2im4HzgWDXnRzmUbJJfsDsCRZYzIewT1Y9F313RQdP4taMQhB lr1aDM5xrft4mnkKRMwHvNVBpWFdP04P1DaOdV5FTj1kJpDqmzD6U+bvKf6Sh/W4 e21RSyf988sHPzn93GGg =FS9I -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: SSH Agent keys 4096 bit?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 03.05.2012 20:14, Ali Lown kirjoitti: I am trying to use gpg-agent for my ssh keys as well as my gpg keys, but am unable to add my 8192 bit ssh key to the agent. Agent log reports: 2012-05-03 17:48:02 gpg-agent[2190] ssh keys greater than 4096 bits are not supported The limit appears to be arbitarily set in agent/command-ssh.c following a max mpi_data_size. Does anyone know why the limit is set at 4096 bits, and whether there are any plans for supporting SSH keys of lengths greater than 4096bit in the gpg-agent? Thanks. Ali ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users Use SSH agent instead of GPG agent for ssh keys. See the manual page ssh-add (and ssh-agent). The ssh-agent should usually start when you login. - -- Mika Suomalainen gpg --keyserver pool.sks-keyservers.net --recv-keys 4DB53CFE82A46728 Key fingerprint = 24BC 1573 B8EE D666 D10A AA65 4DB5 3CFE 82A4 6728 Please don't toppost, if possible https://wiki.debian.org/FAQsFromDebianUser#What_is_top-posting_.28and_why_shouldn.27t_I_do_it.29.3F Please don't send HTML, if possible. It's possible with most of clients, even with webmails, see: https://wiki.debian.org/DebianMailingLists#HowTo_send_plain_text_emails_to_the_list I use GPG/INLINE, because some mailing list programs modify the headers of messages and this way make signature.asc files (PGP/MIME) unverifiable. Please remove lines about beginning and ending GPG signature blocks in your replies to messages, which are sent by me. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPotxGAAoJEE21PP6CpGcoxjkP/2beQQAl2duihGDiF767lIqK tox9RdRrh7Afh0Q03VmHaTHzDb4XegzIc//3SY9bGcOLtXaeefqJ2AHxGyj1fsGq +r84qW0ClAKvlqQF3OY/PMfmTBllUFR4T27C1xmWvU6khTlK+cC+aapSIlSdp8XI Vtbw+naJ/kUO0BXxDJdK8RwmoXR8qeBRGjB+HLx3G+f2xmKIYCjrzMs4TopEecBz n+Vt9DA3aqnhoXZzE49zhKOrBiLM/GLTPtWbXccVicIZxVB72/GASw1mLntJZ62Z g1D+L64C75cI4NgZivUKjLdw7KEZZryrjffJTx4Z9vEfV82+ohkJxUZmDSP+9wBB XxOUY7v4wy36/rU59U62mGBFFRd8bw1X8PoZNBY4K4BfGXtU4XZIlbhNlLzyYiYd 1pgJObu6mQpubwj5E4s2jOlpSNw9QaxQxFJYq6YiNGD5AdCpB+cC7aUldf3wX4yG /PEsv9YVZ/lH3JmgRhaevFTV21XZAZMnVnTT8yWqNodLIS9llSg2mKFJs20mfTrK bvnrjZFUO4JiFppIHN7YShDN7Tj0p5Ha8J8y4s3w1DzSCmVHP3AU4ynakGtnhqiz GLjouApDe90GV2evdf9dx8lGJCY18sqfcAjlQ93ImPC2Qt/QbCsF9h0aTe1VELC6 EZAEBjU/3fXzxywoemPW =6xJh -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: SSH Agent keys 4096 bit?
On Thursday 03 of May 2012 15:09:42 Robert J. Hansen wrote: On 05/03/2012 01:14 PM, Ali Lown wrote: Does anyone know why the limit is set at 4096 bits The consensus of the cryptographic community is that beyond 3K keys you really need to be switching to elliptical-curve cryptography. A 3K RSA or Elgamal key is roughly as difficult to break by brute-force as AES128, and that one's so hard that nobody with two brain cells to rub together is going to try it. It all depends on who you're talking to. French[1] suggest 4k for AES128. But if you've got data that needs to be protected for 30-40 years, using AES256 is basically a no-brainer. Using just 4k RSA with that is not a smart decision, and that's agreed by basically anybody (NIST, ECRYPT II). Especially when the cost of establishing the link with 8k RSA is insignificant for any session over 5min in length (as is common in SSH). Besides that, Schneier and Ferguson[2] say that basically any RSA based crypto system should support 8k keys. Switching to ECC is not easy, you need to change your whole infrastructure, protocols, management systems, etc. to allow this. Generating extemely large keys is very easy in comparision. Using large keys would be stupid only if you need low latency/high IOPS system that can't use long lasting secure channels: web servers. But that's not our use case. Regards, Hubert Kario [1]: http://www.ssi.gouv.fr/IMG/pdf/RGS_B_1.pdf [2]: Practical Cryptography, Chapter: RSA Defined, section The size of n, p233 -- Hubert Kario QBS - Quality Business Software 02-656 Warszawa, ul. Ksawerów 30/85 tel. +48 (22) 646-61-51, 646-74-24 www.qbs.com.pl ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: SSH Agent keys 4096 bit?
Ali Lown wrote: I am trying to use gpg-agent for my ssh keys as well as my gpg keys, but am unable to add my 8192 bit ssh key to the agent. Agent log reports: 2012-05-03 17:48:02 gpg-agent[2190] ssh keys greater than 4096 bits are not supported The limit appears to be arbitarily set in agent/command-ssh.c following a max mpi_data_size. Does anyone know why the limit is set at 4096 bits, and whether there are any plans for supporting SSH keys of lengths greater than 4096bit in the gpg-agent? [I think I write this same email on one list or another at least once per year] Because past RSA key sizes of 2048-3072, the migration is to Elliptic Curve Crypto (ECC). Huge RSA keys does not scale for most Internet usages (PKI/TLS/SSL). NO ONE is recommending 4096 RSA or DSA, not because it's unsafe but it's computationally unwieldy, especially on small devices. At asymmetric key sizes of 3072 bits, the smart money is moving to Elliptic Curve Cryptography (ECC). How does ECC compare to RSA _today_? From the National Institutes of Science and Technology (one of the gold standards for engineering know-how): RSAECCSym 1024160 80 2048224112 3072256128 7680384192 15360512256 (One may add a 'Hash' column by doubling the values in the Symmetric Encryption column.) These recommendations can be found on page 63 of NIST Special Publication 800-57, Recommendations for Key Management, Part I. 2nd Revision, 8 Mar, 2007. [http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57-Part1-revised2_Mar08-2007.pdf] All three parts of SP800-57 are available at http://csrc.nist.gov/publications/PubsSPs.html The NSA's 2010 Suite-B [http://www.nsa.gov/ia/programs/suiteb_cryptography/index.shtml] recommendations are: Type Symmetric Elliptic CurveHash Secret 128 256 256 Top Secret 256 384 384 A key aspect of Suite B is its use of elliptic curve technology instead of classical public key technology. During the transition to the use of elliptic curve cryptography in ECDH and ECDSA, DH, DSA and RSA can be used with a 2048-bit modulus to protect classified information up to the _secret_ level [http://www.keylength.com/en/6/]. So, depending on the source, a consensus seems to be forming that beyond a 2048 or 3072 bit modulus for DSA2 or RSA, folks need to switch to ECC. 2048-RSA is the current default in GnuPG. OpenPGP cards will support up to 3072-bit RSA; GnuPG up to 4096-bit RSA and 3072-bit DSA2. ECC in OpenPGP is on its way toward becoming a RFC and being included in OpenPGP. Larger and larger RSA keys aren't the solution, ECC is. The balance of power has tipped away from RSA and toward ECC. The Internet Draft for ECC in OpenPGP [https://tools.ietf.org/html/draft-jivsov-openpgp-ecc-11] is in the Final Comment period with comments due by 2012-04-09. I suspect WK has ECC ready to go in both GnuPG 1.4 and 2.0 as soon as the ID is approved. I know it's already present in the 2.1 beta code. Feel free to ignore everything I've told you. There's no reason you should trust me. But by all means, keep asking questions and read the authoritative articles and documents. -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
