On-The-Fly Encryption: A Comparison

Contents

• Overview
• Special Notice to the Software Authors/Publishers
• Feature Summary
• Comments
• BestCrypt (v6.06)
• BestCrypt (v6.07.2)
• E4M (v2.00)
• E4M (v2.01)
• E4M (v2.02a)
• FLYCRYPT (v1.01)
• F-Secure FileCrypto (v4.0, build 39)
• F-Secure FileCrypto (v4.30)
• Invincible Disk (v2.3)
• Invincible Disk (v3.0)
• PGPDisk (v6.0.2i)
• PGPDisk (v7.04)
• SAFE Folder (v1.01)
• SafeHouse (v1.80.043)
• SafeHouse (v2.00)
• ScramDisk (v2.02h)
• ScramDisk (v3.01r3c/v3.02A)
• seNTry 2020 (v2.04)
• S to Infinity (v1.1)
• Additional Notes
• Packages Not Reviewed
• Packages Yet To Be Reviewed
• Glossary

Overview

• BestCrypt (v6.06)
• BestCrypt (v6.07.2)
• E4M (v2.00)
• E4M (v2.01)
• E4M (v2.02a)
• FLYCRYPT (v1.01)
• F-Secure FileCrypto (v4.0, build 39)
• F-Secure FileCrypto (v4.30)
• Invincible Disk (v2.3)
• Invincible Disk (v3.0)
• PGPDisk (v6.0.2i)
• PGPDisk (v7.0.4)
• SAFE Folder (v1.01)
• SafeHouse (v1.80.043)
• SafeHouse (v2.00)
• ScramDisk (v2.02h)
• ScramDisk (v3.01r3c/v3.02A)
• seNTry 2020 (v2.04)
• S to Infinity (v1.1)

After the table below, giving a comparitive summary between the various packages, are brief notes on each of the systems reviewed.

Special Notice To The Software Authors/Publishers

It is because of these complaints that I am including this short section in order to warn the authors/publishers of the software included in this review that they might not like some of the comments detailed below, since both positve and negative aspects of the various packages are presented. It is not the intention of this comparison to offend anyone, but to detail the various features of the reviewed packages and highlight some of the means by which they could be attacked; I would ask you to view any critisism as constructive.

If you are the author or publisher of any of the software packages mentioned in this comparison, please beware that all of the packages looked do receive some critisism (to a greater (e.g. serious security flaws) or lesser (e.g. cosmetics) extent) in this review. IMHO, all have some scope for improvement, no matter how minor this may be.

If you believe that any of the comments I have made in any of the sections below are incorrect, please, do drop me an email with all relevant details at sdean12@sdean12.org, and I'll doublecheck any points you raise.

Feature Summary

Comments

BestCrypt (v6.06)

• The maximum password length when using the GOST hash algorithm (key generator) is 40 chars
• The maximum password length when using the SHA-1 hash algorithm (key generator) is 128 chars
• BestCrypt featuress a "keyboard filter" that uses low level Windows functions to provide a certain level of protection against keyboard sniffers such as KEYKEY and SKIn98. When these keyboard monitors were run at the same time as a volume was being mounted, they were able to pick up on keys being pressed, but recorded the wrong keystrokes. For example, when the password "password" was entered on different occasions, the following strings were logged:

wsoocq14
qnxxukem
2t00qeon
vkaai53o
xk992qhw
etc...

