For Beginners & Professional Hackers/cd.iso/hackers/tools/diskreet.ha/DISKR2.TXT

Internet Message Format | 1995-10-24 | 12.5 KB

From: [e-mail] (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.
--
 [e-mail]||[e-mail]||[e-mail]
[e-mail]||[e-mail]||[e-mail]
             (In order of preference - one of 'em's bound to work)
             -- DOS 6 - Double your disk space: delete Windoze --


From: [e-mail] (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
[e-mail]

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.


From: [e-mail] (Peter Gutmann)
Newsgroups: sci.crypt,comp.security.misc
Subject: Norton's [In]Diskreet: An update
Date: 13 Jul 1994 17:21:57 GMT


Last November I picked apart part of the Diskreet encryption program and posted
what I found to this group.  By some miracle I had a bit of spare time this
afternoon, so I've had another quick look at it.  The result is some more
information on the proprietary encryption algorithm and the file format it
uses.  First, a recap of what I presented last time:

The key setup process is very badly done.  The front-end gets a password in the
range of 6..40 characters, and converts it to all-uppercase.  Then it packs it
into a struct along with a collection of other information and passes it to the
DES library used by Diskreet.  The first thing this does is take the password
and reduce it to 64 bits by cyclically xor-ing the full-length password into an
8-byte buffer initially set to all zeroes, ie:

    for( index = 0; password[ index ]; index++ )
        buffer[ index % 8 ] = password[ index ];

It then performs what looks like a standard DES key schedule with the 64-bit
output from this operation.  This creates 128 bytes of subkeys for encryption
and 128 bytes of subkeys for decryption.  These are either used for the
proprietary encryption method or for DES encryption.  Here's a rundown of the
proprietary method:

All operations are performed on 16-bit words.  byteSwap() performs an
endianness-reversal on a word.  Chaining is performed by xor-ing in the
previous ciphertext word.  The keyTable is the 256-byte array of DES subkeys,
treated as an array of words.

    data[ -1 ] = 0x1234;
    index = sectorNo % 128;
    index = keyTable[ index ] % 128;

    for( i = 0; i < SECTOR_SIZE / 2; i++ )
        {
        value = keyTable[ index++ ] + data[ i ];
        byteSwap( value );
        value ^= data[ i - 1 ];
        data[ i ] = value;
        index %= 128;
        }

As can be seen, a known-plaintext attack will recover the (expanded) encryption
key without too much trouble - it's just a repeated addition of a 128-word
array to the data, with the previous word xor'd in for chaining purposes.  The
xor and byteSwap are basically nop's and can be stripped off without any
problems, revealing the key stream used to encrypt the data.  Since encryption
is done by sectors, the same key data is used twice for each sectors.

How do we perform a known-plaintext attack?  It's quite simple actually, since
Diskreet itself provides us with about as much known plaintext as we need.  The
file format is:

    General header

    BYTE[ 16 ]          "ABCDEFGHENRIXYZ\0"
    char[ 13 ]          fileName
    LONG                fileDate
    BYTE                fileAttributes
    LONG                fileSize
    LONG                file data start
    BYTE[ 16 ]          0

    File data

    BYTE[ 32 ]          0

    Padding to make it a multiple of 512 bytes

Everything from the 16-byte magic value to the end of the file is encrypted in
blocks of 512 bytes.  The proprietary scheme will directly reveal its key
stream on the 16-byte check value, the 16 bytes of zeroes at the start, and the
32 bytes (minimum) of zeroes at the end of the data.  Interestingly enough, the
presence of the 16-byte known plaintext right at the start would tend to
confirm the rumours that that's one of the criteria for having an encryption
program approved by the NSA.  The plaintext also gives us the name of one of
the programmers involved.

In my previous posting I said:

  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.

The 16-byte known plaintext makes this attack a certainty.  In addition, if two
pieces of data are encrypted with the same key, one with the proprietary method
and one with DES, the DES key can be recovered from the proprietary-encrypted
data and used to decrypt the DES-encrypted data.  Again quoting from my
previous posting:

  In summary, there may be a 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.

Peter.