Make your own free website on

Creative Commons License
This work is licensed under a Creative Commons License.

How to defend your Privacy


by Anonymous

Nedstat Basic - Free web site statistics

Don't want to be tracked? Then use an anonymous HTTP or SOCKS proxy!

Part 1: How to securely sanitize hard disks (June 21st, 2004)

Part 2: How to securely encrypt hard disks (June 21st, 2004)

Part 3: Defeating your enemy by learning from him (June 21st, 2004)

Part 4: How to hide your data (in preparation)

Part 5: How to stay invisible (in preparation)

1. Sanitizing Hard Disks
    1.1 Introduction
    1.2 Physical Destruction
    1.3 Degaussing
    1.4 Overwriting
       1.4.1 Official overwriting standards
       1.4.2 Bruce Schneier's 7-pass method
       1.4.3 Peter Gutmann's 35-pass method
       1.4.4 Defeating Intelligence
       1.4.5 Open Source matters
       1.4.6 About hard disk densities
    1.5 Conclusion

1. Sanitizing Hard Disks

    1.1 Introduction

Basically, there are 3 techniques for properly sanitizing hard disks:

i) Physical destruction
ii) Degaussing
iii) Overwriting the disk's data
While degaussing and overwriting considerably increase an attacker's effort, solely physical destruction provides 100% secure deletion of data from hard disks.

    1.2 Physical destruction

Smelting or pulverizing the platters of a hard drive seem to be the best ways to get rid of your data forever.
Just breaking the platters in a few pieces is probably not enough. Dean Devera (The Difficulty of Data Annihilation from Disk Drives: or Exnihilation Made Easy) remarks:
"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.

That physical destruction does have to be applied properly shows the following report from the Computer Crime Research Center:
"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.

Nevertheless degaussing should be handled with care. Charles Preston (who attended the FBI National Academy and wrote the article "The Data Dilemma" Security Management, February 1995) once answered a question on Privacy Digest 4.06. Here's some short cutout:
"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.

Not recommended patterns include:
-US NAVSO P-5239-26 (RLL) (3 passes)
-US NAVSO P-5239-26 (MFM) (3 passes)
-US DoD 5220.22-M (8-306./E) (3 passes)
-US DoD 5220.22-M (8-306./E,C and E) (7 passes)
-US AR 380-19 (3 passes)

-ACSI 33 605 (2 pass * n) ( Australia)
-BSI GSHB M2.167 (3 passes) (Germany)

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
Bruce Schneier in his book "Applied Cryptography" (1996):
"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
Here is Peter Gutmann's statement in the updated paper "Secure Deletion of Data from Magnetic and Solid-State Memory":

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

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:
-DBAN (boot and nuke program) by Darik Horn
-Wipe (Linux) by Tom Vier
-Eraser (WinNT/2000/XP, Win9x) by Sami Tolvanen, Garrett Trant, Bill Johnson
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").


1. Devera D: The Difficulty of Data Annihilation from Disk Drives: or Exnihilation Made Easy. (December, 11th 2001)
2. Gutmann P: Secure Deletion of Data from Magnetic and Solid-State Memory. Proceedings of The Sixth USENIX Security Symposium (1996). pp 77-90
3. Schneier B: Applied Cryptography. John Wiley & Sons, Inc. (1996). 2nd ed.
4. Gutmann P: Secure Deletion of Data from Magnetic and Solid-State Memory. updated paper
5. Gutmann P: Data Remanence in Semiconductor Devices. Proceedings of the 10th USENIX Security Symposium (2001). pp 39-54.
6. Garfinkel S and Shelat A: Remembrance of Data passed: A disk sanitization study. IEEE Security and Privacy, January/February 2003. pp 17-27

2. Encrypting Hard Disks
    2.1 Important preliminary information
    2.2 Full/partial disk encryption for Windows OS
        2.2.1 Full disk encryption: Commercial products
  Which software shall I use?
        2.2.2 Open Source solutions
        2.2.3 Know your enemy
        2.2.4 Removing insecure Windows components
    2.3 Disk encryption for Linux/Unix
        2.3.1 Introduction
        2.3.2 Survey of disk encryption approaches for Unix-like OS
        2.3.3 Which encryption system shall I employ?
    2.4 Discussion of encryption algorithms
       2.4.1 Recommendations

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:
Snake Oil Warning Signs: Encryption Software to Avoid by Matt Curtin

