On Thu, May 20, 2010 at 11:29 PM, Richard Walker <richard@softimp.com.au> wrote:
>
> If I understand your scheme, this works in a scenario
> where the row being updated is in some sense "owned" by a
> particular user, who must provide some other data (a "password")
> not otherwise stored in the database in order
> to decrypt it and then encrypt it again after the update.
Well, a pool of users, but essentially yes.
> That's not the case in my scenario. The row being
> updated is not specifically "owned" by an individual
> application user.
So who does own it?
> But you've given me food for thought, by translating
> the original problem into an encryption problem.
>
> There is _other_ data in the database which
> is sensitive and could usefully be encrypted. But
> the data in this particular problem is not
> sensitive per se, I just don't want it to be
> possible to recreate a history of updates.
>
Like I said originally; why? What's the real point in all this?
If it's anonymous records of some kind you could build FK strings that
are essentially variations on the scheme I've given you, but I'm not
sure I'd want to deal with the performance implications...
However, I will point out that if you can't read the data you may be
able to tell who created a given row, but so what? All the variations
on your scenario that I can think of at the moment all seem to boil
down to a security issue of some form...
--
Peter Hunsberger