165 lines
8.4 KiB
Plaintext
165 lines
8.4 KiB
Plaintext
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.
|
|
|
|
|