Message-ID: <200501210737.j0L7bP0Q023370@turing-police.cc.vt.edu>
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks@...edu)
Subject: harddisk encryption 

On Fri, 21 Jan 2005 00:23:40 CST, Frank Knobbe said:

> Since others are still throwing in their recommendations, let me add
> mine as well. Back in the days when I used Windows, I really liked
> HardDisk Encryption Plus from PCGuardian (www.pcguardian.com). It is a
> full-disk encryption program (or just a partition if you like). My old
> NT4 laptop was encrypted with it. No problems. Nice admin and recovery
> features. But what I really liked was the transparent encryption of the
> whole disk which you unlocked with a password on boot-up.
> I believe they still offer eval versions. Feel free to give them a try.

(Not getting on PCGuardian in particular.. it's an endemic problem)

It's almost trivially easy to make a product that *looks* like it's
working.  Doing crypto *right* is a lot more challenging, and there's
a lot of snake-oil crypto out there.  Some of the people think they
really know what they're doing, and some don't care that they don't....

A *partial* list of things to look at:

1) Is the basic crypto algorithm something considered secure?  Or are
they using their own cypher which may be totally borked?  Probably still
a lot of code out there using single-DES even though that's not enough
these days - and a certain company brought DMCA charges against a Russian
programmer for revealing their "secret sauce" was rot-13.  Some even
advertise their "top secret 16000-bit encryption" - any idiot can design
a crypto system they don't know how to break.  Building one that nobody else
can break is incredibly tough (how many cryptographers have designed more
than one system that stood up to more than a few years of attempts to
break it?)

2) Is key management done correctly?  This is the next big weak area for most
systems.  It may keep a copy of the key around in memory or on disk. If it uses
a passphrase to scramble an on-disk private key, it may allow too-low entropy
limits on the passphrase.  Consider suspect anything that advertises "key
recovery" so upper management can get the files back even if a key employee
dies/leaves and takes the passphrase with them - the number of crypto experts
that can correctly implement a key escrow or a threshold secret sharing scheme
is much lower than the number of companies selling stuff that claims to do it.

3) Initialization Vectors:  another tricky spot.  For instance, the current
Linux 'cryptoloop' is known to have an IV scheme that suffers from a watermark
attack - if you store content provided by an attacker, they can insert a
"watermark" in the data which allows them to conclusively prove their data is
on your disk even without knowing the encryption key. This can be a *serious*
issue if you are, for example, trying to use encryption to hide a pirated copy
of an album from the ??AA copyright police - if they can hand you (possibly via
a series of intermediaries) a .MP3 or a movie that they control the bits. they
can "tag" it so they can prove it's on your disk...

4) Information leakage - is it possible to get the software to cough up any
internal state information it shouldn't?

That's just a *partial* list of holes that crypto software can be
carrying around.

And consider the only reason that anybody ever uses crypto for anything - a
hidden crypto hole that you don't know about is is infinitely worse than a bug
that merely renders it visibly dead and useless....

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 226 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050121/01e23276/attachment.bin

Powered by blists - more mailing lists