Slashdot Mirror
7 Secure USB Drives Reviewed
jcatcw writes "Computerworld has reviewed seven USB drives that use either encryption or a physical keypad to protect stored data, and found big differences in I/O speeds, ease of use and strength of security. In the case of the drive using a key pad, the editors were able to break open the device and access the data, bypassing the PIN security. They also state that there is little difference between 128-bit and 256-bit AES encryption because neither has been broken yet. The drives reviewed were the SanDisk Cruzer, the Lexar JumpDrive, the Kingston DataTraveler, the Imation Pivot Plus, the Corsair Survivor, the Corsair Padlock and the IronKey Secure USB Drive. The editors chose the IronKey as the most secure."
How are any of these better than using TrueCrypt in traveller mode? The only thing I can think of is that TrueCrypt requires administrator rights to use. And I suppose they may be easier to use for people who don't know much about computers or encryption. But I trust TrueCrypt a hell of a lot more than anything which comes preinstalled on these things.
This is not a good thing.
How many of these devices are going to have the equivalent "1111" or "1234" or "8520" (the center of the keypad that users think is just OH so clever) as the password?
At least if the person is smart enough to know that they NEED encryption on their disk and they don't have it, they'll [hopefully] be smart enough not to just leave the thing laying around.
With this thing, it gives users a false sense of security...now they don't NEED to worry about losing the thing because "Oh, its ENCRYPTED!"
No amount of hardware will EVER replace proper training.
Example:
At first, we used a pretty strict password policy at work...+8 characters, numbers, symbols, capitols etc. all required. YOu have to change your password every month.
This is a security DISASTER! Everybody will set their password to like "jason1!" the first month, then "jason2@" the next month", then "jason3#" the next month and so on. Finally I changed the policy. Now a user can request a password that never changes, so long as it meets *MY* requirements...
NewslilySocial News. No lolcats allowed.
Maybe not yet, but presumably, when they are broken, they're likely to be broken in such a manner that 128-bit falls way before 256-bit. So if you only care about someone not stealing your data right now, they might both be equivalent, but if you're worried about someone stealing your data at any time and then reading it further down the road, one is likely to be much better than the other.
Also, I'm sure there will be some debate on this, but I'm not entirely convinced that if someone like the NSA has thrown a few billion dollars at the problem including having a custom-made super computer with their own unique, dedicated processors that are highly optimized for cracking encryption, that perhaps 128-bit AES is already compromised and we simply don't know. The relative advantages of 128 vs 256 bit might depend both on how long you want to keep your data secure, and on who you're trying to keep it secure from.
Can anyone tell me how to set my sig on Slashdot?
The big difference is WHEN they will be broken.
With an algorithm like AES, if you need your data to stay secure longer, use a bigger key.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
It doesn't matter that much that there's little difference right now between 128-bit and 256-bit AES. It will matter later. There will almost certainly be time after 128-bit AES is broken but before 256-bit is broken. During that time, the extra 128 bits will mean the difference between secure and insecure. And remember, attackers who can read but not crack your messages can still keep them for later when they're crackable. If your messages still have value at that time, they will crack them then.
Of course, even 256-bit AES will eventually be broken. Everything will eventually be broken. But you have to consider that what you're buying for your encryption dollar isn't secrecy, period, but rather secrecy for a period of time. 256-bit AES buys more time.
--
make install -not war
"This requires trusting the OS with your password, ..."
All drives except those with separate keypads trust the OS with the password. Hardware keyloggers will see the password if there is no separate keypad. But that's not the problem. The problem is losing the drive. Hopefully the drive would not be lost in the same place someone is using a key logging device.
Root is required only to install TrueCrypt, not run it.
Most of it sounds great, but "If someone does happen to gain access to your flash drive and they fail to type in the correct password more than 10 times, IronKey will self-destruct, permanently locking out users and wiping out all the data on the drive."
Seems pretty easy for someone to destroy the drive/data if they wanted to. Even accidentally destroy the drive/data.
What if you want to read the data on a computer that doesn't have TrueCrypt installed?
After 3 days without programming, life becomes meaningless
- The Tao of Programming
One of them won't even tell you the full details of the algorithm they use, saying it's 'proprietary' which is another word for "It's secret and it doesn't actually work." in the security industry.
Not only that, but each and every single one of them uses software on my computer to do the encryption. I can get the same thing by using decent drive encryption software like dm-crypt and LUKS. And those are publicly viewable and peer reviewed so they're much more likely to be secure than some stupid random algorithm slapped together by a few techs they paid to do it out of the spare change jar. So that's just totally silly.
I was hoping for something where the encryption was really done in the drive itself and it required me to enter something on a little keypad attached to it in some way in order to decrypt anything. I bet the one that sounds like it might do that just causes the USB device to refuse to talk to the world unless you enter the right thing on the keypad. You could pull that thing apart, attach a few leads and I bet you could read every bit off there (including the PIN) in the clear.
Security isn't that hard to do right. But nobody seems to want to bother. They just want to slap the word on their product, make the user jump through a few hoops and call it good.
Need a Python, C++, Unix, Linux develop
Good write-up, but afaic it only shows that it's difficult to secure new, unformatted drives because you can tell them apart from the rest. If the drive had been wiped by even a single pass and quickformatted, that would probably make things more difficult.
I agree that salts should apply and keys should be different for every sector, like Truecrypt does. But secure drives should be fully overwritten before use, even then. If the cracker has access to your encrypted data over a period of time, you should also use free space cleaning stuff (alcohol works best) because the same scenario applies.
MMO Vampire Role Playing
TrueCrypt can put data into files, rather than using the whole drive. Put TrueCrypt on the drive as well as the file, and run it from there. So what if they know what program you encrypted it with, as long as you have a properly strong password, it won't matter.
But I'd be wary using a secure key on any public PC... you can't trust the PC, and the key could easily be compromised if the machine is. The chain of security is only as strong as it's weakest link.
My blog. Good stuff (when I remember to update it). Read it.
Hint: 72693 transistor hardware AES implementation at one word of plaintext to one word of ciphertext per cycle runs much faster than 4978652193 transistor Pentium 4 decoding and executing an instruction set. Same with a dust-size ARM. Using a simple chip that does 1 round and has to be run 16 times might just get you 1MB/s at 4MHz. The chip can be simplified down to having a lookup table taking 4096 bytes of ROM to do 3 stages of a round, operating on 32-bit words in 4 stages; this will block the circuit doing that operation for 4 cycles though, so you could implement the circuit 4 times (4 lookup tables?) for 1MB/s at 1MHz. Also the final XOR would be 4 32-bit XORs or (better) just one 128-bit XOR.
With the 4xLookup optimization and the 128-bit XOR in a pipeline, this simple chip would do one AES block per 16 cycles. By duplicating the circuit and pipelining, you would do 2 rounds per clock. Get creative with it.
Support my political activism on Patreon.
Any good flash stick should be doing wear leveling in the controller chip so the filesystem you use shouldn't matter as much as it would with directly connected flash chips.