I originally posted this in the access forum, but I think this one may be a bit more appropriate:

----------------------

So I had one of those wonderbar data-entry bonanza days that left me WAY to much time to think about absolutely nothing.

During the course of said bonanza, I got to thinking, maybe it would be cool to encode sensitive data by bouncing it off coordinates on an arbitrary curve. It's kind of a neat concept because the numbers have no discernable relationship to eachother unless you have the formula for the elliptical curve itself.

Well lo-and-behold, I am WAY behind the times. I've been trying to poke around and get some practical information about using this type of thing in a database without much luck. There's a wealth of information about the theory itself, but not much on the db tip.

So I'm wondering, has anyone here experimented with their own encryption schemes in a database context? In general terms, how did you go about it?

I've got a couple ideas such as with the elliptical method, creating the elipse based on an algorythm derived from the ascii values in a users logon. This would provide a custom key (or curve in this case) for the data created by each user. Naturally groups could be assigned with their own keys etc etc.

I know this is basically reinventing the wheel, but the whole idea really got my noodle going.

Anyways, has anyone else been bitten by the "what if..." bug with relation to encryption?

Edit: I should add that I'm interested in any whitepapers/misc literature on the idea too. I'm not really looking for specific solution or piece of code, I'm just toying with the idea and find it intensely interesting.

Most RDBMSs worth anything support encryption already.

There's probably more value as an alternative communications protocol.

Sounds interesting, I'll work up my hyperbolic personal profile sooon

Vmusic

Dude, are you really sure you want to create your own security hole?

Remember: Always use that whats tested and has proven itself in practise, so don't reinvent the wheel, because you are not capable and you cannot be sure it meets the demands. With proven tools you at least have a stable base to start from.
Don't make a design more complex when it doesn't need to be. I believe there are many alternatives, which are much more flexible, to obscuring the information and attempt to hide the relationsships between data. This will create other problems (integrity to name one) that are very hard to overcome. The security problem can probably be solved another way.


If you are trully interested in cryptography, these is a good (free) book on the subject "Handbook of Applied Cryptography" http://www.cacr.math.uwaterloo.ca/hac/ where you should read chapter 1 to get a good inpression of what security is about. Its quite mathematical and most parts are not very interresting. Probably these are also better books...


Secondly compare these to what a decent RDBMS provides and you might notice that there is a much better way to archieve the security you demand. You don't have to obscure data in the database in many cases. It really depends on who has the rights of all involved people might be. The problems in the RDBMS aren't really different to the problems with e.g. file systems. You can take a system administrator for example.
The solution (or security features) might only be implemented slightly different on a RDBMS compared to a file system.

The RDBMS basically provides security based on tables and columns. The file system provides it on a hierachical base. The latter can be implemented on a RDBMS with some additional tables, views and stored procedures and a performance hit. So you can provide row-level security, but you need to implement it differently.

A good example is a webstore. The interfacing application handles the security so a customer cannot view another customers shopping basket or password. The RDBMS can help to prevent you making some mistakes, but the combination of the application (perform authorization) and the RDBMS (perform 'authentication') make the application secure.

- Joris