Aage Johansen wrote:

> Geoff Worboys wrote:
>> ...
>> . TrueCrypt
>> http://www.truecrypt.org/
>> this is what I use now.
>> ...

> Could you say something about "performance penalty", if any?
> How do the sizes of encrypted and unencrypted files compare?

I have never used TrueCrypt encryption in a performance
sensitive environment (my clients with such requirements secure
the server itself) so I have never tried to measure it's
specific impacts to my applications. I have not noticed
significant impacts in normal use.

I am sure there is some performance penalty - but like so much
else in computer performance the specifics are going to depend
very much on the application. Read-to-write ratios, the type
and size of data being read etc etc etc. And as Doug suggested
the operating system caching plays it's part with disk caching
etc... and I tend to use virtual machines these days which adds
it's own layer of performance impact and complexity.

[I've even used TrueCrypt's whole-disk encryption over virtual
machine virtual disks... and can mount those same "disks" in
either Linux or Windows environments. The overheads in this
must be significant but thanks to modern hardware it works.]

Note too that TrueCrypt's performance will be effected by
the options you choose when you create your encrypted volume
files (cascading encryption etc is going to add load).

> For systems that just encrypt a selection of fields, what
> happens with size of the fields? Is there a point in
> encrypting a char(11) field (maybe it's childs play to
> decrypt them)?

You have TrueCrypt (or whatever) mount the encrypted file as
if it were a disk (drive X: or something - under NTFS you can
even mount as part of a path). The operating system sees this
mounted file as if it were a disk/volume.

As far as the database itself is concerned there are absolutely
no changes required - or even visible to the database. As far
as Firebird is concerned it is using its normal file. Because
the entire dataase file is buried inside the encrypted volume
the varchar(1) is as well protected as everything else.

This is one of the beauties of using this solution; everything
in your application stays the same, you just add encryption for
those users that need it.

See their beginners tutorial:
http://www.truecrypt.org/docs/?s=tutorial

After creating and mounting that file as a disk volume you can
use it just like any other disk - the encryption is totally
transparent to the applications.

(TrueCrypt's ability to use key-files can be very useful if you
need two part authorisation, or a smartcard or smartcard-like
authentication, or just cant remember passwords:
http://www.truecrypt.org/docs/?s=keyfiles )


Using encrypted volumes you will always end up using more disk
space than if you had the database on it's own. Note too that
you cannot compress an encrypted file (this is an attribute of
good encryption), so the volume file you create to hold your
database will not compress. You can, if you want, enable NTFS
compression on the mounted volume - so the files stored in that
encrypted file are compressed within the encryption (with some
additional overhead I presume) but this does not effect the
external size (size of the volume file).

Do not forget that you will need encrypted volume files mounted
(or ready to be mounted) to receive backups.


If these characteristics are not to you liking you could look
at using the Windows supplied NTFS file system encryption. I
have never used it but imagine that it can be made to do what
you need - but I suggest you study it carefully first to make
sure you do not use it in such a way that you will weaken the
security. I imagine there must be articles around to help.


I hope this helps... too much more detail would getting off
topic for this list (if I have not passed that point already).
I suggest you download TrueCrypt and experiment with it. Once
you get familiar with the concepts you can look at the other
products and see what suits you best.

--
Geoff Worboys
Telesis Computing