18.11.2015 19:31, Alex Peshkoff wrote:
>> >I think we need to step back and decide what the real problem is trying to
>> >be solved!!!
> Yes.
In this case the "real problem" is a ticket in tracker with feature request.
--
WBR, SD.
> > Again, I feel that they issue of client/server connection encryption and
> database encryption are being co-mingled.
> >
> > Database encryption is about the engine's ability to access/work with a
> database, there should be absolutely no client dependency.
>
> More than 80% of encryption
18.11.2015 20:27, Leyne, Sean wrote:
>
> Are you saying that the only mode that database encryption will work, is the
> one which satisfies only 80% of the installs?
Nope. You've been told that *both* key management modes (purely
server-side and via client callback) are supported. You asked why
> Sometimes it's highly desired not to let standard tools access encrypted
> database - first of all for distributed databases.
That is what user credentials/grants are for.
That is not the role of database encryption.
Sean
> 2 main usages of database encryption:
> - protect distributed database from unauthorized access,
Actually, no! Access control is not what database encryption is about.
> - protect database from access if server became physically available to third
> party (something like stolen).
Physical
18.11.2015 18:27, Leyne, Sean wrote:
> this is solution should be described in the context of how the embedded
> engine will support encryption. This thread was about SS/other engines.
There is no such things in Firebird 3. Only one engine is used everywhere.
--
WBR, SD.
On 11/18/2015 05:45 PM, Adriano dos Santos Fernandes wrote:
> On 18/11/2015 12:36, Alex Peshkoff wrote:
>> 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
> > Are you saying that the only mode that database encryption will work, is
> the one which satisfies only 80% of the installs?
>
> Nope. You've been told that *both* key management modes (purely server-
> side and via client callback) are supported. You asked why client needs to be
> in the
18.11.2015 18:55, Leyne, Sean wrote:
> What is the sequence of operations for server-side key management?
Crypt plugin either get the key somehow itself, or ask all configured key
holder
plugins for it.
--
WBR, SD.
On 11/18/2015 08:27 PM, Leyne, Sean wrote:
>
>>> Again, I feel that they issue of client/server connection encryption and
>> database encryption are being co-mingled.
>>> Database encryption is about the engine's ability to access/work with a
>> database, there should be absolutely no client
On 11/18/2015 08:45 PM, Leyne, Sean wrote:
>> 2 main usages of database encryption:
>> - protect distributed database from unauthorized access,
> Actually, no! Access control is not what database encryption is about.
Sean, may be "access" is bad word here. I've meant that _only_ special
18.11.2015 19:05, Alex Peshkoff wrote:
> In remote case it will have to send secret key over
> the wire to probably modified engine. No idea how can it be secure.
Server security is not our thing.
--
WBR, SD.
--
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
On 11/17/2015 07:48 PM, 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
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
18.11.2015 15:20, Adriano dos Santos Fernandes wrote:
> What about the callback set in the dispatcher?
Utilities that are not aware of crypt key don't ever set it. Besides, it is
up to key
holder plugin whether to call it.
--
WBR, SD.
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
18.11.2015 15:36, Alex Peshkoff wrote:
> 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.
It is enough to
18.11.2015 14:44, Adriano dos Santos Fernandes wrote:
> Applications developers will need to develop their own tools to work
> with encrypted databases outside their applications?
No, just use appropriate key holder to provide the key for every connect,
including
standard utilities.
--
On 18/11/2015 11:57, Dimitry Sibiryakov wrote:
> 18.11.2015 14:44, Adriano dos Santos Fernandes wrote:
>> Applications developers will need to develop their own tools to work
>> with encrypted databases outside their applications?
>No, just use appropriate key holder to provide the key for
On 18/11/2015 12:36, Alex Peshkoff wrote:
> 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,
> > Why should the **connection** provide the key?
>
>Because looking for a key is not a work for a lock.
>And keeping the key under a door mat is also generally a bad idea.
Perhaps you are referring to a different "connection" than I am.
Could you/someone please confirm the sequence
>Theoretical question: must every connection provide a valid key, or first
> connection unlock the database for everyone?
Why should the **connection** provide the key?
The engine should be able to find/validate the key on its own, when the
database file is _opened_. This would mean that
17.11.2015 16:26, alex wrote:
> This depends upon crypt key holder plugin.
Right. But to make it possible, Firebird code must provide an opportunity.
In terms of
code the question is "should be setKey() called only after plugin's load or for
every new
attachment no matter if the plugin was
17.11.2015 17:47, Dimitry Sibiryakov пишет:
> Hello, All.
>
> Theoretical question: must every connection provide a valid key, or first
> connection
> unlock the database for everyone?
>
можно сделать и так и сяк - определяется holder-ом
(я сегодня почти не на раюоте завтра постараюсь
17.11.2015 16:18, Leyne, Sean wrote:
> Why should the **connection** provide the key?
Because looking for a key is not a work for a lock.
And keeping the key under a door mat is also generally a bad idea.
--
WBR, SD.
Hello, All.
Theoretical question: must every connection provide a valid key, or first
connection
unlock the database for everyone?
--
WBR, SD.
--
Firebird-Devel mailing list, web interface at
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
> - Client application set callback for providing a key
I don't understand why client needs to know anything about whether database is
encrypted or not.
Certainly, MS SQL server doesn't require clients to know such details...
Sean
17.11.2015 18:01, Leyne, Sean wrote:
>> - Client application set callback for providing a key
> I don't understand why client needs to know anything about whether database
> is encrypted or not.
This step depends on implementation of KeyHolder plugin and may be not
required.
--
WBR, SD.
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
Hello!
Tuesday, November 17, 2015, 6:26:04 PM, you wrote:
>> The engine should be able to find/validate the key on its own, when the
>> database file is _opened_.
a> This depends upon crypt key holder plugin. Even in SS it may be written
a> in a way forcing each connection to provide valid
> 17.11.2015 18:01, Leyne, Sean wrote:
> >> - Client application set callback for providing a key
> > I don't understand why client needs to know anything about whether
> database is encrypted or not.
>
>This step depends on implementation of KeyHolder plugin and may be not
> required.
17.11.2015 23:48, Leyne, Sean wrote:
>
> Again, I feel that they issue of client/server connection encryption and
> database encryption are being co-mingled.
>
> Database encryption is about the engine's ability to access/work with a
> database, there should be absolutely no client dependency.
34 matches
Mail list logo
