![]() |
|
Message-ID: <20060909112531.GA11825@openwall.com> Date: Sat, 9 Sep 2006 15:25:31 +0400 From: Solar Designer <solar@...nwall.com> To: john-users@...ts.openwall.com Subject: Re: Using a pre-computed list of alphanumeric strings. (not rainbow tables) On Tue, Aug 29, 2006 at 02:32:59PM +0200, rembrandt@...erlin.de wrote: > Because somebody mentioned the space needed to store "Rainbowtables": > This space can get reduced dramaticly using the "right" compression > algorithm. Oh, and that algorithm is the one that was used to generate those tables originally, right? ;-) > I will (again) mention LZMA because it compresses REALY awesome. LZMA is good, but irrelevant. Please stop plugging it on this mailing list. Rainbow tables - or any pre-computed hash lists, etc. - are supposed to _not_ be compressible. If they are compressible, that would indicate a cryptographic weakness of the hash function and/or non-optimal storage/encoding format. In the latter case, the storage/encoding format would possibly need to be optimized (unless it is non-optimal deliberately - e.g., for quicker access to the data), not a general-purpose compression algorithm used on top of it. > And that LM can get splitted into 7 char blocks is right and this means > you just need a rainbowtable up to 7 Chars because a PW of about 12 chars > gets splitted into 7+5 and should get brocken absolutly fast. That's true. > So conclusion: It makes sense to may even enable JtR to use Rainbowbooks, > at least for such weak algorithms. As I had mentioned before, this might be better implemented as a separate program because it would share little code and functionality with the current JtR. The primary reason to possibly stretch JtR in this direction is that it might be good for "marketing". > It will become kinda useless for Blowfish or maybe even MD5 but for DES/LM > it may makes sense Basically, it makes sense for saltless hashes and possibly for those with small salt sizes (that's just the traditional DES-based crypt(3) hashes with 12-bit salts). > (combinated with a good compression). No. Observe: Archive: SSTIC04-10k.zip Length Method Size Ratio Date Time CRC-32 Name -------- ------ ------- ----- ---- ---- ------ ---- 774 Defl:N 446 42% 07-14-04 23:20 90a9b24b README-10k.TXT 30819324 Defl:N 30710332 0% 06-30-04 18:24 cc44f316 table0.bin 6910420 Defl:N 2402915 65% 06-30-04 18:24 b3b6c086 table0.index 61638648 Defl:N 59604011 3% 06-30-04 18:24 746a2343 table0.start 30814120 Defl:N 30704735 0% 06-30-04 18:26 15eaf5cd table1.bin 6910420 Defl:N 2402928 65% 06-30-04 18:26 f7cb316c table1.index 61628240 Defl:N 59594098 3% 06-30-04 18:26 ffc52302 table1.start 30824574 Defl:N 30715428 0% 06-30-04 18:27 f88e0d5f table2.bin 6910420 Defl:N 2402915 65% 06-30-04 18:27 c516e00a table2.index 61649148 Defl:N 59613310 3% 06-30-04 18:27 3c04a219 table2.start 30811564 Defl:N 30701830 0% 06-30-04 18:28 c5165165 table3.bin 6910420 Defl:N 2402999 65% 06-30-04 18:29 d1e8060d table3.index 61623128 Defl:N 59589739 3% 06-30-04 18:28 d00cf97a table3.start -------- ------- --- ------- 397451200 370845686 7% 13 files Only some files are compressible, for an average size reduction of 7%, and that's likely due to deliberately non-optimal storage/encoding format. LZMA achieves only 1% better results than ZIP: -rw------- 1 solar solar 397465600 Sep 9 15:10 SSTIC04-10k.tar -rw------- 1 solar solar 366442679 Sep 9 15:19 SSTIC04-10k.tar.lzma -rw------- 1 solar solar 370847438 Sep 9 15:05 SSTIC04-10k.zip because there's simply almost no compressible data. -- Alexander Peslyak <solar at openwall.com> GPG key ID: 5B341F15 fp: B3FB 63F4 D7A3 BCCC 6F6E FC55 A2FC 027C 5B34 1F15 http://www.openwall.com - bringing security into open computing environments -- To unsubscribe, e-mail john-users-unsubscribe@...ts.openwall.com and reply to the automated confirmation request that will be sent to you.
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.