The Always-Encrypted Firewire Hard Drive 230
ducman points to the announcement of an encrypted hard drive running on the MacNN website. The drive features a DES 64-bit/ 40bit key strength and "is intended for use by banks, insurance providers, government agencies, and those individuals with sensitive digital intellectual property. It supports the IEEE 1394a connectivity standard, in addition to USB 1.1 and 2.0. It offers data transfer rates over FireWire 400 of 100, 200, or 400 Mbps. The SuperGuard is expected to be available February 7." Sounds great -- but the USB key stuck in the back looks like a likely point of failure.
worthless (Score:5, Insightful)
Re:worthless (Score:1, Funny)
is that a masculinity problem?
Re:worthless (Score:2, Insightful)
Re:worthless (Score:2)
40 bits too short? Bah!
My external harddrive has a 1 bit key. It's a rocker switch on the back with a 0 and a 1. If you don't enter the right key the entire drive shuts down.
-
Re:worthless (Score:3, Funny)
64 bits should be enough for anybody.
This sounds useful (Score:1, Interesting)
One of these puppies would be a neat alternative. Probably a bit costly though.
Use encrypted loopback (Score:1, Informative)
- Make a big file image, format it, mount it via loopback, encrypt everything that goes on it.
He does this already (Score:5, Interesting)
That's what encrypted DiskCopy images essentially are, just wrapped in a nice interface. It's actually a pretty neat system.
DMG images work great (Score:2)
Is there an encrypted filesystem I could use in Linux?
Re:DMG images work great (Score:2)
CryptoAPI [kerneli.org]isn't bad either, but loop-aes is quicker to set up, IMHO.
Re:This sounds useful (Score:2)
Re:This sounds useful (Score:2)
3rd post! (Score:5, Insightful)
And more secure IMHO.
Encrypted disk images rock. (Score:5, Informative)
Encrypted disk images are really easy to use on OS X. They're encrypted using AES-128 (much more secure than the above hardware solution) and the performance is really quite good (fast enough to playback Quicktime movies from, even on a G3.) The Apple KBase entry on how to use them is here [tinyurl.com].
Re:Encrypted disk images rock. (Score:2)
Performance isn't bad at all. I don't even notice it in my application since my bottleneck is the 100T connection to the server rather than the 400Mb Firewire bus or the encryption speed, but even with local copies, a G4 should do a fine job of keeping up with the Firewire bus.
The FW 800 bus will be a little different matter. Maybe the dual 1.42 G4 can do it, but I doubt my lowly PB could.
Re:Encrypted disk images rock. (Score:2, Insightful)
>to the server rather than the 400Mb Firewire bus or the
>encryption speed, but even with local copies, a G4
>should do a fine job of keeping up with the Firewire bus.
>The FW 800 bus will be a little different matter. Maybe
>the dual 1.42 G4 can do it, but I doubt my lowly PB
>could.
While it's fine to get excited about fast busses, it's important to remember that they're that fast because they're designed to support a bunch of drives, not because each drive is actually capable of pushing that much data. If you're luicky, the drive inside the enclosure is a 7200 rpm ata drive, which isn't capable of filling the ata100 bus on it's own, let alone a firewire 800 bus.
Re:3rd post! (Score:2)
Loopback devices are a silly hack. It was nice to add a quick feature. But what is really needed is a smooth, seamless, truly integrated solution which works at the virtual device layer, above individual device drivers, but below filesystems and direct device opening. The reasons for this include the fact that you can't partition loopback devices (that's another issue) and the number of loopback devices being limited. This needs to be made totally transparent except for the fact of enabling it and setting the key (probably an integrated ioctl() and/or /proc operation). Every device (and partitions count) need to be able to have their own separate key and encryption state.
with sensitive digital intellectual property... (Score:2, Funny)
Re:with sensitive digital intellectual property... (Score:1)
I enclosed secured in quotation marks because nothing is truely secure.
On a more "On Topic' note, I bet the Co-operators insurance company wishes they were using a similasr technology last week as this article [therecord.com]
exemplifies.
Wow super secure (Score:5, Insightful)
Anyone in here actually read Applied Cryptography? This was 1995 when it was published, and especially for bank use, you'd NEVER use anything less than a 128 bit key.
Also, did they say DES or 3DES? Hasn't DES been cracked?
Re:Wow super secure (Score:5, Informative)
That said DES and possibly even 3DES should no longer be used.
DES weaknesses (Score:5, Interesting)
"40-bit DES", on the other hand, is either a well-designed crock or poorly-designed crock, which is pretty trivial to crack. The only reason to use such any 40-bit key is to comply with anti-Communist US export regulations that got dropped a few years ago, largely due to the EFF's DES-cracker machine and the internet distributed DES crack effort, both of which emphasized the weakness of 16-bit DES.
On a technical note, cracking well-designed 40-bit DES subsets is not 2**16 times faster than cracking 56-bit DES, or John Gilmore could do it in 3 minutes in his basement. DES has two main phases, a key-scheduling phase and an S-box phase, and the DES cracking efforts took advantage of some interesting work by Peter Trei on key scheduling, which found a search order that makes each key-schedule a simple modification of the previous one, instead if its normal relatively slow calculation. So a 40-bit DES crack might take 5-10 times as long per key as a 56-bit DES crack, unless the 40-bit subset was designed to avoid that. On the other hand, the EFF and Internet DES cracks were in 1998, and computers have gotten about 8-10 times faster since then...
Re:DES weaknesses (Score:2)
No it is not. though the 3DES key is three times as long as the DES key, the 3DES block is still exactly the same size as the DES block. A 64 bit block is simply too short, you will get vulnurable to the so called birthday attack.
With a reasonable security margin you can encrypt no more than 512KB with the same key. If you encrypt 35GB with the same key you can be almost sure, that your data is no longer safe.
I'm also wondering if this product even uses a safe mode of operation. It is easy to use a per sector CBC mode with block number as IV (like cryptoloop for Linux), but that is just not secure. A secure solution has to offer some of your disk space and access speed, I think a 10% cost would be likely.
Re:DES weaknesses (Score:2)
As fast as safe operation modes goes, the nice thing about 40/56/64-bit encryption is that you scarcely have to worry about whether something else is the Weakest Link instead :-(.
Re:DES weaknesses (Score:2)
Re:Wow super secure (Score:2)
At least there is a review on that firewire product that correctly points out that the encryption needs work.
Re:Wow super secure (Score:2)
Military Security and Key Length (Score:2, Informative)
However, to point to where the "military grade" security claim is coming from is the fact that in many military situations information is only needed to remain secure for minutes or a few hours. Unfortunately for FW Depot, that generally applies to wireless communications, not data stored on hard drives.
Maybe they are hoping that people will use it to courier sensitive data...but then they could just hire Johnny Mnemonic.
Yeah, bad product trying to meet ITAR regulations so they can export.
Re:Wow super secure (Score:2, Interesting)
Re:Wow super secure (Score:3, Informative)
DES hasn't been cracked per-se but the 40bit keyspace can be scanned very efficiently now with distributed computing and specialized hardware.
Yes, DES has been cracked... sort of... (Score:2)
A linear attack breaks DES in 2^40-something encryptions and 2^40-something known plaintexts (compare 1 known plaintext and 2^53 work for brute force). This means order of 10 terabytes of data, though, so we don't have to worry about it. Nobody will be using DES by the time anyone will be lazy enough to encrypt 10TB of data with a weak code.
Re:Wow super secure (Score:2)
Why is everyone concentrating on the key length? The method in which they are using DES here is far more relevant.
If you take an entire hard drive and encrypt it sector by sector under a DES key, you've got a problem. There's plenty of plaintext and matching ciphertext available by virtue of known disk structures, and the possibility of constructing a birthday attack is high. Worse, there are parallel attack mechanisms that allow you to break such a scheme in 2^40 tries instead of 2^56. That's under a day for someone with serious money.
But most HDD encryption schemes don't work like that. At work you use a key variant for every sector -- xor the sector number onto the key, so that you effectively have a different key per sector. This helps to reduce the effectiveness of some attacks (e.g. the parallal attack), but suffers a critical problem: break the key for one sector, and you've got the drive.
A far more secure scheme involves key derivatives: encrypt the sector number with the key to find a derived key, then encrypt the sector with that key. Breaking a single sector still doesn't break the master key. This mostly limits you to a known plaintext attach, and raises the complexity to 2^57 (you have to break two keys, the second being the one you want).
Other schemes include the use of multiple keys over a disk, so that breaking a single key only compromises and area (say 1/4) of the disk.
As for the security of DES; it hasn't been cracked. There are some ways to reduce its strength in particular circumstances (see above), but not generally.
Like it or not the banking world still uses DES (yes, 56 bit keys) and will continue to do so for some time to come. Check out the ANSI financial services standards (which govern interbank electronic standards, like ATM networks). Is this a problem? Not really. Intelligent use of protocols ensures that cracking the key is a waste of time because at best you can recover a single PIN ... which is more easily brute forced at 10^5 than a DES key at 2^56.
Re:Wow super secure (Score:2)
DES?!!? (Score:5, Interesting)
DES has been replaced by Rijndael (AES)in the govt. Or at least that's what's supposed to happen, DeS is no longer secure enough. I would bet that with the huge ammounts of data stored on a disk differential techniques would make it a snap to get the key. What's worse is an easy to crack crypto system that you believe in is worse than no crypto system at all since you're likely to store data on it that you might not store otherwise.
Patrik
Re:DES?!!? (Score:3, Informative)
-a
Somebody mod up the ACs... (Score:5, Informative)
What's their definition of OS independent (Score:3, Insightful)
*Device driver free, operating system independent
*Microsoft Windows98 SE, Windows ME, Windows 2000, Windows XP and Mac OS compatible
First off, how can it be OS independent and have a list of compatible OS's? If it's a hardware-based solution, then how can some OS's not work with it?
Re:What's their definition of OS independent (Score:2, Insightful)
Maybe because those OSes don't support USB.
Re:What's their definition of OS independent (Score:1)
Re:What's their definition of OS independent (Score:1)
Re: Portable Drive Standard (Score:2)
I have a portable drive that when plugged into XP,2000, and OSX, it recognizes and mounts.
I have a driver disk for 98.
The company I bought it from told me that Linux didn't have built in support for it yet.
Puto
Re: Portable Drive Standard (Score:2)
for ieee1394a its called sbp2...
and linux DOES have support for it (the standard)... the problem is drives that DONT follow the standard....
http://www.linux1394.org/sbp2.html
for usb it called the mass-storage class... and same issue applies. Linux supports the STANDARD... which some manufacturers may not fully follow....
http://www2.one-eyed-alien.net/~mdharm/linux-us
Re:What's their definition of OS independent (Score:2, Interesting)
It's just a marketing phrase. It doesn't necessarily mean anything. It's like Sally Struthers saying "earn your degree in almost anything" and then she lists stuff like "dog grooming". The list serves as a set of ideas for people unwilling to believe the word "anything" and who only click when they hear the one word important to them.
That's not a contradiction, it's just annoying ad copy. Keep in mind the kind of people writing ads. Watch TV for a few minutes and see that while broadcasters are upset over ad-skipping Tivos we might have a strong case to sue them for cruel and unusual punishment.
More annoying ad copy is the advertising which says "up to 10, or more!". How can it be more?? They just said it's up to 10!
Truly annoying (and common) are the ads that say "Sugar...because cookies would be bland without it.", or "Diamonds...because we've got everyone duped." Well, actually, I never asked why!
Encrypted? (Score:3, Insightful)
An encrypted drive is a cool idea, but i would much rather use CFS (crypted file system) on a regular drive than this. DES offers no security to the people who want your data.
Re:Encrypted? (Score:2)
I have a cheaper solution (Score:5, Funny)
Bruce, put this one in your doghouse listing (Score:5, Informative)
The people who designed this hard disk are confused about how DES works. First of all, DES has a 56-bit, not a 64-bit key. Second of all, the days of being forced to use 40-bit encryption are, thankfully, over.
If one is going to all of the effort to encrypt a hard disk, why will they encrypt it using only Single DES? It is possible to build a single-DES cracker for under $10,000 US; the 56-bit key which single DES has to offer is just not long enough.
They would have been much better off encrypting this unit with AES [plus.com], which uses Rijndael [rijndael.com] to encrypt files. Rijndael has a key size between 128 and 256 bits long, which can not be brute forced with current technology. Rijndael is also more efficient than DES when implemented in software.
Also, security is only as strong as its weakest link. If the hard disk is always readable when the key card is attached, then great care must be taken to detatch and hide the key card. Far better security can be obtained by a system which asks for a passphrase. Ideally, have a system which needs both the key card and the passphrase.
While I think this is a good idea, I think one is better off with the kernel patches which allow one to encrypt [sourceforge.net] filesystems [kernel.org] in Linux.
(For windows and Mac users, sorry, I use neither so can not help you)
- Sam
Re:Bruce, put this one in your doghouse listing (Score:2)
Re:Bruce, put this one in your doghouse listing (Score:1)
Re:Bruce, put this one in your doghouse listing (Score:2)
Re:Bruce, put this one in your doghouse listing (Score:2)
Re:Bruce, put this one in your doghouse listing (Score:2)
I hadn't heard of any salt being used. Salts are completely useless if you're using a seperate strongly (pseudo-)random key for each file. If you're not very very careful, the salting may also very slightly reduce your key space.
If you're using an encrypted fielsystem, make sure your password is stored only using the NT hash. By default, both the LM hash and the NT hash of your password are stored in the registry. In the absolute best case, the work foactor is somewhere aroudn 2 ** 56 to break a 14-character strong password. If you password doesn't require you to hold down the alt key while using the nueric keypad, you're most likely looking at a work factor of about 2 ** 37 to crack your password. (Your password is borken into 7-character halves and converted into upper case, then something like an unsalted UNIX crypt algorithm is applied seperately to each half.) Once they have your password, they can decrypt your SK and get all of your files. Game over man, game over.
Microsoft should be applauded for making a default install crypto-filesysm capable. However, per-file encryption falls to some attacks and information leakage that volume-level encryption doesn't suffer from. Swap space and temp files are still a big problem without third-party add-ons.
It's also important to note that RSA Labs designed DESX explicitly as a stop-gap measure until the Advanced Encryption Standard (AES) was decided upon.
MS could also have done the world a great service by including 40-yaer old password salting technology instead of using unsalted password hashes.
DESX is broken (Score:2)
DESX is broken, and not just academically. See Applied Cryptography for details (it's by Bruce, btw). Any instance of DESX that is as fast as DES is no more secure. It is only slightly better in strength vs performance than 3DES. It was a nice idea, but it didn't work out.
Re:Security trough obscurity (Score:2)
Encrypted file system for mac users (Score:2, Informative)
http://www.apple.com/macosx/technologies/securi
Re:Bruce, put this one in your doghouse listing (Score:2)
Placing the key reader in the back only encourages people to leave the key in the unit which provides even less security, (read none), than the DES encryption provides.
DES and 64-bit keys (Score:2)
All this is, of course, IIRC.
Purple thingy! (Score:1)
It doesn't come with the drive :-) (Score:2)
Why 400? (Score:2)
On the other hand, they probably don't want to force people to buy Apple's high end stuff to use their drive: they aren't Apple, after all.
Re:Why 400? (Score:1, Insightful)
Besides the fact that a single hard disk isn't going to saturate a Firewire 400 bus, you've answered your own question: it just came out. So it'd be useless unless you owned one of the newest 17" PowerBooks, which won't ship for "6-8 weeks".
I'm all for embracing new technologies, but why release a hard disk enclosure that supports a standard nobody's even using yet? (Maybe if they also sold Firewire-800 PCI cards...)
There are more parts to the security here... (Score:2, Insightful)
I'll bet there are other companies working on a similar technology, I won't purchase one until I get variable key length and some decent speed specs.
-Code
Re:There are more parts to the security here... (Score:2)
All the AES candidates (Rjindael, Twofish, Serpent, MARS, etc) were engineered to be as fast as possible in software and in hardware. Encryption chips are already available for Rjindael and IIRC Twofish as well; even if not, they could make an ASIC for it on such a big project. Speed is not an issue here.
would be nice (Score:1)
Not so crap (Score:4, Interesting)
Still, the same device with AES, 3DES or similar would be much better....maybe next time!!
Still crap. (Score:2)
I don't trust the little USB dongle (Score:2, Insightful)
I know a lot of corporate IT types will think this is exciting, especially as new data security laws keep hitting the books. Full time encryption seems pretty secure. And the price seems fair, especially since it seems to take any EIDE drive and secure it, and (quoted from the article), "capable of maneuvering 66MByte/ sec throughput without taking any system resources." Just don't lose that darn key! And maybe they'll develop an internal version that would be more secure from bumps, knocks, and falls.
Now, I've gotta get one of them new-fangled firewire (or USB 2.0) ports. And a hook to hang the little dongle from.
Don't worry about losing the key. (Score:3, Funny)
*ducks*
Re:I don't trust the little USB dongle (Score:2)
I imagine in places that deal with a lot of data that must be secured, it would be a lot easier to lock all the USB keys in a safe than to do so with the drives themselves.
~Philly
False advertising (Score:5, Informative)
"...offers the military grade protection for your classified data."
Calling DES "military grade protection" is pretty close to a blatant lie.
Re:False advertising (Score:2)
Re:False advertising (Score:4, Informative)
Re:False advertising (Score:2, Interesting)
True... but.... (Score:2)
DES is obsolete and would not be used for sensitive information by the US Military.
But they didn't say who's military ;-)
Re:False advertising (Score:3, Informative)
Drive Failure (Score:5, Insightful)
Conceivably. Anyone who is running one of these drives without backups somewhere is even more insane than the folks running un-encrypted drives without backups. The backups themselves can easily be encrypted, so there's no need for major security risk. If your key dongles stop working or your drive fries, you'd better have some way of getting the bits back from outside, 'cause they're not coming from the platter.
OTOH, what is "64-bit/ 40-bit DES" supposed to be? Presumably this means the drive supports "40-bit watered-down DES keys" and "64-bit normal DES blocks". So I guess I'm wrong: this drive is designed to be break-inable in an emergency. Great. I'll wait until they offer 3DES or AES-128 options, thanks.
In the meantime, check out the BSD Cryptographic disk driver cgd [stanford.edu]: SW on-disk encryption at the block level.
Re:Drive Failure (Score:1)
P2P encrypted backups? (Score:2)
I've recently been brainstorming about a P2P encrypted backup system. It would create automatic, encrypted backups using something like FreeNet or OceanStore to distribute redundant, encrypted backup fragments on other people's computers (and vice versa). I know P2P and security are almost oxymorons, but I think it could work securely.
Are there projects like this already? Or applications like it built on top of existing "overlay networks" like FreeNet?
Re:P2P encrypted backups? (Score:2)
P2P can be done securely, depending on your threat model. DOS attacks against P2P systems is still a largely unsolved problem. However you could easily make a system that is for all practical purposes immune to data disclosure. (GPG encrypt your data to yourself befre distributing it, for instance.) I have a nice little perl script that makes a nightly tarball of my CVS repository and GPG-encrypts it, then puts the encrypted tarballup on the web under a filename that contains 64-bits of the md5sum of the unencrrypted tarball. (taken pre-compression). On the backup storage machine, there's a perl script to chck if the md5sum fragment has changed, and if so, use wget to backup the tar ball. (This most defintely isn't P2P, but it deonstrates a simple example of a backup system that lets thee entire world see the backup, yet is for all practical purposes immune to data disclosure.)
If you had a distributed cooperative file system, you could use my perl scripts do do your backups, and the only notable attack (aside from compromise of your machine) would be a DOS/deletion attack against the cooperative filesystem. Of course, you need to chack signatures on the tarballs when you decrypt them.
I was actually talking with one of the Freene developers about his efforts provide distributed encrypted anonymous storage. Unfortunately, the DOS/deletion problem is still unslved, so he was forced to go with storage only on his machines, which means it's not P2P. Most P2P stems are also so transient that you'd need a very high level of replication.
Of course, there's a simple modification to my perl script system that you could make... have it scan random IP addresses for open SMB shares... that would be "non-cooperative distributed filesystems" :-P
usb keys (Score:2)
One of the problems I've been wrestling with is that if anyone copies the file from the thumbdrive that it looks for, they can access my system as easily as I can. This hard drive would seem to suffer the same problem.
So, you say, protect the usb key just as a regular door key - you don't let people copy those. When I get my car serviced I even make a point to only hand them the car key alone, and not my apartment keys, etc.
But the small usb drives are so damn convenient as a replacement for floppies, and in fact I bought mine so I could throw files on it and take them to people's computers. But if I've got a login file on mine, the second I insert it into someone's computer I've theoretically lost security, because they could have a background process that copied off the file.
Now of course I'm not in the habit of trading files with miscreants and criminals, but you get the idea. If I'm building a process that's ostensibly for security it might as well be good.
But I haven't been able to find a way to reconcile the login issue with using the usb key elsewhere. As far as I can see, a perfect copy of my login file is as good as the original.
Re:usb keys (Score:2)
Re:usb keys (Score:2)
This reduces, but does not eliminate the risk.
Re:usb keys (Score:2)
Of course, usb keys are for storage. There is hardware [ibutton.com] designed for what you want to do.
Why not just use Scramdisk or Drivecrypt??! (Score:2)
Scramdisk (free) and Drivecrypt (cheap) both do on-the-fly en/decryption on regular hard drives. 1024 (and I think 2048) bit keys are available, with your choice of algorithm, and it's incredibly easy to use. For the truly paranoid, you can even use a fully encrypted disk on the fly for your entire OS.
I don't at all understand what the benefit of special hardware in the drive would be.
Re:Why not just use Scramdisk or Drivecrypt??! (Score:2, Informative)
For instance, encrypting and decrypting the data via software would cause cpu and memory overhead on the host machine. The encryption software would also need to be installed on all machines that you want to use it on, and this is looking to be a portable drive. Also, using an external encrypter, it's less likely that a keygrabber or trojan can grab your password.
IBM could use them (Score:2)
IBM has lost a hard drive containing the records of 180,000 clients of an insurance company. Details include "names, addresses, beneficiaries, social insurance numbers, pension values, pre-authorized checking information and mothers' maiden names", according to wire reports. Anything else? Oh yes, their bank account details.
"Firewire Encrypt" sounds much more interesting (Score:2)
Re:"Firewire Encrypt" sounds much more interesting (Score:2)
Nevertheless, firewire has always included a facility for encrption and key exchange-- it is a little dissapointing that the first "encrypted firewire drive" to market supports an obsolete standard
firewire encrypt "Designers notes" [kuro5hin.org]
It was demonstrated at the MacWorld Expo (Score:3, Interesting)
It uses software to allow the user to enter their passphrase from the keyboard. By the time of the expo, I had got the AES encryption working in the FireWire/IDE bridge but had only done the passphrase application for Mac OS X.
I've since got it working for Mac OS 9 (and earlier Mac OS versions). Windows and Linux remain before the product can ship. I don't expect either to be hard to do but they do require some work because they have to do some raw FireWire I/O.
I think it is best that I not comment any beyond this until FireWire Encrypt ships. But I think users will like what they see.
I Don't Get It (Score:1)
Yeah, the encryption is weak, blah, blah, but that's beside the point. Isn't the data only as secure as the application that can access it? I guess these things are only used behind a firewall then, and they are just encrypted to protect against physical theft. They can't provide any security if the server is net facing can they? I mean, if Apache can access the data then just crack Apache above the level of drive access.
Parent is correct (Score:2)
Maybe something like this would be useful on a laptop, but encrypted loopback devices probably solve the problem better because the dongle could get lost, stolen etc. The only thing you have to worry about there is speed.
The biggest problem seems to be how to get the password into such a device. The next disk format / drive type spec should have optional encryption (of the whole drive) built into the spec to allow the password to be entered in a user-friendly manner. This would allow, say, encryption on CDs that is transparent to userland processes (not for copy protection, but for data protection).
Already being done?and with better encryption, too (Score:1, Redundant)
Features: (Score:2)
# Microsoft Windows98 SE, Windows ME, Windows 2000, Windows XP and Mac OS compatible
Is that a feature? Or a limitation?
All I need for my "secure" alternative:
128 bytes of storage for some random data, to which I then append a password to and use as the encryption key in my crypto-loopback [kernel.org] software implementation.
What do those "artistic" MAC users have that they need to keep secret anyway? This? [ubergeek.tv] Also mirrored (aka stolen) here [damnit.org]
Likely point of Failure? Not the USB key! (Score:3, Informative)
Re:first post! (Score:2)
It costs next to nothing to implement GOOD encryption these days, and it would've been extremely simple to implement something extremely fast and secure like blowfish with a 256/448 bit password.
Implementing DES (slow in software, probably slow in their hardware) with a 40 bit password (VASTLY INSECURE) is basically saying upfront that they're more interested in preserving an easy attack on the system than ensuring that users' data is secure.
As other posters have mentioned, products like DriveCrypt (for the PC), can encrypt your partitions (or removable drives) with encryption that is for all intents and purposes absolutely unbreakable with a good passkey. Move up to something like DriveCrypt Pluspack and it will even encrypt the boot partition so the drive doesn't even get to the OS until a proper password has been entered (no software keyloggers possible).
There's simply no excuse for the kind of sloppy security that this company is trying to sell. Either they are trying to preserve access to their product for law enforcement purposes (hunt down them terrorists!), or trying to preserve access incase dumb users lock themselves out so their tech support can save the day.
Regardless, it's a waste of money.
40 + 128 = 168 (Score:2)
working for a government contracter, we are required to have more than 40 bits
Not all your bits have to come from the same source. For example, you can use 128 bit AES on the CPU followed by 40 bit DES on the drive, and you get 168 bit cipher strength barring any meet-in-the-middle[1] attacks.
[1] "Meet in the middle" in symmetric cryptanalysis has absolutely nothing to do with "man in the middle" in public-key infrastructure analysis.
Re:40 + 128 = 168 (Score:3, Insightful)
Re:40 + 128 = 168 (Score:2)
It probably doesn't because there's probably good known plaintext that's only encrypted by the 40 bit encryption, like the boot blocks. In this case, your statement is true.
But if it was all encrypted in AES, and then in DES with a completely different key-- I don't see how you can say that the DES doesn't provide proportionally more strength by the relative keylengths. Just like TEMK doesn't provide 2* 2^56, but more like 2^112 of brute force complexity.
Re:40 + 128 = 168 (Score:2)
Re:Conflicting feature listings (Score:2)
Somepeople will always ask for confirmation.