Cryptography Reference
In-Depth Information
In view of such 'exotic' statistics (the zero byte was by far the most
frequent in all cases analyzed), let's not deal with the innards of
WordPerfect and instead search for the most frequent character in the
transformed ciphertext, which was 'cleared' of the disturbing ascending
number sequence. This happens in lines 51 through 62. Without that
number sequence, only the following remains from equation (1):
key = cipher_nonum
⊕
plain
However, since the
plain
byte equals 0, we get
key = cipher_nonum
!
We mark this character as 'unsafe but probable' and output it together
with the other ones in lines 66 through 69. The entire 'session' can look
like this, for example (under UNIX):
$ newwprack <c.wp
$ len = 18: "THIS I
T
NO
T
SECURE"
$
(The marked characters appear inverted in the output, which means that
they have been revealed statistically.)
The program is not flexible — it supplies only one suggestion for each keyword
length. Though significant improvements are possible (if there are several char-
acters with approximately equal probability, then all of them should be output),
I didn't come across a keyword that
newwpcrack
failed to guess. It is rather
striking how surefire this quick-and-dirty method works.
Hopefully you've understood that one can proceed rather heuristically — the
main thing is that this path often leads to the goal. The program's computing
speed is impressive: calculating a password took 9 ms (0.009 seconds) on a 133-
MHz PC Pentium under PC-UNIX (ESIX V.4.2). As mentioned in Chapter 1,
AccessData has wait loops built into its software to avoid having to confront
customers with the brutal truth. But I'd never have imagined they'd occupy a
PC 386-16 for full 60 seconds with the same task that
newwpcrack
handles
...
Certainly, their program is much more reliable than mine (I'm serious).
