Re: key length/size RSA discussion/recommendations in the wiki
On Friday 31 October 2014 at 18:29:21, Robert J. Hansen wrote: I agree that the FAQ is a bad place to present a chain of arguments and the wiki is the natural spot for it. My concern is that the FAQ and the wiki need to be kept in sync somehow, and I'm not going to be watching the wiki constantly to make sure we're giving consistent advice. You could register to set a watch email for this page in particular. This way you would at least get some notification (which you would be able to ignore in most cases). MoinMoin allows you do this this in your personal settings. My other concern is the false air of authority that wikis tend to get. When anyone can edit, wikis periodically wind up saying ... anything. If people are looking for a curated line of reasoning from cryptographers and/or cryptographic engineers, that may not be a good candidate for a wiki. Yes, I agree about this risk. The other risk is that people are underinformed about GnuPG. Most people know these days that Wikis are written by the people. On the other hand at least I am watching stuff and we could think about moderation in the wiki or other methods. Wikipedia has solved the quality problem, so it is possible. All this said, though: how can I help? I'd be grateful if you could read through the LargeKeys page and point out obvious obmissions or things that need improvement. You can email me or just try to correct them yourself. (Use you bugs.gnupg.org credentials.) Thanks, Bernhard -- www.intevation.de/~bernhard (CEO)www.fsfe.org (Founding GA Member) Intevation GmbH, Osnabrück, Germany; Amtsgericht Osnabrück, HRB 18998 Owned and run by Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner 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: key length/size RSA discussion/recommendations in the wiki
Robert, On Wednesday 29 October 2014 at 19:00:39, Robert J. Hansen wrote: Because this gets asked quite often, I've started to capture some arguments of the debate how long RSAs could/should/can be at http://wiki.gnupg.org/LargeKeys I thought we largely addressed this in the FAQ, sections 11.1, 11.2, 11.3, 11.4 and 11.5. Do we need to address it in more depth? yes, I think that the recurring debate demands that the arguments are made visible so they can be tested by readers. You can see in the referred Debian issue tracker, that Werner has to repeat his arguments over and over again, there is not good place to refer to the chain of arguments. If so I'm happy to write an extension to the FAQ. From my point of view the wiki enables us to catch the debate and more in depth. And arguments with its sources. Also it can show the discussion of discenting views point. For example the FAQ does not cover the details of the support for larger keys like 8 KiB or 16 KiB. In my view this would be too much for an FAQ, which should be brief and more official and thus more stable. Best Regards, Bernhard -- www.intevation.de/~bernhard (CEO)www.fsfe.org (Founding GA Member) Intevation GmbH, Osnabrück, Germany; Amtsgericht Osnabrück, HRB 18998 Owned and run by Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner 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: key length/size RSA discussion/recommendations in the wiki
yes, I think that the recurring debate demands that the arguments are made visible so they can be tested by readers. The FAQ is discussed in public and changes are submitted to the community for comment and review before I make any changes. So far, no one on the list has raised a serious objection to the content -- some have said, I don't agree but I'm in the minority, but no one has said, I don't think the community is behind this. You can see in the referred Debian issue tracker, that Werner has to repeat his arguments over and over again, there is not good place to refer to the chain of arguments. The people who are most up in arms over this aren't going to be convinced by a chain of arguments. Holy wars are driven by articles of faith (vi is superior to emacs!), not by reason. [*] I agree that the FAQ is a bad place to present a chain of arguments and the wiki is the natural spot for it. My concern is that the FAQ and the wiki need to be kept in sync somehow, and I'm not going to be watching the wiki constantly to make sure we're giving consistent advice. My other concern is the false air of authority that wikis tend to get. When anyone can edit, wikis periodically wind up saying ... anything. If people are looking for a curated line of reasoning from cryptographers and/or cryptographic engineers, that may not be a good candidate for a wiki. All this said, though: how can I help? [*] emacs is *so* superior to vi, incidentally. I don't know how any right-thinking person could think otherwise. Heathens. They probably eat pork, too. signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: key length/size RSA discussion/recommendations in the wiki
Because this gets asked quite often, I've started to capture some arguments of the debate how long RSAs could/should/can be at http://wiki.gnupg.org/LargeKeys puts on his FAQ maintainer hat I thought we largely addressed this in the FAQ, sections 11.1, 11.2, 11.3, 11.4 and 11.5. Do we need to address it in more depth? If so I'm happy to write an extension to the FAQ. takes off his FAQ maintainer hat signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: key length/size RSA discussion/recommendations in the wiki
Why is brute force even mentioned in something about RSA? You couldn't brute-force a 128 bit RSA key. I'd say 2048 bit quite covers it 8-) 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://digitalbrains.com/2012/openpgp-key-peter ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: key length/size RSA discussion/recommendations in the wiki
Why is brute force even mentioned in something about RSA? You couldn't brute-force a 128 bit RSA key. I'd say 2048 bit quite covers it 8-) Sure you can. To brute-force a 128-bit RSA key would require you to check every prime number between two and 10**19. There are in the neighborhood of ten quadrillion of them. You could break a 128-bit RSA key for under $100 of computation on an Amazon cloud instance. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: key length/size RSA discussion/recommendations in the wiki
On 10/29/2014 at 3:22 PM, Robert J. Hansen r...@sixdemonbag.org wrote: Why is brute force even mentioned in something about RSA? You couldn't brute-force a 128 bit RSA key. I'd say 2048 bit quite covers it 8-) - Surely Peter knows this too ;-) More likely 128 was a typo for the more common older RSA key of 1028 ... vedaal ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: key length/size RSA discussion/recommendations in the wiki
On 2014-10-29 21:49, ved...@nym.hush.com wrote: Surely Peter knows this too ;-) More likely 128 was a typo for the more common older RSA key of 1028 ... No, I'm using a strict definition of brute force. For p = 2^63 to 2^64-1 For q = 2^63 to 2^64-1 If p * q == n: Break Next Next You're free to adapt the order of tries of p and q, though. Happy breaking! I don't feel the method outlined by Rob is still brute force. That brute actually is using his brain. Possibly his brain resembles a sieve, but still :). Am I too strict? Peter. PS: I'm assuming a 128-bit RSA key is made up of two 64-bit primes. -- 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://digitalbrains.com/2012/openpgp-key-peter ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: key length/size RSA discussion/recommendations in the wiki
More likely 128 was a typo for the more common older RSA key of 1028 ... Either-or. RSA-1024's dangerously close to being brute-forceable, too. We've already brute-forced RSA-768 and we're closing in on RSA-890. I haven't looked into how well the general number field sieve parallelizes, but I wouldn't want to take bets on how long RSA-1024 could stand up to a massive Amazon Cloud instance. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: key length/size RSA discussion/recommendations in the wiki
No, I'm using a strict definition of brute force. Technically, brute force is testing every *possible* value... not values that you know aren't going to work. Why test those? If you're trying to factorize 2701, for instance, you can feel free to skip dividing by 2 (doesn't end in an even number), 3 (sum of the digits isn't divisible modulo three), 4 (already know it's not divisible by 2), 5 (doesn't end in a 5 or a 0), 6 (not divisible by 3 or by 2), etc. If your brute-forcer is testing values that cannot possibly be correct, then you're using an inefficient brute-forcer. Get a better one. :) I don't feel the method outlined by Rob is still brute force. That brute actually is using his brain. Possibly his brain resembles a sieve, but still :). Am I too strict? Depends. I think so. But if you're taking an exam sometime in the near future, I think you should answer this however your professor wants. :) ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: key length/size RSA discussion/recommendations in the wiki
On 2014-10-29 22:30, Robert J. Hansen wrote: Technically, brute force is testing every *possible* value... not values that you know aren't going to work. Why test those? Well, why not restrict ourselves to primes whose product equal the modulus? I could solve any key in constant time that way. The distinction obviously(?) is in the cost of computing what makes a possible. But that's the thing about brute force that I thought was not included: using computation to speed up your process, and using insight into the mathematical properties of an algorithm. But you are obviously more in touch with the material than me. If you refer to just testing primes as brute force, I don't think it should be so easily dismissed as I initially did. 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://digitalbrains.com/2012/openpgp-key-peter ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: key length/size RSA discussion/recommendations in the wiki
On Wednesday 29 October 2014 22:18:13 Peter Lebbing wrote: On 2014-10-29 21:49, ved...@nym.hush.com wrote: Surely Peter knows this too ;-) More likely 128 was a typo for the more common older RSA key of 1028 ... No, I'm using a strict definition of brute force. For p = 2^63 to 2^64-1 For q = 2^63 to 2^64-1 If p * q == n: Break Next Next If anything then I'd do For p = 2^63 to 2^64-1 If n modulo p == 0: Break Next q = n / p which is O(n^(1/2)), but IMO still brute force (even in your strict definition), while yours is O((n^(1/2)^2) = O(n). brute force doesn't mean that you have to use the most naïve algorithm. I don't feel the method outlined by Rob is still brute force. That brute actually is using his brain. Possibly his brain resembles a sieve, but still :). Am I too strict? Actually, that brute doesn't seem to be using his brain. If he'd use his brain then he'd use he fists to brute force the secret out of you. ;-p Regards, Ingo 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
