Encryption at data-level?

I read some white papers regarding the Trusted Content Services and well it's a start..

For my next project encrypting is a must but I've got several doubts regarding the how-to with documentum..

Apparently TCS offers me SSO, digital firm, shredding and FILE encryption.. all good and well, but..

Is it possible to store some critical metadatas in an encrypted form, and decrypt in on the fly when consulting it, provided your entitled to, as an OOB functionality? And if it's possible, is the algorithm a secure (or non-public) one?

So far my solution is to use a privately-held secure algorithm library implementation, and add a low-level customization that translates every single request parameter to its matched encrypted correspondant, and viceversa from encrypted result-set to de-crypted visible stuff.. Issue is, on mid-to-large db (around 130gb and growing) and considering a repository of approximately 28 millions of files (currently their file repository is around 5tb) growing on a rate of 7800-8500 files/day I'm quite hesitant about the impact of such customization on the performace of the whole solution...

If you have any advice, I'm wide-open (or eager), since the data is quite sparse as is (during classification/edit I gotta call several webservice that interacts with external systems WITHOUT replicating more than 1/5th of the information I have to fetch, so goes without saying that I'm already performance-tight as is).

Thanks in advance,

Vito

Find more posts tagged with

Note:

If there are Accepted Answers, those will be shown by default. You can switch to 'All Replies' by selecting the tab below.

Accepted answers

witchedwiz

in the end we decided to go with storage-level encryption and db encryption.

Guess I'll do some test with my local content server for "forcing" encryption and decryption of data via customization at the lowest possible level (think I'll have to decompile a few classes)...

Whilst it might end up with nothing worth keeping, on the other hand using TCS file encryption and metadata encryption via customization may turn into a performance increase compared to storage level+db encryption.. as they say, nothing ventured, nothing gained. Worst come to worst, I'll have wasted some time

All comments

BinayGupta

I wont suggest cutsomization at all when you are targetting this bulk of content in the repository. why not TCS and Database encryption. You may also choose to use encryption of the storage device. I guess this should be enough. Your content, metadata is encrypted and the communication is secured.

witchedwiz

issue is..

tcs lists around a 10% performance degradation..

dabatase level encryption with sql server 2008 r2 lists around a 6-7% of performance loss on data encryption..

pluis there's the storage-level device encryption...

I was looking for the most efficient solution, since, as I said, I'm really striving to optimize the whole thing as much as possible and supposedly a documentum-level selective metadata encryption would have served me best...

I guess that if nothing new about an OOB solution comes up, I'll decide whether to go with db-level + TCS encryption or simply going with EFS...

witchedwiz

in the end we decided to go with storage-level encryption and db encryption.

Guess I'll do some test with my local content server for "forcing" encryption and decryption of data via customization at the lowest possible level (think I'll have to decompile a few classes)...