Encryption overhead
One of our customers asks, about encryption: 4. Do you have any idea what is the performance hit by encrypting either specific columns or the full database ? Of course, it's a "How long is a piece of string?" question. But does anyone have a feel for some approximate figures on column or whole database encryption please? This would IDS 11.5 on RHEL 5. Thank you
Neil Truby wrote: > One of our customers asks, about encryption: > > 4. Do you have any idea what is the performance hit by encrypting either > specific columns or the full database ? > > Of course, it's a "How long is a piece of string?" question. But does > anyone have a feel for some approximate figures on column or whole > database encryption please? This would IDS 11.5 on RHEL 5. > > Thank you How long is the piece of string you are comparing against? I think you need to consider index implications rather than just the "encrypt" / "decrypt" itself
> From: neil.truby@ardenta.com > Subject: Encryption overhead > Date: Fri, 13 Nov 2009 09:44:51 +0000 > To: informix-list@iiug.org > > One of our customers asks, about encryption: > > 4. Do you have any idea what is the performance hit by encrypting either > specific columns or the full database ? > > Of course, it's a "How long is a piece of string?" question. But does > anyone have a feel for some approximate figures on column or whole database > encryption please? This would IDS 11.5 on RHEL 5. > The short answer... it depends. What do you mean by encryption. :-P Ok, the longer answer. Within Informix, you can encrypt using AES or 3-DES. There are limitations. 1) This is a software only solution. Meaning no ties to any specialized FIPS rated hardware. 2) You can't encrypt columns which you plan on using within indexes, nor are your indexes encrypted. So you are not really capable of encrypting the *entire* database. You could put the database in cooked chunks and use OS or specialized hardware at the physical disk level. This will encrypt the data on the disk, however the data in memory or cache isn't going to be encrypted. It helps only if your physical drive is lost/stolen. Then there's the issue of 'tape' backups which can be encrypted on the fly. Encryption in the I/O stream. If you are looking at encryption/decryption of a non-indexed column, you could expect to see a bit of growth in the width of the column, along with what some claim to be a 10-15% overhead. Note: I haven't played with Informix's encryption outside of using it as part of a security application as part of an authentication component. There I had roughly 100-300 active accounts where I didn't notice a lot of overhead because the encryption happened infrequently and the decryption was manageable. (No discernible lag time) This is why I asked for 'hooks' so that you could plug in to hardware based solutions. JLeffler mentioned something about a common IBM package, but I don't recall if it was already implemented. If you were talking about encrypting your *entire* database, you'll need hardware encryption, along with writing your own CTI. (Hint: You'll want to return NULL if the encryption key failed.) Sorry, but its been at least a couple of months since I last looked at this and much longer since I actually priced out a FIPS-2 or FIPS-3 solution... HTH -G _________________________________________________________________ Bing brings you maps, menus, and reviews organized in one place. http://www.bing.com/search?q=restaurants&form=MFESRP&publ=WLHMTAG&crea=TEXT_MFESRP_Local_MapsMenu_Resturants_1x1
----- Original Message ----- From: "theBP" <theBP@Usenet-News.Net> Newsgroups: comp.databases.informix Sent: Friday, November 13, 2009 2:47 PM Subject: Re: Encryption overhead > How long is the piece of string you are comparing against? I don't know. But it's blue. Does that help?