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.