Common criteria (EAL) validated products:

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.

-SecureDoc (EAL 1)

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

-Pointsec for PC (EAL 4) : all Pointsec products are company solutions.

-Encryption Plus Hard Disk (EAL 1)

Common criteria (EAL) pending products:

-SafeBoot Professional

Neither validated nor pending products:

-DriveCrypt Plus Pack

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.
 Which software should I use?
The NIAP (National Information Assurance Partnership; an U.S. Government initiative) maintains a list of Validated Products.
The section Sensitive Data Protection lists the following software solutions for a full hard disk encryption under Windows OS:

-Encryption Plus Hard Disk 7.0 (PC Guardian; USA) -> EAL 1
"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]

-Pointsec PC Version 4.3 (Pointsec Mobile Technologies, Inc; Sweden) -> EAL 4
"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]

-SafeGuard Easy for Windows 2000, Version 1.0 (Utimaco Safeware AG; Germany) -> EAL 1
"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 Disk Encryption, version 2.0 for Windows 95/98 and Windows NT (WinMagic Inc.; Canada) -> EAL 1
"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 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:

-Low Security Level:

Your enjoyable Grand Mother is a hacker novice and feels like hacking your computer.

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

-High Security Level

Your now evil Grand Mother finally turned into an UberHax0r and CryptoGuru. She regularly hacks into various supercomputer grids and possesses more computing power than the NSA. She identified you as a threat to national security and hence calls the FBI.

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

Here's a statement from Poul-Henning Kamp, the creator of GBDE, on existing disk encryption approaches:

"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

- CFS: Cryptographic File System

CFS offers the user a "secure directory" (usually /crypt ) whose content is encrypted transparently.

+ 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

You can find Matt Blaze's paper here.

-TCFS: Transparent Cryptographic File System

Based on CFS. 2 main differences compared to CFS:

i) encryption routines are implemented into the kernel -> you need a patched kernel
ii) no plaintext sent over the network -> better suited for networks

+ faster than CFS
+ Works transparently with the remote file system

- One cipher is used for all operations
- encrypted files are accessed simply by logging in. password length restricted to 8 characters
- encryption keys are stored on disk in a key database

- SFS / StegFS

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]

- CryptFS

implemented for FreeBSD, Linux, Solaris.
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]


"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]

- NCryptFS

- security only as strong as the user password (as with most systems)
- directory structure not protected

- vncrypt

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)

Also see The CryptoGraphic Disk Driver by Roland Dowdeswell and John Ioannidis

- GBDE (FreeBSD)

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

Also see GBDE - GEOM Based Disk Encryption by Poul-Henning Kamp

- OpenBSD vnd(4)

OpenBSD's Vnode disk driver, vnd(4), supports encrypted file systems.
so far only Blowfish implemented.
similar to Cryptoloop with a file as backing store

- no cryptographic hash transform -> no protection against dictionary attacks

-> OpenBSD Encrypted Virtual Filesystem Mini-HOWTO by Kyle Amon

- PPDD: Practical Privacy Disk Driver

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

There exist PPDD-enabled rpms for Red Hat Linux.

- Loop-AES

loadable Linux kernel modules.
no kernel modifications.
uses AES.

For more info read the Loop-AES-Readme!

- Cryptoloop

"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]

- Cryptoloop is vulnerable to optimized dictionary and watermark attacks

Cryptoloop HOWTO by Ralf Hoelzer January 15th 2004. (Cryptoloop/CryptoAPI; for Linux Kernel 2.6)

- dm-crypt

"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]

- dm-crypt is, like Cryptoloop, vulnerable to optimized dictionary and watermark attacks

*Comment on Loopback File System approaches*

"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

- EncFS: Encrypted Filesystem module for Linux

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

"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]

- Rubberhose

transparent encryption.

        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!

a) SWAP encryption possible?

