Re: Re: disk encryption modes----- Original Message -----
From: [EMAIL PROTECTED]
> Here is a technique for encrypting a hard disk that should provide
reasonable performance, good security, and be
> easy to render the entire disk unreadable in an emergency.
Actually under many circumstances it will be absurdly slow. The rekey for
each block can be extremely expensive.
> 1. Start with a good (P)RNG. Seed it constantly with radioacitve decay
noise, digitized samples of monkeys farting
> into your sound card, keystroke data, mouse squeaks, your favorite
hardware RNG's, etc. Hash and whiten to your
> heart's content, just make sure it can output a few hundred KB/second of
data cryptographically indistinguishable
> from "random" (an attacker having access to the entire of the output of
this device since it started has no more than
> a .5 probability of determining any future bit of the output).
First, it's a requirement for this that an attacker given bits [0,n-1] and
[n, infinite] can determine nothing about n, since you will be using future
values as well.
> 2. Each disk cluster is encrypted individually. (On my 100 GB NTFS drive
the cluster size is 4096 bytes. Different
> drive sizes under different file systems may have different cluster sizes.
For clarity's sake, I will stick with the 4K
> cluster size.) Encryption can be done with any cipher that can accept a
256 bit key, You can use a block cipher (in a
> suitable feedback mode) or a stream cipher. The first 128 bits of each
block key is the master disk encryption key,
> (a hash of a passphrase ors ome such hereafter called the "permanent" key
half) and the other 128 bits are the
> randomest bits you can obtain from the aforementioned (P)RNG whenever a
cluster is written to (hereafter referred
> to as the "temporary" half. The temporary bits of the key are stored in a
separate file which can be on a CDRW disc,
> compact flash card, etc. The format of this file is simple; the first 16
bytes of the file is the temporary 128 bits of the
> key for the first cluster of the disk the next 16 bytes are for the second
cluster, and so on. Each time a disk cluster is
> written to, a new temporary half-key is pulled from the (P)RNG and used to
encrypt the cluster data, and then is
> stored in the temporary key file. When a cluster is read, the appropriate
temporary key half is read from the
> temporary key file, combined with the permanent key half, and then the
data is decrypted.
This has the same need for a second storage location problem as the other
suggestion along the same lines. Additionally it has a key agility problem.
And have you actually done the math on encrypting your 100GB drive, and how
much flash RAM it will take, it will require 200 MB. That is an added
expense which consumers will not like. I checked, devices that large are
still in the multiple hundred dollars category, it would be cheaper to buy a
second hard drive of that size and carry it with you, then you share split
all the blocks, and poof it's secure. But I wouldn't recommend that either.
People wouldn't want to use their CDRW for this purpose, they want to use it
for CDs, not for hard drive access, so that is simply an even more expensive
option (a second CDRW drive).
> Here are the advantages I see with this technique:
> 1. If you edit a sensitive file and save several versions of it, no 2
versions of the file, or even any 2 4K sections of the
> file will be encrypted with the same key, so an attacker will not have
many instances of similar ciphertexts as obvious
> targest for attack.
But it suffers from the worst usage characteristics of any of the
suggestions so far, as well as having the highest pricetag.
> 2. If you need to destroy the encrypted data quickly, and have the
temporary key file on separate media, (like a
> CDRW) the temporary key file can be destroyed quickly (microwave the CDRW
until extra crispy) thereby
> rendering the encrypted data unrecoverable even if the main passphrase is
rubberhosed out of someone.
Or just carry around your CDRW until it inevitably gets scratched and you
lose portions of your hard drive. With flash RAM you don't have this
problem, and it works out less expensive, but it's still multiple hundreds
of dollars, not a viable option.
> Imaginative encryption driver design could have several temporary key
files; a real one and several dummies, so
> that an attacker could be confused as to which file was real until the
real one had already been destroyed.
Which wouldn't matter in the slightest since any reasonable attacker would
simply grab all the disks at once, and worry about which one was real later
on. Not to mention that if the target grabs one disk and tries to destroy
it, that's a major clue as to which one is real.
> The
> temporary key file could also be located in a remote location (preferably
somewhere with no extradition treaty
> with your jurisdiction) if you can find a party there who would be trusted
to cut off access to, and securely destroy
> the real temporary key file (They could continue to provide access to a
bogus one) if a certain signal was received.
Not a bad idea, but it has a fatal flaw, how do you access this data? If you
go over there and grab the disk in person, you'll simple be arrested when
you return, the disk confiscated, and your computer accessed. If you don't
go over there, then the disk is at best useless, at worst your "trusted"
individual sells it to your worst enemies.
> "If I ever tell you to write value X to block Y of the key file, assume I
have been arrested and burn the CD the real
> key file lives on..." If you wanted to get really fancy you could use
secret splitting or RAID techniques where the
> temporary key file is split into X pieces, and Y number of pieces are
needed to reconstitute the entire file. You can
> use whatever values of X and Y you need to satisfy operational reliability
requirements and your paranoia level.
> Comments, nits to pick?
Yeah, it's the worst design suggestion so far, at least at the consumer
level. It may have uses at military levels, or at other levels where cost is
not a concern, but since the target is to get this on every desktop it's
simply not doable.
Joe
