The MindReader Decryption Project


On 8th March 1994 Paul Winter died of Motor Neurone disease. His wife, Kathryn (Kathy) sent Dave Smith the Mindreader program and the three files which Paul had written using this program and which they had found on his computer. Two were diary files, started at different times when Paul was at an earlier stage of his illness. Diary2 shows a deterioriation in his physical abilities. These had been encrypted within Mindreader using the password "winter". He also left another file "LL" - last letter? - but this was not encrypted simply with the same password. This is the file which we want to decode.

About the Mindreader program

This is a simple word processor which remembers words previously typed and allows selection from starting strings to avoid unnecessary typing, much like the predictive text input facility of modern mobile 'phones.

It has an encryption option, and also an autosave option. The passwords are case-sensitive, alphanumeric and must be from 5 to 10 characters long. They may include spaces. The password is visible when typed and has to be repeated before encryption/decryption is applied. The files are saved in simple ASCII form with the extension "DOC". White space characters, i.e. ASCII characters whose value is less than 33 within the document are not altered by the encryption process so the files show word and line structures reflecting the original file.

Observations on the diary files and the use of Mindreader

The spelling in these wasn't 100%, obviously and not consistent. There are also occasional "glitch" characters indicating accidental and uncorrected key errors. The use of upper and lower case is not consistent. Punctuation is not always maintained and the firsr ketter of names and the personal pronoun "I" are not always capitalised. It is difficult to mistype a password in the encryption / decryption process since it is visible and also has to be repeated. The LL file is not decrypted with the password 'winter'.

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 early years

Dave Smith was given the files several years ago, and, with the help of the readers of the sci.crypt newsgroup, discovered the algorithm, and the password used for the diary files ('winter').

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

By chance, Dave mentioned the project to me (Matt Gumbley) in 2004, and I decided to investigate the problem.

I felt that a massively distributed set of computers, as used for other projects such as, 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!

Volunteers are most welcome to join the project, especially if they have fast systems, on permanent (broadband/ADSL) connections to the Internet.

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

For details of the encryption / decryption algorithms, please see Algorithm Details.