From: Secret Squirrel <nobody@secret.squirrel.owl.de>
Date: Tue, 16 Dec 1997 09:48:10 +0800
To: abdiel@worldnet.att.net
Subject: Security of Encrypted Magic Folders
Message-ID: <bb1f3667bf58c57a2cca976efd767f1c@squirrel>
MIME-Version: 1.0
Content-Type: text/plain



From: "Alex Woolfson" <abdiel@worldnet.att.net>
Subject: Security of Encrypted Magic Folders

>I just downloaded Encrypted Magic Folders--a program that hides Windows 95
>folders and then encrypts them to prevent a disk utility from revealing
>their content.  In their help file, they try to answer the question "How
>Secure is it?"--and, of course, they say *very*, but I can't tell if this is
>so or if they're just blowing smoke.  Particularly, their claim that key
>size doesn't matter.  (My mom taught me size always matters... )   If
>someone with a stronger cryptography background than me could take a look at
>this and let me know, I would greatly appreciate it.

>* How Secure is it?

>    EMF's encryption offers good protection and excellent speed.  It
>    hasn't been broken yet.  It is, as far as we know, exportable.  THERE
>    IS NO BACKDOOR.  Should you forget your password there is nothing we
>    can do to decrypt your encrypted files.

How do we know this?

>    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.

How do we know this?

>    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.

How do we know this? 

>    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 high security and high speed.  We are trying to patent EMF's
>    encryption method.

How do we know this? And why are they trying to patent a mathematical
algorithm? (The fact they can do it is irrelevent. Patenting a mathematical
algorithm, much like patenting something like XORing pixels on a screen, is
stupid.) And is the fact that they're trying to patent it supposed to make
us feel safer?

>    Having said all 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.

Cool. But since we have to disassemble the program to figure out how your
program really handles keys...how do we know this?

>    We actually have an advantage because we aren't an established
>    standard.  Because we're small and relatively obscure chances are no
>    one will take the effort to write a password guessing program 

FUD and smokescreen. Security through obscurity.

>    (which
>    incidentally would violate copyright and intellectual property laws.)

FUD and smokescreen. The fact that creating a password program allegidly
violates intellectual property and copyright laws in some country isn't
going to keep somebody from writing one.

>    Even if someone were to go thru all this effort we could easily
>    change the encryption method for the next update.

I doubt it's much effort. For example it can take 3 weeks for a group of
programmers to write a copy protection algorithm for their new PC game and
about 8 hours for a cracker to break it.

Further, if they're patenting this algorithm it will be public.

FUD.

>    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

FUD. Decrypt in relatively small pages and cache in memory. Since they've
apparently added an encryption/decryption layer between the filesystem and
the userspace libraries to begin with this shouldn't be too hard.

Well, then again, considering this is Windows which is probably the
worst attempt at an operating system this decade maybe it isn't.

>disadvantages.  First, if your computer shuts down while you have
>    "encrypted" files open, then those files would be unencrypted.  This

Not an issue if the operating system and/or encryption program are/is properly
designed. 

>    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!

Finally something which might actually be valid.

>    If you still think you'd like to see us use a standard encryption
>    method like DES or Blowfish, or have any other suggestions, let us
>    know and we will consider your input in future updates

Unless these people have released source this program should be avoided. The
algorithm is unknown, they aren't telling what it is or how it works, it
hasn't been submitted for review by cryptographers (at least this list hasn't 
heard about it), and they aren't releasing source so you can see what's going 
on. They're hyping security through obscurity as a valid security method,
while simultaneously applying for a patent on their security method and saying 
"Well, if it's cracked we'll just change to another algorithm whenever we
get around to releasing the next binary-only distribution. Hope nobody gets
your data in the meantime."

Further, it is designed for use on an operating system which is notorious
for insecurity, where everybody and everything is root (except under NT,
where you actually have to make some syscalls to get admin privlidges from
an unprivlidged account), where nobody releases source for anything, and
where there is no source available for the OS so you can modify it to fix
security holes or "features," much less add security enhancements of your own.

This entire thing reads like this: "We've developed our own proprietary
encryption method which nobody has ever heard of. We don't really know how
good it is, but you should believe us when we say it's really, really good.
In fact it's so good that we're patenting it just like RSA! Nobody will ever
be able to break it because our algorithm isn't in wide use and we aren't
releasing source! However if somebody actually does break it your data won't
be in the open for long because we'll use some other algorithm which is just
as good as the one we came up with originally and got a patent on. Hope you
didn't need security in that interim and we hope that when somebody breaks
this algorithm they'll tell us rather than taking advantage of all the (for
them) plaintext data laying around."