How to encrypt some tables?

[Fabiano SCI]

Hi!

I know there is a Firebird plugin to encrypt the entire database BUT I wonder if there is a way to encrypt only SOME tables (or even fields).

I take a look and ran the demo encryption plugin of Firebird and not figured out how to tell Firebird about encrypting some tables/fields only.

I dont want to encrypt the entire database because it slow downs the wole system by no less than 35% in our tests and also when you create a backup of an encrypted database it does not ZIP at all for obvios reasons.

[Dimitry Sibiryakov]

Fabiano SCI wrote 24.05.2023 21:41:
> I know there is a Firebird plugin to encrypt the entire database BUT I wonder if
> there is a way to encrypt only SOME tables (or even fields).

No, but you always can encrypt them in your application before storing.

> I dont want to encrypt the entire database because it slow downs the wole system by no less than 35% in our tests

That's quite a lot. What encryption did you use? I believe that
hardware-accelerated AES should have much smaller impact.

--
WBR, SD.

[Elmar Haneke]

> and also when you create a backup of an encrypted database it does not
> ZIP at all for obvios reasons.

It is not the best idea to backup FDB-files directly using ZIP as you
need to stop database daemon before.

For Backups taken with gbak or nbackup encryption is optional. Both can
be used while daemon is running.

Elmar

[Fabiano SCI]

35% is using hardware-accelerated AES instructions, otherwise the show down is up to 400%

I know that is possible to myself encypt the data with my application but the point here is that it is much more simple to write an encryption plugin than messing with million of codes from our application - and we have a much partners that access our database with other softwares, so is not practically at all.

[Fabiano SCI]

I know it. BUT the most practical way to get a BIG database of more than 250Gb with more than 8500 indices is to nbackup a copy of the whole database, compress it and send over the internet, this takes less than an our. If I need to gbak database, compress, transfer over internet, recreate database AND then indices the whole process takes more than 24 hours.

[Elmar Haneke]

> 35% is using hardware-accelerated AES instructions, otherwise the show
> down is up to 400%

You should also test shorter encryption keys.

The secuity depends on getting the key out of your software which is
less difficult than breaking an not that long key in AES.

Elmar

[Dimitry Sibiryakov]

Elmar Haneke wrote 25.05.2023 17:30:
> You should also test shorter encryption keys.
>
> The secuity depends on getting the key out of your software which is less
> difficult than breaking an not that long key in AES.

That's true, 128 bits AES key is out of range for brute force and pre-image
attacks.
In addition there are block chaining modes that can be paralleled.

--
WBR, SD.

[Fabiano SCI]

My test key is only 3 characters long. But thats not the point, I would like to select certain tables for crypt even in a non orthodox way.

[Dimitry Sibiryakov]

Fabiano SCI wrote 25.05.2023 21:42:
> My test key is only 3 characters long.

This is not how AES works. It performs 10, 12 or 14 shuffle rounds, so if you
use 3 characters key expanded to 256 bits, it will be 40% slower than with 3
characters key expanded to 128 bits key for no advantages.

--
WBR, SD.