On 11/18/2015 04:44 PM, Adriano dos Santos Fernandes wrote:
> On 18/11/2015 11:40, Alex Peshkoff wrote:
>> On 11/17/2015 07:52 PM, Adriano dos Santos Fernandes wrote:
>>> On 17/11/2015 14:48, Dimitry Sibiryakov wrote:
>>>> 17.11.2015 17:40, Leyne, Sean wrote:
>>>>> For me, the sequence of operations for accessing a database would be:
>>>>>
>>>>> - Client initiates connection to remote server, requesting access to 
>>>>> database XYZ.fdb  (there is nothing new in the connection string other 
>>>>> than what is available now)
>>>>> - engine tries to open database XYZ.fdb and read header page
>>>>> - engine determines that header page reads "I am encrypted and need key 
>>>>> with name = ABCD"
>>>>> - engine determines (through server/database config settings) which 
>>>>> plug-in to use
>>>>> - engine loads/calls plug-in asking "I have database which needs key with 
>>>>> name = ABCD, are you able/ready to work?"
>>>>> - if plug-in says "Yes", then the engine proceeds with database open, and 
>>>>> all non-header page operations are channeled through the plug-in
>>>>> - if plug-in says "No", then engine stops the database open, and returns 
>>>>> error to client.
>>>>      Currently it is this way:
>>>>
>>>> - Client application set callback for providing a key
>>> Why a callback instead of directly passing it to attach/create?
>>>
>>> Hot does different clients (my application x IBExpert) will work with an
>>> encrypted database if the applications are wrote by different developers
>>> and plugins are not standard?
>>>
>> Sometimes it's highly desired not to let standard tools access encrypted
>> database - first of all for distributed databases.
>>
>>
> Well, but sometimes it is!
>
> Applications developers will need to develop their own tools to work
> with encrypted databases outside their applications?

2 main usages of database encryption:
- protect distributed database from unauthorized access,
- protect database from access if server became physically available to 
third party (something like stolen).

In first case it's clear - IBExpert should not work at all. In second 
case it should work, but it's not reasonable to store key on clients 
cause it will be enough to have single client machine (together with 
server) to solve access problem. Another way to provide a key should be 
used.

I.e. I do not see need in callback to standard utilities, but if needed 
we certainly can a call to key holder in yvalve. But personally I prefer 
not do it cause it may be treated as suggestion to use bad design.



------------------------------------------------------------------------------
Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel

Reply via email to