Ok I had to jump in here... While I do not agree with some that have stated that there is no need to encrypt data stored in a RDBMS (I can give you real world examples where it is required on several levels, including legal ones), I do agree that encryption is better left outside of the RDBMS itself. That is not the job of an RDBMS. If you need encryption build it into your application. If you do that, then encrypting the storage area and datasaves is redundant and doesn't give you anything anyways.
Also, encryption in the RDBMS itself will usually always be very weak for what most people would use it for. This is because most people would want to do queries on the encrypted data, but that requires that the RDBMS be able to decrypt the data using a key that it stores on the filesystem or in memory. Any way you go about it, if you keep the private key on the RDBMS your encryption is going to be weak. The only way around that would be to have an extended syntax for select statements that would pass the private key in the query somehow. Then on top of that you would need a mechanism to store the private key safely in the application that sends the query. You see encryption in itself isn't much good, you have to have it as part of a larger strategy. If you don't approach it that way, all you are getting is a false sense of security. In the real world, most people using encryption that is included in another product such as a RDBMS are just being fooled. It isn't providing them any real security because they have no clue about how encryption really works, and what things have to be in place for their encryption to even be worth anything. As an example of a strategy that works for us, we have several fields in a number of tables that need to be encrypted. We use a PKI with our own CA and provide the RDBMS users with their own certificate. We encrypt the data with the public key which is stored in the RDBMS itself. When a user runs a query, the application accesses the private key on their pc and decrypts the encrypted data on their end. Our servers don't even have the private key and never see the plaintext at all. If someone broke into our systems all they would get is a bunch of 2048 bit encrypted data wrapped in a PKCS#7 envelope. If a users computer was compromised, it can only compromise their own data, not the entire RDBMS. Sometimes we even provide offline storage for the private keys of the users if they wish that is stored in printed form in a safe. So if they lose their private key all is not lost. And even then, the whole system is compromised if someone gets access to our safe. In the long run, there is always a weak point somewhere. Chris ----- Original Message ----- From: "Juergen Sauer" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Tuesday, February 11, 2003 9:21 AM Subject: Re: Suggestion Encryption [Re: AW: Frage??] > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Am Dienstag, 11. Februar 2003 18:11 schrieb Richard Barrington: > > Could you not accomplish much of this using OpenSSL toolkit and Loopback encrypted > > filesystem under Linux? There are port monitoring / firewalling systems which > > can determine access easily enough as well. > > In Linux we can work around nearly anything. ;->> > But this is a big effort and not really well to maintain. > > > As already said, going about it this way allows us to leverage existing work > > easily, eg hardware accel is available off-the-shelf, it's already well tested, > > etc. > > The point is not using all linux-aware options to fix out design flaws made > generations before. > > Encryption of the storage area and the datasaves looks *very* nessesary to me. > But it has to grow as standard option, aviable for all Sap-DB palttforms. > Linux, Windoze, HP-UX, AIX, Solaris. > > Since the needed Libraries are LGPL, so it should not be a problem to use them > in the commercial/proprietary SAP side also. > > mfG > J�rgen > > > - -- > J�rgen Sauer - AutomatiX GmbH, +49-4209-4699, [EMAIL PROTECTED] ** > ** Das Linux Systemhaus - Service - Support - Server - L�sungen ** > ** http://www.automatix.de http://www.kranautomatisierung.de ** > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.1 (GNU/Linux) > > iD8DBQE+STD+W7UKI9EqarERAq8RAKCQy6JYYNcbDun3mwqgPsoFEg3oowCgzock > +SCCJS808W2XUbgfsa6XWnU= > =4utM > -----END PGP SIGNATURE----- > > _______________________________________________ > sapdb.general mailing list > [EMAIL PROTECTED] > http://listserv.sap.com/mailman/listinfo/sapdb.general > _______________________________________________ sapdb.general mailing list [EMAIL PROTECTED] http://listserv.sap.com/mailman/listinfo/sapdb.general
