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.