🚀 go-pugleaf

kocherp@leland.Stanford.EDU (Paul Carl Kocher) writes:

>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.) 
>           

I don't know very much about cryptography, however, every encryption
is supposed to give output that closely resembles random data.

>     3) 12K of encrypted data isn't enough

Huh? If it is normal ascii, it has an information content of about
5 bits per byte (max), this gives you three bits/byte that get
"expected values" when you decrypt correctly. This gives you about
4.5K of "expected data", this is much longer than the .... distance
that theoretically gives you the password. (in practice you often need
at least double, however 4.5K with a key of 7 bytes gives a lot of
room for higher datacontent in the file, as well as larger requirements
to find the password.)

>     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. 

Does this give you more "known plaintext"?

>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.

The question is wether or not the algorithm is "know plaintext" proof.
It should be if it is to be considered "strong", however I don't know
about the PKWARE encryption scheme.

>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.

I agree with you that nobody ever uses a password that contains
56 bits of information in 7 bytes.

>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.

Well, if the password is cracked, there is MUCH more point in it:
A good encryption scheme should withstand known plaintext attacks, 
however if it breaks under "not known plaintext" attacks is is even
weaker! (i.e. If it isn't broken, PKWARE can't say their software is
safe)

 
>-- 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) 
-- 
If the opposite of "pro" is "con", what is the opposite of "progress"? 
	(stolen from  kadokev@iitvax ==? technews@iitmax.iit.edu)
EMail:  wolff@duteca.et.tudelft.nl   ** Tel  +31-15-783644 or +31-15-142371