"It is exceedingly difficult, but not impossible
if we're dealing with relatively few pieces. Once reassembled,
high-powered magnetic microscopy could then be turned to the media
surface. [...] But the possibility of platter reconstruction exists,
however minute." [1]

If heat is used for physical destruction,
one
must take into account the Curie point, where
the material looses its
ferromagnetic
properties. E.g. the Curie point for pure iron (Fe) is
above 750 degrees Celsius. Consider that the drive's case gives some
protection against temperature changes. The Curie point must be
exceeded on the platters directly for quite a long time.

"The detailed examination made
it possible to restore most files that the criminal tried to damage
through physical destruction of the computer hard disk. The
technically
correct investigation materials including expert examination results
allowed proving guilty of Mr. F. and institute criminal proceedings
against him." [Source]

1.3 Degaussing

The coercivity
used for proper degaussing depends on the drive and its
materials. Generally, adequate magnetizing forces start with 0.8 Tesla.
Unless working in a clinic, where magnetic
resonance tomographs usually
provide 1.5 or 2 Tesla (research facilities might have more
sophisticated scanners up to 9 Tesla), the normal citizen is not
equipped with means of creating these strong magnetic fields.

"Degaussing (strong magnetic fields that destroy
patterns on the
media) with a very strong magnetic wand or strong degausser will make
the data very expensive and difficult to recover.
A report from the Institute for Defense
Analyses from several years ago stated that with enough processing
power and time, data could be recovered almost regardless of the method
used to erase it. The same report gave a rule of thumb about the
necessary strength of magnetic fields used to erase data. If this
holds true for newer media like high-density diskettes and DAT drives, it may be
impossible to adequately erase this media, including hard drives, with
current degaussers."

1.4 Overwriting

Overwriting is, if properly applied, a thoroughly secure way of
erasing data from hard disks.Warning: There may occur errors in a hard drive. These bad
sectors are
then mapped and locked by the drive. I.e. no regular software will then
be able
to access these bad sectors and information in these will NOT be
overwritten by what pattern ever. There do exist software tools that
directly access the drive, but those are usually restricted to vendor
staff.

1.4.1 Official overwriting standards

There are several different overwriting patterns, proposed by various
intelligence, the military and government organisations.
You should
make yourself clear that no government in this world will ever publish
a method that will protect you from its law enforcement and
intelligence agencies at the date of publication. E.g. the DoD
5220.22-M pattern (3 passes) is not approved for sanitizing media
that
contains secret or top-secret information by the DoD itself!
Renowned security expert Peter
Gutmann explains:

"The ... problem with official data
destruction
standards is
that the information in them may be partially inaccurate in an attempt
to fool
opposing intelligence agencies (which is probably why a great
many guidelines on sanitizing media are classified)." [2]

Furthermore, most of these official overwriting "standards" contain
static elements, which means that a lot of passes consist of
overwriting with Ones or Zeroes. Later on, we will learn that the best
strategy is to apply a scrubbing with random data to the drive.

Comment: The original
NISPOM (National Industrial Security Program
Operating Manual = DoD 5220.22 M) was first published in 1995. When you
look at Chapter 8
section 306, you can see the "Clearing and
Sanitization Matrix" which prescribes the well-known 3-pass pattern for
hard drives. So far, so good. Since then NISPOM has been changed twice:
in July 1997 and February 2001. After the 2001 change, the recommended
3-pass pattern vanished! The updated NISPOM now only contains a general
description (8.301) of what Clearing(a) and Sanitization(b) mean.
The
same holds true for the Army Regulation 380-19. The version
from
August, 1st 1990 describes a 3-pass pattern for hard disks, whereas
the
updated
version from February, 27th 1998 does not contain information
on specific overwriting patterns any more.
This might indicate that the
progress in hard disk technology with increasing densities causes
considerable problems to those trying to recover deleted information.
Maybe progress in computer forensics is much slower than required to
fill the gap.

1.4.2 Bruce Schneier's 7-pass method

"Most commercial programs that claim to implement the DoD standard
overwrite three times: first with all ones, then with all zeros, and
finally with a repeating one-zero pattern. Given my general level of
paranoia, I
recommend overwriting a deleted file seven times: the first
time with all ones, the second time with all zeros, and five times with
a cryptographically secure
pseudo-random sequence." [3]

First, it must be criticized that Schneier does not explain why he
recommends the described 7-pass pattern. "Given my general level of
paranoia" is all we get to know.
Second, he himself admits:

"Recent developments at the National
Institute of Standards and Technology with electron-tunnelling
microscopes suggest even that might not be enough. Honestly, if your
data is sufficiently valuable, assume that it is impossible to erase
data completely off magnetic media. Burn or shred the media; it's
cheaper to buy media new than to lose your secrets." [3]

1.4.3 Peter Gutmann's 35-pass method

In the time since this paper was published, some people have treated
the 35-pass overwrite technique described in it more as a kind of
voodoo incantation to banish evil spirits than the result of a
technical analysis of drive encoding techniques. As a result, they
advocate applying the voodoo to PRML and EPRML drives
even though it
will have no more effect than a simple scrubbing with random data. In
fact performing the full 35-pass overwrite is pointless for any drive
since it targets a blend of scenarios involving all types of (normally
used) encoding technology, which covers everything back to 30+-year-old
MFM methods (if you
don't understand that statement, re-read
the
paper). If you're using a drive which uses encoding technology X,
you
only need to perform the passes specific to X, and you never need to
perform all 35 passes. For any modern PRML/EPRML drive, a few passes of
random scrubbing is the best you can do. As the paper says, "A good
scrubbing with random data will do about as well as can be expected".
This was true in 1996, and is still true now." [4]

I.e. overwriting with the Gutmann pattern makes only sense if you have
a hard drive that uses MFM/RLL
encoding. In general, MFM was used on
most drives before IDE.
The initial RLL encodings were used until the
mid-1990s. All hard drives acquired after that time should be sanitized
with random data.

1.4.4 Defeating Intelligence

In December 2003, the German news magazine "Der Spiegel" (52/2003)
published an article
covering the issue of secure removal of data.
Among others they quote Roy Pfitzner, an IT security consultant working
for the Department
of the Interior of the Federal
State Brandenburg.
Pfitzner wrote an so far unpublished paper in which he criticizes the
BSI (Federal
Office for IT security)-pattern (3-pass) and postulates
maximum security for the average citizen that would even defy intelligence.
Pfitzner explains that even after 20 times overwriting it is still
possible to retrieve useful information. Secure deletion requires a
"deep clearing process" which means that the data is overwritten with
random data more than 30 times.
The interesting
point is that Pfitzner, unlike others, is likely to have access to
classified papers and resources that allow an assessment of what
(German) law enforcement/intelligence agencies are able and of what
not. If this holds true for foreign intelligence as well cannot be
answered here.

