Re: Has IDS 9.5 been released?

Way back when (28 October 2004, to be precise) nobody wrote: > it depends on how its being implemented. > > Just because you have a feature doesn't mean its optimal or works the > way you would want it, or is as secure as you think it is. ;-) > > Example. You have a column that you want encrypted. So you treat it as a > blob, so you encrypt the data but you can't index it. You can't index blobs. Indexing encrypted data is a dubious proposition. You could do equals comparisons, but you can't do meaningful range comparisons. When designing a system that will store encrypted data, you need to concentrate your efforts on not needing to do more than look up the encrypted information based on non-encrypted information. For example, if you decide you need to encrypt (US) Social Security Numbers, then you do not try to use the encrypted SSN as the identifierfor an individual in any tables - you invent an alternative identifier number (for example, an employee ID). > Or if the column in the row is encrypted, and you can index it, is the > index of the column also encrypted? It had better be - otherwise the encryption overhead is wasted. Of course, you could create a functional index on the decrypted data, but then you're back to 'why are you encrypting it?' > Which encryption scheme do you use? Any you like. DES has been retired from (US Federal) government service, though 3-DES is still permitted. DES has been superceded by AES - aka Rijndael. So, 3-DES and AES are good options; many of the other contenders for the AES are also good candidates. > Can you allow for a system call to encrypt/decrypt so you can use > hardware based encryption for faster throughput? That's harder to address. > All sorts of design and implmentation decisions that you should think > out ahead of time. > > But hey, what do I know? Its not like I asked this from Informix back in > '98.... ;-) > > Hari Gupta wrote: > >> Wow !!!!! Col. level encryption. What a great feature. This is what I >> was looking for a long time as Oracle has it from a long time. Well >> done guys. This will be another major step towards implementing best >> practice for database security at our work. Would be great to know >> more details of new features. Don't forget - encryption is computationally expensive. You use it when you need to (probably because you have to), not because you think it would be cool. Database server machines already work hard; you don't want to add unnecessary computational workload on them. And note that encryption is a more expensive process than decryption, even with symmetric encryption algorithms, because the encryption process generates a random IV (intravenous - no, initialization vector) which the decryption process simply uses. (Yes, Linux has /dev/random and /dev/urandom - it isn't clear how much that improves the performance.) -- Jonathan Leffler #include <disclaimer.h> Email: jleffler@earthlink.net, jleffler@us.ibm.com Guardian of DBD::Informix v2003.04 -- http://dbi.perl.org/