Interbase: Full encryption vs None, performance diff

[Joe Sansalone 6]

Hi,

 

In terms of performance:

Has anyone tested Interbase with encryption (at rest and in motion) vs no encryption?

 

Even rough comparisons would be useful.

Just looking for any data describing relative performance.

 

Thanks,

Joe

[Sriram 4]

@Joe Sansalone, 

I don't have any hard numbers to share. But, we did run some informal benchmarks when testing our workload way back when encryption feature was being developed.

 

On average, we found that full database encryption (for data at rest) introduced a 5-10% performance impact depending on the encryption key strength used. Of course, full database encryption encrypts only "user data" related data pages, but for the whole database. So, if you have a large enough database in-memory cache, and your "write" activity is minimal, you will mostly incur only "decrypt" cost when loading your database pages into memory. Pages are unencrypted when residing in in-memory cache. Simultaneous user requests don't add any further load to the decryption mechanism. If you have high level of "write" activity, the "encrypt" cost for these database pages will also add to the performance tax. You can offset some of this, if you use InterBase short-term Journaling for synchronous writes (database file writes will be async automatically at checkpoint intervals) resulting in only delta changes written to the journal rather than a whole database page immediately.

 

OTOH, a Column-Level Encrypted database, will have far less negative impact on performance than a fully encrypted database for individual requests. Your mileage may vary as to how many columns are encrypted in your database, and in what strengths. But, column-level encryption could have a larger negative impact if you have hundreds of simultaneous requests accessing those encrypted column data. Each request now has to "decrypt" the column data when fetching the "row" from the database page.

 

For OTW/SSL (network encryption), I understand that the performance impact could largely be felt at establishing the SSL "connection" as compared to an unencrypted TCP/IP socket connection. Since we use OpenSSL for our network encryption, I am sure the data packets encrypted/decrypted between InterBase Client and Server through this encrypted channel will incur some CPU charge (heard about 10%-25% addition from conversations many years ago). If your system architecture allows you to have a Connection Pool setup ahead of time, and then shared by your application threads communicating with the server, the "connection" time can largely be inconsequential over time. The data load though will continue to incur the encrypt/decrypt cost at either end of the encrypted channel. IIRC, you use InterBase Change Views. Providing your Change Views usage is factored in, you are already reducing large data sets from being sent to the client application; so, the impact should be fairly painless thanks to Change Views usage adding to bandwidth savings. 

 

You may already know this. But, encrypted (database and column-level) databases have a restriction that they can only be backed up and restored using the InterBase service manager component (GBAK, IBConsole supports this); so, network bandwidth impact is eliminated because of this. Backup/restore is most data intensive, and glad to note that encryption does not impact performance adversely here.

 

A couple questions for you...

1. What kind of database connection and request load do you anticipate?

2. Do you have a middle tier using any custom connection pooling?

3. Have you though of using some VPN layer implementing encryption at the network level, and just use InterBase Client and Server to communicate through this network provider?

4. Do your client applications communicate to systems over WAN or to public cloud environments?

 

Hope this helps.

[Joe Sansalone 6]

@Sriram

 

We have 1 column that we need to encrypt.  Although it will be in a very used table.

And we are thinking of encrypting the entire database too.

5 to 10% overall performance impact is not bad.

 

For our website, we do custom connection pooling.

But also have direct connections to the server, via desktop apps.

 

Even a full 10% hit is ok.

 

Thank you for the detailed reply.  Useful to have as reference.

Good to know that using Change Views also helps reduce impact because of encryption.

 

Thank you.

[Joseph MItzen 251]

On 3/31/2022 at 4:26 PM, Joe Sansalone said:

Hi,

 

In terms of performance:

Has anyone tested Interbase with encryption (at rest and in motion) vs no encryption?

 

Even rough comparisons would be useful.

Just looking for any data describing relative performance.

 

Thanks,

Joe

 

While I don't have numbers for you, I do have this perspective - Interbase's encryption is effectively useless. People have occasionally proposed the same feature for PostgreSQL, and every time there's both little interest and sound arguments about why it's useless.

 

If you want to protect your data if someone walks off with a server hard drive, you have OS-level or hardware level full-disk encryption available. Embarcadero would argue that this doesn't protect anyone from snooping while the system is running, since the encryption in this case is transparent to the running OS. That's true, but Interbase's solution won't help you here either. Here's why:

 

On a typical server, the database is given its own user account and is the only application running as this user. All the files are set to belong to the database only. This makes sense as nothing else should be touching the raw database files. So in this case there would be a user "interbase" that owns all of Interbase's files and the Interbase executable is the only application that should be able to touch the raw database files. All well and good. Data is encrypted within the Interbase database to protect it from someone who manages to gain access to the raw database files anyway. But here you're not helped. The encryption key is stored on the server. The "interbase" user owns the key file. If anyone has gained sufficient access rights to read the raw database file, they also have the right to read the key file, since it's going to have the same access privileges. Now if you have the raw database file and the encryption key you can decrypt the encrypted data and the Interbase encryption was useless in protecting your data.

 

Some would argue it's better to do encryption on the client end and store the encrypted data in the database. Now if someone gains access to the server and the database file they still need to also gain access to the client to get the encryption key. This is more secure, but if encryption happens on the client end the database can't read the unencrypted data and hence indexes won't work on those columns.

 

So IMHO neither of these solutions accomplish much and in most instances aren't worth the hassle.

[Sriram 4]

@Joseph MItzen,

InterBase never stores the "encryption value" that is used to encrypt/decrypt database pages (for Database Encryption) or column values (in the case of Column Level Encryption) directly in the database. What is stored in the RDB$ENCRYPTIONS.RDB$ENCRYPTION_VALUE is a derived/encrypted form of the aforementioned "encrypted value" using an encrypted derivation of the System Encryption password (SEP) as the key. If one does not have knowhow of the SEP, it is not possible to derive the correct encrypted derivation of the SEP to further decrypt the stored RDB$ENCRYPTION_VALUE of an encryption key.

 

In the case of an Encryption Key having an additional PASSWORD associated with it, a further gauntlet is available for a stronger encryption filter that needs to be validated by the user/application, as an alternative to the SEP that may be more widely available in the application interface (though not recommended).

 

When you mention "key file" in your comment, what are you alluding to? InterBase does not store Encryption Keys and their values in any adjunct "key file" for encrypting data at rest in the database file. So, I am not sure I follow your argument. Can you elaborate please?

 

I would also be interested to know if your comments are based on some real tests, or speculative/thoughtful comments for engaging further discussion on this topic.

 

Thanks.