From: pgut1@cs.aukuni.ac.nz (Peter Gutmann) Subject: Norton's InDiskreet Date: Thu, 11 Nov 1993 12:37:43 GMT People have mentioned Norton's [In]Diskreet here recently and I thought I'd have a look at it to see how good (or bad) its DES implementation really is (I didn't bother with the "fast, proprietary method", by all indications it's worthless). As the summary line in the header says, don't throw away your copy of PGP yet. For those of you who have a copy and would like a quick look at the sort of security you're buying, try the following: - Create a test file, I used 128 zeroes. - Encrypt it with the password 'xxxxxx' - Decrypt it with the password 'xxxxxx' - Decrypt it with the password 'xxxxyy' - Decrypt it with the password 'yyyyxx' The DES routines themselves seem to be taken from a DES library rather than being written by Symantec/Norton. Symantec provide the front-end, and Peter Norton provides the picture of himself wearing a pastel shirt and silly smirk for the cover of the box. This seemed to be a good indication - perhaps the DES implementation was by someone vaguely competent, which meant Symantec would have little chance of screwing it up. Unfortunately, as the above test shows, it isn't. The front-end gets a password in the range of 6..40 characters, and converts it to all-uppercase (red neon sign lights up and flashes "MISTAKE. MISTAKE. MISTAKE"). Then it packs it into a struct along with a collection of other information and passes it to the DES library. The DES library then takes the password and reduces it to 64 bits by cyclically xor-ing in the full-length password into an 8-byte buffer initially set to all zeroes, ie: for( index = 0; *password; index++ ) buffer[ index % 8 ] = *password++; Finally, the top 32 bits of this buffer is passed to the key schedule routines and some of it used for the key schedule (this is what the sample en/decryption shows up). They seemed to be doing a DES key schedule, but I didn't bother verifying its correctness - there didn't seem much point really. Note that the first mistake was made by the front-end, but the second two were made in the DES library itself, meaning that both parts are incompetently implemented. Oh well, at least Peter Norton's contribution to the whole affair doesn't weaken it's security. Usually I check DES implementations against the NBS test data, but I couldn't be bothered ripping out the code, and the key handling provides holes big enough to drive a bus through anyway. Note that it doesn't even use a proper 56-bit key as per the FIPS docs (although, admittedly, it's in good company there), or check for the weak keys which are possible with the key setup they're using. The encryption itself uses DES in CBC mode with a fixed IV. This means that, in combination with the tiny key space, it's possible to create a precomputed collection of plaintext/ciphertext pairs and "break" most encrypted files by reading the results out of a table. Since the whole-disk encryption always begins with a fixed DOS FAT (file allocation table), this instant decryption is entirely feasible. When encrypting files, [In]Diskreet stores the file name, date, and various other pieces of information at the start of the data and a key check sequence at the end, allowing a quick and easy check for correct passwords. In summary, there may be a possibly-correct DES implementation in there somewhere, but it doesn't help much. [In]Diskreet will stop a casual browser, but won't give you any protection at all against any serious attack. ObPropaganda: There should be an encrypting filesystem offering *real* security available within a few weeks. The initial version will be for DOS only, and will provide sector-level encryption for entire disks. I just need to test it a bit more, I'll call for beta-testers here once it's ready. Peter. -- pgut1@cs.aukuni.ac.nz||p_gutmann@cs.aukuni.ac.nz||gutmann_p@kosmos.wcc.govt.nz peterg@kcbbs.gen.nz||peter@nacjack.gen.nz||peter@phlarnschlorpht.nacjack.gen.nz (In order of preference - one of 'em's bound to work) -- DOS 6 - Double your disk space: delete Windoze -- From: kocherp@leland.Stanford.EDU (Paul Carl Kocher) Subject: Norton Diskreet (Security overview) Date: Thu, 18 Nov 93 23:43:32 GMT The signal-to-noise ratio here has made me mostly stop reading sci.crypt, but I saw this and thought I'd contribute the results of some work I did with the program a year or so ago. Hopefully there'll be a moderated group soon so I can come back (hint hint)...! First off, the "propriatary" algorithm is fairly easy to crytanalyze. It uses the DES key schedule and leaks information badly. Consequently it's quite easy to break. Fine for stopping casual snoopers, but definitely not something I'd use on important data. (I'm afraid my code is not available. See note at the end.) The DES function orders the output bits in a nonstandard way (they do the permutation differently from everyone else), but otherwise the algorithm is correct. CBC mode is used, with a new initialization vector every so often (I forget the block length). The IVs repeat, so if you encrypt a few megs of zeros, the output will repeat. The key initialization function is a very, very, very bad problem, though. The function is actually worse than people have been suggesting, since it's case insensitive and the parity bit is the least significant bit. The algorithm is: unsigned char DESKey[8] = { 0,0,0,0,0,0,0,0 }; for (n = 0; n < password_length; n++) DESKey[n % 8] ^= toupper(password[n]); /* toupper converts lowercase ascii to uppercase */ /* (n % 8) equals (n mod 8) */ To see just how bad this is, consider a password containing just letters that is known to be 16 bytes long. This *should* give an effective keyspace significantly above that of the DES key (26^16 = 4.3 x 10^22, while the 56-bit DES key has 2^56 = 7.2 x 10^16 possibilities). However for this password, the keyspace is actually only 32 bits (4 billion passwords): - The total keyspace in DESKey is 64 bits. - The most significant bit (value 128) is zero in each password byte, and consequently is zero in each byte the DES key, reducing the keyspace to 56 bits. - The bit with value 64 is set to 1 for all capital letters, lowering the keyspace to 48 bits. - The bit with value 32 is set to 0 in all capital letters, lowering the keyspace to 40 bits. (If the password length isn't known, there are 16 different possible combinations for the bit in this position if the password only contains letters.) - The lowest bit is the parity bit, and is not used, lowering the total to 32 bits. A PC is more than adequate to crack such passwords. I hacked my 32-bit DES code to optimize key searches quickly, and it took about a week to find a password for a client. I seem to recall that I was getting a bit over 15000 passwords/second on a '386-33, though it might have been faster. Fortunately the password was all letters, or it would have taken longer... >How is the key check computed? Could you post the algorithm? It uses DES, and should be secure. (There is quite a bit of known plaintext in the file header, and it checks to make sure this decrypts peroperly. However, with the propriatary algorithm, this known plaintext is enough to crack the password.) -- Paul Kocher kocherp@leland.stanford.edu PLEASE READ BEFORE RESPONDING TO THIS POST: My e-mail box is already flooded with messages; it has over 900 in it, about 150 of which I still have to respond to. So if you write please keep understand if I don't respond immediately. If you don't hear back within a couple weeks and want a reply, resend your message, since I could easily have missed it. So I don't have to write the same thing to 50 people: My code/executables for breaking DISKREET passwords are NOT available, and I don't have time to find forgotten passwords for people. Sorry to sound so rude and all, but I can't afford the risk of annoying the government (e.g. ITAR, etc.) or companies I'm working with by giving out crypto code. Plus I haven't been to bed before 3am in weeks and need more sleep :-). While I am sometimes available for contract work, I don't have any time available before January.