Boston Linux & UNIX was originally founded in 1994 as part of The Boston Computer Society. We meet on the third Wednesday of each month at the Massachusetts Institute of Technology, in Building E51.

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss] NAS: encryption



On Wed, Jul 08, 2015 at 11:53:35AM -0400, Richard Pieri wrote:
> On 7/8/2015 11:06 AM, Chuck Anderson wrote:
> >I think this whole discussion revolves around choice.  With open
> >source, I have a choice to audit the code if I so desire, or to hire
> >someone to do so on my behalf.  With internal drive encryption, I have
> >(almost) no choice but to trust someone else's judgement about the
> >implementation, whether that be the manufacturer or the government or
> >some industry body or nonprofit.  Their incentives and my incentives
> >may not always be aligned.
> 
> You are not qualified to perform a security audit.

You have no basis upon which to make such a statement.

> Neither am I.
> Only a handful of people in the world have those chops and most of
> them work for the NSA and GQHQ and maybe the FSB. The rest charge a
> great deal of money for their time and expertise, money that you as
> an individual probably don't have.
> 
> You only have the illusion of choice.

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.

> >I say "almost" no choice, because I guess I could reverse engineer the
> >device.  But this is much harder to do than if I had the source code
> >in the first place.  Isn't that one of the major selling points of
> >open source software?
> 
> If you are not qualified to audit the thing then you are not
> qualified to reimplement it. The license is irrelevant.

People can learn.

> >Even if I do not exercise my choice to audit the code, the mere fact
> >that anyone can chooose to do so at any time can be a deterrent to
> >trying to "pull a fast one" and hide malicious code in there.
> 
> It didn't stop the NSA from compromising Dual_EC_DRBG. It didn't
> stop Intel from compromising RdRand (likely at the NSA's prompting).
> It didn't prevent the ProFTPD sources from being compromised. It
> didn't prevent the OpenSSH sources from being compromised.

And do you think we would know about those instances if the
code/standards were closed?



BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org