MicroEmacs

MicroEmacs was a very good subset of emacs which run in DOS.

I used it in some extremely low end machines. I wrote several macros, e.g. to convert data between binary, decimal and hex, to calculate simple expressions (like "2+3") etc.

I liked the editor a lot, it was hugely superior to anything else, especially for programmers. I loved it much and it a big reason why I used XEmacs for a long time.

The version I used back then was most likely 3.11c or 3.12. MicroEmacs is GPL and still alive, get it from here.

The crypt function

Background

When I was a kid, I wrote some text and encrypted it. Then I forgot about the text. And the key. Then I found the text ten years later. I tried the decryption with a couple of "possible" values for the key - none worked. Unluckily of me, I tried to decrypt with wrong version of the uemacs crypt. My text was encrypted using the "new" method and I tried to decypt with "old" (the sources I first downloaded had only "old" method).

I gave up at least twice.

Breaking the encryption

One evening I decided to crack the thing. I decided to brute force every possible less than six letter word. I first tried with every four letter word (because I had a feeling that the password was "jhol" or something like that). The brute force failed. As said before, I used wrong source. When I found the source I already though it might be wrong.

When I got the new sources, I started the brute force of every possible less than nine letters words (maybe the password was "jhol123" or whatever?). I planned to run it for several weeks...

I experimented with several heuristics to check if the decryption had succeeded. There were a lot of false positives. But the "positives" seemed too similar ... there was something wrong now. One rule of good encyptor states, that neither of these, especially latter, may not happen. Something was horribly wrong.

The crypt function is fatally flawed. Both the "old" and "new" method are equally bad. Even an amateur like me can break the encryption in one evening.

I reverse engineered the algorithm from the source. The source is quite nicely commented, btw. I found out the flaws in the encryption algorithm. There were several, fatal flaws. Putting them together I now could decrypt (any short password) encrypted text in matter of few minutes, where most of the time is taken by manual labour.

  1. The internal key space is extremely small. Brute forcing the key full space can be done in one night with a 1GHz pentium. So even using (very) long passwords do not protect your files.
  2. The password to internal key mixer does a bad job. Especially for short (less than 6 character) passwords it creates far too simple keys.
  3. The encryption function is linear. I do not (only) mean the mixing of clear text and cipher stream, but how the cipher stream changes between characters. If you know one character in the cipher stream you can calculate the next by simple linear computation. This means that if you know several characters in the cipher stream you can deduce the internal key and decrypt the whole text. This is exactly how I broke the cipher.

Breakthrough

I found that the encryption for short keys used only extremely small key space to encrypt the first four letters. The key space was 95. Yes, only ninety five different keys for the first four characters. I am absolutely confident, that even if the password to internal key algorithm would have been good, I still would have broken the encryption. This is because the probability that the internal key for second character changes is only 50%. And the change is linear.

So I discovered the key for first four characters. Now, brute forcing through the whole key universe (which was, as said, far too small in the first place) divided by 95, was very fast.

I got the internal key. I got my text. I noticed that password "jhol" created the internal key. So I tried UE and the key "jhol". Decyption was succesfull! All the work was done because I had wrong version of the source ... Well, the time spent was really educational.

Lessons learned

  1. Do not invent "new" encryption methods. They are going to be fatally flawed. Use AES, RSA or like. Hell, even DES with 52 bit key universe would have stopped me, and most of the persons in the world.
  2. Use Open Source software. Save the source code.
  3. Use open standard file formats. For example OpenDocument is an ISO international standard (ISO/IEC 26300). Use OpenOffice.org
  4. And, most importantly, do not encrypt your files.

Your files are not most likely that confidential anyway. It makes much much more sense to protect your machine from viruses etc. than encrypt. Only exception to this is a untrusted machine (like a laptop which can be stolen) where you must encrypt. The point is that never encrypt your backup copies. You are going to put them in a safe anyway, right? Or, if you encrypt, encrypt using RSA (or like) and save the private key in bank vault, written on a paper (magnetic media is susceptible to several problems).

Offtopic

There are rational beings in the universe who attempt to make this text illegal. If you feel that this text should be illegal, do nothing. If you feel this text should not become illegal, please contact EFF.

Last modified: 2017-02-26 13:07:58