Path: gmdzi!ira.uka.de!sol.ctr.columbia.edu!cunixf.cc.columbia.edu!em21
From: e...@cunixf.cc.columbia.edu (Eben Moglen)
Newsgroups: sci.crypt
Subject: Archiver encryption security
Message-ID: <1991Dec29.081650.11688@cunixf.cc.columbia.edu>
Date: 29 Dec 91 08:16:50 GMT
Organization: Columbia University
Lines: 4
Has anyone considered seriously the security of the various encryption
algorithms in use in the various archiver programs? PKZIP, ARJ, ZOO and
other similar products include a scrambling facility, and the algorithms
in use should be scrutinized, I think. Anyone have any useful information?
Path: gmdzi!ieee.org!dorm.rutgers.edu!rutgers!usc!elroy.jpl.nasa.gov!
ames!network.ucsd.edu!qualcom.qualcomm.com!chicago.qualcomm.com!karn
From: k...@chicago.qualcomm.com (Phil Karn)
Newsgroups: sci.crypt
Subject: Re: Archiver encryption security
Message-ID: <1991Dec30.005026.1177@qualcomm.com>
Date: 30 Dec 91 00:50:26 GMT
References: <1991Dec29.081650.11688@cunixf.cc.columbia.edu>
Sender: n...@qualcomm.com
Organization: Qualcomm, Inc
Lines: 27
Nntp-Posting-Host: chicago.qualcomm.com
I never use the built-in encryption facility in PKZIP. If I need to
protect an archive, I create it normally and then run it through my
own DES software. This has the following advantages over using the
built-in encryption:
1. I wrote the encryption code and know it to be at least a faithful
implementation of DES, without any trap doors of my own. I have no
idea what the encryption algorithm is in PKZIP, and whether there are
any trap doors, deliberate or otherwise.
2. The encryption option has been removed from the shareware version
of PKZIP, ostensibly for export control reasons. You have to get a
registered copy and not live outside the US or Canada. This
makes the built-in encryption in PKZIP a lot less useful in practice
when you want to exchange encrypted files with others.
My technique does have the disadvantage of requiring me to decrypt
an entire archive even if I only want to extract a single file.
My DES encryption code, including full source, can be obtained by
anonymous FTP from ucsd.edu, /hamradio/packet/ka9q/des/des.tar.Z. It
runs under both MS-DOS and UNIX, and is backward compatible with the
SunOS 'des' command. And it is completely in the public domain -- you
may do whatever you want with it.
Phil
Path: gmdzi!unido!mcsun!corton!chorus!nocturne.chorus.fr!jloup
From: jl...@nocturne.chorus.fr (Jean-Loup Gailly)
Newsgroups: sci.crypt
Subject: Re: Archiver encryption security
Message-ID: <12576@chorus.fr>
Date: 31 Dec 91 16:27:27 GMT
References: <1991Dec29.081650.11688@cunixf.cc.columbia.edu>
<1991Dec30.005026.1177@qualcomm.com>
Sender: jl...@chorus.fr
Reply-To: jl...@nocturne.chorus.fr (Jean-Loup Gailly)
Organization: Chorus systemes, Saint Quentin en Yvelines, France
Lines: 79
Eben Moglen <e...@cunixf.cc.columbia.edu> writes:
> Has anyone considered seriously the security of the various encryption
> algorithms in use in the various archiver programs? PKZIP, ARJ, ZOO and
> other similar products include a scrambling facility, and the algorithms
> in use should be scrutinized, I think.
I think I have broken the encryption scheme of pkzip if the random
header is known. (This header consists of 10 random bytes prefixing
the plaintext plus two known bytes. For more details, please look at
appnote.txt in the pkzip documentation.) In the portable zip, the
'random' header is in fact not much random, since it is directly
related to the date and time at which the zip file was created.
(I will try to improve this for the next version of zip.)
pkzip might use a better algorithm (e.g., based on the delay between
each key press). But pkzip 1.10 has another vulnerability, because it
stores pre-computed Huffman trees before the compressed data, so a lot of
plaintext is known. pkzip 2.0 will be less vulnerable.
If the random header is really random, then I think that the
encryption scheme is quite good and will resist all amateur attacks
for a well chosen password. It is however likely that it will not
resist attacks by cryptanalyst experts (which I am not). The most
effective attack by amateurs is a brute force attempt at likely
passwords. Such attacks are very effective to break Unix passwords.
For the pkzip encryption scheme, the attack is even more effective
because one can determine very quickly (a few dozen instructions) if a
password is correct or not. So it is quite easy to try several
billions passwords on any workstation. Any password consisting of
lower case letters only and of 7 characters or less can probably be
cracked overnight.
The encryption algorithm of ARJ is kept secret, but its author Robert
Jung says that "it only uses an XOR string routine which can be broken
with a little patience".
zoo and lha do not include an encryption capability.
Phil Karn <k...@chicago.qualcomm.com> writes:
> I have no idea what the encryption algorithm is in PKZIP, and whether
> there are any trap doors, deliberate or otherwise.
The algorithm is public. Pseudo-code is given in appnote.txt in the pkzip
documentation, and C code is available for the portable zip. (ftp sites
given below.)
> 2. The encryption option has been removed from the shareware version
> of PKZIP, ostensibly for export control reasons.
For the same reasons, the encryption code for the portable zip is
distributed separately. You must get it from a US site if you are
within the US and from a European site otherwise.
Jean-loup Gailly
ftp info:
From the US only:
pit-manager.mit.edu:/pub/zip/crypt/zipcrypt.shar
(mail server at mail-ser...@pit-manager.mit.edu)
Outside the US:
garbo.uwasa.fi:/pc/arcutil/zcrypt10.zip
ftp.win.tue.nl:/pub/compression/zip/zcrypt10.zip
ftp.inria.fr:/system/user/zcrypt10.zip
ftp.informatik.tu-muenchen.de:/pub/utils/archiver/zcrypt10.zip
(mail server at ftp-mai...@ftp.informatik.tu-muenchen.de)
zcrypt10.zip is only a complement to the export version of zip 1.0,
which can be found on many ftp sites, such as
wuarchive.wustl.edu:/packages/compression/zip-1.0-export.zip
The pkzip documentation can be found in:
wuarchive.wustl.edu:/mirrors/msdos/zip/pkz110eu.exe
which is a zip file that the portable unzip can extract.
Path: gmdzi!unido!mcsun!uunet!cs.utexas.edu!utgpu!utzoo!utdoe!generic!pnet91!
argonaut
From: argon...@pnet91.cts.com (C. Peter Constantinidis)
Newsgroups: sci.crypt
Subject: Re: Archiver encryption security
Message-ID: <1323@generic.UUCP>
Date: 31 Dec 91 09:45:04 GMT
Sender: r...@generic.UUCP
Organization: People-Net [pnet91], Etobicoke, ON
Lines: 13
Why worry? I never use those archiver encryption algorithms anyways.
Safer to use something real like DES or RSA, archive it, which makes it harder
to decode because the info is all compressed, etc. (the bits are in a
different neat order anyways), and just put a password on the archive..
A decryptor would need to manually decipher the password, then uncompress the
file, and THEN work at the actual file.
It would take a long time and would be a pain.
------------------------------------------------------------------------------
| INET: argon...@pnet91.cts.com | "My computer is better than your computer!" |
------------------------------------------------------------------------------
Path: gmdzi!unido!mcsun!uunet!cs.utexas.edu!utgpu!utzoo!utdoe!generic!
pnet91!marekp
From: mar...@pnet91.cts.com (Marek Pawlowski)
Newsgroups: sci.crypt
Subject: Re: Archiver encryption security
Message-ID: <1324@generic.UUCP>
Date: 31 Dec 91 16:00:05 GMT
Sender: r...@generic.UUCP
Organization: People-Net [pnet91], Etobicoke, ON
Lines: 55
argon...@pnet91.cts.com writes:
>Why worry? I never use those archiver encryption algorithms anyways.
>Safer to use something real like DES or RSA, archive it, which makes
>it harder
>to decode because the info is all compressed, etc. (the bits are in a
>different neat order anyways), and just put a password on the
>archive..
The poor english makes this hard to understand, and contorts the message
Peter was attempting to convey.
Common practise is to prepare a file by first archiving it, be it
TAR, or some other utility such as LZH. And encrypt the resulting
file using a more secure encryption scheme such as RSA, or DES.
RSA and DES have proven to be extremely hard to attack (however, I'd
like to see two Israeli's prove me wrong). Where as the encryption
included with commercial or semi-commercial packages is questionable,
and in most cases, reversable.
>A decryptor would need to manually decipher the password, then
>uncompress the
>file, and THEN work at the actual file.
I think what he's trying to refer to, is encrypting a file BEFORE
you archive it, leaving the task of uncompressing, and THEN decrypting
the files in the archive. If this is what he's trying to say, I agree
with the following statement:
>It would take a long time and would be a pain.
It is always a quicker process to encrypt a smaller file, than a larger
one. Why waste time, if you're not gaining as much anyway?
On top of that, using the above method would give a cracker more samples
to decrypt from, all using the same key. This would increase the
probability of a successful crack.
The smaller the sample, the less chance it will be broken.
>-----------------------------------------------------------------------------
>| INET: argon...@pnet91.cts.com | "My computer is better than your
>computer!" |
>
>
>-----------------------------------------------------------------------------
..Not if it's a Mac.. :)
Marek Pawlowski - mar...@pnet91.cts.com, mar...@cerf.net
Ph: (416) 884-4501. Inquisitive computer enthusiast.