From: kocherp@leland.Stanford.EDU (Paul Carl Kocher)
Subject: PKZIP encryption contest is meaningless
Organization: DSG, Stanford University, CA 94305, USA
Date: Sat, 11 Apr 92 02:27:56 GMT

Before anyone wastes time on PKWARE's "Encryption Contest" here are
a few reasons why the challenge is not worth taking seriously:

     1) Their file didn't compress at all, so it is quite possible 
           that the file was produced with a random-number generator 
           board or that it contains other unrecognizable junk.  
           (Running truly random data through their encryption 
           produces truly random output.) 
           
     2) There is no way to know if you've found the right password, 
           except that the 16-bit checksum in the encryption header 
           and the CRC are both good.  However, a massively-parallel 
           machine could find one of these that would *not* produce 
           the original data.

     3) 12K of encrypted data isn't enough

     4) Only one file/encryption header is provided.  It would be 
           interesting to have a ZIP (encrypted with the same
           password) that contains 10000 zero-byte files. 

If PKWARE wants to make this a real test, they should at least offer 
to encrypt files (supplied by the public) using the same password.

PKWARE writes in the "contest" rules:
   > The strength of the encryption scheme in PKZIP has come under some 
   > scrutiny lately.  There have been allegations that the encryption
   > method used is open to defeat by a "brute force" attack: that is
   > simply trying every possible combination of characters until you
   > find the one that was used.
   >  
   >  In response, we offer this challenge.  Decrypt the file BREAKME.DAT
   >  in the enclosed encrypted ZIP file: PKCONTST.ZIP

This statement is misleading and boarders on dishonesty.  Their 
challenge is not a "response" to the brute-force problem.  The contest
carefully evades the brute-force attacks (which make ordinary UNIX-style
passwords unreliable) by using *any* of the 256 ASCII characters in 
their 7-digit password.  (How many users actually use all 256 ASCII 
characters when selecting passwords, anyway?)  If only lowercase 
letters are used, my zipcrack program can find the password in a 
maximum of 18-19 days on a 80386-33.

If PKWARE thinks their encryption system, as it currently stands, is
adequate, I dare them to randomly select a registered PKZIP user who uses
and who TRUSTS zip encryption, publish one of his/her encrypted ZIPs, 
and offer $1000 to anyone who can find the password.

-- Paul Kocher

	- Author of ZIPCRACK: 5-6K password/sec brute-force on zips
	- Author of ARCCRACK: Solves directly for ARC passwords
	- Broke PKWARE's AV system by finding PKWARE's serial number

kocherp@leland.stanford.edu       415-497-6438 (10am-1am pacific time) 
----------------------------------------------------------------------
I'm not an expert in encryption.  All I know is what I've figured out 
myself.  If I'm wrong about something, please e-mail/post, polite 
flames welcomed!  Disclaimer: This article contains only my opinions.
----------------------------------------------------------------------
To get a uuencoded copy zipcrack (about 60K, crippled for shorter 
passwords only), send an e-mail message to kocherp@leland.stanford.edu 
stating that your e-mail address is in the US, that you won't export 
the program, and that you will immediately delete the file if you 
don't agree to the legal stuff in the docs.  Zipcrack was written in 
80x86 assembly.  (I've also ported it to C, but sources not publicly 
available).  Zipcrack can test 5-6000 passwords/second on a '386-33.
----------------------------------------------------------------------
I'm an undergrad at Stanford and am seeking paid summer/contract work.  
Please send e-mail if you know of available positions, would like a 
resume, have questions, or just want to chat!