Paul Saenz <[email protected]> wrote: > What I was looking to crack were books. I would imagine that cracking them > wouldn't be to hard because the probability of repeating letters in the > English language is very predictable.
It's almost certain that encryption is done after compression, and the output of any decent compressor is statistically indistinguishable from a random bit stream. > I havn't done any cracking before, but > I do know a little about encryption, and that would be quite interesting, > and it would help me learn a lot about encryption. If you want to pursue rar cracking, a good start would be to find the spec for the rar format (it should be available given that there are FOSS unrar tools), read and understand it. If encryption is part of rar, it should explain the algorithm and how it's applied. That's what I did for zip. Zip encryption uses a 96-bit key generated from the user-supplied password; the latter is presumed to be an ASCII string if it's typed by a human on a keyboard. My zip cracking was limited to brute force, but I did it on the ASCII string rather than on the 96-bit key as I was betting on the starting password string consisting of printable ASCII characters only and being relatively short. My cracker tried password strings of increasing length, trying the 95 possible printable ASCII characters (space through tilde) in each character position. The password turned to be 7 characters long (that's 95 to the 7th power combinations, about 6.98e13, close to 2^46) and the effort took just over 5 months (from the day I received the encrypted zip to the day the password was recovered). If the password had been just one character longer (each character multiplies the brute force effort by 95), it would have been hopeless; ditto for doing brute force directly on the 96-bit key to which the password is reduced. I admit that the cracking time probably could have been shortened if we had better programming labor resources available. It took so long because the division of the key space among parallel crackers was done manually (very inefficient), and the PFY who had promised to write the automated tools to do that never delivered. But oh well, I can't really blame him as it was his running instance of the cracker that hit the key. :-) Note that an essential component of any brute force encryption cracker is the hit criterion which has to be evaluated on every key trial. The speed of that hit check pretty much determines the speed and hence the feasibility of the crack. In the case of zip we were lucky because the zip encryption format contains what's essentially a hole added for user convenience: there is a sequence of 12 bytes which are encrypted with the same key as the real data, and the last of these bytes is supposed to match another byte given in plaintext when decrypted correctly. The feature was obviously put in there so that unzip would report a "wrong password" error instead of decrypting garbage, but it reduces the hit criterion (the most essential part of a brute force cracker) to a decryption of 12 bytes and a single byte comparison instead of decrypting, decompressing and CRC-checking an entire file - a very major difference in cracking feasibility. I don't know if rar's encryption mechanism features any similar hole. HTH, MS _______________________________________________ LinuxUsers mailing list [email protected] http://socallinux.org/cgi-bin/mailman/listinfo/linuxusers
