Encrypted Magic Folders

Encrypted Magic Folders is a quite efficient shareware program to hide and encrypt files. It is shareware, but it never expires. I have myself used it on Windows 95, 98, Millenium, and 2000. It hides files by using an old bug in Microsoft software of putting a null in front of a directorys name to render it, and all its contents and sub-directories totally invisible to Windows and DOS (but not Linux :P ) The Encryption is a quite unorthodox, yet beautiful method. The following paragraph is an excerpt from the EMF Manual, it is a long, but informative read, you can skip it if you dont understand encryption in the first place.:

Quite a few people ask us how big EMF's key size is. They've learned from other encryption programs that the bigger the key the stronger the encryption. This really doesn't apply to EMF. We developed our own encryption instead of using a standard because we wanted EMF to be able to decrypt at the byte level. In this way we only need to decrypt/encrypt the data your programs require and not the entire file. In theory, because we decrypt at the byte level, the biggest key we could use would be 8 bits - which is a joke. So instead of decrypting every hunk of data using the same key, as most other encryption programs do, we developed an algorithm to vary the key based on the data's location within the file. In this way we get both security and high speed. Having said that, truth is, most encryption isn't "cracked" by breaking the algorithm, it's done by guessing the password. Brute guessing of passwords tends to level the playing field tremendously. In face there are programs out there for sale that can break passwords in hours if they're too short. Use passwords at least 10 characters in length and you should be fine. If we used an established encryption method like DES or Blowfish then your files would probably have to be fully decrypted when opened, would exist on disk as unencrypted while you're using them, and then would need to be encrypted when closed. This has multiple disadvantages. First, if your computer shuts down while you have "encrypted" files open, then those files would be unencrypted. This doesn't happen with EMF as your encrypted files are always encrypted as stored on disk. The second disadvantage is that it slows things down tremendously. As an example, let's say you retrieve your email and your email program needs to add today's message to the end of your 3MB email file. If we used a standard encryption method requiring the decryption of the file before use then the entire 3 MB file would have to be decrypted, your 300 byte message added to the end and then the entire file encrypted again. With EMF, no decryption would need to take place, and the only data needing encryption would be the 300 byte message. MUCH faster. Around 20,000 times faster in this example! Until recently EMF's algorithm hadn't been broken. That has changed. Someone doing work for the FBI has cracked our algorithm. There is however no program available to decrypt EMF files. So if you're worried about the FBI, or someone with the resources to hire encryption consultants to break your files, then you should choose another program. On the other hand if you're protecting files from anyone else then you'll find EMF's security more than adequate and it's speed and convenience amazing.

So it'll keep out your little brother, and the hacker who comes in cause you've got DSL and left your computer on all night, but it wont keep out the FBI, which is reasonable. It has another feature, Scrambling, where it dynamically scrambles all the filenames, and directory names of the directorys it is protecting after having encypted them.

Also as it says in the excerpt above, in case you didn't read it, the data on your disk is never actually unencrypted unless you tell EMF to stop protecting that directory. If not then when you wish to view data it copies the encrypted data to memory, decrpyts it there, and unloads it when your done, so in a case of power failure or another event, the data on your disk would still be encrypted and the the unencrypted copy in RAM would be gone.

I'm not going to make this writeup longer by re-explaining everything in that excerpt so on second thought, you should read it.

Bruce Schneier has devoted much space to "snake oil" in his (highly recommended!) monthly newsletter "Cryptogram". The surest signs of snake oil are unbreakable encryption algorithms, somebody from the TLA (particularly when unnamed) and a distinctly unhealthy fascination with key lengths. Oh, and ignorance of modern cryptographic practice is a dead give-away, too.

Judging by the excerpt above, EMF seems to score top marks in all categories. A more detailed explanation follows, but the short version is this: regardless of whether or not somebody has bothered to break the encryption (and if they have, you need to think if they've told anybody...), you shouldn't use this program. There's no reason to get a cryptographic program from someone who doesn't know the field. If you distrust AES (or even DES!), fine, but you should base your distrust on something solid.

Don't use a program implementing somebody's made-up algorithm -- they've been analysed far less than the standards, and may well have trivial holes. Don't use a program written by someone who doesn't know the field -- they're far more likely to have left some silly holes in their program, through which your data will escape even if the encryption itself is secure.

So what's so bad about EMF?

[The fuss about key sizes] really doesn't apply to EMF. We developed our own encryption instead of using a standard...

DANGER! The standards aren't up to the task of encrypting a file on disk? NIST employed Don Coppersmith of IBM, and had the NSA review DES, and it cannot encrypt a file? And then, YEARS LATER, they repeated the same mistake, but with an open process examined by thousands of people, all of whom failed to notice the AES standard is also useless??

Oh, it says what's wrong with DES, AES, RC4 and RC5, and the rest of the alphabet soup of standard algorithms:

...because we wanted EMF to be able to decrypt at the byte level. In this way we only need to decrypt/encrypt the data your programs require and not the entire file.

This is good stuff. So... they wanted a stream cipher, not a block cipher. Well, open Applied Cryptography and check those out -- there are plenty. OR, use DES. DES is a block cipher, so you get 8 bytes encrypted at a time. Most accesses to a file require considerably more than 8 bytes (some would even note every OS fetches an entire sector at a time), so it's not clear why bother to encrypt single bytes. AES uses larger blocks (16, 24 or 32 bytes), but that's still enough to be useful.

Oh, wait! They want random access to the file! That doesn't work with a stream cipher (because you often can't easily sync the stream to a given place in the file)! And my program "des" can only DES-decrypt an entire file.

Well, the most common (and probably best) mode of operation for DES, AES, and most block ciphers is CBC ("cipher block chaining"). With CBC, you must decrypt by a multiple of the block size. And since every block is XORed with the previous block's ciphertext, given a single block you cannot just decrypt it. BUT, if you know the previous block, you can. That's one of the reasons CBC is the near-standard mode: it's good.

In theory, because we decrypt at the byte level, the biggest key we could use would be 8 bits - which is a joke.

Not only is this a joke, it's also news to every cryptographer who's ever used a stream cipher. Or some block ciphers, for that matter. The reasons for making key size == block size are that it offers a good balance of security against different attacks. That's all.

So instead of decrypting every hunk of data using the same key, as most other encryption programs do,

Name 2 such programs which are not trash. Does PGP do this? Does GPG? Any S/MIME implementation? SSL, maybe? SSH?

we developed an algorithm to vary the key based on the data's location within the file. In this way we get both security and high speed.

Ooh! A more appropriate finish to the paragraph would be "we COULD get both security and speed". Without telling what cryptanalysis they've tried to perform on it, they can't claim to get security.

Anyway, out of idle interest, just how big IS the key? The encryption algorithm is completely deterministic (or you'd have difficulty decrypting, unless you had redundancies in the ciphertext, which would be horrible...), so it has to have a well-defined key. Your algorithm might square the key and take the square root of its sine between every two bytes, but it would still be using a key of the same size -- the initial key given.

Finally, the claims about DES and BlowFish (Schneier's AES candidate) needing to decrypt a file before random access are patently false. CBC mode, explicitly recommended for them, gives excellent, fast, random access. The claim about having to decrypt before appending is even more ridiculous: CBC requires just access to the last block, and it uses it encrypted, so you have to decrypt 0 bytes before you can start appending. CTR lets you setup to decrypt immediately: you just need to know the initial value (used for encrypting the first block) and the number of the next block. Seriously, it's a solved problem -- you need a good reason to step away from the examined standards and do something else!

RUN, don't WALK, away from programs making these sort of claims.