Any software claiming to cryptographically protect your data should use a cipher (encryption algorithm) that meets public standards, and has an extensive history of independent cryptanalytic validation. Its key-size should place its workfactor ("cracking" resistance) well beyond the limits of today's export controls (and of computing power increases expected over the lifetime of its encrypted ciphertext).

In addition, however, its implementation should meet the standards for that cipher's strongest operating modes, so as to provide a cryptanalytically secure cryptographic engine. Most importantly, the complete software cryptosystem in which the engine is embedded (not just the engine) should meet (and pass the DERIVED TESTS for) NIST's FIPS PUB 140-1, SECURITY REQUIREMENTS FOR CRYPTOGRAPHIC MODULES.

Clearly, a Windows® cryptosystem should meet this standard while operating under Windows®. But, even the strongest lock is useless if it can be bypassed, so such a cryptosystem should also include specific functions to plug Windows® security leaks. These forensic software countermeasures should be seemlessly integrated; be clearly identified; and require minimal user-intervention for their effectiveness.

Many encryption software products, though they encrypt with strong ciphers, do not include such functions. They were designed for e-mail COMmunications SECurity between secure systems, rather than secure data storage on unsecure systems. Their ciphertext doesn't have to be "cracked;" un-encrypted plaintext is available.

Some (such as PGP for Windows®) don't contain functions to prevent Windows® from ignoring their attempts to securely overwrite discarded plaintext files. Others (such as the DOS version of PGP) do contain such functions, but Windows 95® ignores their 16-bit cache-flushing calls, anyway. Most do nothing to eradicate the copies of your passwords or encryption keys in the Windows® swapfile, or the "temporary" copies of your plaintext files that Windows® makes every time you print them, in disk clusters that are merely unlinked ("deleted") and left available on the disk for forensic recovery.

Meeting independent standards and plugging Windows® security leaks makes the difference between Windows®-compatible software designed to encrypt copies of data for communication, versus software cryptosystems specifically designed for its secure storage on PCs or laptops through truly Windows®-compatible encryption.

The type of software-based "data recovery" attacks mounted by forensic software may be defeated by Sanitizing (or even Clearing) per DOD 5220.22-M. However, files can be of any number of bytes, while Windows® can only address disk space in clusters of 512-byte sectors, whose unoccupied remainders can contain sensitive plaintext.

Consequently, forensic software countermeasures should include functions to

(1) Clear previously deleted data from all unallocated clusters on a drive (disk slack) - automatically on exit for whichever drive Windows uses for the TEMP space into which it leaks non-zeroized printer spooling files, unless the TEMP space has been configured on a RAM drive;

(2) Clear the tails of all existing files on a selected drive (file slack), to eradicate deleted data held in subsequently reallocated clusters (any file written to disk by the encryption software should have its tail Cleared automatically, in order to zeroize RAM buffer scavanging leaks);

(3) Clear the internal slack space (not just the tails) of all compound files created by MS Word®, MS Excel® and similar application programs (OLE container slack), to eradicate deleted data captured in the interiors of such files - automatically as part of the operation to Clear file slack;

(4) Clear the entire swapfile (not just the unallocated clusters from those virtual memory pages which Windows® has released at the moment), in order to eradicate non-zeroized object leaks - automatically on exit;

(5) Sanitize all unallocated clusters on a drive, for disposal of hard disks (or floppy diskettes prior to destruction) from which all files have been deleted; and

(6) Sanitize all disk sectors occupied by any sensitive plaintext file to be discarded, including the file's tail (to be performed automatically on plaintext after encryption, using the larger of the plaintext file's current size or its size at last decryption, to counter file-editing deletion leaks);

Functions (1), (2) and (3), and (4) should be used to Clear the drive of a PC or laptop meant to be recycled to other users without having to re-install all the software on it.

Function (5) should be used for purging hard disks classified as less-than-Top Secret (not DoD Classified floppy diskettes, which should be destroyed per DOD 5220.22-M).

Function (6) must be implemented with full understanding of the idiosyncracies of the operating system layers between the file-manipulating commands at the Application Programmimg Interface and the actual performance of disk overwriting, to prevent Windows® from ignoring intended overwrites and instead merely "deleting" the file.