• We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.

Data / HDD encryption

Page 2 - Seeking answers? Join the AnandTech community: where nearly half-a-million members share solutions and discuss the latest tech.
Further more, you seem to be implying that because you can't verify one part of the trust chain (your hardware, which is debatable) then you shouldn't bother verifying anything. At that point, why bother with encryption at all?

Good question 😉

Obviously, no single person is capable of fully verifying the security of his or her computing platform. At some point, they have to trust a component provided by a third party. There's no reason why that trust shouldn't be extended to software.

Although your basic message is true. If you want real encryption, you need to not only verify your encryption program, but the algorithm, the operating system, and the hardware.

If you're building everything from source code (which I'm sure you are), don't forget to verify the compiler :awe:
 
Good question 😉

Obviously, no single person is capable of fully verifying the security of his or her computing platform. At some point, they have to trust a component provided by a third party. There's no reason why that trust shouldn't be extended to software.



If you're building everything from source code (which I'm sure you are), don't forget to verify the compiler :awe:

I consider a compiler a intergal part of an operating system. No real operating system would ship without a compiler. 🙂
 
Yes, I know I can encrypt the whole drive (doing this as I type; for test purposes), BUT the same problem remains. If there's one error, one corruption, I can't access anything on the whole drive, correct?
...

TIA!
Mat

That is not correct. TrueCrypt, and most other whole disk encryption problems I can think of, encrypt the drive in blocks, and each block is encrypted independently of any others. If a single bit is corrupted in a block (as in, a bit error on the drive itself), that block won't decrypt correctly, but the rest of the drive will be fine. The exception to this is the header information, which is needed to decrypt the drive, but TrueCrypt (and maybe others) has a backup copy of the header embedded in the encrypted container, and even allows you to create your own backup copy as a standalone file.

So, with the default behavior, in order to corrupt your whole drive, bit errors would have to occur in both the original header and the backup header. And if you make a copy of the header, that too would have to become corrupted. In my opinion, this makes TrueCrypt no more susceptible to disk destroying errors than regular files.
 
Back
Top