Slashdot Mirror
Lexar JumpDrive Password Scheme Cracked
Saint Aardvark writes "Lexar describes the
JumpDrive Secure as "loaded with software that lets you password-protect
your data. If lost or stolen, you can rest assured that what you've
saved there remains there with 256-bit AES encryption." @stake
has a different take: The password can be observed in memory or
read directly from the device, without evidence of tampering." And
best of all, the punch line: "[The password] is stored in an XOR
encrypted form and can be read directly from the device without any
authentication." That's why I use ROT-13 for my encryption needs."
That's why I use DriveCrypt. I got my version years ago and it's pretty antiquated but it supports up to 1024 bit encryption (granted it makes things relatively slow).
It was Base64 "encryption" (*snicker*)
Javascript + Nintendo DSi = DSiCade
[The password] is stored in an XOR encrypted form and can be read directly from the device without any authentication.
That's not much of a punchline when you realize that XORing something to something unknon (and presumibly unknowable) is unbreakable excryption.
You're not the one missing something. The lexar software engineer who came up with this one obviously never read The Cookoo's Egg or the Linux Source Code- or he'd know how to do a password right (yes, the password does need to be stored someplace, NO, it does not need to be in it's original form, and ideally it should be either hashed beyond mathematical recognition or part of the encryption key for the rest of the data or ideally both).
SJW: a person who perceives an injustice, and while correcting it, commits a greater injustice.
I use MD5. Not one collision ever found in the wild.
On the off chance that this isn't a joke, and you're one of the genii on /. who thinks that MD5 has anything to do with cryptography, let's reiterate:
MD5 is a hashing algorithm. All hashing algorithms are guaranteed to collide, since hashing is the process of reducing an N-fold dataset to an M-fold one, where M<N.
Because of this, hashing is irreversable, and therefor only an idiot would use it for encryption. It's proper purpose is for checksuming.
Tubal-Cain smokes the white owl.
"The password is in XOR'd form? Yeah. That's encryption."
Don't knock XOR. XOR alone can be used for encryption. Infact it is unbreakable when used for encryption. Ever heard of an one time pad. For example free gmail invite to the first person to crack the following:
1111011011001110110101011110011110101010
Dont know what they were doing but dont make fun of XOR in encryption.
The war with islam is a war on the beast
The war on terror is a war for peace
That's AND.
XOR means "exclusive or". A regular "or": if one of the inputs is 1, return 1. An "exclusive or": if one of the inputs is 1, but not both, return 1.
OR:
0101
0011
----
0111
XOR:
0101
0011
----
0110
AND:
0101
0011
----
0001
Because of this, hashing is irreversable, and therefor only an idiot would use it for encryption. It's proper purpose is for checksuming.
MD5 *does* have something to do with cryptography (why else would Schneier devote the whole 14th chapter of Applied Cryptography to "One-way hash functions"), and the reason is simple: it is used to encrypt your *password*, not your data (Lexar was claiming that they use 256-bit AES encryption for the data itself).
For authentication you do not store the password in plaintext, only its MD5 hash, when user enters the password, MD5 of that is computed and compared to the stored MD5 string, if they match -- your user is authenticated. Of course XOR with a "magic number" could be used for the same purposes, but it would be much weaker. Thus, I think that the GP was not a troll and made a valid point: use MD5 to hash your passwords, and preferrable add some salt value to prevent against dictionary attack.
The other questiuon is why did Lexar had to store passwords on the drive at all, one does not need to authenticate users in their scenario (the drive itself is not a self-cointained computer to which a user needs to gain access) -- they could've just asked for the password, convert it to the key used in AES algorithm, decode the data and give the result: if password is incorrect, the decoded data is garbage.
Paul B.
After being put on hold for over twenty minutes, I finally spoke with a man named Henry who said that he has never heard that JumpDrive had a security problem (even after I confronted him with the advisory from @Stake), and did not know that @Stake was trying to contact them for over a month. He was quite shocked but promised to check out /. and @Stake to verify the claim.
The ostrich finally wakes up.
When I bought mine, it came down to a basic business decision:
The decision didn't require much thought.
That is until the drive mysteriously stopped working at all after about 6 months.
Could be the luck of the draw. I've had mine for over a year and it's still going strong.
You sly dog: you got me monologuing! - Syndrome
Not if the key was exactly as long as the message. In that case, we'd have a system equivalent to a one-time pad (i.e., unbreakable) so long as the key was kept secure.
In this case, it might be feasible to XOR an 8-character password with 8 random bytes (those 8 random bytes would be the key). The problem isn't the XOR operation. The problem is maintaining the security of the key itself.
Statistical attacks can only work when there is a lot of ciphertext, AND the key is significantly shorter than the message.
I needed a way to make a "secure zone" similar to what Lexar was advertising - a place where I could drop files and have them automatically protected. After doing a fair amount of research, I decided to use PGPDisk. It allows you to create a PGP-encrypted file on any device (hard drive, CD, USB key, etc) which "expands" into a virtual drive (e.g. "C:\Private\SecretStuff.dsk" becomes a new "Removable drive G:" in Windows once you enter the password). Anything you drop into the virtual drive becomes encrypted. It uses 128-bit symmetric CAST algorithm, which is plenty strong enough for anything I'd need. (I believe the newest versions may also have a Twofish algorithm option). PGPdisk virtual drives can be up to 4Gig on a FAT32 machine, or unlimited size under NTFS.
You can check out the commercial version at http://www.pgp.com/, but I would also seriously consider PGPckt 6.58, a forked and free version that works just fine under WinXP (and previous versions of Windows). That's the version I've been using.
This kind of thing just burns me up. Clueless companies hire clueless developers who think they can make software or hardware relatively secure by mearly applying encryption in whatever way they think is convenient. Never mind the plain-text password behind the curtain. Never mind that xor is equivalent to plain text (Lexor). Never mind that supporting multiple decription keys reduces the effective key length (DVD). Never mind that if you somehow store the decryption keys in a way that the software retreive (DVD again) that anyone can extract them. Never mind that storing a strongly-encoded password along with a weakly-encoded one buys you nothing (Microsoft). Never mind that encryption can't prevent copying (DRM). Never mind that this list can go on forever...
I own a JumpDrive Secure. Don't laugh; I only got it because Wally World didn't have the regular 256MB one. I plugged it in and the first thing it did was install their security software *without asking me*. Yes, Windows XP. Yes, I had turned AutoRun off on my CD. No, I have no idea how to disable AutoRun on a device that has never been plugged in before. Grrrr.
What did I do? I used Linux to reformat the JumpDrive then uninstalled the software it added without my permission. Now I have a perfectly usable device. (This was 4 months ago)
What's wrong with XOR? Example. I've encrypted a short message of ten bytes, by XORing it with a random sequence of ten bytes. Here's the ciphertext:
26 6B F1 2C 2E 1E 71 12 A9 68
Since XOR encryption is so weak, this should be no sweat to crack, right?
Unfortunately, you'll never be able to crack it, because you don't know what the key was. Even if you found a key that would decrypt this sequence to a meaningful series of bytes, you still don't know if that's the correct answer. More than one valid message can fit into 10 bytes, and you have no way of telling which one of those valid messages was the one I intended. It is literally unbreakable. This is called a one-time pad. Now, if I used the same key repeatedly to encrypt lots and lots of data, you could apply statistical techniques to attack it. But the weakness is not inherent in the XOR operation.
The weakness is in the key security. If you cannot protect the key properly, not even the most complicated cipher in the world can help you.
XOR is a perfectly legitimate method for combining the key, or key-generated data, with the plaintext.
So what we usually do in these situations is store the main key in the device itself, encrypted with a smaller key which can be generated from a user-selected password. Why not just use the password-generated key as your main key? Because easily-remembered passwords don't have enough entropy to generate a key strong enough to protect megabytes of data, but they are good enough to protect something small like an encryption key.
Usually such schemes fail when the encryption of the main key is too weak for whatever reason, such that the main key can be recovered without knowing the password. It is indeed bizarre that they would store the password itself on the device in any form, though as we all know the world is full of crappy software "designed" by idiots.
Instead of hashing the PASSWORD, you can hash the DATA. If you decrypt with the wrong key, the hash of the corrupted data will certainly not match the corrupted hash of the original data. Maybe that isn't clear. Let me try again.
Suppose you have data D and the hash of that data, H(D). Now, encrypt them with key A:
Ciphertext = Encrypt_A(D . H(D))
Then ,decrypt with incorrect key B:
Plaintext_Incorrect = Decrypt_B(Ciphertext) = C . GarbageHash.
Now, since the incorrect key will produce garbage instead of meaningful data, we know that H(C) != GarbageHash if the key is incorrect. Thus, you can verify whether the key was correct without storing the key, or a hash of the key, anywhere.
Oh really?
------------------
#!/usr/bin/perl -w
use strict;
use Digest::MD5 qw(md5_hex);
# Create a stream of bytes from hex.
my $bytes1 = map {chr(hex($_))} qw(
d1 31 dd 02 c5 e6 ee c4 69 3d 9a 06 98 af f9 5c
2f ca b5 87 12 46 7e ab 40 04 58 3e b8 fb 7f 89
55 ad 34 06 09 f4 b3 02 83 e4 88 83 25 71 41 5a
08 51 25 e8 f7 cd c9 9f d9 1d bd f2 80 37 3c 5b
d8 82 3e 31 56 34 8f 5b ae 6d ac d4 36 c9 19 c6
dd 53 e2 b4 87 da 03 fd 02 39 63 06 d2 48 cd a0
e9 9f 33 42 0f 57 7e e8 ce 54 b6 70 80 a8 0d 1e
c6 98 21 bc b6 a8 83 93 96 f9 65 2b 6f f7 2a 70
);
# Create a second stream of bytes from hex.
my $bytes2 = map {chr(hex($_))} qw(
d1 31 dd 02 c5 e6 ee c4 69 3d 9a 06 98 af f9 5c
2f ca b5 07 12 46 7e ab 40 04 58 3e b8 fb 7f 89
55 ad 34 06 09 f4 b3 02 83 e4 88 83 25 f1 41 5a
08 51 25 e8 f7 cd c9 9f d9 1d bd 72 80 37 3c 5b
d8 82 3e 31 56 34 8f 5b ae 6d ac d4 36 c9 19 c6
dd 53 e2 34 87 da 03 fd 02 39 63 06 d2 48 cd a0
e9 9f 33 42 0f 57 7e e8 ce 54 b6 70 80 28 0d 1e
c6 98 21 bc b6 a8 83 93 96 f9 65 ab 6f f7 2a 70
);
# Print MD5 hashes
print md5_hex($bytes1), "\n";
print md5_hex($bytes2), "\n";
------------------
What do I win?
did you know you can open a bicycle lock with a bick pen?
But the key cannot be kept secure, as I need only enter a known password on a known device, get the "encrypted" text and XOR it against my original password. Since XOR is symetrical, A^B = B^A, then we are guaranteed that (A^B)^A = B, and *poof* we derive the magic password.
A single XOR when I can generate more than one "encrypted" text is no security at all.
One-Time pad means ONE-TIME ! If you use it twice, the security becomes exactly Zero.
Jeff Naujok
Life, the Universe, and Everything... in my image.
Your example works, because your key and plain text are the same length. I think the point is that all Jumpdrives either use the same key, or use one short enough to apply the above to, etc. Short of including (and inventing) a one time pad generator that is truly random, and with the availability of other password encryption methods, why use XOR?
Yes, but the problem is using the pad again. Nothing to do with XOR. Notice that any key-combining operation must be a bijective operation (i.e., "one to one, and onto"). Thus, at least theoretically, you can determine the key by comparing various plain/ciphertext pairs, regardless of which key-combining operation was chosen. Yes, XOR makes this slightly easier. So?
XOR is not the problem. The fact that the key is reused, and is most likely much shorter than the plaintext, is the problem.
- Format your pen drive to MS-DOS
- Create an encrypted, password protected disk image roughly the size of your pen drive (also in MS-DOS format)
- Store the disk image on your pen drive
The reason I recommend using MS-DOS format for both the disk and disk image is two-fold. First off, you can use the extra space not taken up by the disk image to grab files from a PC (since both the Mac and PC can read the MS-DOS file system), and because if you use HFS+, the Mac will store all sorts of file extras on the disk, giving you much less usable space (same reason you can't get the full 654 or 700 MB when you burn an HFS+ CD).I would also recommend storing a fake
Ack!
Truecrypt (mirror 1 [freewebtown.com], mirror 2) does the same as PGPdisk but is open-source and seems to still be actively developed, unlike PGP658ckt. It also doesn't have the drive size limitations of some competing commercial products.
Damien
"Because of this, hashing is irreversable, and therefor only an idiot would use it for encryption"
... repeat until you get to Xn (n being the length of your message)
Count me an idiot then. I should mention why:
(a) take your key. MD5 it. Store this as X1
(b) Take X1. MD5 it. Store this as X2
(c)
(d) For each 64-byte segment of your message, XOR it with one of the numbers in the sequence you just generated
To decrypt the message, do exactly the same thing.
Actually, CHR$(13)+CHR$(10) is used to terminate lines of text (carriage return/linefeed), not character strings.
Passwords can simply be stored by using a simple encryption method and encrypting the password, using the password itself as the key. That way, the only way to read the password to verify it is if you have the password. Works pretty well in the passwd/shadow file...
There isn't much excuse for this other than "we never thought anyone would try that", but then if that's the thinking, why do we even need security products or encryption?
CAn'T CompreHend SARcaSm?
AFAIK, all you actually need is NAND to make every other operation.
XOR is a perfectly legitimate method for combining the key, or key-generated data, with the plaintext.
If you're using the key, it has to be an OTP. As soon as you repeat your message using the same key, your cipher's busted.
In the case of key-generated data, that's pretty much what a stream cipher does. But then you don't refer to the cipher as XOR, you refer to it as a stream cipher. You could just as easily use mod-256 addition as XOR if you wanted; the point of the cipher isn't the combination technique, but the stream generator.
The grandparent was referring to XOR as the only cipher method. In the case of an OTP (like you used), it's okay, but that's the only case. This is clearly not an OTP we're dealing with here.
What's worse (and aside from your point), it's open to a chosen-plaintext attack: buy another JumpDrive, set the password, observe. A chosen-plaintext attack can reveal the key of a simple XOR cipher in a single attack (assuming you can ascertain the maximum key length, which is probably something that the password entry dialog gives you). Even without chosen-plaintext, it doesn't take many samples to reveal the key of an XOR cipher, but with chosen-plaintext it's just too trivial.
would be jetico's bestcrypt.
http://www.jetico.com/
supports twofish and blowfish too and even GOST too, all the way up to 446bit of keylength.
a must have for any paranoid nut
Online backup with Mozy, sounds like Ozzie, but more!
You need to read more about shiva. Shiva is not a destroyer. Shiva disolves so that creation can happen. Shiva represents creation as well as dissolution. If you want to reach enlightenment it is through shiva. Shiva is nothing close to the christian belief of devil which is naught but a fallen angel.
Only one addition, since from what I know, your post is fundamentally right. I have a Hindu friend, and he got upset when I refered to Shiva as the Hindu equivalent to the devil while trying to make sense of his religion. He explained it this way: Shiva is usually portrayed as benevolent. Old buildings decay to make way for new ones, old people die to clear the way for the next generation, old animals die so they don't slow the herd down, old civilizations fall as new ones are created, and so forth. If not for Shiva, the world would become choked with the old and sick, and the world would be a much worse place. When things are particularly off course, there are large epochs of destruction (Ranging from war to famine to cataclysmic floods, fires, and earthquakes, and that this is also used to reconsile scientific observations like mass extinctions with the religion). There's also a belief (which he says is obsolete and not held as seriously as it once was by many Hindus, at least those living in the western world) that the entire cosmos is periodically destroyed when a great many things get too far gone to be fixed even by global-level catastrophe, and Brama starts creation over anew.
Also, another thing he pointed out is that the devil (in Judeo-Christian theology) is not a destroyer in himself, only a temptor who can lead humans to destroy, but does not destroy himself. God orchestrates the end of the world in Revelation, and is also caused all the destructive events in the Bible. He rattled off several names (many of which sounded like names for D&D characters to me) for minor Hindu gods who are more comparable to the devil, since they manipulate living beings into distrupting the normal order of things.
He is. Look closer. There are several differences, e.g.
"bd 72 80" vs "bd f2 80"
and "80 a8 0d" vs "80 28 0d"
MD5 is dead.
Actually, in the Christian chronology, the devil is not a destroyer.
In a parable by Jesus in the Gospel of John, chapter 10, the devil was compared to a thief, who "...only come to steal, kill, and destroy..." (John 10:10).