BLU Discuss list archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Discuss] NAS: encryption
- Subject: [Discuss] NAS: encryption
- From: cra at WPI.EDU (Chuck Anderson)
- Date: Wed, 8 Jul 2015 11:06:32 -0400
- In-reply-to: <559D3884.7010505@gmail.com>
- References: <5596D8DA.2000201@gmail.com> <55980A9F.4020007@gmail.com> <BY1PR0401MB1641117906253C39D8075681DC940@BY1PR0401MB1641.namprd04.prod.outlook.com> <sjmd203evpz.fsf@securerf.ihtfp.org> <CAFv2jcba50_Kw9V-p7brmeJ5Fk=9rzeQRLRzBUVRK8uZ71wZNA@mail.gmail.com> <BY1PR0401MB164127DEA53006B9692DC60CDC920@BY1PR0401MB1641.namprd04.prod.outlook.com> <3d14590da6e6f0bd76b8e75496117136.squirrel@mail.mohawksoft.com> <559D3884.7010505@gmail.com>
On Wed, Jul 08, 2015 at 10:49:40AM -0400, Richard Pieri wrote: > On 7/8/2015 10:23 AM, markw at mohawksoft.com wrote: > >The problem with internal drive encryption is getting any level of > >disclosure and accountability. > > This is simply not true. > > FIPS security profiles are public record. Here's the security > profile for the cryptographic module used in several of Seagate's > enterprise SEDs: > > http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp1299.pdf > > The process of obtaining the certificate is accountability in and of > itself. The device or software is tested by an accredited test lab > to ensure that it works as described in the security profile. If > anything fails to work as documented then the device or software is > sent back to the vendor to correct the fault or update the security > profile. 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. 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? 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.
- Follow-Ups:
- [Discuss] NAS: encryption
- From: richard.pieri at gmail.com (Richard Pieri)
- [Discuss] NAS: encryption
- References:
- [Discuss] NAS: buy vs. build
- From: tmetro+blu at gmail.com (Tom Metro)
- [Discuss] NAS: encryption
- From: tmetro+blu at gmail.com (Tom Metro)
- [Discuss] NAS: encryption
- From: blu at nedharvey.com (Edward Ned Harvey (blu))
- [Discuss] NAS: encryption
- From: warlord at MIT.EDU (Derek Atkins)
- [Discuss] NAS: encryption
- From: abreauj at gmail.com (John Abreau)
- [Discuss] NAS: encryption
- From: blu at nedharvey.com (Edward Ned Harvey (blu))
- [Discuss] NAS: encryption
- From: markw at mohawksoft.com (markw at mohawksoft.com)
- [Discuss] NAS: encryption
- From: richard.pieri at gmail.com (Richard Pieri)
- [Discuss] NAS: buy vs. build
- Prev by Date: [Discuss] NAS: encryption
- Next by Date: [Discuss] NAS: encryption
- Previous by thread: [Discuss] NAS: encryption
- Next by thread: [Discuss] NAS: encryption
- Index(es):