Again, I think we need to put that statement (such - "good security" is
impossible) within a boundary. If the goal is to make sure that no on-disk
storage stay unencrypted, then, I do think there should be a solution for
"good security" (not "obscurity"). It is certainly not an easy job to do.
Along the course of this discussion, very constructive aspects have
been brought up toward this goal.

* temporary files - need to use PIO or something simular to PIO
* paging of memory - may need system configuration (it might be simpler for
64bit Windows)
* some other loose ends ? (please help)

It is too often too easy to give up when we run into problems. Let's at
least list out the things that are involved toward a "good security" and
discuss the possibility of solving the problem(s). If at the end it is
concluded that it's impossible to achieve the goal. Then we all know that we
can nail down the topic of "database encryption" (or rather "Firebird
database encryption") in the history of mankind and formally release this
conclusion to the public that "it is not doable with Firebird"! We can
also formally claim that Firebird should not be used in any government (or
any) projects that require encryption for data security.

BTW, let's leave the process protection from the topic at this moment. That
sure is important. But let's hold until we prove that the "prerequisite" can
be achieved. After that, we can proceed with this "more advanced security"
level :)







2010/11/6 Geoff Worboys <geoff@...>

> Dimitry Sibiryakov wrote:
> > In this topic we seemed to agree that [...]
>
> <cynic mode>
> Something agreed? Nah. I'm sure you're mistaken, there's
> not much chance of anything being agreed.
> </cynic mode>
>
>
> > "good security" is impossible and some level of obscurity
> > may be enough. In this case you can choose between, say,
> > base64, uuencode, ROT or Caesar (if I remembered name for
> > variable ROT right) algorithms.
>
> There does seem to be some ... contention/uncertainty in the
> discussion about exactly what level of security is being
> requested.
>
> On one hand we have a request for real/serious encryption and
> wanting to include temporary files and disk cache etc,
> but on the other the request is "not promising the world".
>
> I think the reason for this is a distinct lack of understanding
> in what is involved. It is possibly counter-intuitive to some
> that you could use the current encrypt/decrypt interface to
> apply AES encryption to a database - and yet have a result that
> is little different in its security from a simple XOR with a
> text password. One will cost you 30% overhead, the other I
> guess a few %, and neither will offer any real security (but
> both would stop local search engines finding plain text).
>
> --
> Geoff Worboys
> Telesis Computing
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>

[Non-text portions of this message have been removed]