Re: Security of Encrypted Magic Folders

[geeman@best.com]

Sounds like a crock.  See the Snake-Oil FAQ.
This (mis)information is so full of nonsense I wouldn't touch the product
with rubber gloves.

At 07:51 PM 12/4/97 -0800, Alex Woolfson wrote:
>
>Hello, all!  Back reading the list after a long hiatus.  Glad it's still as
>good as ever.   Anyway, thought I'd appeal to the collective brain trust as
>this question is over my head.  Please "cc" me directly since I'm on the
>filtered cypherpunk list.
>
>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.
>
>Thanks!
>
>Alex
>
>
>* 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.
>
>    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 high security and high speed.  We are trying to patent EMF's
>    encryption method.
>
>    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.
>    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 (which
>    incidentally would violate copyright and intellectual property laws.)
>    Even if someone were to go thru all this effort we could easily
>    change the encryption method for the next update.
>
>    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!
>
>    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
>
>
>