It is possible to accidentally select decryption instead of encryption or vice versa if one isn't concentrating when using the drop-down menus. If an incorrect password or encryption process is applied unless one thinks carefully one may not remember that the reverse process has to be applied to get back to the original file (unless one uses the File-Open menu again first. If the autosave is set to "on", then an incorrect application of the encryption / decryption process may overwrite an earlier version of the file. Exiting the program prompts for Save / Abandon if the file has been changed.

Observation of the file LL suggests that it starts with a date (plus one or more extra characters) and then possibly 'my dearest / darling kathy / wife (+1 character) and then begins i am .......'

The story so far

The descriptions on these pages are mostly his. Dave worked on the problem for some time, but could not decrypt the LL document. From Dave's notes:

Brute force testing has been applied using all possible password length and character combinations (see Matt's note below). The results were not checked by observation but instead using a simple statistical test (Chi Square) to compare the result with what is expected if the text is purely random characters - since the algorithm does not preserve letter frequencies. A large(ish) Chi Square would indicate some form of readable text. Any large values spotted were examined manually, but all appear to have been purely random / chance values (as one would expect to occur when a large number of such calculations are performed!). Although this process could usefulyl be repeated to be absolutely sure (see Matt's current efforts), we have tentatively concluded that a single decryption was not applied. Multiple encryption / decryption, possibly using different passwords (or cases) seems likely to have occurred but in what combination and to what depth is not known. Another test applied suggedting that the process probably wasn't a single enryption was to assume a limited set of possible word strings for the first part of the text abd to physically deduce possible character strings by comparing these with the encrypted file. However, this was extraordinarily tedious and not comprehensive of possible strings and so cannot be regardede as a definitive test. (Matt is re-investigating this also). The latest idea has been to produce a simple program to try to check for specific likely passwords whether a set of encrypt / decrypt processes were with differing cases since leaving the caps lock key on rather than changing the password seems to be the most likely cause of the problem, but the sequence of subsequent events is not known. An extensive set of possible alternative passwords may also be tried since a lot of personal information and names meaningful to Paul has also been collated. "

Matt's involvement in 2004

I felt that a massively distributed set of computers, as used for other projects such as distributed.net, SETI@Home, etc., could be applied. I developed a central server which would send out batches of keys to clients; these clients would then attempt encryption/decryption of all keys in the supplied batches, and report back any successes. Success being measured with letter-pair frequency analysis.

An initial attempt at a distributed brute force scan is in progress (Sept 2004) assuming that one of the early letters in the text is I, i, A or a - any transform which yields these characters is further examined to discount obvious noise, and then by letter-pair frequency. Anything else is ignored.

I (Matt) prefer the letter-frequency test, since it seems to give clearer results; However I am not an accomplished mathematician, and do not fully understand Chi Square. I'm not concentrating on the multiple encryption / decryption and case shifting hypotheses yet, until I'm certain that a single pass was not involved - i.e. when the current brute-force approach runs out of steam.

I'm also attempting to document the algorithms in plenty of detail, and provide source code to anyone who would like to join our effort, via this web page.

In addition, I'm attempting to reverse the algorithm, so that given the existing LL ciphertext, and some possible values for the initial bytes of the plaintext, we can reduce the keyspace.

Volunteers needed!

I am also attempting to gather knowledge of cryptology, and to find crypto and maths experts who may be able to assist with analysing the algorithm, to find weaknesses, and to possibly even decipher the LL document without resorting to brute force.

I'm in the process of setting up a SourceForge project, mailing lists, etc.

Watch this space, but in the meantime, if you're interested and would like to get involved, please contact Matt.

Technical details