Issue Details (XML | Word | Printable)

Key: CORE-657
Type: New Feature New Feature
Status: Closed Closed
Resolution: Fixed
Priority: Major Major
Assignee: Alexander Peshkov
Reporter: Pavel Cisar
Votes: 27
Watchers: 10

If you were logged in you would be able to see more operations.
Firebird Core

Database encryption

Created: 17/Sep/03 12:00 AM   Updated: 22/Sep/15 09:41 AM
Component/s: Security
Affects Version/s: None
Fix Version/s: 3.0 Alpha 1

Issue Links:

SF_ID: 807965

 Description  « Hide
SFID: 807965#
Submitted By: pcisar

Allow for database to be encrypted -- user
defined/selectable library/parameters.

 All   Comments   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Alice F. Bird added a comment - 14/Jun/06 09:41 AM
Date: 2005-12-02 16:24
Sender: adnanoncevarlik
Logged In: YES


I recommend this too (and I need it). Steve Charon has said
truth. If the some one have access rights to DB, he can see
the Data in the FDB file. I think everything in the DB can't
 be readable by an user.

Some DB Admins have the access rights to DB but they don't
have permission to read Salary Data or payment Data :)

May be it will be solved with a default UDF's. I want to
write my some data with a encryption function in the
Firebird Standard UDFs.

for example ;

(INSERT example)


(SELECT example)


May be this way better than the whole database encryption.

Best Regards

Alice F. Bird added a comment - 14/Jun/06 09:41 AM
Date: 2004-08-23 00:36
Sender: brianmoloney
Logged In: YES

This should be a mandatory and selectable feature for any
DBMS; not used (mainly for performance reasons) when the
envt is secure; used when the DBMS is for a shrink-wrapped
product. The availability of this feature should be scheduled
and would be a distinguishing factor for many software
houses in DBMS choice (i.e. for me, it's the key one missing
that makes Firebird a maybe instead of a definite choice for
It would be the best of all worlds if the encryption were a)
selectable (on/off), and b) encryption-level selectable, to
give some selectable trade-offs between security and
performance, and c) algorithm-selectable

Alice F. Bird added a comment - 14/Jun/06 09:41 AM
Date: 2004-05-05 10:59
Sender: stevecharon
Logged In: YES

I recommend this too as this is something a PRO DB should
This is to have nobody else but the db engine reading the db

Mercea Paul added a comment - 01/Jan/07 11:30 AM
It's not clear for me if I could specify what 'objects' I want to encrypt.

I think for demo database where I want users to see tables and data but I don't want to allow users to see any procedure.
It will be available this feature? To encrypt only triggers or procedure?

Dejan Schild added a comment - 17/Oct/07 04:23 AM
There should be two levels of encryption: data and structure.
Encryption of data could be like Alice suggest.
Encryption of structure should prevent end users to see or modify structure of database (DDL), but don't prevent them to see data (DML). There could be file with same name as database (ec. dbname.key) with structure key. If key file exist and key is correct, then user can access to db structure, elsewhere just access to data (do select/update/modify).

Yiannis Bourkelis added a comment - 02/Mar/11 02:46 AM
I would like to choose a table or a column to be encrypted, not everything because of the performance penalty.

The encryption key could be specified in the connectionstring. That way we will not have to change anything else in our applications except of the connectionstring, that is a global variable most of times.

Karol Bieniaszewski added a comment - 08/Dec/11 08:13 AM
>>Dejan Schild
objects and data should be encrypted when storing by providing key but for read data should provide another key (like AES work)
but this key should not be stored with database or inside - this is wrong solution
if user can steal whole database file what prevent for steal also dbname.key from the same disc?

Mike added a comment - 16/Oct/13 01:35 PM
as mentioned in a duplicate issue and imho VERY important,

"In the U.S., the meaningful use rules(for the healthcare industry) now dictates that data encryption has to be an option that can be turned on. And, the encryption algorithm that is acceptable is AES. "

So it should be clearly visible for future users that the DB has a important security issue and maybe should not be used without special considerations on these issues.

In other words, i think its extremly important to have this encryption feature fore firebird. And yes, i would neet it too, urgendly.
The structure of the db as well as the data have to be encrypted.

For making it faster, this could be in a 2-Level-fashion(maybe in next Version V4, after first
encryption features in V3):
Strong costly encryption in first level, when starting the DB, so that a stolen, down db couldn't
be used,
and a faster decryptable part which with use of the first part is allowing the fast access of the data.