Re: Cryptography and the Open Source Security Debate
On Wed, Aug 25, 2004 at 03:17:15PM +0100, Ben Laurie wrote: lrk wrote: My examination of RSAREF and OpenSSL code was more toward understanding how they handled big numbers. It appears both generate prime numbers which are half the length of the required N and with both of the two most significant bits set to one. This means the ratio R=P/Q (P being the larger prime) is limited to 1R(4/3). The actual maximum R is less and can be determined by examining N. This doesn't sound right to me - OpenSSL, IIRC, sets the top and bottom bits to 1. Of course, all large primes have the bottom bit set to one. The source of OpenSSL I looked at was part of the FreeBSD distribution. int BN_rand(BIGNUM *rnd, int bits, int top, int bottom); BN_rand() generates a cryptographically strong pseudo-random number of bits bits in length and stores it in rnd. If top is -1, the most significant bit of the random number can be zero. If top is 0, it is set to 1, and if top is 1, the two most significant bits of the number will be set to 1, so that the product of two such random numbers will always have 2*bits length. If bottom is true, the number will be odd. It appears this is called with top=1 for RSA primes. OpenSSL may not use it that way. -- [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Cryptography and the Open Source Security Debate
lrk wrote: On Thu, Aug 12, 2004 at 03:27:07PM -0700, Jon Callas wrote: On 10 Aug 2004, at 5:16 AM, John Kelsey wrote: So, how many people on this list have actually looked at the PGP key generation code in any depth? Open source makes it possible for people to look for security holes, but it sure doesn't guarantee that anyone will do so, especially anyone who's at all good at it. Incidentally, none of the issues that lrk brought up (RSA key being made from an easy to factor composite, a symmetric key that is a weak key, etc.) are unique to PGP. Yep. And I know that. But as my hair turns grey, I make more simple mistakes and catch fewer of them. Looks like we are batting zero here. I have seen no responses nor received off-list e-mail from anyone admitting to examining the open source for holes. My examination of RSAREF and OpenSSL code was more toward understanding how they handled big numbers. It appears both generate prime numbers which are half the length of the required N and with both of the two most significant bits set to one. This means the ratio R=P/Q (P being the larger prime) is limited to 1R(4/3). The actual maximum R is less and can be determined by examining N. This doesn't sound right to me - OpenSSL, IIRC, sets the top and bottom bits to 1. Of course, all large primes have the bottom bit set to one. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Cryptography and the Open Source Security Debate
On Thu, Aug 12, 2004 at 03:27:07PM -0700, Jon Callas wrote: On 10 Aug 2004, at 5:16 AM, John Kelsey wrote: So, how many people on this list have actually looked at the PGP key generation code in any depth? Open source makes it possible for people to look for security holes, but it sure doesn't guarantee that anyone will do so, especially anyone who's at all good at it. Incidentally, none of the issues that lrk brought up (RSA key being made from an easy to factor composite, a symmetric key that is a weak key, etc.) are unique to PGP. Yep. And I know that. But as my hair turns grey, I make more simple mistakes and catch fewer of them. Looks like we are batting zero here. I have seen no responses nor received off-list e-mail from anyone admitting to examining the open source for holes. My examination of RSAREF and OpenSSL code was more toward understanding how they handled big numbers. It appears both generate prime numbers which are half the length of the required N and with both of the two most significant bits set to one. This means the ratio R=P/Q (P being the larger prime) is limited to 1R(4/3). The actual maximum R is less and can be determined by examining N. While this seems not very helpful, the more bits of R I know, the easier it is to factor N. Is this well known and has it been discussed here? -- [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Cryptography and the Open Source Security Debate
From: lrk [EMAIL PROTECTED] Sent: Aug 6, 2004 1:04 PM To: R. A. Hettinga [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: Cryptography and the Open Source Security Debate ... More dangerous is a key generator which deliberately produces keys which are easy to factor by someone knowing a secret. These should be found in open source but I suggest many reviewers could miss this and again the group think would probably cause most not to even look. So, how many people on this list have actually looked at the PGP key generation code in any depth? Open source makes it possible for people to look for security holes, but it sure doesn't guarantee that anyone will do so, especially anyone who's at all good at it. --John - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Cryptography and the Open Source Security Debate
There doesn't appear to be a discussion forum related to the Web post, so I'll reply here. We've gone through a similar thought process at my company. We have a commercial security product (MatrixSSL), but provide an open source version for many of the good points Daniel makes. There are a few additional reasons that the general open-source conclusion isn't as clear cut however. One of the benefits of having security algorithms open source is that the code can be better trusted in terms of back doors. So while Daniel may trust the NSA, others may not. Standard software typically isn't treated with the same positive paranoia, and therefore doesn't often have the same requirement. Back doors in closed source networked software, for example can be somewhat tested for through network protocol analysis and controlled through firewalls. Cryptography must be trusted at an algorithm level, since protocol analysis of the resultant data (should be) very difficult. A larger problem with the expansion from cryptographic algorithm benefits to open source benefits in general is one of pure code size. The number of lines of code of both Windows and Linux distributions is 30-40 million. The number of developers that 1. bother reading the code, 2. can actually understand it, 3. have the expertise and motivation to suggest/correct problems is a very small subset of developers for either proprietary or open source solutions. Developers that understand the complex interactions between software components are even fewer. When it comes down to it, a very small set of people becomes trusted in whatever code area they specialize in. Crypto algorithms are typically on the order of 1000 lines of code, with a large portion containing static key blocks. Experts looking at an open crypto algorithm require a great deal of expertise, but can also be much more focused in their analysis. Do you trust both the talent and moral integrity of the company you are getting your closed source software from so much that you think the products they are supplying you are superior (from a security standpoint) to those that can be created via peer review and attack by tens of thousands? This question is less related to the crypto specific conclusion, so I'll keep it short. The power of capitalism to produce competition and better products is underestimated here. Market pressure is growing for closed source to become more secure, and when money is at stake, the products will improve. Peer review by tens of thousands of largely unpaid, untrained developers vs. a corporation's all important shareholder value in this increasingly security conscious market is a much more even fight than one might expect. This is why we have combined both sides of the debate to produce a dual licensed product that has the security benefits of open source, with the market responsibility of a commercial product. J Harper PeerSec Networks http://www.peersec.com - Original Message - From: R. A. Hettinga [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, July 20, 2004 9:46 AM Subject: Cryptography and the Open Source Security Debate http://www.osopinion.com/print.php?sid=1792 osViews | osOpinion Cryptography and the Open Source Security Debate Articles / Security Date: Jul 20, 2004 - 01:03 AM Contributed by: Daniel R. Miessler :: Open Content If you follow technology trends, you're probably aware of the two schools of thought with regard to security and/or cryptography. Does cryptography and security solutions become more secure as the number of eyes pouring over its source code increases or is a private solution which leverages security through obscurity provide a more secure environment? Daniel R. Miessler submitted the following editorial to osOpinion/osViews, which offers some compelling arguments for both scenarios. In the end, his well thought out opinion, comes to a universal conclusion. -- I've been reading Bruce Schneier's Book on cryptography for the last couple of days, and one of the main concepts in the text struck me as interesting. One of the points of discussion when looking at the security of a given algorithm is its exposure to scrutiny. Bruce explicitly states that no one should ever trust a proprietary algorithm. He states that with few exceptions, the only relatively secure algorithms are those that have stood the test of time while being poured over by thousands of cryptanalysts. Similar Situations What struck me is the similarity between this mode of thought and that of the open source community on the topic of security. In that debate there is much disagreement about which is better - open or closed -, while in the crypto world it's considered common knowledge that open is better. According to the crypto paradigm, having any measure of an algorithm's security based on the fact that it's a secret is generally a bad thing. There, keys are what makes the system
