Dimitry Sibiryakov wrote:

> Do you consider these points to be good? From this point
> of view, encryption on client side is an absolute winner
> as it solves all problems at once: network, memory, swap,
> hibernate, sort and storage are protected automatically. You
> just have to find encryption function which comply one rule:
> for every x1 < x2, f(x1) < f(x2) must be also true.

I am not aware of any encryption that will satisfy your rule
and still provide good security.

I have not mentioned network security because I don't know
enough about it. I use a VPN and am happy with it, I've never
felt the need to building my own encryption over top of it.

Most of my discussion here - trying to take database encryption
seriously - is aimed at the embedded situation. In a non-
embedded situation I would most strongly advocate that a user
implement operating system supplied security to ensure that
no unauthorised users (including users on the same system) can
access the database file directly - database file encryption
makes very little sense in such a situation (if it makes sense
anywhere).


Jim suggests that database file encryption is somehow useful
in the "cloud" but I am not sure how this works. If I don't
trust the cloud operator (God?) to keep my system secure then
why should I imagine they can stop someone from interfering
with my server and so make any file encryption pointless?

I am not sure how the temporary file situation is effected
by cloud possibilities either.

--
Geoff Worboys
Telesis Computing