Cryptography Reference
In-Depth Information
$ vigc_crk <u1
maximal keylength: 64 bytes
period: 60, PROPOSED KEY:
"0123456789a123456789b123456789c123456789d123456789e123456789"
key dump: 0123456789a12345
6789b123456789c1
23456789d1234567
89e123456789
16980 recursive calls
$
In contrast, short files could cause problems. When using the program to test
a 512-byte file, I observed the following computation times, depending on the
password length (on the same Pentium computer).
Up to 5 characters long:
less than 1 second; unambiguous solution
6 characters:
1.8 seconds; 2926 function calls; unambiguous solution
7 characters:
9.4 seconds; 4643 function calls; unambiguous solution
8 characters:
1.5 seconds; 2795 function calls; unambiguous solution
9 characters:
8.6 seconds; 5646 function calls; unambiguous solution
10 characters:
8.3 seconds; 14 553 function calls; 16 passwords
Additional tests are necessary to find the correct password from the passwords
proposed in the last example: whether or not the plaintext produced can be
decompressed (which is sometimes possible even with 'wrong passwords'),
whether or not the decompressed output is something meaningful, and so on.
There are cases where
vigc crk
in the form represented here won't be sufficient:
when I encrypted the file with a 15-byte password, it took the program 25
minutes (and almost four million function calls) to come up with about 31 000
possible passwords on the screen (all of which obviously let you guess the
correct password: 'abcdefghijklmno').
The program tends to get tangled up particularly with multiples of the period
length. While searching it displays the period length currently assumed for
controlling reasons. With the correct period length (and its multiples), it can be
seen clearly how the search time increases: from 0.1 to 0.2 seconds to several
seconds. With wrong assumptions about the period length, the dead ends in
