Newsgroups: sci.crypt From: pgut1@cs.aukuni.ac.nz (Peter Gutmann) Subject: Norton's InDiskreet Date: Thu, 11 Nov 1993 12:37:43 GMT Message-ID: <1993Nov11.123743.1701@cs.aukuni.ac.nz> Summary: Don't delete your copy of PGP yet 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. Peter. Newsgroups: sci.crypt,comp.security.misc From: pgut1@cs.aukuni.ac.nz (Peter Gutmann) Subject: Norton's [In]Diskreet: An update Date: 13 Jul 1994 17:21:57 GMT Message-ID: <3017rl$8j4@ccu2.auckland.ac.nz> 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.