His point of view is somewhat backed by David H.
Schultz ("Beyond
Fingerprints") who writes in a foot note:

"xxii Until recently computer forensic and data recovery
specialists agreed that data overwritten a total of nine times
would ensure the data could not be recovered. With the development of
Magnetic Force Microscopy, however, data can be recovered even after
the hard disk has been overwritten a dozen or more times. The ability
to detect each "layer" becomes progressively more difficult to recover
the older it is. Michael Overly, Overly on Electronic Evidence in
California, p. 2-25. (Eagan, MN: West Group, 1999)."

Though I personally would rely solely on physical
destruction if absolute security is needed, Pfitzner's statement gives
a good estimation of what is needed to reach a high security level with
overwriting methods (given that no sensitive information is locked on
bad sectors).

Overwriting with "random" data brings us to the next very important topic: The creation of strong random numbers.
Read more about the software generation of practically strong random
numbers in Gutmann's Chapter about Random Number
Generation.

1.4.5 Open Source matters

I highly recommend not to use any, most often commercial, closed source
Software.
Use open source Software
instead. Besides being available for free, the
major advantage of open source tools is, that theoretically they can be
checked by anyone for (intentionally implemented) flaws or security
weaknesses which might leave your data not sufficiently erased. One
example is Evidence Eliminator of which some think that it contains a
booby-trap to silently disable itself.

To my knowledge there are only 3 active open source projects available:

The latest releases of DBAN, Wipe and Eraser
contain, besides the
source, signatures which provide some good protection against program
file manipulations.

1.4.6 About hard disk densities

"Finally, however, the best defence against data remanence problems
in semiconductor
memory is, as with the related problem of data stored on
magnetic media, the fact that ever-shrinking device dimensions (DRAM
density is increasing by 50% per year), and the use of novel techniques
such as multilevel storage (which is being used in flash memory and
may eventually make an appearance in DRAM as well) is making it more
and
more difficult to recover data from devices. As the 1996
paper
suggested for magnetic media, the easiest way to make the task of
recovering data difficult is to use the newest, highest-density (and by
extension most exotic) storage devices available." [5]

"Older disk drives left some space between tracks; data written
to a
track could occasionally be recovered from this inter-track region
using special instruments. Today's disk drives have a write head that
is significantly larger than the read head: tracks are thus
overlapping, and there is no longer any recoverable data "between" the
tracks. " [6]

1.5 Conclusion

If absolute security is indicated, then physical destruction (through
smelting or pulverizing) is the only solution.
Degaussing may be an alternative, though I have no data
which might indicate magnetic forces that have been proven to be sufficient
for securely erasing data from hard disks.

When the drive should be
usable after the process of erasure, then overwriting with random
numbers more than 30 times provides a high security level which may
even beard intelligence. I personally suggest 10 passes random
numbers for a medium security level and 2 passes random numbers for a
low level.
Theoretically, true random numbers are preferred to CSPRNG
and PRNG data. However it's quite hard to gain unpredictable
random numbers (unless you
click here). In practice, random numbers from CSPRNG are desirable.
Currently only Eraser uses a practically strong PRNG (ISAAC). (It seems that enabling the ISAAC on Windows XP makes the Explorer crashing)
DBAN and Wipe use the Mersenne Twister;
DBAN allows an optional seeding of the PRNG.
However, it seems plausible that having a strong PRNG is more important
with less overwrite passes, while when overwriting e.g. 40 times, the
Mersenne Twister should be perfectly enough.

The afore mentioned applies to modern hard drives. With
older hard drives (more than ~10 years), the Gutmann Method might
provide a sound mean of sanitization.

I strongly discourage the use of
"official" patterns like DoD 5220.22-M or Bruce Schneier's method.

The use of modern hard drives should increase an attacker's
effort significantly. In general, the higher the density, the higher the cost for
recovery.

Furthermore, by using open source software you can reduce the
risk of getting programs that have built-in mitigation
of security features. If you want to wipe whole partitions/hard drives, then DBAN is the best choice. If you
are operating from within your OS, you have to stick to Eraser or Wipe respectively.

In General, it is recommended to erase full partitions or better the
complete
drive than just single files. Remember that many applications create
temp and/or dump files and that a lot of information is stored by your
OS (esp. by the cheap ones from Redmond), e.g. the tracking features in Windows XP or the SWAP file.

The task of hard disk sanitization becomes clearly easier and more secure when the disk's contents have been properly encrypted before any wiping process. Look to it that every bit is written in encrypted form onto your disk. Notably, it wouldn't make any sense to write your data in plaintext onto the disk, encrypt it after that and then erase it.
If you properly applied a full disk encryption system and never stored your key on the disk, I bet even with a few single passes of random scrubbing no terrestrial attacker will be able to compromise your privacy within the next years.

In conclusion, a combination of strong full disk encryption on all your hard drives and the overwriting with strong
random numbers more than 30 times will give you a sound position of
defence (for an introduction see Sun Tzu's "The Art
of War").

2. Encrypting Hard Disks

2.1 Important preliminary information

- Never ever store your encryption key on your hard disk! Otherwise the password process that unlocks your key can be compromised with dictionary or brute-force attacks. Always put your key file on an external storage device, e.g. CD-ROM,USB-dongle
or floppy. In case of emergency, having the key on a floppy may be your
life insurance. A floppy disk can be easily destroyed by burning it. If
you destroyed the key, your enemy is left with attacking the encryption
scheme itself, which is almost certainly infeasable when you employed
an encryption system with security in mind.

- Don't trust the Boot Partition on your hard disk! Always boot from external media like CD-ROM or an USB device if possible.

- No matter whether you use Linux/*BSD or Windows, you MUST harden your
system. Most, if not all, disk encryption systems protect only your
"cold" disk but offer no further protection in "online" mode. When your
system is running and your encrypted disks/volumes are mounted, you
have to rely on the security of your OS.
You may want to consider the use of a "secure" linux distro in the first place.

2.2 Full/partial disk encryption for Windows OS

2.2.1 Full disk encryption: Commercial products

Before you buy anything that boasts with slogans like "1344 bit Military Strength Encryption" I highly recommend to read this:

SafeGuard Easy (EAL 1) : In
August 2001, it was reported that the Danish police had successfully
cracked 5 of 16 seized computers that were protected with SafeGuard
Easy by German Utimaco AG in a tax evation case against Tvind. It was
speculated that the British Scotland Yard had participated in the
breaking. [Source]Later, a Bo Elkjær (from Ekstra Bladet) claimed that he had interviewed the chief investigator Jens Kaasgaard (police in Holstebro) and that this Kaasgaard said:
"To avoid misunderstandings, we haven't broken Safeguard by technically breaking down the encryption. We have located the
passwords in different ways. We have done it like any hacker would have
done, by trying to figure out the most probable passwords. This has
payed success in five cases."
This explanation seems to be reasonable. If they really cracked Safeguard Easy, why did they crack only 5 of the 16 computers?
Nevertheless, this case should be a warning to all of us.

<>Winmagic, the producer of SecureDoc, claims that Bruce Schneier
(a renowned and well-known cryptographer) "has reviewed and
crypto-analyzed SecureDoc source code. Bruce has verified the strength
of SecureDoc's construction, and testified that there are no security
holes."

Here's Bruce Schneier's statement:
"SecureDoc's sector based encryption is smart. It sits at the lowest
level and intercepts all requests to read and write to the disk, so the
entire disk is encrypted and no sectors are missed. With strong,
trusted encryption algorithms, SecureDoc has a clean design."

CompuSec is a FREE full disk encryption program from CE-Infosys. Unsurprisingly, it is NOT validated.
Personally, I would only use it if I had to protect my box from occasional, inexperienced script kiddies.
Businesses and people with sensitive data are advised to carefully select one of the Common Criteria validated products.
All paranoids MUST employ solutions from the open source crypto community, which means that they have to use a Linux or *BSD operating system.

"PC Guardian has chosen to make a developer claim of compliance.
This means that there has been no independent verification (by either
the evaluators or a third party standards body, such as a FIPS
laboratory) that the implementation of the cryptographic algorithms
actually meets the claimed standards." [Source]"The evaluation of PC Guardian
Encryption Plus® Hard Disk Version 7.0 provides a basic level of
independently assured security in a conventional TOE and is suitable
for the environment specification in this ST. The assurance
requirements were chosen to be consistent with this goal." [Source]

"The TOEs cryptographic functionality is based upon code
that has been certified as meeting the requirements of FIPS 140-1 Level
1. Cryptographic keys are generated, accessed, protected, and destroyed
in accordance with requirements defined by FIPS 140-1 Level 1.
Additionally, the TOE supports important cryptographic operations such
as data and key encryption/decryption." [Source]

"Finally, the evaluators concluded that the independent tests
carried out by them indicated that each aspect of TSFs tested are
functioning correctly as one expects and would anticipate based on
their descriptions given in ST [6], chapter 7 and Functional
Specification respectively." [Source]

"SecureDoc's use of the DES, Triple-DES and CAST5 algorithms and
associated key lengths was validated under the Cryptographic Module
Validation Program (CMVP). The Common Criteria evaluation verified that
no plaintext remained in areas of disk media encrypted using SecureDoc. The cryptography, however, was not validated
to FIPS 140-1, meaning that the ability of cryptography to withstand a
concerted attack effort is unknown and cannot be inferred from the
algorithm validation effort." [Source]

EAL stands for
Evaluation Assurance Level. The higher the number, the more thorough
the security testing. I.e. an EAL 4 certified product has undergone a
more indepth testing of its security implementation than an EAL 1
solution. BUT: how secure an EAL 4 product really is, can only be snatched from the certification report. The
evaluation team tests the system in a given environment or for a
special
purpose. E.g. this allows a server manufacturer to let his product be tested in
an environment that contains only a few threats. By this, a product can
achieve EAL 4 without being secure from remote attacks!
The fact that Microsoft gained EAL 4 for
its Windows 2000 OS should make your alarm system go off! Here you can read more about this "deal".

Nevertheless, it's much better to use certified software than not validated programs.

Based on the Certification Reports for the four above mentioned
products, there is a clear recommendation for Pointsec PC Version 4.3.
Unfortunately, all Pointsec products are company solutions. (more info soon)

Limitation: Though this seems to be paranoia, it is possible
that the NIAP list of validated products (only) contains products that
can be easily bypassed by US intelligence or law enforcement agencies.

Further Warning: All full disk encryption products for the Windows OS
are commercial.
These products are often used by companies. What if the CEO
looses his
key? It is possible and maybe even probable that these products contain
"reset codes" or other "backdoors" whose primary intention are, to
recover assets if keys of an authorised user are lost. These
"backdoors" can also be used by any intelligence to
compromise your system! Don't be too sure that companies won't
implement such
"recovery" functions because of their reputation. As long as you don't
have the source code, you cannot proof that there is none.

2.2.2 Open Source solutions

If you don't fear the police or your local intelligence agency, you can well live
with one of the above mentioned products. Otherwise you have to stick
to open source.
Cryptographic applications are often broken not because
of the underlying encryption algorithm, but because of an improper
implementation. Open source cannot guarantee that the implementation is
strong, but at least it can be peer reviewed and if experts on that
field don't find anything, you have a good chance of winning the race.

To my knowledge, there are only 2 open source hard disk encryption
tools for Windows OS: Truecrypt and PGPdisk.
PGPi 6.02 also includes PGPdisk. PGPdisk lets you create "Container"
files. You then mount these container files and they act as Virtual
Drives. Truecrypt even lets you encrypt whole partitions.
PGPdisk encrypts the data with CAST-128. Truecrypt lets you choose
between Blowfish, CAST-128, TripleDES and IDEA.
Furthermore, Truecrypt offers "plausible deniability".Truecrypt
is quite a young project, so it has not undergone a lot of
testing. An anonymous contributor once told me about his Truecrypt
testing experience and he noted that it was working correctly with one
exception: his p2p downloads became "corrupted", though I don't know
which application he used.Warning: At the moment truecrypt.org is not reachable. There are rumours that the authors of Truecrypt are bound by patent disputes.

Beware that both tools won't offer any FULL disk
encryption. You cannot encrypt your root device. Much sensitive data
stored by your OS will not get encrypted! Keyloggers are another
problem. If someone installed a keylogger on your system without your
knowledge, he won't need to do Brute Force or Cryptanalysis, because he
gets the password as soon as you mount your encrypted volume.

2.2.3 Know your enemy

Now that you know that there is no open source solution for a full disk
encryption for Windows, you should reflect who your possible
adversaries might be:

-> Create an Encrypted Volume using Truecrypt/PGPdisk. Put all your
sensitive data in it.
Additionally, disable every unneeded/unwanted Windoze function storing
data on your disk you can! If no information is written to your hard
drive, nothing can be recovered. If you've read the sanitization part, you know
that wiping sensitive data is time consuming and not absolutely secure.
Disable the SWAP file, hibernation and system restoration (these are
very important!). Disable user tracking, recent files history, recent
files in media player etc.
Install every program that may create copies of your sensitive data
(e.g. MS Office) into the encrypted volume. Be sure that these programs
don't put any tmp files on your root filesystem. Otherwise these copies
are
laying in plaintext somewhere on your root or program partition.

-Medium Security Level:

Your angry Grand Mother became an elite hax0r and determined crypto expert. She decided not to sell you to the FBI.

-> Get one of the validated commercial FULL disk encryption tools.
You may want to disable the same things that apply to Low Level.

-> Do NOT use any Windows OS! Use Linux or *BSD instead. Apply a strong
open source encryption package. If you cannot get forced (torture) to reveal your
key, you won't probably need Steganography.
Of course you should know what and where your Unix OS stores
information. "Anonymizing
UNIX systems" by THC's van
Hauser may be a start.

2.2.4 Removing insecure Windows
components

If you still depend on Windows XP (or 2000), you should have a look at nLite
and XPlite/2000lite.
These two little programs let you remove unwanted features from Windows
XP (2000).
nLite (by Dino Nuhagic) is for pre-installation tweaking. It lets you slipstream Service
Packs, remove the unwanted programs and then create a "fresh" ISO.
XPlite/2000lite are for post-installation only. Once you did a clean
install, run the program and remove whatever you want.
Delete all features you do not explicitly need. A minimum system should
be your goal.By totally removing unneeded features you can significantly improve your security and privacy
situation.
I advise you to do a backup before any Windows tweaking. Beware that
nLite is still in beta phase and that you should wait for a final
release before using it for a productive system.

2.3 Disk encryption for Linux/Unix

2.3.1 Introduction

"Several implementations have been produced which implement a disk
encryption feature by running the user provided passphrase through a
good quality one-way hash function and used the output as a key to
encrypt all the sectors using a standard block cipher in CBC mode. A
per sector IV for the encryption is typically derived from the
passphrase and sector address using a one-way hash function. Two
typical examples are [CGD] and [LOOPAES]. Unfortunately this approach suffers from a number of significant
drawbacks, both in terms of cryptographic strength and deployability.

Protecting a modern disk, typically having a few hundred millions of
sectors, with the same single 128 or 256 bits of key material offers an
incredibly large amount of data for statistical, differential or
probabilistic attacks in the future.
Worse, because the sectors contain file system or database data and
meta data which are optimised for speed, the plaintext sector data
typically have both a high degree of structure and a high
predictability, offering ample opportunities for statistical and known
plaintext attacks.
This author would certainly not trust data so protected to be kept
secret for more than maybe five or ten years against a determined
attacker." [Source]

So far so bad. But is there any secure disk encryption system for
Unix-like OS? Well, I cannot give you an answer like "The best system
is ...", but I'll do my best to give you important information on the
security of various approaches. Neither will I present a detailed
technical explanation, nor will I focus on trusted network file systems.

If you don't want to read through the short
descriptions of the various solutions and linked technical papers,
simply jump to 2.3.3.

2.3.2 Survey of disk encryption approaches for Unix-like OS

+ No kernel modifications (works completely in user space)
+ System independent architecture, which makes deployment possible on
almost all Unix Systems (basically only NFS compatibility needed).
+ Independent of employed file system
+
CFS supports the use of Smart Cards for storing the passphrase

- does not protect the filesystem meta-data (CFS encrypts each file separately and doesn't encrypt file system meta-data)
-> directory layout visible
-> position, count and size of files are in plaintext
-> possible
"known plaintext" attack: files and file activities can be analyzed,
file content (at least the beginning) can be deducted from size and
position
- slow (because of user space and NFS server)
- one password for all files
-
CFS does not secure the key while it is entered (as most other systems)
- As long as the key is
in the memory of CFSd, you have to trust the security of your system (as with most other systems)
- CFS does not guarantee that no vital data appears in plaintext in a paging
device or the system cache

Both SFS and StegFS are based on the work of Anderson et. al. and try not only to encrypt but also to hide the data.
SFS can be seen as a first implementation of the proposed ideas.
StegFS was independently developed from SFS in order to remove SFS's
weaknesses and to provide a fully functional and secure steganographic
filesystem.
This is accomplished through a modified Ext2 kernel driver that keeps a separate block-allocation table per security level.
The
secret data is stored in unused blocks of a partition. In order to
minimize the risk of data loss, several copies of the original file are
created.
According to this work, 4 copies of the original file should be enough so that the risk of data loss becomes acceptably small.

"Although StegFS achieves plausible deniability of data's existence,
the performance degradation is a factor of 6-196, making it impractical
for most applications. " [Source]

Kernel-based.
implemented for FreeBSD, Linux, Solaris.
Performance-tuned.
Uses Blowfish algorithm.
Uses "VNode-Stacking". Encrypted data is written through a loopback file system on the disk.
CryptFS works on file level, which means that it has to process file
contents and file names separately. This leads to performance losses
and various other problems. E.g. you are not allowed to encrypt "." and
"..".
With this approach, the principal directory structure is always
visible. Creating or deleting files is visible to an attacker, which
reduces the security of CryptFS.

"Cryptfs was never designed to be a secure file system, but rather a
proof-of-concept application of FiST [73]. Cryptfs supports only one
cipher and implements a limited key management scheme." [Source]

- ZIA"Zero-Interaction Authentication (ZIA) uses Cryptfs with Rijndael
as a basis for a system that uses physical locality to authorize use on
a laptop [11]. To effectively use file system encryption, users must
provide the system with a passphrase. Normally, after the user provides
the machine with the passphrase, anyone who physically possess the
machine has access to the data. The laptop running ZIA communicates
with an ancillary device that is always in the physical possession of
the user, (e.g., a wrist-watch) that provides the laptop with the
encryption key over a wireless channel. When the device leaves the
vicinity of the laptop, all information in the file cache is encrypted.
When the user returns, the information is automatically decrypted.
[...]Zero-Interaction Authentication (ZIA), another encryption file
system based on Cryptfs, takes the approach of encrypting all pages
when an authentication expires [11]. This is less efficient than the
NCryptfs method, because ZIA will also maintain copies of pages in the
lower-level file system. ZIA requires the initial encryption of pages,
and will use memory for these encrypted pages." [Source]

cryptographic disk driver for FreeBSD.
based on the vn(4) driver.
uses a normal file as a backing store.
similar to cryptoloop.

- CGD (NetBSD)

cryptographic disk driver for NetBSD.
similar to Linux loopback device, but uses a native disk or partition as backing store.
fully featured suite of user-space configuration utilities.
+ n-factor authentication and PKCS#5 used for transforming user passwords into encryption keys.
+ each block is encrypted separately from any other block.
+ different IV for each block (against structural analysis)

based on GEOM (provides modular framework to perform transformations for cryptographic protection of the data)
user-supplied passphrase is hashed into 512 bits of key material.
key material is then used to locate and encrypt a 2048 bit master key on four distinct lock sectors.
when a sector gets encrypted, the sector number and bits of the master key are hashed together with MD5 to create a kkey.
the sector key (randomly generated) is then encrypted with the kkey and then written onto the disk.
the data on the sector is encrypted with the sector key and written on the disk.
similar to Cryptoloop (using a raw device as backing store).

- no PKCS#5,
PBKDF2 or any other iterated salted key generation -> no adequate
protection from dictionary attacks against the pass phrase

PPDD is based on the LoopFS device which allows creating file
systems within files. These files can then be mounted like regular file
systems. The Kerneli project offers patches for LoopFS. The whole file
system structure gets encrypted, including Inodes and Superblocks.

PPDD extends the basic functionality of LoopFS: it is easy to use and
makes backups more secure by offering to store the password-protected
key separate from the user's data.
Another bonus of PPDD is the ability to encrypt the whole system
(including swap partition) and then booting from a secure root
partition. This allows a high security level to be accomplished.

PPDD device driver either is implemented directly into the kernel or done via kernel module.
PPDD uses Blowfish; cipher algorithm is written in assembler -> runs on x86 platforms only.

As long as the secret key is not within the system and the file system is not mounted, PPDD offers a high security level.
As soon as the file system gets mounted, the only protection are Linux
file permissions. Therefore PPDD should reasonably only be employed on
single-user systems (especially if the whole system is encrypted).

"The Linux loopback device driver presents a file as a block
device, optionally transforming the data before it is written and after
it is read from the native file, usually to provide encryption. Linux
kernels include a cryptographic framework, CryptoAPI [53] that exports
a uniform interface for all ciphers and hashes. Presently, IPsec and
the Cryptoloop driver use these facilities.
[...]
Using preallocated files is more secure than using sparse files,
because an attacker can not distinguish random data in the file from
encrypted data. However, to use a preallocated file, space must be set
aside for encrypted files ahead of time. Using a sparse backing store
means that space does not need to be preallocated for encrypted data,
but reveals more about the structure of the file system (since the
attacker knows where and how large the holes are)." [Source]

"In Linux 2.6.4, the Cryptoloop driver has been deprecated by dm-crypt.
dm-crypt uses the generic device mapping API provided by 2.6 that is
also used by the LVM subsystem. dm-crypt is similar to Cryptoloop, and
the architectural overview remains the same. dm-crypt still uses the
CryptoAPI, and the on-disk encryption format has remained the same.
There are two key implementation advantages of dm-crypt over
Cryptoloop: (1) encryption is separated from the loopback
functionality, and (2) dm-crypt uses memory pools to prevent memory
allocation from within the block device driver (eliminating deadlocks
under memory pressure)." [Source]

"The drawback is that a filesystem usually contains a lot of data that
is known to the attacker, so a known plaintext attack becomes more
feasible. The cryptanalyst might also glean knowledge about the
filesystem and its contents by comparing blocks supposed to contain the
same contents if constant IVs are used. Like in TCFS, the same key is
used to encrypt the whole filesystem, so again the attacker has to
compromise just one key to retrieve all the information stored. Since
the filesystem has to be mounted to be accessed, and the key has to be
in the kernel to mount it, any local user with adequate file
permissions can access any file contained in the encrypted volume.
Decrypted pages from encrypted files might end up getting swapped out
to disk and remain there for a long time." [Source]Also see: Vulnerability in encrypted loop device for Linux by Jerome Etienne December 27th 2001

encrypted file system in user space.
uses fuse libary and linux kernel module to provide the file system interface.
works on files, not on a block device.
pass-through-system (not an encrypted block device)

+ easy backups (on a file-by-file basis)

- much information visible to an attacker (count, permissions, size of files, approximate size of filename)

"CryptoFS is a encrypted filesystem for the Linux Userland FileSystem.
[...]
CryptoFS will use a normal directory to store files encrypted. The
mountpoint will contain the decrypted files. Every file stored in this
mountpoint will be written encrypted (data and filename) to the
directory that was mounted. If you unmount the directory the encrypted
data can only be access by mounting the directory with the correct key
again.
[...]
When a filesystem is mounted CryptoFS first generates a key for the
requested cipher algorithm (CRYPTOFS::cipher) using the message digest
function (CRYPTOFS::md). Every algorithm has a specific key size and
every message digest function has a specific length of the generated
message digest. If the message digest size is smaller then the keysize
the message digest will be repeated until the key size is reached.

After they primary key has been generated CRYPTOFS::salts subkeys
(initialization vectors) will be generated by encrypting 0 bytes with a
0 initialization vector. These will later be used to encrypt blocks
with different subkeys to make sure the cipher text will first repeat
after (salts * blocksize) bytes (If the same data is encrypted).

When files or links are created or renamed the name will be encoded
with the selected cipher, the primary key and the first subkey. The
result will then be encoded using a modified Base64 algorithm because
the encrypted filename could contain characters that are not allowed by
the target filesystem. (The original Base64 algorithm uses '/' for
encoding. This is the directory delimiter so it was replaced by '_')

When files are written the data will be encrypted. CryptoFS always has
to write full blocks. So if only a part of a block should be written
the original block will first be read, decrypted, the part replaced and
then the result then written encrypted back to disk. To keep this
performant that block size must not be too large. But to make sure the
cipher text does not repeat to early, CryptoFS uses salts to encrypt
blocks. Every block will be encoded with the (blocknumber module
salts)th salt. (NOTE: Linux always reads or writes "pages" of size 4096
bytes, these writes will be forwarded by lufsd to CryptoFS. So if you
use a blocksize of 4096 bytes reading the old block before writing can
be omitted and writing should be faster)." [Source]

2.3.3 Which encryption system shall I employ?

"And my orders are to weed out all non-hackers who
do not pack the gear to serve in my beloved Corps!
Do you maggots understand that?"

As Gunnery Sergeant Hartman already indicated, my goal is to present
encryption systems that were designed with security in mind.
Therefore, I will define requirements that secure systems should fulfill in order to separate the wheat from the chaff.
In my opinion, the most important questions are:

- Can I encrypt the swap partition?
- How are keys generated, stored and destroyed?
- Can I encrypt my root directory?
- Is the directory structure visible?

There are many other aspects that influence the strength of a system,
but these will be discussed in detail when we narrowed the whole thing
down.
Some of you may be bound to a specific OS or kernel and hence have a
limited choice. However, I will not do a ranking for every OS.

First, we will check whether the various systems support swap encryption.
Why is this so important? - Many computers use a paging device for
swapping data from the RAM to the hard disk for improved performance.
When your swap is not encrypted, you face 2 main problems:
i) the key you use for accessing your data may eventually be
transferred to the paging file (probably this occurs only when you're
short with RAM or running some heavy RAM-eating processes such as video
encoding)
ii) sensitive data you're working with, is stored in the swap file
When you now turn off your computer, an attacker could simply
investigate the swap file and maybe find your key or the data you
normally encrypted in plaintext. So, even if the encryption system
itself encrypts your root directory, stores your key(s) on external
media, uses secure hash transforms and keeps the disk layout invisible,
all this is in vain when your swap is not encrypted!

1 the pager could be directed at a file located in an CFS encrypted
directory. However, this is not implemented.
2 SFS is/was a first implementation of the ideas of Anderson, Needham and Shamir, done by Carl van Schaik and Paul Smeddle.
Their homepage http://leg.uct.ac.za/~carl/vs3fs/
doesn't exist anymore. Peter Schneider-Kamp updated SFS to the Linux
kernel 2.2 (last stable 2.2.1). Now the project is abandoned for almost
5 years and hence is dead.
3 NCryptFS pins the keys in physical memory, yet it does not encrypt an entire swap device4 Maybe with swapon? If you have a FreeBSD box running, ask the
FreeBSD crypto community for advise or simply use GBDE.5 gbde_swap script6 uses a file container for block storage. the authors state that using a partition may be possible, but has not been tested.
Anyway, rubberhose currently only exists for Linux Kernel 2.2 and was last updated on March 28th, 2001 (0.8.3 alpha snapshot).
It is plausible to assume that Rubberhose isn't maintained actively anymore.

Well, you can see that already 10 systems don't pass the first
round. Unfortunately also the 2 systems with steganographic features
(StegFS and Rubberhose) don't provide swap protection. Nevertheless,
this does not mean that you cannot hide your data. There are still
steganographic tools you can use, ahead of a disk encryption system
(There will be info on this in the future:).

Poul-Henning Kamp makes an interesting point:

‘‘[...] The Steganographic File System’’ [STEGFS], which provides a
facility where a hierarchy of passphrases protect data at different
levels. The argumentation more or less goes ‘‘protect a couple of
unimportant files at the lowest level, and your important files at
higher levels. When captured, give them the lowest level key and deny
that any more keys exist.’’
If we include the attacker in the analysis, she will soon know that the facility used is STEGFS, and consequently
that multiple levels of keys are not only a possibility but to be
expected: Why else would people use STEGFS in the first place ?
A user caught with a STEGFS encrypted set of data, will therefore
likely be subject to pressure to release keys until the attacker is
satisfied that there are no more keys. If the attacker is the police,
this can now land the user in jail for up to five years in certain
countries."[Source]

I still believe that steganography is an important concept. Especially when you're living in UK you have to live with RIP legislation, i.e. you can be put in jail for 2 years if you don't hand them over your key.

Second, we will examine whether the remaining systems allow us to encrypt our root directory.

When you look at the table below, you can already see that the BSDs
offer no "full disk encryption". However, especially GBDE and CGD are fairly
secure encryption systems and excluding them just because they offer no
encrypted root filesystem makes no sense.
At this point, you should decide whether you really need an encrypted
root partition. If you're familiar with your *BSD, you probably know
what and where it stores information about your activities and whether
these could compromise your privacy.
If you don't know whether an unencrypted root directory on a *BSD box
poses a threat to your sensitive data, you either have to learn more
about your *BSD system or change to Linux, because currently only a
Linux system offers "full (almost) disk encryption".
Having an encrypted root filesystem is at least much more comfortable.
You don't have to worry that sensitive data is swapping to some
unencrypted disk parts. If you then boot only from a trusted medium
(e.g. CD-ROM, flash device) you don't even have to fear that someone
manipulated your boot process.

b) Encrypted Root directory possible?

Supported Systems

vncrpyt

no

FreeBSD 4.x/5.x

cgd

no

NetBSD

gbde

no

FreeBSD,
requires 5.0 or higher

OpenBSD vnd(4)

? 1

OpenBSD

ppdd

YES

Linux 2.0, 2.2. and 2.4

loop-aes

YES

Linux 2.0.x, 2.2.x, 2.4.x (2.4.7 or later) and 2.6.x

cryptoloop
(based on CryptoAPI)

YES

Since kernel 2.6, the CryptoAPI has been integrated into the main kernel.
Hence Linux 2.6 has already built-in cryptoloop support.

1 vnconfig + union mounting over a minimal unencrypted boot partition?
if you boot from external media,
then there should be a way. Ask the
OpenBSD community for help. I don't want to give you false information.

When running ...

- OpenBSD, then there's only OpenBSD's vnd(4) for you.
Unfortunately, when it comes to key generation, vnd(4) offers no
cryptographic hash at all and hence offers no protection against
dictionary attacks. Adding HMACs should be possible, though you have to write it on your own.

- NetBSD, then there's only cgd, the Cryptographic Disk driver.
Fortunately, cgd seems to be a secure system. AFAIK, cgd is the only
approach that uses a very strong cryptographic hash (PKCS#5
PBKDF2) and thus provides better protection against dictionary
attacks than all the other remaining systems. A disadvantage of cgd is,
that you cannot change the password without reencrypting. Thus
employing cgd in an enterprise or organisation that requires changing
passwords all x days may become impractical.

- FreeBSD you can choose between vncrypt and GBDE.
Personally, I would use GBDE. It takes a much stronger security
approach than vncrypt and has received good reviews from crypto
experts.
"Up to four separate pass-phrases can unlock their own separate copies
of the 2048 bit masterkey. The master-keys are protected using
AES/256/CBC keyed with a SHA-2
hash derived from the pass-phrase. A salted MD5 hash over the
sectoroffset "cherry-picks" which masterkey bytes participate in the
MD5 hash which generates the "kkey" for each particular sector. The
kkey AES/128/CBC encrypts the PRNG produced single-use key which
AES/128/CBC encrypts the actual sector data.
GBDE has features for master-key destruction and pass-phrase invalidation."

- Linux, you can theoretically choose from 4 encryption systems, while actually only Loop-AES and PPDD are fairly secure.

With Kernel 2.6.3-mm1, Cryptoloop was replaced by dm-crypt.
Read what the maintainer of Cryptoloop, Clemens Fruhwirth has to say:"dm-crypt is vastly superior to cryptoloop for a number of reasons:
1) It does not suffer from loop.c bugs (There are a lot, no maintainer)
2) dm-crypt does not depend on special user space tool (util-linux) 3)
dm-crypt uses mempool, which makes it rock stable compared to
cryptoloop."

The two biggest security issues in Cryptoloop are weak IVs and an extremely bad key management.
Jari Ruusu, the author of Loop-AES, reveals:"Kerneli.org loop crypto implementation (and derived versions such as Debian,
SuSE and others) are vulnerable to optimized dictionary attacks because they
use unseeded (unsalted) and uniterated key setup. Mainline linux
implementation is equally vulnerable.

Most, if not all, file systems have known plaintext. On popular file systems
such as ext2, ext3, reiserfs and not so popular minix, first 16 bytes of
fourth 512 byte sector is such good known plaintext. Byte offset 0x600 to
0x60F of plaintext contain all zero bits. File system itself does not use
that data at all, but mkfs for file system in question puts that known
plaintext there. When encryption key setup does not include seed, there will
be direct connection from password to ciphertext. The problem is that these
ciphertexts can be precomputed in advance, and if the database is kept
sorted by ciphertext value, optimized attack is reduced to doing binary
search of precomputed ciphertext values.

You can display precomputed ciphertext with command like this:

dd if=/dev/hda999 bs=16 skip=96 count=1 2>/dev/null | od -An -tx1 -

Here are some samples using AES256 encryption and RIPE-MD160 password hash
function, no seed, no key iteration:

Of course different ciphers, different key lengths and different password
hashes are going to need separate databases as precomputed ciphertects will
be different if key is set up differently." [Source]

Unfortunately, the current dm-crypt does not solve Cryptoloop's
security weaknesses. IV schemes currently supported by dm-crypt are the
same as the ones supported by cryptloop. A difference is that dm-crypt
uses "plain" as default, instead of ECB, which is already an
improvement but is still insecure.

Because of these unsolved security issues in dm-crypt, you should stay
away from dm-crypt (and Cryptoloop) as long as they don't implement a
better protection against dictionary attacks.

Well, after all only Loop-AES and PPDD remain to protect us from the
"Axis of Evil" ("I believe Libya, Cuba and Germany are the ones that
..." | Best wishes from Weyhe-Sudweyhe Mr.-I-don't-know-of-any-torture !)

PPDD or Loop-AES?

Take Loop-AES. Simply because PPDD stores your key on the disk and that is something we don't.
Loop-AES uses more random keys for encrypting the sectors and has
better password seeding. PPDD uses Blowfish, which is a secure block
cipher, but it has a 64 bit blocksize and it becomes risky when encrypting
large texts with a few keys. Loop-AES lets you store your key on
external media and has a wide range of ciphers such as AES, Serpent,
Twofish and Blowfish.
Furthermore Loop-AES is actively maintained and works with 2.6 kernel.
PPDD works only for 2.0, 2.2. and 2.4 kernel and has not been worked on
since February 2002.

2.4 Discussion of encryption algorithms

Most disk encryption systems, be it for Windows or *nix, let you choose
your desired block cipher. Thus we can select the most "secure" cipher.
I will only present encryption algorithms that you can actually choose
in the "selected" programs (Loop-AES, GBDE, cgd, OpenBSD's vnd(4),
Pointsec for PC, SecureDoc, Safeguard Easy, Encryption Plus Hard Disk,
PGPdisk and Truecrypt).
If your encryption system offers additional block ciphers not listed
here, please refer to Wikipedia or search the web on the security of
this cipher.

"IDEA is vulnerable to key schedule attacks, and therefore it should
only be used with keys that are generated by a strong RNG, or by a
source of bits that are sufficiently uncorrelated (such as the output
of a hash function)." [Source]

"Some classes of weak keys have been found (see, e.g., Daemen
[DGV94]), but these are of little concern in practice, being so rare as
to be unnecessary to avoid explicitly. As of 2004, the best attack
which applies to all keys breaks 5 out of 8.5 rounds [DTS03].
Bruce Schneier thought highly of IDEA in 1996, writing, "In my opinion,
it is the best and most secure block algorithm available to the public
at this time." (Applied Cryptography, 2nd ed.) However, by 1999 he was
no longer recommending IDEA due to the availability of faster
algorithms, some progress in its cryptanalysis, and the issue of patents." [Source]

"Triple-DES has a key length of 168-bits (three 56-bit DES keys),
but because of an attack it has an effective key size of 112 bits" [Source]

"Quoting from the paper "Attacking Triple Encryption" cited above:

[A]bout 2108 steps of computation are
sufficient to break three-key triple DES. If one concentrates on the
number of single DES operations and assumes the other operations to be
much faster, 290 of these are enough.

Better attacks than this are available against
two-key triple DES (which should only be used for backward
compatibility, if at all)."[Source]

You may use one of the following block ciphers:(Though it is not recommended to use ciphers with a 64-bit Block size!)

"There is no effective cryptanalysis of Blowfish known publicly as of 2004, although the 64-bit
block size is now considered too short, because encrypting more than
232 data blocks can begin to leak information about the plaintext. Despite this, Blowfish
seems thus far to be secure, although specific implementations may not be." [Source]

"The weak keys described in Vaudenay's paper do not appear to be
significant for full (16-round) Blowfish."[Source]

"In June 2003, the US Government announced [1] that
AES may be used for classified information:
"The design and strength of all key lengths of the AES algorithm (i.e.,
128, 192 and 256) are sufficient to protect classified information up
to the SECRET level. TOP SECRET information will require use of either
the 192 or 256 key lengths. The implementation of AES in products
intended to protect national security systems and/or information must
be reviewed and certified by NSA prior to their acquisition and use."
This marks the first time that the public has had
access to a cipher approved by NSA for TOP SECRET information."

The most common way to attack block ciphers is
to try various attacks on versions of the cipher with a reduced number
of rounds. AES has 10 rounds for 128-bit keys, 12 rounds for 192-bit
keys, and 14 rounds for 256-bit keys. The best known attacks are on 7
rounds for 128-bit keys, 8 rounds for 192-bit keys, and 9 rounds for
256-bit keys. See [2] for
details of these particular attacks.

Some cryptographers worry about the security of
AES. They feel that the margin between the number of rounds specified
in the cipher and the best known attacks is too small for comfort. The
risk is that some way to improve these attacks will be found and the
cypher will be broken. A "break" in cryptography is anything that is
faster than an exhaustive search, so an attack that requires 2120
operations is considered a break even though it is quite infeasible.
For practical applications any attack which is only just better than
this is irrelevant, and these concerns can be ignored.

Another concern is the mathematical
structure of AES. Unlike most other block ciphers, AES has a very neat
mathematical description [3], [4]. This has not yet
led to any attacks, but some researchers are worried that future
attacks may find a way to exploit this structure.

[...]

September 2002:
A worrying theoretical attack on AES has been announced in a paper by
Nicolas Courtois and Josef
Pieprzyk entitled "Cryptanalysis of Block Ciphers with
Overdefined Systems of Equations". This appears to show a potential
weakness in the AES algorithm. It seems that the attack, if the
mathematics are correct, is not currently practical as it would have a
prohibitively high "work factor". There have been claims of
considerable work factor improvement, however, so the attack technique
might actually become practical sometime in the future.
On the other hand, several cryptography experts have criticised the
underlying mathematics of the proposed attack, suggesting that the
authors have gotten their sums wrong. Whether this line of attack can
be made to work against AES remains an open question. For the moment,
as far as is publicly known, the XLS attack against AES is speculative.
As is currently understood, it may or may not be possible to actually
carry out the attack in practice."[Source]

"After a competition
Rijndael was selected as the successor to DES
and became the Advanced Encryption Standard,
or AES. Strictly speaking, AES is not precisely Rijndael, as Rijndael
supports a larger range of block and key sizes, they can be
independently
specified to any multiple of 32-bits, with a minimum of 128 bits and a
maximum of 256 bits."[Source]

"Serpent was widely viewed as taking a more conservative approach to
security than the other AES finalists,
opting for a larger security margin: the designers deemed 16 rounds to
be sufficient against known types of attack, but specified 32 rounds as
insurance against future discoveries in cryptanalysis."[Source]

"16 rounds are secure. 32 are proposed"
[...]
"For example, Serpent has 32 rounds. The authors claim that 16 rounds
are already secure, and thus the longest variant which is not as secure
as exhaustive search might have 15 or fewer rounds. Serpent is a SP
network, and thus each pass contains one round, and two passes contain
two rounds. Therefore, the minimal number of rounds is at most 17."[Source]

2.4.1 Recommendations

1. Avoid block ciphers with a
block size of 64 bit or less if you can! Therefore, do NOT use CAST-128 or Blowfishif there are better alternatives.

2. Use the largest possible keysize. I.e., if you can choose between
128 bit, 192 bit or 256 bit key encryption, select 256 bit! If you can
use 448 bit, then use it!

3. Perform as many rounds as possible. E.g., if the algorithm lets you
choose between 8 rounds and 16 rounds, then take 16!

AES, Twofish or Serpent?

There are only 2 block ciphers, that are recommended by both NESSIE and CRYPTREC: AES
(aka Rijndael) and Camellia.
It should be noted that there is a wide range of views regarding the
security of AES/Rijndael.

The security of Twofish has been criticised by NESSIE project
members. Some of them state that Twofish seems to have statistical
properties and that the variable S-Boxes might lead to 8-round attacks.
Furthermore, the key-dependent S-Boxes, which should improve security,
may in fact weaken it in some cases. [Source]

"Serpent was widely viewed as taking
a more conservative approach to security than the other AES finalists,
opting for a larger security
margin: the designers deemed 16 rounds to be sufficient against known
types of attack, but specified 32 rounds as insurance against future
discoveries in cryptanalysis."[Source]

Nr. of votes on the last AES conference for ...

-Rijndael 86
-Serpent 59
-Twofish 31
-RC6 23
-MARS 13

When comparing Rijndael and Serpent, which are in fact quite similar,
Rijndael is faster with Software, while Serpent is more secure. The advantage of
Serpent is, that it's based on well-understood mechanisms, which means
that those basic mechanisms have already been extensively studied in
cryptanalysis. Given that the XLS attack does not work (if it works
then you can flush all above mentioned
block ciphers down your toilet!), Serpent
seems to incorporate a more thorough security approach. It uses double the
rounds that are deemed to be secure. Twofish also takes a stronger
security approach than Rijndael. However, Twofish is a quite complex
cipher which makes the analysis fairly difficult and it is hard to tell
whether this complexity might lead to future attacks. In fact, many
argue that Rijndael was chosen as AES because of its speed, especially
in low-RAM and embedded systems.
In conclusion, if you can, then take Serpent. Otherwise you should use Twofish or AES.

Final rating

1.Serpent2.Twofish
3.AES/Rijndael

3. Defeating your enemy by learning from him

How forensic examiners overcome encryption and what we can do against it:

Opportunities for Assault

Countermeasures

simple encryption algorithms like XOR

Use advanced encryption algorithms like Serpent, Twofish or AES

short keys -> brute force attack

Use at least 128 bit keys

weak passphrases

Use a strong password! (More on this topic soon...)

(strong) passphrases are written down

Don't ever write your password down!

Instead of using "x$tB0QH5n8§xI2" as password, use a sentence like
"G30rg3WBu$h1s4dumb4ssth4tg1v3sm34r0y4lp41n1nmy4$$". Contradicting
common belief, such a sentence password is much more secure than a
8-character "random" one.

identical passwords are used on other accounts (e.g. email) that can be monitored

Never ever use the password for your encryption systems for other accounts like email, ebay etc.

observe user when he types in his password

Make sure that noone is watching over your shoulders when you provide the password.
If they installed cameras in your room, then it's maybe already too late.

persuade the user to reveal his key

Well, this depends on how much your enemy already knows and what he can prove.
Let's assume that you got raided because you offered a brand-new music
album. The RIAA investigators know and can prove that you offered album
X. But they don't know that you also have (illegal) copies of another
5.000 albums (given that you didn't burn them on 5,000 CD-Rs).
In this case it makes sense not to give them your key, because they
would find out about the other 5.000. Certainly you'll have to pay less
compensation for 1 album than for 5.000 albums.
Furthermore, don't let the Feds fool you. Feds often tend to flatter you, playing good cop, bad cop etc.
In most situations, not revealing the key is the best strategy.

install software/hardware keyloggers on the user's machine

Keyloggers are one of the biggest threats for
(disk) encryption systems. Minimizing the risk of getting one is
therefor essential.
The best way to defeat software keyloggers is to use a full disk
encryption system that uses an authentication mechanism before the OS (or at least most of the OS)
loads. Most keyloggers (that are part of Trojan Horses) can be defeated
this way. Furthermore you should harden your system and be very careful
in every day use of networks. If your enemy cannot place a keylogger on
your system through a remote hole, he'll probably try to put a hardware
keylogger into your machine locally that will bypass any
PreBootAuthentication. The only thing you can do is use a laptop or
check your machine for integrity every time you boot it.
Any unknown devices between the keyboard and the motherboard or on the
motherboard itself should alert you. Maybe they try to hide it within
the keyboard, so you may want to remove the coating at all.
If you're a truely professional paranoid, you should install systems in
your rooms that show you whether you had uninvited guests during your
absence.
E.g. you could set up a hidden camcorder that can record for a few
hours or buy some nice equipment from your local espionage store.

obtain source code for the encryption system from the manufacturer

This is another big problem, especially for
Windows users. As long as you don't have the source, you don't know and
cannot check whether the encryption system contains secret backdoors
that could be used by your enemy (intelligence) to bypass your
whole protection. The only thing you can do is to use open source
crypto like Loop-AES for Linux.

sensitive data stored in RAM in plaintext

Surprisingly, it is harder to delete data from
RAM than magnetic media if the data is stored there for a very long
time and if the RAM is "fresh".
Make sure that you did fill your physical memory with random noise
before using it with sensitive data. Furthermore, you should keep
sensitive information not too long in your RAM.
If you're finished with hacking the FBI, don't simply shut your machine
down. Either you start a process that eats all your RAM and let this
one run long enough so that most of your RAM got overwritten 50 to 100
times. Or you could create a small Ramdisk and when you're finished you
simply increase the size of your Ramdisk and overwrite the free space
with "random" numbers 50 to 100 times.
If you're in an emergency situation, open your machine quickly, take the RAM modules out and broil them for a few minutes.

post-mortem analysis of RAM

see above

sensitive data stored in SWAP devices in plaintext

either don't use any SWAP at all or use a Full disk encryption system

sensitive data stored unencrypted on backups

Never ever store unencrypted backups of your sensitive information!

single files/folders are simply deleted after the encryption process and not erased properly

only encrypting single files or folders is a very bad idea!If you do this, you only show that
you're some stupid kid and every RIAA/IFPI investigator will laugh at
you!

OS stores copies of sensitive files or maintains activity logs

-> Full disk encryption!
You can also try to disable history logs etc. but you cannot always be sure that Program X did not create a hidden tmp file

applications create temp files of (eventually) sensitive data

see above

OS/applications create dump files

-> Full disk encryption!
Disable the creation of dump files at all if you can

exploit EFS recovery agent

Don't use Windows EFS!
On a Win2k box, all I need is Admin privileges, because Admin is a recovery agent on Win2k. I don't even need your key.
On WinXP/2003 Admin is not recovery agent. Still EFS has some nice
vulnerabilities and it's quite easy to overcome.

encrypted network traffic: exploit protocol vulnerabilities

Though this topic is certainly not within the
scope of this tutorial, you should be aware that sophisticated
attackers actually can break SSL and other protocols probably as well.

encrypted network traffic: break into clients or servers and monitor communication at the end points

Harden your system!

Finally, if you're afraid of the police, don't use Windows! These folks
have a lot of experience with seized Windows machines and most of them
don't even know how to handle a Linux box. If you then carefully employ
something like Loop-AES or GBDE, you'll find them desperately seeking
advice from the Royal Canadian Mounted Police.