[Discuss] NAS: encryption

[markw at mohawksoft.com (markw at mohawksoft.com)]

> On 7/8/2015 3:19 PM, Chuck Anderson wrote:
>> Sorry, I call BS.  My point was that having access to source code is a
>> prerequisite.  If you don't have access to the source code, it becomes
>> MUCH harder to audit because you are limited in the techniques you can
>> use, such as black box testing.  If you have source code, you can read
>> the code and try to understand what it is doing.
>
> This is why I say you don't have the qualifications. Access to the
> source code isn't worth nearly as much as you seem to think it is. There
> are classes of vulnerabilities like insecure compiler optimizations that
> are impossible to detect by examining the source code even when you do
> understand what the code is supposed to do. On the other hand, no-source
> techniques like black box testing work whether or not you have the
> source. This is why my answer to your next question is...
>
>
>> And do you think we would know about those instances if the
>> code/standards were closed?
>
> ... yes, we would.
>

Everyone, step back and think about encryption.

There are a lot of moving parts. Take for instance, the AES encryption
algorithm. This is a known quantity and you can "trust" that it works when
 given any two independent implementations of it can encrypt/decrypt.

That's just the beginning. The next step is your key value. Is your key
sufficiently random to really get the benefits of the encryption? How do
you know? Does your key generation use /dev/urandom, /dev/random, some
neat hardware entropy generation?

If your key is not sufficiently unpredictable, then no matter how good the
encryption algorithm is, it will break if the attacker knows about your
key vulnerability.

Next, how safe is your private key? Why use brute force when the key can
be had by bad programming?

"trusting" that a closed system like encrypted hard disks is probably OK,
but if you are paranoid, it isn't. We should all be paranoid.