From these results, it would appear that the "scrambling" is just a fairly trivial character substitution system.
• Interestingly enough, if you use Uncover-It!, Spy & Capture, WinDowse, or some similar tool that can display the contents of Windows password entry editboxes (i.e. editboxes that display "*"'s instead of letters when you are entering passwords, etc., you will find that this software correctly pick up the password as it is typed in by the user. This means that even though BestCrypt may prevent keyloggers from operating correctly, it would still be fairly trivial to write a program that attacked BestCrypt by monitoring everything that is typed into password editboxes to grab the "unencrypted" password as entered by the user. Obviously such an attack would not be limited to attacking BestCrypt, but would work against any application using this type of editbox.
• One major criticism of the keyboard filter is the fact that it can be turned off by the user (or an attacker), by simply changing a single registry entry. The only indication that this option is turned on (and I can't really think why anyone would have it switched off) is a tiny little red line that appears on the password entry dialog. This indicator is easy to miss, and it's just tough luck if you happen to be color blind!
• BestCrypt volume files have the filename extension ".jbc" by default, but can be renamed to anything else, although doing so will prevent the shell support from working, which is a pity since there is no real reason why the shell support can't pick up on the "signature" stored at the start of all BestCrypt volumes. BestCrypt Control Panel (the main BestCrypt application), however, will still correctly identify the volume files no matter what the filename.
• BestCrypt itself is only capable of using volume files that are stored in root directories (e.g. C:\, D:\, etc) and not in subdirectories, as this is the only place that the BestCrypt Control Panel checks for volume files. The shell support displays an error when you attempt to mount a volume stored in a subdirectory. However it is possible to mount volumes stored in subdirectories by using 3rd party software (for example, SecureTrayUtil), or using the command line support. This of course does rather leave the question as to why Jetico didn't add this ability to the BestCrypt user interface to begin with...
• One minor GUI oddity that I found while creating a new volume file; at the top of the volume creation dialog, the user is asked for a filename for the new volume, but the drive that the volume will be written to is selected by a control at the bottom of the dialog(!). Nothing serious, it just struck me as being a little odd; surely it would have been more logical to have the host drive selection first?
• When creating a new volume, the dialog that the user is presented with has the option to "Fill in container by random data".


Under Windows 95/98, turning this option off can cause the newly created file to contain data that was previously stored in the computer's memory, possibly leaking sensitive information, presenting a security risk.

This is not such a problem under Windows NT, as NT's security automatically zeros storage before it is allocated, but this can lead to the same problem seen in the review of "seNTry 2020", in which the maximum amount of data actually stored in the volume file can be determined quite easily.

Turning this option on will cause the volume creation process to take slightly longer while the newly created volume is filled with random data, but the benefits of doing so clearly outweigh this one disadvantage, and makes absolutely no difference to the volume's end user.

This option is turned on by default and, IMHO, should never be turned off.

• BestCrypt uses an "encrypted master key system"
• The user may change the encryption algorithm used for any given volume, which will result in a new master key being generated, and the volume being reencrypted with the new algorithm
• The user may change the hash algorithm used for any given volume, which for some strange reason results in the entire volume file being reencrypted, although no new master key is generated
• The user has the option of associating a text description with the volume. This as stored in plaintext within the volume file
• BestCrypt is supplied with the freeware file shredder, BCWipe (which can be downloaded separately if needed). See Disk and File Shredders: A Comparison for a review of this shredder.
• When creating a new volume, the user is asked to generate random data by randomly pressing keys on the keyboard
• Mounted volumes can appear either as removable drives or normal HDDs, this can be configured by the user. This will probably be of little use to the majority of users (it's only really a cosmetic change), but it's a nice touch!
• Another nice touch is a user definable hotkey for displaying the tasktray icon's menu
• BestCrypt keeps a count of the number of times that the incorrect password has been supplied when mounting each volume, although this is stored in plaintext within the volume file and so could easy be changed by an attacker wishing to cover his/her tracks
• Jetico have released the "BestCrypt Development Kit" (BDK) which is available for download from their WWW site. The BDK contains the source code of all the BestCrypt v6 modules responsible for encryption/decryption and key generation (hashing). This allows both inspection of some of BestCrypt's source (not all of it), and allows 3rd party development of modules implementing other encryption algorithms and key generators. However! As I discovered while trying to use the information in the BDK to implement a BestCrypt Delphi component, the BDK is technically incorrect in some places (details of the driver interface in particular). Having said that, Jetico were helpful when asked for clarification of details.
• Igor Arsenin has written a driver module for BestCrypt that implements the IDEA encryption algorithm. This can be downloaded (with source code) from the Igor Arsenin Home Site as a 3rd party add-on to BestCrypt.
• BestCrypt provides optional delete protection ("Container Guard") that prevents the user from deleting ".jbc" files. This protection can be disabled by the user under Windows 95/98, or any user with administator privileges under Windows NT
• BestCrypt can optionally display a tasktray icon which displays:
• an MRU list of volumes files
• options to:
• Clear the MRU list,
• Dismount all mounted volumes, and
• Launch the BestCrypt Control Panel
• If displayed, left doubleclicking on the tasktray icon dismounts all currently mounted drives. Right doubleclicking on it launches the BestCrypt Control Panel
• If displayed, the tasktray icon will subtly change when one or more drives are mounted. This is hardly noticeable, but it's there! (See BestCrypt screenshots)
• One thing that I did find annoying about the tasktray icon is that whenever you right doubleclicked on it, or selected "BestCrypt Control Panel" from it's menu, the BestCrypt Control Panel is launched. That's pretty obvious, and quite reasonable, but after launching one copy, repeating this action results in another copy being launched. It would have been far nicer to simply bring any already existing BestCrypt Control Panel window to the front, which would prevent the desktop from becoming unnecessarily cluttered up with excessive copies of this application
• After mounting a drive, BestCrypt can be configured to automatically launch Window's Explorer to view it's contents
• Volumes can optionally be set to "automount". This means that when you start your computer, BestCrypt will automatically prompt you for the passwords to those volumes.
• During installation, BestCrypt adds a "BestCrypt Auto Open" item in your Windows StartUp folder; this is how "automount" works. Crude, and can be done with any OTFE system that supports command line mounting, but effective
• A Delphi Component (with full source code) is available that allows easy access to BestCrypt (mounting/dismounting volumes, retrieving volume information, etc.); see Delphi Components
• Overall, BestCrypt is a well presented package

• A volume's "description" (if specified by the user) is stored in plaintext within the relevant volume file
• The ID of the encryption algorithm used to encrypt any given volume is stored in plaintext within volume files
• The ID of the key generator used to encrypt any given volume is stored in plaintext within volume files
• A file called BESTCRYPT.INI is created in your Windows directory, in which BestCrypt stores a list of all your volume files that it is "aware" of(!)
• BESTCRYPT.INI also holds the usernames of users that have used each volume file, and the default drive letter assigned to each volume when mounted.
• The number of times that the password has been entered incorrectly for any given volume is stored in plaintext within it, and can easily be changed by an attacker wishing to cover her tracks
• The tasktray icon displays a MRU list of volume files. Although this can be cleared, it would have been a lot nicer to include an option to disable the MRU list

BestCrypt (v6.07.2)

• Windows 2000 is now supported
• The BDK (BestCrypt Development Kit) is still on v1.0, and has not been updated.
• Volume files created by BestCrypt under DOS/Windows 3.xx, Windows 95/98/NT/2000, Linux are claimed to all be compatible with one another (untested)
• When changing the encryption algorithm used for any given volume file, BestCrypt uses a "safe" method for reencrypting volume files. Should the reencryption process be interrupted or some reason, BestCrypt can started up again, and can then continue where it left off. This appears to operate correctly, although no specifics are given as to exactly how this functionality operates, so it's not clear exactly how safe, and secure, this is, but it certainly sounds like a good feature to have...
• Volume files can now be created on floppy disks
• When a mounted volume is shared over a network, BestCrypt will automatically re-share the volume when the volume is next remounted. See security risk related to this in the Additional Notes section of this document
• The BestCrypt INI file no longer used. Some of the settings that were previously stored in this file are now stored in the registry instead, although not all of them.
• Although the logged in user's username is no longer explicitly stored in an INI file, since settings are stored under the HKEY_CURRENT_USER registry hive, this effectivly indicates the user's username
• BestCrypt now has a hidden feature; the ability to create a hidden volume within a volume file!

 

 

For example: it is possible to create a perfectly normal volume file (e.g. "volumefile.jbc") of, say, 200MB that has the password "normal_password". BestCrypt's hidden volume feature allows you to then create a second hidden, volume within the first. This hidden volume must have a different password to the normal one (for example, "hidden_password")

When the user tries to mount this special volume file ("volumefile.jbc", in this example) the user is prompted for the volume's password, as normal. If the user enters "normal_password", then the first, clearly visible volume will be mounted. If the user enters "hidden_password", then the second, hidden volume will be mounted.

Very nice!!

This feature can be enabled by creating a duplicate of this of the BestCrypt Control Panel shortcut and then editing this copy so that the shortcut's target file is "BestCrypt.exe" as usual, but with the word "debug" tacked onto the end. Alternativly, run BestCrypt.exe from the command line, passing it the command line parameter "debug"

After this, creating and using hidden volumes is simple; locate the volume that you wish to create a hidden volume within, and display the volume's properties using the BestCrypt Control Panel. Underneath the checkbox for "Change Algorithms and Password" you will now find a second checkbox, "Create Hidden Part". Checking this and clicking "OK" will take you to a new dialog from where you can add a hidden volume to the existing volume.

This is currently an undocumented feature of BestCrypt, however BestCrypt have now finished testing this functionality and have confirmed that it works correctly.

This ability to create a hidden volume within another volume certainly looks like it could be a key selling point for BestCrypt.
 

• A hidden volume can be destroyed by writing data to the "outer" volume, which could be useful in case of an emergency; simply mount the outer volume, and create a bunch of very large files on it.
• To prevent the user from accidently overwriting the hidden volume, a dialog box pops up whenever the hidden volume is mounted, stating that the the hidden part of the volume has been mounted.

 

 

It is important that the user ensures they receive this dialog every time after mounting a hidden volume, in order to be sure that the "normal" volume has not been mounted by mistake, as this could easily lead to the hidden volume being overwritten and irreparibly corrupted.

• From creating volume files of different sizes and with varying size hidden parts, the starting position within the "outer" volume varied as follows:

 

Outer volume size	Starting position within "outer" volume file with varying sized hidden part
	25% hidden	50% hidden	100% hidden
1MB	770K	514K	36K
2MB	1538K	1026K	132K
5MB	3842K	2562K	132K
10MB	7682K	5122K	2404K

From this, it appears that approximatly the final x% of the volume is used for the hidden part
 

• From talking to Jetico, the starting position of a hidden part is encrypted together with encryption key for the hidden volume and its digest. This means that it is not possible for an attacker to determine the size of the hidden part.
• Hidden volumes can only be created within a normal volume if the SHA-1 has algorithm is used for the "outer" volume
• For those who are into the technical details of BestCrypt's hidden part key management, I have written a simple Delphi application (now available for download) that dumps out the details of BestCrypt volume files.

 

 

From using this tool, it can clearly be seen that of the eight "key slots" within the volume file's DATA_BLOCK, the first relates to the "normal" outer volume's password, and the eighth relates to the hidden block.

For those who are not inclined to delve into the details of BestCrypt volume file formats, BestCrypt uses a "encrypted master key" system. This "master key" is protected by the user's password, and is used in the encryption/decryption process.

BestCrypt's volume file format has space reserved within it for up to eight "keys"

Normally only one is used, the first ("key slot 1"), which is protected by the user's password. When a hidden partition is created, a second copy of this master key is effectivly encrypted using the hidden partition's password, and this is stored in the volume file (in "key slot 8") in the same way as the first. If used, the eigth "key slot" is still marked as unused, for obvious security reasons.

All unused "key slots" are filled with pseudorandom data.

• You cannot create a hidden volume in a volume file that was encrypted using the "DUMMY" encryption algorithm (i.e. the encryption algorithm that returns plaintext as ciphertext, and vice versa, used for testing and demonstrative purposes)
• In addition to hidden volumes, running BestCrypt in debug mode also allows the user access to another interesting feature: swap file encryption!

 

 

From Jetico:
 

"The driver which encrypts swap file is added, but its testing is not complete yet. Besides of this, in Windows 2000 version we did not implement support of several swap files, scattered on different partitions.

In general we would not recommend to test the feature right now (as it can be with hidden containers). I think we should be more confident in the feature ourselves before asking others to take a look at it."


In other words, this functionality is very much in the beta stage, and it is not advisable to use it in it's current state.

Obviously this feature will improve security, but it should be noted that many applications write data to the computer's TEMP directory, which will not be protected against by this functionality. (i.e. Swap file encryption will increase security, but should be considered as just one security tool in a much larger toolkit)

Use of BestCrypt's OTFE functions should not be required in order to make use of swap file encryption, leaving the user free to use another system for data encryption (ScramDisk, for example), while keeping BestCrypt for swap file encryption.

• Under Windows NT, if you dismount a drive which has files open, BestCrypt warns you about this, and then asks if you want to dismount the drive anyway.

 

 

If you choose to go ahead and unmount the drive regardless, you will not be able to remount that voume under any drive letter other than the one is was previously mounted as, nor will you be able to mount any other volume as that drive until this is done (or the computer is rebooted). When a drive is dismounted in this manner, the tasktray icon still indicates that one or more volumes is mounted, again, until the volume is remounted and dismounted or the computer is rebooted.

This anomoly does not appear to affect Windows 9x/Me.

• Additional changes made to this version (according to Jetico) include:
• Problems with using BestCrypt on magneto-optical devices with physical sector size 2048 bytes fixed
• Windows NT/2000 version: solved problem of creating very large NTFS containers (dozens GBytes) when operating system's memory resource is low.
• Bugfix: Windows 95/98 version of BestCrypt had a conflict with MS Internet Explorer 5.5 that appeared during caching long WWW-addresses is solved
• For further information on BestCrypt, see the review of BestCrypt v6.06

• Although the INI file containing BestCrypt settings has been removed, some of the settings previously stored in this file have been moved over to the registry, but not all of them
• Although many of the leaks relating to the BestCrypt INI file have been removed, the following information is will stored in the registry:
• Every time a volume is mounted, a ASCII encoded SHA-1 hash of the volume's filename is stored in the registry, together with the default drive letter used for mounting that volume. Although the hash doesn't give away any information about the filename itself, this information can still be used to determine the maximum number of volume files the user has
• The MRU list of all mounted volume files mentioned in the previous review is stored in the registry. This can be disabled, but only by disabling the tasktray icon.
• Every volume that the user sets to "automount" (prompt user for passwords and attempt to mount after the user logs on) has it's filename stored in the registry; although realistically this can't really be avoided, bearing in mind this information is required for automounting.
• The drive letters that volumes are mounted as are stored in the registry. However, instead of storing a "volume filename to mounted drive letter" mapping, an "ASCII encoded SHA-1 hash of the volume filename to mounted drive letter" is stored. This is better than storing the volume filename straight out, but does still give an attacker an indication of the number of volume files mounted.
• If the hidden volume functionality is used to conceal a second volume within another, it is vital that the "outer" volume was either created with the "Fill in container by random data" option checked, or that the user runs one of the many "shredder" programs (See review) to overwrite all free space (including file slack) on the mounted volume after it is created. Failure to do so could make your "hidden" volume stick out like a sore thumb!
• BestCrypt volume files have space reserved within them for up to eight keys (they have eight "key slots").

 

 

For a normal volume file, one of these key slots is used, and the other seven are filled with pseudorandom data.

For a volume file that has a hidden volume within it, two of these key slots is used, and the other six are filled with pseudorandom data.

Potentially, this could lead to the attacker being able to determine how many of the key slots are being used (one or two), and therefore if the volume file has a hidden part concealed within it by simply using the data stored in the six key slots as data known to be pseudorandom, and then checking to see if the data stored in the eighth key slot belongs to the same sequence of random numbers, or if it effectivly has significantly more entropy, which would be the case if a hidden part had been created.

Note: This "leaked item" is based on examining source code currently released by Jetico, in which the standard "rand()" function is used to initialize the DATA_BLOCK within volume files

Note: This "leaked item" should be currently be viewed as a theoretical risk, bearing in mind the amount of data stored within the six "known unused" keys; I am not certain exactly how effective this attack would be in practice.

• See also the "leaked information" detailed in the review of BestCrypt (v6.06), with the obvious exception of the INI file references which are detailed in the list above

E4M (v2.00)

• Requires administrator privileges to install under NT
• The minimum size of a volume file is 19K
• E4M refers to partitions by their Windows system designation, For example:

\Device\Harddisk0\Partiton1
\Device\Harddisk0\Partiton2
\Device\Harddisk1\Partiton1
\Device\Harddisk2\Partiton2

When referring to partitions on a HDD, the partitions are referred to as Partition1, Partition2, etc. It should be remembered that the partition number refers to the position of the partition within the HDDs partition table, and are not necessarily in the order C:, D:, E:, etc

Although this is sufficient, it is not particularly user friendly, and (IMHO) it would have much better if E4M displayed further information relating to the different partitions (as ScramDisk does) for the user; for example, the partition's starting location, size and volume label (where appropriate). Having said that, under NT this may not be possible unless the user has administrator privileges

• E4M's GUI appears to assume that the user has a maximum of 4 partitions on any given HDD, as this is the maximum that will be displayed for the user to select from. Although it is not immediatly obvious, if you with to use a fifth (or greater) partition you can type in it's partition number in the partition selection dialog to use it.
• From the E4M manual, E4M generates random data (for use when creating a new volume) by:

"Random data are collected all the time in the background from your mouse movements, key clicks, and from your system data such as memory status, performance data, etc"

When creating a new volume, the user is presented with a dialog that is displayed while E4M generates it's random data as described above, and asked to click a button to make E4M use the last "n" random bits generated

The user is not explicitly asked to press keys/waggle the mouse/etc at random.

• When referring to volume files, E4M always uses their short filenames. This is due to a limitation in the E4M driver, which will not allow a full filename (including drive letter, and path) that is greater than 63 chars long
• E4M has a very simple, easy to use GUI. The user is guided through the volume creation via an easy to use "Wizard"
• Support is included to allow reading/writing to ScramDisk volumes. However, E4M cannot create ScramDisk volumes itself, or change ScramDisk passwords.
• Support is included to allow reading/writing to SFS volumes, and to change their passwords. E4M can create SFS volumes.
• Settings are optionally stored in in an INI file ("e4m.ini"), although due to a minor bug in E4M, the option to save the users settings is set by default. This default is a little silly - if the user doesn't want E4M to save it's settings, then every time E4M is launched, the user will have to deselect this option again to prevent E4M saving it's settings, because it didn't save them the last time! (i.e. It would have been a lot more sensible to default to not saving settings!)
• Mounted volumes appear as removeable drives
• One serious security risk that I noticed - if you logon to Windows NT, mount an E4M volume, logoff, and then logon again as a different user, you will find that your E4M drives have not been dismounted when you logged off.
• The maximum password length is 100 chars. With a well chosen password, this limit should make no difference
• A Delphi Component (with full source code) is available that allows easy access to E4M (mounting/dismounting volumes, retrieving volume information, etc.); see Delphi Components

• The filenames of the last 8 volumes mounted (only if the "save settings" option is checked, which it is by default)

E4M (v2.01)

Why ScramDisk support was removed though, I'm not quite sure...

Notes:

• Apparently, E4M suffers from the same bug as ScramDisk wrt the computer locking up when shutting down. See ScramDisk notes for further details
• For further details of E4M, see the review of E4M v2.00

• See the review of E4M v2.00

E4M (v2.02a)

• v2.02a introduces beta Windows Me support (i.e. it supports Windows Me, but this support cannot be guaranteed, and users may have problems). Personally, I did not find any problems in using E4M under this OS while carrying out this review.
• Windows 2000 is now "officially" supported (i.e. previous versions should run quite happily under Windows 2000, although I have not attempted to verify this using an older version)
• I did notice that when a volume is already mounted and you open the link (optionally) added to your Start menu to mount a second volume, you are presented with a slightly confusing interface which, at first glance, does not appear to allow to you mount more than one volume.

 

 

This is because the same executable is responsible for both mounting and dismounting volumes; it displays a list of volume letters, together with the filename of the volume (if any) that is mounted to create that drive.

If an E4M drive (and corresponding volume filename) is selected in this dialog, the user is given the option to dismount the drive.

If the drive selected is not a mounted E4M drive, the user is given the option to mount a volume file as that drive selected.

This is fair enough, however, when the Start menu shortcut to mount a new volume is run while a volume is already mounted, this executable starts up with the first mounted drive selected, giving the user the option to dismount it, and thereby giving the impression that no more than one volume can be mounted at any one time.

Obviously selecting a different drive does allow you to mount another volume, but this did not seem particularly intuitive to me. (i.e. Running "mount volume file" prompts the user to "dismount volume file" instead)

• E4M does not support FAT32, and the user is prevented from formatting mounted volumes
• E4M v3 (when it is released) is claimed to support various stealth features such as:
• not storing any information in the volume that can cause the volume to be identified as an E4M volume,
• WAV steganography
• Image steganography
• New in v2.02a is the ability for the user to test the cipher implementations against each of the cipher's official test vectors. However, the user is only able to test the encryption algorithms, and not the HMAC-SHA1 or HMAC-MD5 implementations.
• A few minor changes have been made to the command line options, including a "quiet" mode which when the volume's filename is passed as a parameter and  the user is only prompted for the volume's password, instead of being prompted with the main "mount" dialog
• The drive letter that the last volume was mounted as is saved to an E4M.INI file, unless the user specifies that settings should not be saved
• The issues with previous versions of E4M saving it's settings, and the filenames of the last eight volume files to be mounted have noth been addressed by changing the default such that settings are not normally saved.

 

 

However, the implementation of this solution is faulty - if the user mounts a volume file and saves their settings at any time, E4M quite happily saves it's settings and the volume's filename into an "E4M.INI" file.

This is fair enough, and the logically correct operation.

If the user then dismounts this volume, and then mounts a second volume this time specifying that settings are not to be saved, the volume will be mounted and no settings will be saved. But! The E4M.INI file will not be changed to reflect the fact that the user no longer wishes to save their settings/volume filenames, which means that when the user dismounts the second volume, the drive letter that volume was mounted at will be saved to the INI file. Additionally, when the user next mounts a third volume, unless the user notices that the "Never save settings" checkbox is no longer checked, this volume, and subsequently mounted volumes, could easy have their filenames saved to the INI file.

If you prefer not to save your settings and volume filenames to this ini file (e.g. for security reasons), there is an obvious workaround to this problem; simply delete the E4M.INI file from your Windows directory, and leave E4M to default to not saving it's settings

• As stated in E4M's documentation, under Windows NT, E4M is unable to mount a volume file that is located on another computer via a network. Under Windows 9x/Me, users can mount volumes by specifying their their full UNC path and filename (e.g. "\\computername\sharename\path\volume_filename.vol")
• A Delphi Component (with full source code) is available that allows easy access to E4M (mounting/dismounting volumes, etc); see Delphi Components

• As volumes drives are dismounted, the drive letter the volume was mounted as will be saved to an E4M.INI file, if this INI file exists.
• When mounting volumes, unless the "Never save settings" checkbox is checked, the volume filenames of volumes being mounted are saved to the E4M.INI file.
• See also the review of E4M v2.01

FLYCRYPT (v1.1)

FLYCRYPT HAS NOW BEEN DISCONTINUED, AND IS NO LONGER AVAILABLE.

FLYCRYPT does not operate with a single volume file containing an encrypted "virtual drive". Instead, FLYCRYPT operates on a folder level, allowing the user to select a folder to encrypt, after which all files written/read to/from that directory are simply encrypted/decrypted OTF

Notes:

• The maximum password length when using Blowfish is 56 chars
• The maximum password length when using GOST is 32 chars
• Creating an encrypted directory is trivial, although the package does go about it in a slightly strange fashion; displaying a dialog similar to the Windows "Open"/"Save As" dialogs when asking the user to select the directory. Displaying the standard Windows "Select Directory" would (IMHO) have been more sensible.
• A note of which encryption algorithm used to encrypt (Blowfish/GOST) does not appear to be stored anywhere within encrypted files. (This information may very well be stored within the "FlyCrypt.ctl" file; see below)
• A keyfile can be used instead of the user entering a password; in this case, FLYCRYPT will create a file of 56 bytes containing random data generated by the user waggling the mouse
• Keyfiles are called "SUPERPASSWORDS"(!)
• The full version claims to be able to encrypt the Windows swap file(?!) and also the temp directory. This was not tested during the course of this review
• One amusing thing I noticed - one of the restrictions on using the software mentioned in the "licence.txt" file stated:

"You can use the given version of the program till December 1, 1998."

Oops! Guess nobody's actually allowed to try out the trial version then, huh? ;)
• Only one directory (and all it's subdirectories) can be OTF encrypted/decrypted by FLYCRYPT at any given time
• FLYCRYPT has a tasktray icon, although this appears to be of little use, except to bring up the main application window and give an indication of whether the system has been enabled/disabled
• This package has a hilarious security problem: the last (file size mod 8) bytes of all files are not actually encrypted! i.e. Up to 7 bytes at the end of each file are stored as plaintext!
• Encryption is performed on 64 bit (8 byte) blocks. Feedback ciphering is not used. The explanation given for this is the software would be more resilient to failure this way. The downside of this approach, of course, is that every 8 bytes are encrypted with the same password; if you have a file containing the text "abcdefgh" repeated 100 times, and with your password "abcdefgh" encrypted this to "jfhghrhn", then your encrypted file would contain "jfhghrhn" 100 times.

• Filenames of encrypted files
• File sizes of encrypted files
• The presence of a "FlyCrypt.ctl" file in any directory indicates that the data in that directory is encrypted
• The last (file size mod 8) bytes of all files are not actually encrypted, but stored as plaintext!

F-Secure FileCrypto (v4.0, build 39)

Notes:

• F-Secure FileCrypto is part of the F-Secure Workstation Suite.
• The OTFE component of FileCrypto operates by allowing the user to specify one or more directories as being "Top Secret". Any files or subdirectories stored in one of these "Top Secret" directories will be automatically encrypted/decrypted OTF. As such, FileCrypto operates on a "directory" level, and not on a "drive" level, as do ScramDisk, PGPDisk, etc.
• The user can setup an "Excluded" list. This list defines which files are never to be encrypted, even when they are stored within a "Top Secret" directory.
• Installation is simple, and the initial configuration is carried out via a Wizard. Users can change their FileCrypto configuration later either by invoking the Wizard again, or via the "FileCrypto Explorer" (to set/unset directories as being "Top Secret" or "Excluded") and the options dialog (all other settings).
• Whenever a file is opened, regardless of whether or not it is stored within a "Top Secret" directory, it is examined by FileCrypto for a distinctive "signature" to see if it is encrypted. If the signature is found, the file will be treated as though it was stored in one of the "Top Secret" directories.
• Using FileCrypto is fairly simple, when Windows is started, FileCrypto displays a password prompt and the user can either enter the correct password, in which case all "Top Secret" files are encrypted/decrypted as appropriate, or click "Cancel", in which case FileCrypto is disabled.
• If FileCrypto is disabled, any attempt to read encrypted files will result in an "Access denied" error.
• It is not possible to enable FileCrypto at any time, except when Windows starts up/the user logs onto Windows.
• Ater it has been enabled, it is not possible to disable FileCrypto's OTFE except by logging off Windows, or rebooting the computer.
• Because FileCrypto cannot be disabled easily (logging of/restarting Windows is required), there is a security risk that the other OTFE packages do not suffer from; if you were to leave your computer for a few minutes while FileCrypto was enabled, an attacker would only need access to it for a few seconds to reconfigure FileCrypto by turning off the OTFE facilities (either by instructing FileCrypto not to encypt data being written to the "Top Secret" folders, or by adding "*.*" to the "Excluded" list). This would not easily be noticed by the user, who would probably end up writing data to their HDD, believing that it was being automatically encrypted, while in reality the data was being stored as plaintext. Having said that, if an attacker can gain access to your physical hardware, then he/she would probably be able to circumvent any security systems in place anyway...
• The minimum password length is 6 chars
• The maximum password length is 80 chars
• Files encrypted by FileCrypto are encrypted with a "master key" (".key" file) which is created during installation by getting the user to waggle the mouse in order to generate random numbers (alternativly, the user may supply an existing ".key" file containing this data instead).
• This "master key" is encrypted using Blowfish (this encryption algorithm cannot be changed) and the user's password.
• One nice feature about the generation of the ".key" file is that after it is created, the user is prompted to make a backup of it on a 3.5" disk, encrypted with a different password. This is what Datafellow's call their "administrative key recovery feature". Despite concerns about "key recovery features", I do not see this particular system as being a security risk.
• An annoying splash screen is displayed when the system starts up, this cannot be disabled.
• Files encrypted by the Windows 95/98 version of FileCrypto cannot be decrypted by the Windows NT version, and vice versa.
• FileCrypto is only available in Wassenaar countries; see Countries eligible for downloading Strong Encryption for details
• One interesting note that is included in FileCrypto's README.TXT:

"Encryption/decryption operations performed simultaneously can cause the system to crash."

Yike! A couple of the F-Secure modules appeared to crash a couple of times during testing; FileCrypto simply detected the crashes, and tried to restart them automatically. Although I did not appear to lose any data, this was a little worrying...
• FileCrypto comes with a file shredder ("Secure Delete"; a review of which can be found on the Disk and File Shredders: A Comparison page), and self-decrypting exe generator ("Encrypted package generator")

• Filenames of encrypted files
• File sizes of encrypted files

F-Secure FileCrypto (v4.30)

• From the F-Secure WWW site, the main bugfixes include:

• Under Windows 9x, when an encrypted file is opened twice, FileCrypto no longer causes the system to crash
• ScanDisk can now be run in "thorough" mode

• Also from the F-Secure WWW site, there are a number of known bugs with FileCrypto v4.30, including one that can cause "problems" when encrypted executables are run under Windows 9x. F-Secure recommend that executables are not encrypted for this reason. Additionally, some users have experienced problems while compiling source code that was stored within encrypted folders.

 

 

These bugs mean that FileCrypto is not a good choice for securing source code, and it's effective inability to encrypt executables means that it can only be used for securing user data.

• A number of other known F-Secure FileCrypto v4.30 bugs can be found in the F-Secure FileCrypto Release 4.30 build 270 release notes
• Apart from a number of bugfixes to v4.0, v4.3 appears to only introduce one other significant change: the graphics changed color!
• For further information on F-Secure FileCrypto, see the review of v4.0

• For information on information leaked by F-Secure FileCrypto, see the review of v4.0

Invincible Disk with Data Lock (ID: v2.3, DL: v3.0)

• Passwords
• "Invincible Keys" ("iButtons")
• Smart cards
• Fingerprints

WARNING: If you take advantage of the 60 day trial version of Invincible Disk, be aware that when the trial period expires, Invincible Disk will be disabled. Obviously, purchasing a full version should re-enable it. However, while it is disabled, you will not be able to use Invincible Disk. Not even to read back any data you may have written to any volumes created during the trial period.

Notes:

• Data Lock comes with a file shredder util called "Invincible Shred"; a review of which can be found on the Disk and File Shredders: A Comparison page. The fact that this shredder does not perform as it should does raises serious questions about the rest of this package; if they can't get a simple file shredder to work correctly...
• Invincible Disk displays an annoying splash screen when it starts
• When a volume is created, the user is prompted to enter a "description" for the volume. This is used as the filename of the volume, and for some reason cannot contain spaces...
• Although the user can specify the drive on which any given volume file is to be stored, volume files must be stored under a specific subdirectory ("\xidiskx"), and must not be moved or renamed, except to transfer them to the same directory on a different drive.
• The Invincible Disk "\xidiskx" directory is a hidden directory, for what good that does...
• The help file included with the package states that it is possible to set a dismount hotkey. In practice, no such option appears to be available.
• One annoying "feature" of Invincible Disk/Disk Lock is that once any of the tasktray icons have appeared, there's no way of getting rid of them without rebooting the computer/logging out and back in again
• Invincible Disk's GUI (IMHO) does not appear 100% polished, but is reasonably good
• Data Lock v3.0 includes Password Watchdog v1.02
• Amusingly enough, part of the advertizing for Invincible Disk states: "Virtually unbreakable on-the-fly disk encryption so transparent it's hard to notice it is there". "Hard to notice"?! Well, yes, provided, of course, you ignore the large splashscreen and password prompt that is displayed every time you start Windows, due to one of the items it places in your startup folder during installation!
• The advertizing also states that Invincible Disk uses both the Blowfish (128 bit) and IDEA encryption algorithms (in the PDF brochure they have available for download), but their WWW site only mentions Blowfish. The user is not given the choice between selecting between the two though, and it is not obvious how each of the ciphers are used, or which one volumes are encrypted with (presumably only Blowfish is used?).
• If you are using "Invincible Keys" or smartcards with Invincible Disk, you can configure the system such that your Invincible Disk volumes are mounted when the token is inserted, and dismounted automatically when removed. (This functionality was not tested in this review)
• By default, Invincible Disk installs two items in your startup folder. The first is Invincible Disk (as mentioned above) which installs a tasktray icon for Password Watchdog, and the second is a little utility ("IDS Control panel") that just sits in the tasktray and allows you to launch Invincible Disk (the main mount/dismount, etc dialog), "Access Watchdog" and "i-Mail", if they are installed. Doubleclicking on the IDS Control Panel tasktray icon displays a floating toolbar with the tasktray's rightclick menuitems displayed as a series of buttons.
• Invincible Disk is slightly different to most other OTFE systems in that all volume files on your system must use the same password! Actually, it is possible to have different passwords for different volumes, but to do so involves logging out of the computer, and logging back in again as a different user. In practice this is clumsy (to say the least), and it is unlikely that anyone would bother going to such trouble, thereby creating a potential security risk
• In summary? I would not recommend this package; it might be useful for newbies with extremely low security needs, but even then, one of the other packages would probably be more suitable.


If the hardware (smartcard reader/etc) parts of this system are required, I would recommend looking into trying to implement such extensions into one of the other OTFE systems. This sould not be too difficult (providing API, etc details for your hardware are available, which will probably be the case), since many OTFE systems permit 3rd party software to control them; SecureTrayUtil is just one example of this, and demonstrates how many OTFE systems can readily be extended by the user.

• Volumes must be stored in a certain, specific directory, which cannot be changed, so it's clear which files are Invincible Disk volume files, how many you have, how big they are, etc
• Additionally, a list of all volumes files is held in a file called "index", stored in the "\xidiskx" directory
• The "description" the user enters for the volume is used as its filename
• Invincible Disk appears to suffer from a serious security flaw while creating new volumes; a new volume could contain (in plaintext) data already stored on the disk.

 

 

Probably the best way to describe this is to say that if you:

1. Create a large file (outside Invincible Disk) that fills up all the free space you have left on the drive it is stored on. This file should contain nothing but the character "K", repeated over and over again.
2. Reboot (ensuring that the file is written to the disk, and no trace of it resides in memory)
3. Delete this file, and remove it from the recycle bin
4. Reboot (ensuring that no trace of the file can reside in memory)
5. Create a new Invincible Disk volume on the drive that held the large file created in step 1
6. Dismount the new volume if has been mounted
7. Examine the volume file
You will find a large number of "K"'s within the volume file; this is the data that was previously stored on the free space.

This is a serious security risk, for obvious reasons; if the user creates a new Invincible Disk volume, it could easily contain sensitive information that had previously been stored on the drive. The user would not be aware of this. If the user attempts to work around this problem by shredding all free space on the drive before creating a new volume file, then (due to the nature of free space shredders), the free space on the drive will then be filled with a constant character (typically 0x00 or 0xFF, or some other repeated pattern), or pseudorandom data, depending on the shredder used.

If this workaround is used, then:

• If a constant character is used, then an attacker can gain an idea of how much data is stored in the volume file/the amount of use a volume has had by simply examining it and noting how many blocks are full of the constant character.
• If pseudorandom data is used, then an attacker can still determine the about amount of data by analysing the amount of entopy within the file, and which parts have high entropy (the encrypted areas) and which have low entropy (areas containing pseodorandom data)

Invincible Disk with Data Lock (ID: v3.0, DL: v3.0)

WARNING: If you take advantage of the 60 day trial version of Invincible Disk, be aware that when the trial period expires, Invincible Disk will be disabled. Obviously, purchasing a full version should re-enable it. However, while it is disabled, you will not be able to use Invincible Disk. Not even to read back any data you may have written to any volumes created during the trial period.

• Although Invincible Disk is claimed to be compatible with Windows Me, Invincible Data Systems, Inc acknowlege that it does not work properly with Window's System Restore, and that users may experience problems, in which case the user will have to switch off System Restore
• See review of Invincible Disk (v2.3) for further details on Invincible Disk.

• See the review of Invincible Disk (v2.3)

PGPDisk (v6.0.2i)

• There is a little confusion over where PGPDisk can be obtained from. Currently, PGPDisk is available with:
• PGP v6.0.2i (freeware)
• PGP Personal Privacy v6.x.x
• PGP Desktop Security v6.x.x
• The Cyber Knights Templar (C-KT) build of PGP v6.0.2 (from build 3 onwards) (freeware)
Note that official versions of PGP freeware have never included PGPDisk. v6.0.2i is not an "official" version of PGP.

For users of PGP v6.5.x freeware, you can still use PGPDisk without reverting back to v6.0.2i by using Imad R. Faiad's hack for PGP Freeware

• PGPDisk v1.0 and the version of PGPDisk shipped with PGP v6.0 both had a serious security flaw in them, and should not be used; see "The Zimmerman Telegram" (Volume 2, Issue 1; December 1998) for further details. This review concentrates on the version of PGPDisk shipped with PGP v6.0.2i, which does not suffer from this problem.
• In order to reduce the risk of corruption, each PGPDisk volume has a copy of it's header (including a copy of the master key, etc) stored at the end of the volume.
• PGPDisk uses an "encrypted master key" system
• When creating a new volume, random data must be generated by the user by pressing keys and waggling the mouse. This random data is used to create the "master key"
• Volume files can be mounted as readonly, unless they are formatted as NTFS
• If you take a look at Control Panel->System->Device Manager->View devices by type, and check under "Disk drives", you will find that PGPDisk installs 26 "disks". This is "normal" for PGPDisk; there is one entry for each possible drive designation (A:, B:, C:, etc). They cannot be deleted without uninstalling PGPDisk. If you do try to remove them, PGPDisk will simply recreate them again then next time you reboot the computer
• In addition to the passphrase initially setup for a volume (the "master passphrase"), up to seven "alternate passphrases" can be added to a PGPDisk volume. This means that if several users need access to use a given PGPDisk volume, they can each have their own passphrase; any one of which can mount the volume.
• Alternate passphrases can obviously be removed and changed after being setup
• If you add an alternate passphrase and then forget it, you have no way of revoking that alternate passphrase, unless you remove all alternate passphrases on the volume
• Alternate passphrases can only be added/removed by using the "master passphrase"
• As well as allowing alternate passphrases, PGPDisk also has the ability to add PGP public keys to a volume. If a public key is added to a volume, it can be mounted by any user holding the corresponding private key, by using the password that protects the private key
• It is not clear to the user how many alternate passphrases have been added to a volume, nor how many PGP keys have been added
• An alternate passphrase or public key added to a volume can be setup to only allow readonly access to the volume's contents. (Surely a modified version of PGPDisk could give write access to a volume when mounted with a readonly alternate passphrase?).
• PGPDisk is also available for the Mac. This version was not looked at during this review, but I doubt that volumes created with one Mac version could be read by the PC version, and vice versa.
• An interesting feature that PGPDisk has is "Memory Static Ion Migration Protection"(!). In a nutshell, PGPDisk stores two copies of the hashed passphrase in memory; one of which is a bit-inverted copy of the other. Every few seconds, both copies are inverted. The theory behind this is that if the computer's memory stores the same data for a long time (i.e. the hashed passphrase), that memory may retain a static charge that could be read by an attacker. Flipping the bits should prevent this type of attack.
• As well has having hotkey and timeout dismount facilities, PGPDisk can also be configured to automatically dismount all mounted volumes when the computer goes into sleep mode (Windows 95/98 only)
• The minimum size of a volume is 100K
• The minimum password length is 8 chars
• Volume files have the filename extension ".pgd", but volumes may be renamed to anything, although changing a volume's ".pgd" extension will effectively disable shell support for that volume. This is a pity since PGPDisk volumes can be easily recognised by their "signature" and therefore shell support shouldn't need to rely on the filename extension
• Although "PGP" being in its name, PGPDisk is not a part of the famous PGP public/private key system used for secure communications, although it is supplied as part of the "PGP Suite".
• PGPDisk is designed such that passwords can never be swapped out to disk
• PGPDisk has an extremely clear and simple user interface; making it a excellant choice for newbies. Creating volumes is performed via a simple "Wizard"
• By all accounts, Network Associates, Inc (NAI) have a pretty bad reputation with respect to customer service and supporting their products. Help and support is available (to to some degree) from the PGP related USENET newsgroups.
• When specifiying a password (when creating a new volume/changing a volume's password), PGPDisk will display a little progress bar to give an indication of the quality of the passphrase entered, which is a little amusing!
• A Delphi Component (with full source code) is available that allows easy access to PGPDisk (mounting/dismounting volumes, etc); see Delphi Components

• The number of alternate passphrases attached to a volume
• Details of any PGP public keys attached to a volume

PGPDisk (v7.04)

• PGPDisk is part of the "PGP Desktop Security for Windows 95/98/NT/2000" (aka PGP Corporate Desktop) package from Network Associates
• PGPDisk is not available with the freeware versions of PGP, with the exception of the previous version bundled with PGP 6.0.2i (see review above), which is still freely available for download
• Unlike the version of PGPDisk supplied with PGP v6.0.2i, no source code is available for this later version.
• The Twofish encryption algorithm has now been added
• The user has the option of either re-encrypting the whole drive using different encryption algorithm, or re-encrypting the whole drive using the same algorithm that is currently being used in order to change the underlying "master key" used for encryption. Re-encryption causes all alternate public keys and username/password combinations to be lost.
• Previously, when creating a PGPDisk volume, the user had to specify a "master password" for the volume which would be used for the encryption/decryption of a master key, as in any other OTFE system using a master key system. Additionally, the user had the option of adding PGP public keys to the volume as an alternative to using the "master password" to mount the volume, which would also allow control over whether that user had read/write or readonly access. i.e. In order to mount any given volume, the user would have to either type in:

 
1. The "master password", or
2. The password to the private key corresponding to any one of a number of PGP keys that were added to the volume


This newer version of PGPDisk extends the range of password options to allow the user to specify any number of "username/password" pairs as well as PGP public keys.

In other words, to mount any given volume, the user would have to either type in:
 

1. The password to any one of the username/password pairs that was added to the volume (the username need not be specified by the user)
2. The password to the private key corresponding to any one of a number of PGP keys that were added to the volume


The concept of a single "master password" is depreciated, as any one of the PGP keys or username/password combinations associated with a volume file can be setup as the volume's "administrator key", and it is this key that is required to add/remove PGP keys and username/password combinations from the volume file.

These changes have two effects:
 

1. If more than one user requires access to mount the volume, they may each have their own password for that volume, and don't need to mess around with PGP keys
2. If required, the user has the option of exclusivly using only PGP keys for mounting.
• There is however, a serious security flaw wrt adding multiple users to the same volume file, but with different access rights. When mounting a volume, PGPDisk only asks for a password with which to mount that volume. If two or more users have the same password, then the volume will be mounted using the first user's details PGPDisk comes accross that matches that password. Putting it another way, if "user_1" and "user_2" both have the password "password", but "user_2" only has readonly access, whenever the volume is mounted using that password, it may well be mounted for read/write access, even by "user_2".

 

 

The same applies when trying to add/remove users from the volume - the user is only prompted for the administrator password, which means that if a "normal" user happens to have the same password as the administrator, they are free to modify the volume to their hearts content!

• An option to disable specific PGP Keys and username/password combinations is available
• The main GUI has had a complete overhaul to accomodate the new PGPDisk key management, and now clearly indicates to the user which keys and passwords (if any) have been added to a volume
• Amusing wiggle added when the password entered is incorrect ;)
• The weird 26 "disks" added by PGPDisk (visible via Control Panel) in the previous version of PGPDisk have now been removed
• A "mount at startup" option has been added for volume files
• As well as allowing you to mount volumes to create "virtual drives", under Windows 2000 PGPDisk allows the user to mount volumes as "virtual subdirectorys" within the existing (unencrypted) filesystem. In other words, instead of a virtual drive (e.g. E:\) appearing when the volume is mounted, a new subdirectory (e.g. C:\my_pgpdisk) can be used. This operated much in the same manner that it is possible to mount logical (i.e. real physical) harddrives under different subdirectories in the Windows 2000 filesystem.


If a volume is mounted as a virtual drive, it may be dismounted and re-mounted under a directory later, and vice-versa

In order to use functionality, the directory the volume is to be mounted under must reside on an NTFS formatted filesystem, although the volume itself may be formatted as FAT/FAT32

• A Delphi Component (with full source code) is available that allows easy access to PGPDisk (mounting/dismounting volumes, etc); see Delphi Components
• For further information, see the review of PGPDisk (v6.0.2i)

• The number of alternate passphrases attached to a volume
• Details of any PGP public keys attached to a volume
• Details of any usernames attached to a volume

SAFE Folder (v1.01)

• SAFE Folder creates one or more "virtual directories" (folders) on your existing HDDs in much the same way as other OTFE systems (e.g. ScramDisk, PGPDisk, etc) create a "virtual drive"; that is to say, they do not actually exist as actual directories that are written to your HDD. Data transferred to these directories is encrypted/decrypted OTF
• SAFE Folder uses slightly different terminology; volume files are referred to as "archive files", mounting an archive file is called "Opening" it, and dismounting is "Locking"
• Before a volume file can be used, it must first be "attached" to SAFE Folder, i.e. you must tell SAFE Folder which archive files it can use. A record of all attached archive files is stored in the registry
• Volume files can be "detached" later, in which case the relevant registry entry is removed, but SAFE Folder will be unable to mount it until it is reattached
• After being "attached", a volume file can then be mounted. Once mounted, all encrypted directories stored within that volume file suddenly appear as directories on your HDD. Data written to these directories are not written directly to the disk, but instead encrypted OTF, and stored in the archive file. Dismounting the volume obviously causes these directories to disappear in a similar manner that a "virtual drive" system would cause it's virtual drives to disappear.
• After attaching an archive file, SAFE Folder will prompt the user for the password to it.
• Detaching a mounted volume will cause it to be dismounted before it is detached
• While testing this package, one serious problem appeared; after mounting one of the test volumes I had created, I tried creating a few subdirectories off one of the encrypted directories. I then tried deleting one of these subdirectories. A simple enough operation, right? Well... Maybe not. Explorer simply couldn't do it, even though the subdirectory was empty, it kept causing "Access is denied" errors, and the directory would not be deleted. When removing these subdirectories from a DOS command prompt, no errors occured
• The user can add existing directories to a volume file which will cause them to be encrypted, the original directories to be shredded, and transformed into a "virtual directories". This is particularly useful if (for example) you have an application that you don't want anyone to use, but are unable to move it to a "virtual drive" because of registry settings, etc. SAFE Folder could transform the directory (and any subdirectories) in which the application was stored into a "virtual directory" which would not even exist until the user had supplied the correct password. Extending this idea slightly, as well as an application being encrypted in a volume file, any other (separate) directories containing related, user created, data files could also be added to the same volume, even if these directories were held on a different drive.
• Whenever the software is started, and annoying splash screen is displayed for a few seconds. There is no way to prevent this.
• The password used to encrypt a volume file can be changed, which will re-encrypt the entire archive with the new password
• Volume files can be mounted as readonly
• Installation is trivial, although for some unusual reason, SAFE Folder's default installation directory is a folder named "SAFE" under the windows directory. The user is given the warning:

"Keep in mind that the SAFE Folder programs folder and any folder above it in the directory hierarchy, can not be secured."

however, this did not appear to be the case when I tried it!
• The evaluation version of this package is the same as the full version, but the password is fixed to "DEMO" and cannot be changed
• SAFE Folder volume files have the extension ".gfs", but SAFE Folder is a little strange in that it only appears to "half register" this filetype; an icon is associated with it, but when a ".gfs" file is doubleclicked in Explorer, nothing happens! SAFE Folder doesn't startup/attach/mount or do anything!
• The shell extension allows the user to (among a couple of other things) attach and detach ".gfs" files.
• The shell extensions only work after SAFE Folder is launched, which is a little strange...
• Although volume files have a default file extension ".gfs" when created, the user is free to rename them to anything else, and will still be able to use them. Changing the file extension will prevent the shell support from working correctly though, unless you modify the relevant registry settings
• SAFE Folder also offers the ability to encrypt individual files (although not directories) and create self-decrypting executables
• SAFE Folder has the option of displaying a tasktray icon that gives the option to mount/dismount archive files and configure SAFE Folder.
• If the tasktray icon is doubleclicked, then:
• if exactly one archive is attached, it will either be mounted or dismounted
• if more than one archive is attached, a dialog will be displayed showing all attached volumes, and prompting the user which are to be mounted/dismounted

• The tasktray icon, the shell extensions, and the properties dialog form the entire GUI
• Volume files are initially 512K, and increase in size automatically in steps of 512K as needed when data is added to its virtual directories. Reducing the size of a volume file is possible, (although not obvious) by selecting "Check Archive..." from the main application window and selecting "Compress" after the volume file has been checked. The volume file will then shrink down to the smallest size possible to contain all the data being stored in it
• This package also comes with a facility to shred files called "SAFE Erase". A review of SAFE Erase can be found in the Disk and File Shredders: A Comparison
• When directories are added to an archive, they (and their contents) are shredded using SAFE Erase
• As well has allowing the user to set a hotkey to dismount all mounted volume files, SAFE Folder also offers the option of dismounting them automatically whenever the screensaver kicks in.
• As well as displaying a splash screen when it starts, SAFE Folder also displays another splash screen declaring "SAFE Folder Locked" when the user presses the dismount hotkey. This is particularly stupid - most users use hotkey dismounting as a "panic button" to secure their system, and as such is something that most users would certainly not want announced by a large dialog appearing on their screen!
• SAFE Folder attempts to provide some protection against the user accidently deleting volume files by preventing the user from deleting any file with a ".gfs" file extension. An option to disable this protection is available


Unfortunatly, this protection does not appear to work in practice since disabling it (by unchecking the option to "Allow normal delete of archives") does not actually prevent the user from deleting these (".gfs") files. However, doing so does prevent the user from changing the ".gfs" filename extension! by displaying an error stating "A required privilege is not held by the client" whenever this is attempted. Strange, but true!

• One very good point to be raised wrt SAFE Folder is the issue of how it deals with the user deleting files stored within a secure archive (i.e. mounting a volume file, locating one of the "virtual directories" that appears, and deleting a file stored within it).


When a file is deleted by the user, it is normally just moved to the "\RECYCLED" directory on the same drive. This is not an issue with "virtual drive" systems, but can be a serious security threat to "virtual directory" systems if sensitive files can end up unencrypted in the recycle bin!

I am glad to say that GTC have addressed this potential problem by offering the user an additional option; the ability to "Allow secure files to be thrown in the recycle bin". Checking this option permits normal recycle bin operation; unchecking it causes files deleted from virtual directories to actually be deleted, without being moved to the recycle bin first. In the case of a "virtual directory" system, simple deletion of the file (as opposed to shredding it before deleting it) should be sufficient since, as mentioned above, files are never actually held on the HDD in plaintext.

IMHO, even though it removes the "safety net" provided by the recycle bin, this option should never be enabled. Sadly though, it is enabled by default.

• Overall, SAFE Folder is a very nice system, but it does have it's fair share of problems.

• Unused space in a SAFE Folder volume file is filled in with "0"'s. Because of this, it is obvious to any attacker more or less exactly how much data you have encrypted.
• The size of a SAFE Folder volume file also gives an attacker a good indication of how much data you have encrypted
• A list of all attached volume files is stored in the registry. This is of particular concern since although unattaching a volume file will remove its registry entry, it may very well still be possible to recover this information from the registry; see Disk and File Shredders: A Comparison for further information on how to securely delete information from the registry

SafeHouse (v1.80.043)

• SafeHouse is aka SAFEDISK
• The minimum size for a SafeHouse volume is 2K
• The maximum size for a SafeHouse volume is 2G
• Volumes files can be increased in size, but only up to a predefined limit that depends on
1. initial size of the volume file.
2. the limit imposed by the user when creating the volume
• Volume files cannot be reduced in size
• SafeHouse does not have one main application with which you can create and manipulate it's volume files, instead it is the only OTFE system reviewed to have separate little utilities for each function; one program to create a volume, another to mount it, a third to change the password, etc. This all puts a fair number of icons on your start menu.
• Volume files can be set to expanded (increased in size) on demand, and optionally setup individually so that SafeHouse will automatically expand them whenever the volume is mounted, and the amount of free space left on the mounted volume is less than 50%-95% (this percentage is user definable) of the total size
• Volume files can only be expanded if they were set up to do so when the volume was first created
• If automatic expansion is turned on for a given volume, then when the volume is filled to more than the user specified percentage, the user is prompted to confirm that the volume is to be expanded. If the user doesn't want to expand the volume at that time, automatic expansion will be turned off for that volume
• Sadly, there does not appear to be any means of changing the expansion options set for a volume after it has been created; if automatic volume expansion is turned off by the user refusing to let SafeHouse expand it when it wants, there is no way of turning it back on again.
• When creating a volume file, the user can set the minimum and maximum length password required, should the user ever decide to change it's password.
• The rules as to what passwords can be used are a little confused:
• The documentation claims that the minimum length the password can be is 3 chars, but in practice the minimum appears to be only 1 char
• The documentation claims that the maximum length the password can be is 16 chars, in practice, it appears to be 127 chars
• The documentation claims that passwords are not case sensitive, but it appears that they are case sensitive
It is possible to create a volume with a password of more than 127 chars, but it will not be possible to mount it.

In the same way, it is possible to change a volume's existing password to one of more than 127 chars, but it will not be possible to mount it.

If you have a volume that has a password of over 127 chars, which will cause it to be unmountable, it is possible to change the password to shorter one, which will allow you to mount it again.

• SafeHouse features optional password expiration on a per volume basis; when a volume is created, the user can specify the number of days that may elapse before the user is forced to change their password.
• In addition to password expiry, SafeHouse also provides a user definable "grace period" for expiring the current password. When password expiry is enabled, and the user's password expires, this "grace period" is the number of days, during which whenever the user mounts the volume, they are warned that they need to change their password. After any grace period ends, the user is forced to change their password the next time they mount the volume
• SafeHouse volumes can have a "volume information" label (a short 31 char description of the volume that is separate from the DOS volume label) that can be seen by anyone without needing the password.


This volume information label is the primary means that SafeHouse uses to describe which volume is which to the user; it is by this label that the user selects the volume to be used in any operation from a pull down list.

• Whenever the user has to specify a volume file to work with in any of the SafeHouse programs, they are asked to specify the directory in which the required volume file is located. The user may then select the relevant SafeHouse volume from a dropdown list of volumes found in that directory. However, volumes in the dropdown list are not referred to by their filenames, but by their "volume information" labels
• SafeHouse has an option to "brand" the volume creation programs (SDWLIB.DLL and SD.EXE) so that they will add a "backdoor password" to any volumes they create. "Branding" these two programs does not require any password, and may not be immediately obvious to the user - a serious security risk; if an attacker was to "brand" your SafeHouse system, then they could easily gain access to any subsequent volumes that you created. It's worth repeating that only these two files are modified, and it is recommended that you take a backup copy of them before branding them so that they can be copied back to reverse the "branding"; useful if you wish to change the details of the "brand"
• During branding, you have the option of specifying a message that will be embedded in any volume files that are subsequently created, and another message that will be displayed when volumes are created.
• The backdoor is used by running the "change volume password" utility, selecting the volume to be mounted via the backdoor, and rightclicking on the dialog's title bar. If the volume has a backdoor password, an option will appear on the menu that pops up, otherwise this menuitem will be disabled.


After the user selects the backdoor menuitem, the branding message embedded in the volume is displayed, and the user can enter the backdoor password. When the correct backdoor password is entered, the normal password used for mounting the volume is changed to "password"

• The backdoor can also be used to provide "remote password recovery". This is an interesting feature of SafeHouse that may be of use to system administrators who have a large number of users that need to use SafeHouse.


If one of the users forgets their volume's password, and the volume was branded, the administrator could reset the volume's password as described above. However, this would require either:

1. The administrator to be present to type in the password, or
2. The administrator to tell the user what the backdoor password is.
Option 1 could be inconvenient for the administrator (and could also result in the backdoor password being "sniffed" by the user running a keyboard logger)

Option 2 may well well be undesirable if the user is not authorized to know the backdoor password.

"Remote password recovery" addresses both of these concerns. The user starts off as though they knew the backdoor password, and were using it to reset the normal password, but instead of entering the backdoor password, the user clicks a "remote unlock" button. This displays a dialog showing a hexadecimal number (the challenge) that is 48 chars long. The user reads this out to the administrator, who enters it into a separate utility (most likely running on a separate computer), together with the backdoor password. The administrator's utility generates another hexadecimal number (the response) that is 32 chars long, which is then read out to the user who enters it in to the dialog. After the correct response is typed in by the user, the volume's password is changed to "password"

• The backdoor password on volumes created with a "branded" version of SafeHouse uses the Diffie-Helman public/private key system
• "ActivCard" keys can be used with SafeHouse volumes. If these are used, then every time a user attempts to mount a volume that is associated with one or more ActivCards, they will be required to identify their self using one of the associated ActivCards. The requirement for users to identify themselves with ActivCards is in addition to the volume's password.
• Up to 5 ActivCards can be associated with any given volume
• As PC Dynamics puts it:

"SafeHouse encrypted volumes may optionally be protected using an ActivCard hand-held personal security authenticator. ActivCards may be purchased either directly from PC Dynamics or from a variety of third party sources. By keying your SafeHouse volumes to an ActivCard, you will need both your secret password and possession of the ActivCard to gain access to your files.

ActivCard security is based upon a technique known as challenge-response authentication."

• Passwords can be changed easily; SafeHouse uses an "encrypted master key" system
• One thing I noticed was that within the various SafeHouse programs, only short (8.3) filenames were used (e.g. "C:\PROGRA~1\" for "C:\Program Files", etc.)
• The documentation states that only short (8.3) filenames may be used. Having said this, when a I attempted creating a volume file with a long filename, the filename was truncated to 8.3 chars, but the filename extension remained intact.
• When creating a new volume, if the path to the directory where the file is to be stored is given in it's LFN format, SafeHouse will be unable to create the volume. Sadly, when this happens, the user is just given the extremely unhelpful message "Cannot create new volume file", and has to abort the whole operation without first being given the chance to go back and change the directory's LFN for it's short form. This is a very poor piece of GUI design - from the error message displayed, the user isn't going to have a clue as to what went wrong, and is not likely to be able to rectify the problem without contacting technical support for help.
• While on the subject of short and long filenames, I did come across one amazingly stupid bug - if you have a SafeHouse volume that is stored in a subdirectory which has a long directory name, although you can quite happily mount using the shell extensions, attempting to do so using the mount utility program can cause this utility program to crash! Specifically, if you launch this utility and then try and specify the directory which it is to look in for volume files, it crashes after you specify the directory! This is because the dialog that the utility employs to allow the user to specify the directory displays the LFN versions of directory names, and not the SFNs, which it should show.


All other dialogs that prompt the user for a directory appear to correctly display the directory SFNs, not LFNs. All is not lost with this utility though - if you mount a volume using the shell extension, the mount utility will pick up on the last directory used, and will be reasonably happy continuing to use that directory, until you change the directory used from within the utility...

• By default, volumes are created with a ".DSK" filename extension. Renaming a SafeHouse volume to change this filename extension will prevent all of SafeHouse's utility programs from recognizing the volume as a SafeHouse volume file. Shell support will also cease to work on volumes that do not have a ".DSK" filename extension, however, if the registry is modified by the user after installation, shell support can be made to work again, regardless of what the filename extension - which would allow the user to mount volumes, etc. again.
• Three other things that I noticed wrt the shell support:
1. When using it to mount a volume, the user is not given the option to specify which drive the mounted volume is to appear as; the drive letter that the last volume was mounted as is used. If this drive letter is already taken, then the lowest drive letter possible is used.
2. If the user enters the incorrect password when trying to mount a volume via the shell support, SafeHouse launches the main utility program that mounts volumes, and the user is prompted again to enter the password - by a completely different "mount" dialog, which also gives the option of specifying the drive letter the volume is to be mounted as! Bizarre...
3. SafeHouse's shell support is pretty "dumb" - when you rightclick on a volume file, you get options to both mount and dismount the volume, regardless of whether it is already mounted or not!
• This software requires a mouse to use it; it is simply not possible to use it without one. Yes, I know that pretty much 100% of PCs these days do have a mouse, but (IMHO) it was a little annoying not being able to use the keyboard for some key operations which could be carried out much faster if the keyboard could have been used...
• After mounting a SafeHouse volume, the computer will "bleep" twice. Unmounting a volume causes a "crashing/banging" sound to be played. Personally I can't imagine why anyone would want such sound effects, but thankfully, there is a command line switch that can be used to turn them off.
• After being mounted, SafeHouse volumes appear as "Removable Disks" within Windows Explorer
• As well as having a timeout option to dismount mounted volumes, SafeHouse can also be configured to dismount all mounted drives when power management kicks in, and the computer goes into standby mode.
• When creating a new volume, the user has the option to "Quick Create" the volume. Normally, when a volume is created, it is filled with what appears to be random data. Enabling "Quick Create" makes SafeHouse skip this vital operation, which means that if you examine your new volume file with a hex editor, you will find that it contains whatever data was stored on the disk when the volume was created. The security implications of this are obvious, and IMHO, this option should never be used, even though using "Quick Create" can create the new volume in a fraction of the time it would otherwise take.
• Another option that the user has when creating a new volume is to "Hide Volume File". Personally I don't feel that there is really any point to PC Dynamics including this option; all it does is set the "hidden" file attribute on the volume file after it is created, which really does nothing to increase security
• One anomaly I found was that if you mount a volume, and then launch the dismount utility, if you press <ALT+M> instead of unmounting the drive, you are shown the mount volume dialog again, but this time the label at the top of the dialog states "Unmap SafeHouse volume"! After pressing this key combination, you can't actually mount/dismount anything with it, and are forced to restart the utility. It's pretty trivial, but I found it a little amusing!
• SafeHouse can be run from DOS (i.e. after booting to DOS, without loading Windows). However, in order to do so, you must first add a device driver ("SAFEDISK.SYS") to your config.sys file. This is simple enough, but if you then reboot into Windows, Windows will be forced to run in MSDOS compatibility mode (i.e. you'll take a performance hit when running under Windows)
• If you install SAFEDISK.SYS in your config.sys file, you will only be able to mount volumes that are stored on FAT16 drives.
• When running SD.EXE (the SafeHouse utility for manipulating volumes under DOS (not Windows)) with the "/?" parameter, part of the command line reference displayed states that passwords must consist of between 3 and 16 letters, which seems a little short...
• Overall, not a bad program, apart from the major security risks related to the backdoor functionality...

• The filename of the last volume to be mounted is stored in a file called "sdw.ini" within the SafeHouse application directory
• The drive letter that the last volume to be mounted was assigned is also stored in "sdw.ini"
• Any description you specify for a SafeHouse volume is stored in the plaintext at the start of the volume file
• A record of the encryption algorithm used to encrypt any given volume is stored within the volume's header at the start of the file

SafeHouse (v2.00)

• If you previously purchased copy of SafeHouse 1.80 then you are entitled to a free upgrade to v2.0.
• v2.00 sees the addition of Windows Me/2000 support
• The maximum size for SafeHouse volumes is now 4GB
• FAT32 and NTFS are now supported (to use NTFS, the volume must be created, mounted, and then reformatted)
• The Rijndael (AES) encryption algorithm has been added (with 128 and 256 bit keylengths)
• The Twofish encryption algorithm has been added (with 128 and 256 bit keylengths)
• The shareware version of SafeHouse only supports the Blowfish (32 bit), DES (40 bit) and "Fast encryption" encryption algorithms. It is additionally restricted such that only the following 10 passwords may be used:

pass
password
safehouse
one
two
three
four
five
six
seven
• The maximum password length for the full, retail, version is 255 characters long. This clears up the problems and confusion with the previous release wrt how long the password can be.

 

 

As with the previous release, the user can specify a minimum and maximum password length on any given volume, for use when the user tries to change the volume's password.

• As well as being able to expand volumes to increase their capacity (see previous review), users are now able to shrink them!
• As described in the previous SafeHouse review, when creating a new SafeHouse volume, the user is offered the option to "Preinitialize Volume With Random Data", which by default is selected.


However, when expanding a volume, although the user is given the same option, it is not selected by default. It is recommended that whenever volumes are resized, the user makes sure that this option is selected, for the reasons explained earlier.

• The filename extension for SafeHouse volume files has now been changed to "SDsk" instead of ".DSK". This change was made in order to avoid to avoid confusing Windows Me's system file protection features.


Volumes created with an earlier version of SafeHouse must be renamed to have the ".SDsk" extension in order for