Subject | Re: [Firebird-Architect] Re: database encryption |
---|---|
Author | Olivier Mascia |
Post date | 2010-11-08T14:53:41Z |
Roman,
To make it short: we agree.
For the minor differences, please read below.
Thanks!
Though I think you might actually make my first point easier...
—
Olivier
To make it short: we agree.
For the minor differences, please read below.
Thanks!
>>> I think there is market for in-database encryption (probably small), basically the case when people want to protect the data from a casual look (embedded use of Firebird, dictionaries, etc.).You're right.
>>
>> Best handled at the application level then. Cloud computing? Not wanting your data unencrypted "over there"? Simply want to obfuscate or encrypt some data stored on a DVD? Nothing stops a developer to encrypt some of the data before storing it in the DB. Details are completely application dependent. Firebird out of the (in)equation.
>
> Not everything can be encrypted on the application level... How are you
> going to perform the range queries on obfuscated content? What about
> LIKE queries or using SUM function?
Though I think you might actually make my first point easier...
> Also as Geoff pointed out, ECB cannot be used here, but then...you're explaining why such cases would benefit so much from a simple EFS, without re-inventing the wheel, the axle, and all the gears (and whistles) that go with it at the Firebird application level.
> initializing the encryption code with a deterministic, though random,
> init vector complicates the database layer (and I am not talking about
> space overhead, when from a 4-byte integer encryption code will generate
> e.g. 16-byte block, but that one corresponds 1:1 to the number anyway
> and can be mapped easily).
> Sorry, for such cases a replacement for PIO that encrypts/decrypts dataAnd there I have to agree it would be good marketing for the project to have some sort of extensibility feature to replace the PIO core, should it be needed (and not only for encryption needs, but for specific storage -- not file based per se for instance). Though if thinking of a loadable PIO replacement scheme, great care should be taken about conditions when the engine accepts to load a replacement IO core module, so that hijacking the whole server does not become kids play.
> transparently seems to be a lot better, easier and separates the
> responsibilities cleanly.
—
Olivier