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.