Other Directory Sites: SeekWonder | Directory Owners Forum
The following archive was created by hippie-mail 7.98617-22 on Sat Apr 10 1999 - 01:13:58
Bob Baldwin (baldwin@rsa.com)
Thu, 3 Sep 1998 09:23:54 -0700
As Jim points out, if you care about security, don't
use the Unix crypt program even if you compress files first.
As the author of CBW I have been called in a few time to
help decrypt files that were created with crypt, and I found
that the enhancements suggested in "Practical Unix
[& Internet] Security" by Garfinkel & Spafford do not help much.
The first thing I check is whether crypt was in fact
the cipher system used. A statistical test based on the
differences between adjacent bytes and based on correlations
between bytes separated by 256 positions can determine if
the ciphertext resulted from Unix crypt. The adjacent byte
test also tells me whether the plaintext was ascii or some
binary format (including compressed files).
If the plaintext is compressed with the standard Unix
tool, then it starts with a fixed three byte header. I was able
to break files like this by trying a large list of passwords
(the 2 million most common passphrases) and checking for the
three byte header.
If the fixed three byte header is stripped, a different
approach works. I loaded the CBW language statistics tables
with frequencies based on compresses english text. This works
very well for the first two blocks (256 bytes per block)
of the file, since the output of compress is still using 9
or 10 bit "characters" to represent the compressed text.
After breaking the beginning of the first block, I resorted
to the big dictionary attack using the now known plaintext,
and the rest of the file is broken with the recovered passphrase.
If the passphrase was not recovered, I could have extended
the attack through to the third block, and with three blocks
I could recover the internal key settings of crypt algorithm
to decrypt the whole file.
The moral of the story is that crypt will not stop a
serious adversary.
--Bob
> -----Original Message-----
> From: Bernardo B. Terrado [SMTP:bbt@mudspring.uplb.edu.ph]
> Sent: Thursday, September 03, 1998 2:28 AM
> To: Jim Gillogly
> Cc: CodherPlunks@toad.com
> Subject: Re: Crypt and compression [Re: question....]
>
> Computer Security Basics
>
>
> @@@@@@@@@@@@@
> ***************
> ** @ @ **
> ** ^ **
> ** U **
> ***************
> ***********
>
>
> To do the right thing(s) for the wrong reason(s) is human,
> To do the right thing(s) for the right reason(s) is divine.
>
>
> metaphone@altavista.net
>
> On Wed, 2 Sep 1998, Jim Gillogly wrote:
>
> > Bernardo B. Terrado writes:
> > > I have read that in Unix's crypt,
> > > let me put it this way
> > > the "book" suggested that
> >
> > The book? What book?
> > >
> > > One solution for the weakness of crypt
> > > is, first compress the plaintext then run crypt on the
> > > compressed data
> > > moreover it said that compressed data looks like random noise
> (so it
> > > would be very hard to decipher)
> >
> > Depends on the compression scheme.
> >
> > > My question is this,
> > > In case the ciphertext is deciphered, the "decipheree" will not
> know
> > > what compression scheme the "encipheree" used? what if he uses
> many
> > > decompression softwares, could he still get the plaintext ?
> >
> > First, what are you trying to achieve? If you simply want to keep your
> > data private, why not use a stronger algorithm, such as the ones used
> > in PGP?
> >
> > Second, the amount of protection you get from this will depend
> > on the resources and energy of the attacker. However, Robert H.
> > Morris (NSA, ret.) offered the dictum "Never underestimate the amount
> > of effort the enemy will undertake to get your plaintext."
> >
> > The easiest attack on crypt is if the plaintext is in English or
> > some other standard ASCII-based language. In this case one can
> > use Crypt Breaker's Workbench by Bob Baldwin, available at the
> > usual sites. However, the docs say it can't be used on binary files.
> > Assume, then, that your attacker will start with CBW and modify it
> > to work with binary files.
> >
> > If the compression used is the old standard Unix "compress" it
> > shouldn't be impossible if there's enough ciphertext, since "compress"
> > is quite heavy on NULs. The same is true of both GIF and JPEG. Gzip,
> > however, has a very flat table and would make the recovery
> > challenging. Some of the standard compression packages like gzip and
> > pkzip leave some known plaintext at the beginning as recognition
> > characters, and that's important for the attacker. If the attacker can
> > guess the beginning of your plaintext (e.g. "#include <stdio.h>" or
> > something) she's got an even better chance.
> >
> > However, with good compression and no hints even a weak encryption
> > system gives a surprising amount of help. ARJ, for example, uses
> > a Vigenere-like encryption, and if there is only one file in the
> > ARJ package it's difficult to spot patterns in it.
> >
> > I know, that's more than you wanted to hear, so here's an executive
> > summary: if you really care about your data, use stronger encryption
> > than "crypt (1)" and don't worry about ways to put band-aids on it.
> >
> > Jim Gillogly
> >
> >
The following archive was created by hippie-mail 7.98617-22 on Sat Apr 10 1999 - 01:13:58