On Wednesday 08 June 2005 18:33, [EMAIL PROTECTED] wrote: > "Ken Buchanan wrote:"
> Another area where I predict vendors will (should) offer built in > solutions is with database encryption. Allot of laws require need-to-know > based access control, and with DBA's being able to see all entries that is > a problem. Also backups of db data can be a risk. > Oracle, for example, provides encryption functions, but the real problem > is the key handling (how to make sure the DBA can't get the key, cannot > call functions that decrypt the data, key not copied with the backup, > etc.). > There are several solutions for the key management, but the vendors should > start offering them. Yes, this is a perfect example of where we need tools that can make this use of crypto more transparent. Of course, anyone who's worked on big database projects must have realised that they've drifted somewhat away from the idealistic vision of the relational story (as told by Coase? Date? some other guys no doubt) and adding encryption and key handling to that is just like throwing sand into the machine. I'd suspect most of us here could have a fair stab at the "encrypted tapes" problem. But we'd not get nearly as far with the "encrypted database" problem. I think this is one area where databases are going to continue to create more noise than value, and things like capabilities are more likely to advance, simply as they are looking more clearly at the underlying data and the connections and authorisations that need to be protected. iang -- Advances in Financial Cryptography: https://www.financialcryptography.com/mt/archives/000458.html --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
