Re: gpg.conf
On Thu, 3 May 2012 23:15, da...@gbenet.com said: A re-think of valid user options are required by the developers I think :) I suggest that you use GPA or Kleopatra to modify the options. To a large extend they make sure that the options are correct (via gpgconf). 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 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: Welcome to the Gnupg-users mailing list
I am trying to decrypt file from command prompt as below and it works fine. echo paraphase|gpg --batch --passphrase-fd 0 --decrypt-files *data*.txt.gpg But the same command when I call from application (Informatica), it gives below error. Secret file not found. Is that I need to give some other details ? --- On Fri, 5/4/12, gnupg-users-requ...@gnupg.org gnupg-users-requ...@gnupg.org wrote: From: gnupg-users-requ...@gnupg.org gnupg-users-requ...@gnupg.org Subject: Welcome to the Gnupg-users mailing list To: rychi...@yahoo.com Date: Friday, May 4, 2012, 8:44 AM Welcome to the Gnupg-users@gnupg.org mailing list! To post to this list, send your email to: gnupg-users@gnupg.org General information about the mailing list is at: http://lists.gnupg.org/mailman/listinfo/gnupg-users If you ever want to unsubscribe or change your options (eg, switch to or from digest mode, change your password, etc.), visit your subscription page at: http://lists.gnupg.org/mailman/options/gnupg-users/rychitre%40yahoo.com You can also make such adjustments via email by sending a message to: gnupg-users-requ...@gnupg.org with the word `help' in the subject or body (don't include the quotes), and you will get back a message with instructions. You must know your password to change your options (including changing the password, itself) or to unsubscribe. It is: hondacivic Normally, Mailman will remind you of your gnupg.org mailing list passwords once every month, although you can disable this if you prefer. This reminder will also include instructions on how to unsubscribe or change your account options. There is also a button on your options page that will email your current password to you. ___ 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 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
secret key not found
I am trying to decrypt file from command prompt as below and it works fine. echo paraphase|gpg --batch --passphrase-fd 0 --decrypt-files *data*.txt.gpg But the same command when I call from application (Informatica), it gives below error. gpg: encrypted with RSA key, ID AA gpg: decryption failed: No secret key Is that I need to give some other details ? ___ 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
non-interactive expiration of a key using --batch?
Hi folks-- I'm having trouble setting up non-interactive expiration updates of a key with a passphrase. I think i should use the --batch argument because i want to ensure that gpg doesn't try to hang waiting on user interaction, but when i use the --batch argument, the update isn't saved. let's say the passphrase is contained in the file pw. As you can see below, saving an update to 12 weeks without --batch advances the expiration date to 2012-07-27, and a following --list-keys shows the update. Subsequently, saving it to 13 weeks with --batch shows the change to 2012-08-03, but a following --list-keys shows the expiration date reverted to 2012-07-27. this is with gnupg 1.4.12-4, from debian testing. Any ideas what's going on here? Am i wrong to try to use --batch in this instance? --dkg 0 wt215@pip:~$ gpg --list-keys /home/wt215/testexpiry/pubring.gpg -- pub 1024R/20819466 2012-05-03 [expires: 2012-07-20] uid blab blab (DO NOT USE!) t...@example.org 0 wt215@pip:~$ printf 12w\nsave\n | gpg --passphrase-fd 3 --command-fd 0 --edit-key t...@example.org 3pw expire gpg (GnuPG) 1.4.12; Copyright (C) 2012 Free Software Foundation, Inc. This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Reading passphrase from file descriptor 3 Secret key is available. pub 1024R/20819466 created: 2012-05-03 expires: 2012-07-20 usage: SC trust: ultimate validity: ultimate [ultimate] (1). blab blab (DO NOT USE!) t...@example.org Changing expiration time for the primary key. Please specify how long the key should be valid. 0 = key does not expire n = key expires in n days nw = key expires in n weeks nm = key expires in n months ny = key expires in n years Key expires at Fri 27 Jul 2012 04:37:23 PM EDT You need a passphrase to unlock the secret key for user: blab blab (DO NOT USE!) t...@example.org 1024-bit RSA key, ID 20819466, created 2012-05-03 pub 1024R/20819466 created: 2012-05-03 expires: 2012-07-27 usage: SC trust: ultimate validity: ultimate [ultimate] (1). blab blab (DO NOT USE!) t...@example.org 0 wt215@pip:~$ gpg --list-keys gpg: checking the trustdb gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model gpg: depth: 0 valid: 1 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 1u gpg: next trustdb check due at 2012-07-27 /home/wt215/testexpiry/pubring.gpg -- pub 1024R/20819466 2012-05-03 [expires: 2012-07-27] uid blab blab (DO NOT USE!) t...@example.org 0 wt215@pip:~$ printf 13w\nsave\n | gpg --batch --passphrase-fd 3 --command-fd 0 --edit-key t...@example.org 3pw expire Secret key is available. pub 1024R/20819466 created: 2012-05-03 expires: 2012-07-27 usage: SC trust: ultimate validity: ultimate [ultimate] (1). blab blab (DO NOT USE!) t...@example.org Changing expiration time for the primary key. Please specify how long the key should be valid. 0 = key does not expire n = key expires in n days nw = key expires in n weeks nm = key expires in n months ny = key expires in n years Key expires at Fri 03 Aug 2012 04:37:34 PM EDT pub 1024R/20819466 created: 2012-05-03 expires: 2012-08-03 usage: SC trust: ultimate validity: ultimate [ultimate] (1). blab blab (DO NOT USE!) t...@example.org 0 wt215@pip:~$ gpg --list-keys /home/wt215/testexpiry/pubring.gpg -- pub 1024R/20819466 2012-05-03 [expires: 2012-07-27] uid blab blab (DO NOT USE!) t...@example.org 0 wt215@pip:~$ pgpsT9Xp5u8TP.pgp Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: secret key not found
Am Fr 04.05.2012, 12:18:40 schrieb Rupali Chitre: But the same command when I call from application (Informatica), it gives below error. gpg: encrypted with RSA key, ID AA gpg: decryption failed: No secret key Does the application run under the same user ID or in a chroot environment? Hauke -- PGP: D44C 6A5B 71B0 427C CED3 025C BD7D 6D27 ECCB 5814 signature.asc Description: This is a digitally signed message part. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: 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
