As you describe it, it also does not prevent against a man-in-the-middle attack
between the client and the broker, but that could be rather easily fixed by
using something like Diffie-Hellman at the outset.

-a



________________________________
From: Jim Starkey <jstarkey@...>
To: Firebird-Architect@yahoogroups.com
Sent: Wed, November 3, 2010 2:26:40 PM
Subject: Re: [Firebird-Architect] database encryption

I think it address the problem where database medium, e.g. the disk,
are not provably secure. An example would be a database running in a
public cloud. The database file, broker store, and database executable
can be all be compromised or hacked without exposure of the database.

What it does not do is authenticate a broker to the client, so a
completely compromised server with a hacked broker could spoof a correct
broker and break the scheme. There's probably a solution for this, but
I'm going to leave it for somebody else to solve.

On 11/3/2010 5:17 PM, Doug Chamberlin wrote:
> On 11/3/2010 5:08 PM, Jim Starkey wrote:
>> OK, here's a schema that I think works...
> So that we can evaluate this scheme properly while thinking it through,
> to which of the many use cases that have come up over the years is this
> intended to apply? In other words what protection level is intended?
>


--
Jim Starkey
Founder, NimbusDB, Inc.
978 526-1376



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

Yahoo! Groups Links



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