Slashdot Mirror
Universal Disk Encryption Spec Finalized
Lucas123 writes "Six of the largest disk manufacturers, along with encryption management software vendors, are backing three specifications finalized [Tuesday] that will eventually standardize the way encryption is used in firmware within hard disk drives and solid state disk drive controllers ensuring interoperability. Disk vendors are free to choose to use AES 128-bit or AES 256-bit keys depending on the level of security they want. 'This represents interoperability commitments from every disk drive maker on the planet,' said Robert Thibadeau, chief technologist at Seagate Technology."
Can any storage gurus explain the real-world benefit to this? Is it currently impossible to encrypt a RAID volume built on two different manufacturers' disks?
from: http://www.reddit.com/r/programming/comments/7otuy/who_wrote_this_software_an_excia_agent/
If someone has Truecrypt on their hard drive and the police raid your house for some server and they take that encrypted drive, there is nothing stopping you from saying, "I forgot my password... oops." But if you trust the hardware, then what stops the police from going after that hard drive manufacturer and putting the legal pressure on them to provide a back entrance and/or technical help? The idea that the government won't put a legal squeeze on the hard drive manufacturer the second they think they've come upon a child pornography/warez/other horrible illegal things seems absurd to me. I understand that manufacturers of things like flash drives and such have had hardware encryption before, but it hasn't been widespread and mainstream. When you throw in the "average citizen" factor, I think we'll see all kinds of challenges and laws spring up.
-- And as always IANAL, but I do read Slashdot!!
"The best way to accelerate a Macintosh is at 9.8m/sec^2" -Marcus Dolengo
I worked for a company that shipped encrypted firmware. We were required to send the keys to the NSA.
Speaking from experience, this seems to be true only of the 'fakeraid' setups that you see on cheap RAID controllers, which aren't really hardware RAID at all. They cheat and instead use firmware that executes on the main CPU to do the RAID, making them no better in principle and more often than not worse in performance than the Linux kernel's heavily optimized high-performance software RAID implementation. True dedicated hardware RAID controllers, such as the HP Smartarray, IBM ServeRAID, and the RAID controllers you see on fiberchannel SANs, are actually quite rare except in enterprise setups, and they are in general much faster than the Linux software RAID implementation.
But of course, nothing stops a manufacturer from doing bad engineering and making a product that has a dedicated piece of hardware that actually does the job slower than the main CPU would. And performance is not the only reason to make a dedicated hardware implementation of some bit of functionality. It could be done for "trusted computing" purposes for instance, in which case, it doesn't matter that it's slow, just that it keeps control out of the hands of the main CPU.
Qu'on me donne six lignes écrites de la main du plus honnête homme, j'y trouverai de quoi le faire pendre.
I think we can fully trust manufacturers to take a shortcut and implement this as dual ROT-13 encryption, perhaps with a delay thrown in to make it seem like it's doing something. How would the average user determine whether the magnetic patterns on the disk are encrypted anyway? This seems very similar to the issue with electronic voting machines, only worse. Encryption on the host machine seems far superior, since the data is never traveling over the I/O bus unencrypted, and it's much easier to verify that the data is actually being encrypted.
True dedicated hardware RAID controllers, such as the HP Smartarray, IBM ServeRAID, and the RAID controllers you see on fiberchannel SANs, are actually quite rare except in enterprise setups, and they are in general much faster than the Linux software RAID implementation.
Smartarray is dead slow for RAID5, and RAID1 in software doesn't tax the CPU. RAID controllers are only worth it because it can be hard to get Linux booting reliably from a software RAID 1 with a failed disk. As for RAID levels other than RAID1 and RAID10, don't.
Finally! A year of moderation! Ready for 2019?
All TCHunt does is look for random data. If you append 100MB of /dev/urandom to a file and run TCHunt, it will "recognise" it as a TrueCrypt volume.
This is not a secret. This is how encryption works. Obfuscating your data inside a apparently plaintext structured format is called stenanography and is another subject entirely.
The changelog is here
Discussions on using CVS and other version control are scattered throughout the forums without apparent quoshing by the admins. Yes, old versions of the source are not available - unless you already downloaded them, of course.
The MD5 hashes changing for the installer was just that - they rebuilt the installers with some of the new setup (like offering the option to disable the pagefile) from the version 6 installers, but the binaries inside remained identical. Doing this is rather poor practice because it raises this sort of question, but hey, you trusted the first file signed with their PGP key, why not the second? The TCHunt guys have an archive of old TrueCrypt versions, but they won't let you download them now for bandwidth reasons ; it might be illuminating to pick through the various MD5 versions and compare the actual binaries installed.
If someone is concerned about back doors, they can audit the code, and build it themselves. (don't respond to this with the Ken Thompson compiler back door proposition). Undoubtedly there are people that do this, although they are not equipped to sign their builds with the TC foundation PGP key.
As a popular encryption soft, I have no doubt it comes under scrutiny. I might trust it a mite more if it was signed by Bruce Schneier's key though :-)