On Thu, 28 Feb 2013 23:26:43 +0000 Ed W articulated:

I believe the high profile user of polarssl is the Dutch government who have approved OpenVPN + PolarSSL for use. (The point being that openssl is just too huge to audit for security)

Just because a program has a large footprint does not equate to it being a security risk. In fact, that might be one of the dumber statements I have heard in awhile. Unless you have proof of a specific and reproducible security exploit, your statement is pointless.

-- Jerry ♔

Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header.

On 2/28/2013 4:09 PM, Reindl Harald wrote:

Am 01.03.2013 01:02, schrieb Jerry:

...

On Thu, 28 Feb 2013 23:26:43 +0000 Ed W articulated:

...

I believe the high profile user of polarssl is the Dutch government who have approved OpenVPN + PolarSSL for use. (The point being that openssl is just too huge to audit for security)

Just because a program has a large footprint does not equate to it being a security risk. In fact, that might be one of the dumber statements I have heard in awhile. Unless you have proof of a specific and reproducible security exploit, your statement is pointless

you did not understand the statement or refuse to understand what auditing means - a code audit is the seek for UNKNOWN implementation weakness and bugs - you can guess which is easier to audit: 1000 LOC, 10000 LOC or 1000000 LOC.....

there are common known statistics of hidden errors in a defined count of codelines - the statistic remains always the same: having 3 times more code means mostly 3 times more of unknown bugs

and NO this DOES NOT say anyhting about the quality of OpenSSL, these are only statistics and facts for audits

not more and not less

There are two statements, which apply here. They appear to be contradictory, but they are not.

1. You can never prove something is secure, only that it is insecure. Proving something is insecure is easy; find an insecure case. Q.E.D. Proving something is secure involves finding no cases that are insecure, but that could mean it is secure, or that it is not secure and you have not looked hard enough for the insecure case. This cannot be done in finite time and thus cannot be done in the real world.

2. Programs *can*, in fact be proven correct. There is a whole area of computer science dedicated to it, and has been for several decades now.

The reason that these two statements are not contradictory is that the second one states you can prove a program correct; that given a set of parameters and criteria that it must meet, that the program meets these. However, "secure" can never be one of the criteria, since it is unprovable.

Enough theoretical discussion. In the real world, most coders do not have the background to prove programs, thus it is generally not done. What is done, rather, is use good programming techniques and extensive testing. After that, it is subjected to attacks. The longer it resists the attacks, the more confidence is placed in its security.

Both OpenSSL and PolarSSL can be proven correct (or not). This is not dependent on the size of the code. It is merely a function of mathematics and logic.

However, OpenSSL has been in use much longer and has withstood more attacks. Confidence in it, then, is higher than for PolarSSL. If both were the same age and had the same number of attacks, then it would appear that the smaller code base would have less hiding places for bugs, but if both were "proven" correct by the same set of standards, then neither could be considered more secure than the other.

In regards to the Dutch government, unless they have gone through the process of proving PolarSSL, which I suspect they have not, they are merely saying that due to sheer size, they suspect less bugs could be hiding in the smaller code base.

I cannot say that I disagree with this method, but I do fault it. It is the wrong approach. Both code bases need to be proven before you can really do a comparison of which might have more security flaws. If both can be proven to the same set of criteria, then any flaws would be due to the underlying algorithms involved (MD5, SHA, Diffie-Hellman, etc) and would exist in both equally.

Dem