no 1
no 2
NCryptFS no 3
? 4
OpenBSD vnd(4)
no 6

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 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 device
4 Maybe with swapon? If you have a FreeBSD box running, ask the FreeBSD crypto community for advise or simply use GBDE.
5 gbde_swap script

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

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
FreeBSD 4.x/5.x
requires 5.0 or higher
OpenBSD vnd(4)
? 1
Linux 2.0, 2.2. and 2.4
Linux 2.0.x, 2.2.x, 2.4.x (2.4.7 or later) and 2.6.x
(based on CryptoAPI)
Since kernel 2.6, the CryptoAPI has been integrated into the main kernel.
Hence Linux 2.6 has already built-in cryptoloop support.

For earlier kernels (2.2., 2.4 and 2.5) you have to apply the International Kernel Patch
With Linux 2.6.3-mm1 kernel, Cryptoloop was replaced by dm-crypt

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.
Building a Secure Mobile OpenBSD Workstation

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

" 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:

precomputed ciphertext                               silly password
~~~~~~~~~~~~~~~~~~~~~~                   ~~~~~~~~~~~~~~
3288d92bcd29df6756fdf12804566612         FUBAR
4d0ae7ae3d261d3d26898882bc1fb2f2     mercury
521e79d1791ea67bbddb9dd9cc0b3131     password
5491b0159ac34f130804fef2ef72aed1         letmeinNOW!
6dfd1358075030c91d55038ad7f1aca4     **********
6e87eb085049906e9ecb43300f3f170d     swordfish
eab19121387408bfa5d76d7cd124631f         backdoored

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.

If you still want to use "back-doored" CryptoAPI, then read this:

A structured approach to hard disk encryption by Boyd Waters September 11th 2003. (CryptoAPI; for Linux Kernel 2.6)

Linux Encryption HOWTO by Marc Mutz October 4th 2000. (CryptoAPI, Kerneli Patch; for Linux Kernel 2.2)

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.

Encrypted Root Filesystem HOWTO by Christophe Devine  December 1st 2003. (loop-AES; for Linux Kernel 2.4)

Disk Encryption HOWTO by David Braun December 18th 2003. (loop-AES; for Linux Kernel 2.4)

Further Reading:

Demands, Solutions, and Improvements for Linux Filesystem Security by Michael A. Halcrow (coming soon :D

Operating System Support for Extensible Secure File Systems by Charles P. Wright May 2004
(survey of file system encryption)

Cryptoloop - why they are only partial secure by Nico Schottelius, 27-Mar-2004

Vulnerability in encrypted loop device for Linux by Jerome Etienne December 27th 2001

Encrypting Virtual Memory by Niels Provos

TransCrypt | a Crypto Layer above the File System by Roland Schulz and Matthias Bauer

For more information see the linux-crypto mailinglist

    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.

You should not use one of the following block ciphers:

- DES ( 64 bit Blocksize / 56 bit Key length)

The fixed 56-bit effective key length of DES is too short to prevent brute-force attacks.

- IDEA ( 64 bit / 128 bit )

"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]

- TripleDES ( 64 bit / 112 bit effectively )

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

- Blowfish ( 64 bit / 32 - 448 bit )
"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."

- CAST 128 ( 64 bit / 40 - 128 bit )

It is recommended to use one of the following block ciphers:

- AES (=Rijndael) ( 128 bit Blocksize / 128, 192 or 256 bit Keysize )
"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]

- Rijndael ( 128-256 bit / 128-256 bit) [chosen for AES]
"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]

- Twofish ( 128 bit / 8 - 256 bit ) [AES finalist]
"As of 2004, there is no known attack on Twofish more efficient than brute force key search." [Source]

"The best known attack is on 5 rounds. 10 rounds using related or weak keys. 16 are proposed." [Source]

You can find a security evaluation of Twofish by NESSIE here.

- Serpent ( 128 bit / 128, 192 or 256 bit ) [AES finalist]
"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."

        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 Blowfish if 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

3. Defeating your enemy by learning from him

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

Opportunities for Assault

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.

Additionally, you should have a look at Defeating Forensic Analysis on Unix.

Search Engine Submission and Internet Marketing