Lexar JumpDrive Password Scheme Cracked 565
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."
Even worse... (Score:5, Insightful)
Re:Even worse... (Score:5, Funny)
stupid response #1 (Score:3, Funny)
FLASH: One Time Pad CRACKED (Score:5, Funny)
Since no one else is stupid enough to use that pad, it's a one time pad.
Another milestone in encryption technology - One time Pad CRACKED!
Emergency patch: Now they use the Pad "000000000...."
Re:Even worse... (Score:4, Funny)
I couldn't remember what (Score:5, Funny)
I was always forgetting important things, like the meaning of the word "redundant." But thanks to the Joe Johnson memory system, I can now remember things like the meaning of the word "redundant." Thanks, Jack!
Copyright 2004, Jake Johannson Memory systems.
Re:Bleh (Score:3, Insightful)
Also, if you only work with Win2K/XP boxes, there might be a
DMCA (Score:4, Interesting)
Dude, (Score:5, Funny)
The #1 DMCA Rule (Score:5, Funny)
The number one rule of talking about the DMCA and archiving the results, encrypted, on a Lexar JumpDrive.
You do NOT talk about DMCA and archive the results, encrypted, on a Lexar Jumpdrive!
Re:The #1 DMCA Rule (Score:5, Funny)
Tin-foil hats work, I tell you!
Somebody call the police (Score:5, Funny)
Re:The #1 DMCA Rule (Score:3, Funny)
Indeed they do. When the government's orbiting atomic-powered microwave mind-beam satellites are activated to make sure the election goes off without a hitch this time, that tinfoil crisper up there will help turn your head a nice golden brown. Important safety tip: tinfoil hats are not for use in a conventional oven.
Re:The #1 DMCA Rule (Score:3, Funny)
Re:Dude, (Score:5, Funny)
Re:DMCA (Score:3, Funny)
Re:DMCA (Score:5, Insightful)
Re:DMCA (Score:3, Insightful)
I don't think so. The DMCA pertains to the encryption of copyrighted works. What's the "works" in this case? The "encryption" is on someones personal documents, not Lexar code or works.
This is just encryption here, not "encrypted works". Circumventing for research is legal under the DMCA, but I'm pretty sure that it doesn't apply here.
And it only took the guys at distributed.net (Score:5, Funny)
An embarassment of security. (Score:5, Insightful)
Couldn't the software or driver have stored the password in a MD5 or SHA1 form, and still present a valid authentication mechanism for end users?
From the article:
Vendor Response:
08-05-2004 Vendor contacted via email to support@lexarmedia.com
No response.
08-12-2004 Vendor contacted again via email to support, sales
Public Relations, Investor Relations, and general
inquiry email addresses.
08-12-2004 Automated response from support received
09-13-2004 No further response from vendor, advisory released
Vendor has not acknowledged issue or produced a fix.
This is a pretty embarassing non-response.
The product is only about 5 or 6 months old, and the password was just sitting there. AES is a perfectly fine standard for encryption, but this is an embarassing implementation. Thankfully, I don't know anyone who owns this.
Re:An embarassment of security. (Score:2, Insightful)
Re:An embarassment of security. (Score:5, Funny)
-Peter
Re:An embarassment of security. (Score:5, Funny)
What a waste of valuable CPU cycles! Here's a speedup that does the same thing much faster:That should run much faster -- standard library functions are always well-optimized.
Just doing my part for data security.
steveha
Re:An embarassment of security. (Score:5, Funny)
That joke sure was cryptic.
I tried that... (Score:4, Funny)
Re:An embarassment of security. (Score:3, Funny)
I think they call that a one-time pad.
"One-time" 'cause that's how many times you'll try it.
Re:An embarassment of security. (Score:5, Insightful)
Couldn't the software or driver have stored the password in a MD5 or SHA1 form, and still present a valid authentication mechanism for end users?
Aside from storing the password in XOR'd form, the software checking the password is flawed. It unencrypts the password first, then compared the password entered. Rather then encrypting the password entered and comparing it to the device?
There may even be better ways than that. I'm not a cryptography person, but that's the first thing that comes to mind.
Re:An embarassment of security. (Score:4, Insightful)
That would not be any better than it is now.
The right way to do this would be to use the password to generate an encryption key and encrypt the data with it. Then, the only possible vulnerabilities are the password itself and various known-plaintext attacks.
Re:An embarassment of security. (Score:3, Interesting)
No, there's one more... the user forgetting that password. Not exactly a compromise situation, but a support nightmare.
Re:An embarassment of security. (Score:5, Insightful)
Re:An embarassment of security. (Score:3, Insightful)
Makes me think there si NO encryption on any of the data... Just a funny driver hack that stops you from reading a certian sector of the drive.
Re:An embarassment of security. (Score:3, Insightful)
If you're carrying around secure documents/files on a jumpdrive using only the included encryption scheme, you may need a lobotomy. I took one look at the security program that came on the drive, and threw it out. I knew I'd never need it. It wasn't a program that looked like it reeked of security, either. I'm acutally surprized this is the first report of the JumpDrive being cracked.
Since there are dozens of USB drives on the market, and the're
Lexar is not alone in bad cryptography (Score:4, Interesting)
I spent a little while analyzing the "CruzerLock" software that came with my Cruzer Mini USB drive. It appears to be using a 64 bit block cypher (perhaps DES) which pretty much rules out any of the more modern encryption algorithms.
Its biggest readily apparent weakness is that the encryption algorithm is running in ECB mode. If you have a file containing AAAAAAAAAAAAAAAAAAAAAAAA it will encrypt to an 8-byte repeating block on the drive, like this: 123456781234567812345678 When I changed that to AAAAAAAAbbbbbbbbAAAAAAAA I saw the following encoding: 12345678abcdefgh12345678. That indicates Electronic Code Book. If I learn what your first block means, I know the third block means exactly the same data. (Please note that these are just example values with nice visual properties, and not the exact values I saw!)
Also, the encryption is the same from file to file. AAAAAAAA encoded in one file produces exactly the same results as AAAAAAAA encoded in another. So the IV for the encryption routine is fixed as well.
At least XORing blocks of encrypted binary nulls with two different keys didn't quickly reveal any obvious common bits, nor did encrypting two successive blocks that differed only by a single bit of plaintext. That means it's at least more than a plain old 8-byte XOR cypher using a folded password.
I figure if I can find all those holes in an hour of poking around with a hex tool, I know they didn't actually hire any cryptographers to produce the software. All the alarm bells have already gone off, and I never even stepped into it with a debugger to learn how they fold your password into a key, or what the IV was, or what the encryption algorithm itself was.
Re:An embarassment of security. (Score:5, Interesting)
I do, and I keep fairly sensitive information on it (in fact, I bought it in order to keep that information handy but secure). But I don't use Lexar's software--never even occured to me to try to use it, as I want to access it in Solaris and Linux. I use GPG; downloaded a GPG for Windows and put it right on the key so that I can use it in any Windows machine as well.
Chris Mattern
Re:An embarassment of security. (Score:3, Insightful)
One Time Pads are as close to a perfect means as is out there. This, well, isn't.
Re:An embarassment of security. (Score:3, Insightful)
However, using a small key and XOR-ing it periodically with the data is very insecure and can be broken easily.
When one wants security coupled with a (relatively) small, fixed-length, reusable key, block ciphers such as AES [wikipedia.org]
Re:An embarassment of security. (Score:3, Funny)
Cue::Cat (Score:5, Funny)
Re:Cue::Cat (Score:5, Informative)
Re:Cue::Cat (Score:5, Funny)
It's a "feature" (Score:5, Funny)
Not much detail? (Score:4, Interesting)
Re:Not much detail? (Score:4, Funny)
You can find the "what with" part by simply XORing again with you key. So to find out what the magic string is, simply buy one of these devices, encrypt some data to it, then locate the encrypted key and XOR you original password with the "encrypted" version.
Doing this with your own device means you are not violating DMCA - trying this out with someone elses device will subject you to the possibility of 57 consecutive life sentences.
Re:Not much detail? (Score:4, Insightful)
xor + small_key = cypher for dummies, it's an old standard for those who don't care about security.
Re:Almost... (Score:5, Informative)
OR:
0101
0011
----
0111
XOR:
0101
0011
----
0110
AND:
0101
0011
----
0001
OK, don't kill ALL the lawyers yet (Score:3, Interesting)
Seriously (Score:3, Funny)
You will be legally liable for the legal consequences of any attempt to break through this advanced encryption technology.
Drive Crypt (Score:5, Informative)
Re:Drive Crypt (Score:3, Informative)
Nevertheless, I've used CrossCryptGUI 0.75 for some months now with a 20GB encrypted volume, and haven't had a problem (though backups are essential in case of corruption). As far as I'm
Re:Drive Crypt (Score:3, Interesting)
Inevitable? (Score:5, Insightful)
I mean, if you have the jumprdrive in your possession it's only a matter of time before you find a weakness to exploit, right?
Re:Inevitable? (Score:4, Interesting)
That's not true. If my harddrive contains an encrypted filesystem, it does a "hacker" no good to steal my PC. He's mathmatically less likely to brute force that encryption than if he sniffed encypted email or SSL sessions.
If the hacker installs a keylogger, and I don't detect the intrusion when I return, then a second trip to physical access could break the security... but getting his hands on it once won't help.
That famous saying only applies if the machine gets some ongoing use after the hacker has physical access. (Thus it demonstrates a core flaw of DRM, etc)
I mean, if you have the jumprdrive in your possession it's only a matter of time before you find a weakness to exploit, right?
No. There is no reason a device like this needs to store the password at all.
Properly, it shouldn't be a "password" at all, but a decryption-key you type before accessing the files. Type in the wrong key, and the files appear scrambled.
Re:Inevitable? (Score:3, Interesting)
I mean, if you have the jumprdrive in your possession it's only a matter of time before you find a weakness to exploit, right?
Nope. The jumpdrive is just a data storage device and if it only contains encrypted data, an attacker can only read the (probably useless) encrypted data it stores. You can't decrypt it unless you have the decry
Re:Inevitable? (Score:4, Interesting)
No. It is absolutely possible to implement a symmetric encryption scheme that does not expose any details of the password and requires the password to be correct in order to decrypt the data.
For instance, instead of saving an xored version of the password (I'm assuming you need the cleartext of the password to run through your decryption algorithm), you can save a hash of the password. Then when the user enters their password, you compare hashes for correctness, and if there's a match, you use the cleartext they just entered.
Assuming all your math is done right and you're using strong crypto, there's nothing anyone could do to decrypt that data without a) knowing the password or b) having more computing power at their disposal than is currently available to any private citizen or group.
wow (Score:3, Interesting)
No way am I buying anything they make again.
I'm fuzzy on something... (Score:5, Insightful)
Is this some sort of 'encrypted session key' thing where one long, secure password decrypts another shorted one that's used to do the dirty work? Is it stored for key recovery by tech support droids?
Why store the password? Is this just the worst implementation in the whole world or am I missing something?
Re:I'm fuzzy on something... (Score:5, Insightful)
One word: support.
Ideally, they should not be storing the password on the disk itself at all for it to be a secure drive. But I've seen a lot of these decisions that seem boneheaded because a *lot* of people will forget their passwords and come back *demanding* that you decrypt their shit. If this is someone that even remotely knows the CEO of the company or somebody higher up and if you try to explain them one-way math functions, you will be getting the pink slip in no time.
Although what these guys did is unpardonable. I mean XOR? Jeez.
Re:I'm fuzzy on something... (Score:5, Informative)
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.
Re:I'm fuzzy on something... (Score:3, Informative)
Re:I'm fuzzy on something... (Score:4, Informative)
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.
Re:I'm fuzzy on something... (Score:3, Insightful)
But where do you store this key? do you XOR it with something else? (and what do you do with that something else?) If you use any other more sophisticated method to hide it, why not just use that for the password in the first place? Also, in this case you alredy know what the password is (after all, it's _your_ JumpDrive, whatever that is), so you can xor it and get the 'secret key'. With that, it should be easy to f
Re:I'm fuzzy on something... (Score:3, Insightful)
But that question has nothing to do with XOR, does it?
My point was simply that XOR is a key-combining operation. The fact that an algorithm uses XOR does not imply insecurity. There are, of course, plenty of bone-headed possible implementations. But none of those problems are the fault of the XOR operation.
Re:I'm fuzzy on something... (Score:3, Informative)
Re:I'm fuzzy on something... (Score:3, Informative)
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 . Ga
Re:I'm fuzzy on something... (Score:3, Insightful)
Either they're horribly naive about this stuff, and could/should have done a better job;
Or the constraints of the device wouldn't let (How can this be on a multi-M
Re:I'm fuzzy on something... (Score:3, Informative)
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?
Re:I'm fuzzy on something... (Score:5, Informative)
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.
This shows once again... (Score:5, Insightful)
Man, that's scary... (Score:3, Interesting)
But seriously, I own one of these... In fact, they're pretty popular in my area just because their cheap and sold at Wal-Mart... I don't personally use the password protection because I always felt it was just an extra step and I didn't really need that much security on my Flash Drive anyways...
(It's not like I was storing all of my server's passwords on it or anything..... Honest...)
Thank you @stake and people like you for making sure products are as secure as they say they are...
My password is twice as secure as yours!!! (Score:5, Funny)
-
Re:My password is twice as secure as yours!!! (Score:3, Funny)
I don't advise that. All crypto experts know you should do something unexpected to throw the analysts, like performing extra rounds or something.
I use 3 rounds of ROT-8 followed by one of ROT-2. They'll never work that one out.
Security through obscurity sucks... (Score:3, Funny)
*holds down shift* (Score:3, Funny)
ROT13? (Score:3, Funny)
Tried contacting them... (Score:5, Interesting)
Sounds awfully like a head-in-the-sand approach to security to me.
Re:Tried contacting them... (Score:3, Funny)
If you would try that long enough it would probably work. Any data that was in the brain is probably irrecoverable.
XOR Encryption is NOT unbreakable (Score:3, Funny)
I've seen a number of posts stating the XOR is unbreakable. Hopefully they're just joking and didn't get modded as such, because I've read in several places that XOR sucks. A quick Google revealed the following.
Hack-FAQ [linuxsecurity.com]
And I quote: XOR encryption is trivially simply to implement and equally trivial to break. XOR encryption should not be utilized for any data which you would want to protect.
I could go grab my Applied Cryptography book and make sure, but it's out of arms reach right now.
UPDATE from conversation with Lexar... (Score:5, Informative)
The ostrich finally wakes up.
A better way to make "secure zones" (Score:5, Informative)
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/ [pgp.com], but I would also seriously consider PGPckt 6.58 [zedz.net], a forked and free version that works just fine under WinXP (and previous versions of Windows). That's the version I've been using.
Re:A better way to make "secure zones" (Score:3, Insightful)
You could partition the USB drive. Partition #1 is normal (FAT-12) and partition #2 is mounted via loop-aes.
Assuming you use Linux or BSD and not Windows.
The fun part is if you partition 50%/50%, and the drive doesn't have the size printed on it, when a Windows person installs it they will never even see partition #2 unless they go into a partition editor. All they get is an automounted partition #1 -- which is the proper size for the little brother to the model you're using.
Security through obsc
(fixed) A better solution (Score:4, Informative)
Damien
Another good one.. (Score:3, Informative)
http://www.jetico.com/ [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
Tough.. (Score:3, Interesting)
Grrrr (Score:4, Informative)
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)
This reminds me of an "un-pickable" lock my .... (Score:5, Interesting)
It had no keyhole, just a bunch of magnectic "reeds" that would line up when a special magnetic key was put along side of it. My dad had just purchased it that day and was explaining to me how it worked. I asked, "couldn't you just shake it until the reeds lined up?". He tosses the lock to me and says, "here...try it then". I shook the lock for a couple of seconds and, sure enough, it popped right open.
my dad was pretty grumpy for the rest of the day...
Re:This reminds me of an "un-pickable" lock my ... (Score:5, Informative)
ROT-13? (Score:4, Funny)
Bu abrf! Yrkne = shknerq! [rot13.com]
Refunds? (Score:3, Interesting)
As one poster commented, "Why not just use ROT-13 to hide the password?"
If Lexar replies, I'll post a follow up. If they don't, then it is off to the BBB to get things fixed.
Mac Users (Score:3, Informative)
- 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
I didn't buy it for the security (Score:3, Insightful)
- Good cost per MB
- Fast
- Great rebate offer at the time
- DURABLE! This thing looks a little bulky, but it's rock solid. Thick plastic, really solid. Unlike any other I've seen so far.
I never used the security stuff. IMHO not worth it. But having such a durable, fast, cheap device was more than worth it to me.
I don't regret my purchase. It's a solid product. I'd still recommend it.
Re:For my encryption needs (Score:5, Informative)
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.
Not so fast! (Score:5, Informative)
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.
Re:Not so fast! (Score:4, Informative)
Reading your post is like one of those "How Many Mistakes Are In This Picture" things you see in Highlights.
The salt doesn't have anything to with protecting against dictionary attacks,
The salt is exactly to prevent against dictionary attacks. A dictionary attack (using the term old-school) is where I prepare, in advance, a dictionary of passwords and their hash values, indexed by the latter. Then, when you're making your attack, you look up the hashed password and voila! you know the password. In a world without salts, I expect that many security folks would be able to recognize many common passwords' hash values on sight.
it is used to make the algorithm computationaly harder to break.
The salt does nothing (or rather an insignificant amount) to make the computation harder. It's specifically used to prevent a dictionary attack.
The salt is simply the first two characters in your hash,
The salt is a randomly-generated sequence. It's stored as the first two characters of the encrypted password in traditional crypt() passwords, and is followed by the hash. But it's not the first two characters of the hash.
all of the subsequent characters are based from the salt.
They're based off of both the salt and the password. Your post makes it sound like the password is hashed, the first two characters of the hash are the salt, and the rest of the password entry are generated from that. This is not at all what happens.
The salt is generated randomly (from the time of day, number of processes running, etc), to get 12 bits of randomness (note that the salt is isomorphic with the space [A-Za-z0-9/.]{2}). The password is hashed using a DES, with the password as the key and a string of 0s as the plaintext. Partway through the DES operation (specifically, after the E-box), some of the bits are swapped based on the salt.
After DES outputs the hash value (its ciphertext), it is appended to the salt. This concatenated value is stored in the passwd field of your passwd file. So the salt is the first two characters of that output, but it's not the first two characters of the hash. It's used to perturb the hash in one of 2^12 ways.
Note that the specifics I gave (length of salt, use of DES) only applies to traditional Unix passwords. Most modern Unixes use a different hash scheme by default, such as MD5. The role of the salt still applies: it's used to perturb the hash function to prevent dictionary attacks. There are differences in how it's stored and how it perturbs the hash.
For further study, I recommend reading Password Security: A Case History [bell-labs.com] by Robert Morris and Ken Thompson.
Snuffle (Score:5, Interesting)
Because of this, hashing is irreversable, and therefor only an idiot would use it for encryption. It's proper purpose is for checksuming.
Try telling that to Daniel Bernstein. His "Snuffle" code converts any hash into a cipher. To put it shorter: sampling the output of a well-designed hashing algorithm after every n bytes produces a suitably random bitstream; XORing that against the message produces a stream cipher.
Re:For my encryption needs (Score:3, Interesting)
It also works for small data units, like e.g. keys. Hash a (sufficiently difficult) password and xor the result of the hash with the (symetric) key and presto.
Re:For my encryption needs (Score:5, Informative)
------------------
#!/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?
Re:XOR is not the problem (Score:3, Informative)
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.
Statistica
Re:XOR is not the problem (Score:3, Informative)
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 reus
Re:the punchline (Score:5, Informative)
If A XOR B = C , then A XOR C = B and B XOR C = A.
So if MYPASSWD XOR SECRET = ENCRYPTEDCODE, and I know both MYPASSWD and ENCRYPTEDCODE, then I can find SECRET.
I don't know if all of the drives have the same SECRET or not, but, having determined what SECRET is on my drive, I can give the drive to you, or I can try my SECRET on another drive and see if it works.
--hymie!
"Milk Experiment" (Score:3, Funny)
Some guy was living with a bunch of others and always had a problem with them drinking up his milk. So one day he simply wrote "Milk Experiment" in big letters on the carton and never had another issue.