02.04.2018 18:40, Alex Peshkoff via Firebird-devel wrote:
It does not receive key name. chainHandle does transfer all keys application wants to send
to the server.
I see. It does that a way before server get to know if the database is
encrypted at all.
Wonderful: one key holder can get app
On 04/02/18 18:57, Dimitry Sibiryakov wrote:
02.04.2018 17:43, Alex Peshkoff via Firebird-devel wrote:
- one more closed-source plugin I've used to deal with
Perhaps, it has the same limitations.
No.
Could you reveal the secret then: how application callback receives
name of crypt key
02.04.2018 17:43, Alex Peshkoff via Firebird-devel wrote:
- one more closed-source plugin I've used to deal with
Perhaps, it has the same limitations.
No.
Could you reveal the secret then: how application callback receives name of crypt key
if it is called way before the key holder get
On 04/02/18 18:31, Dimitry Sibiryakov wrote:
02.04.2018 17:25, Alex Peshkoff via Firebird-devel wrote:
Encryption of database using key passed from application over the
wire works well in at least 2 known to me plugins:
- DbCrypt_example/KeyHolder_example present in firebird distro
This one
02.04.2018 17:25, Alex Peshkoff via Firebird-devel wrote:
Encryption of database using key passed from application over the wire works well in at
least 2 known to me plugins:
- DbCrypt_example/KeyHolder_example present in firebird distro
This one can serve only one key for only one predefine
On 03/31/18 16:45, Dimitry Sibiryakov wrote:
Hello, All.
Is it intentional that database cannot be encrypted via remote
connection if encryption plugin requires key obtained from application
callback?
I'm getting following error:
Statement failed, SQLSTATE = 42000
unsuccessful metadata
Hello, All.
Is it intentional that database cannot be encrypted via remote connection if encryption
plugin requires key obtained from application callback?
I'm getting following error:
Statement failed, SQLSTATE = 42000
unsuccessful metadata update
-ALTER DATABASE failed
-Missing correc
20.11.2015 14:27, Vlad Khorsun wrote:
> I tried to show you why key holder is important and necessary part of
> design. It seems
> (to me, at least) you not understand it.
Yes. With server-side only key holders, I don't see anything that crypt
plugin cannot
do itself. Whatever key holder
20.11.2015 14:19, Dimitry Sibiryakov wrote:
> 20.11.2015 13:12, Vlad Khorsun wrote:
>> Key holder allows engine to never see encryption key. It is very
>> important as
>> engine is open for everyone while plugins are private\closed code and could
>> protect
>> itself. It is not required by de
20.11.2015 13:54, Alex Peshkoff wrote:
> On 11/20/2015 03:46 PM, Dimitry Sibiryakov wrote:
>> 20.11.2015 13:42, Alex Peshkoff wrote:
>>> In that case why not pass it as datetime in Delphi representation? :)
>> Delphi datetime is not a pointer.
>>
> Who cares - bits are bits.
Fixed size als
On 11/20/2015 03:46 PM, Dimitry Sibiryakov wrote:
> 20.11.2015 13:42, Alex Peshkoff wrote:
>> In that case why not pass it as datetime in Delphi representation? :)
> Delphi datetime is not a pointer.
>
Who cares - bits are bits.
20.11.2015 13:42, Alex Peshkoff wrote:
> In that case why not pass it as datetime in Delphi representation? :)
Delphi datetime is not a pointer.
--
WBR, SD.
--
Firebird-Devel mailing list, web interface at
https:
On 11/20/2015 03:32 PM, Dimitry Sibiryakov wrote:
> 20.11.2015 13:27, Alex Peshkoff wrote:
>> Yes I understand that one can put some binary data into string :)
> "string" it is only in IDL. After compilation it is "const char*"
I know what is string in idl.
> which allows to clean
> some ugly
20.11.2015 13:30, Alex Peshkoff wrote:
> On 11/20/2015 03:26 PM, Dimitry Sibiryakov wrote:
>> 20.11.2015 13:24, Alex Peshkoff wrote:
>>> In case of real key holder, not just sample
>> It exists?
> As far as I know not.
Then it is theoretical, not real.
--
WBR, SD.
---
20.11.2015 13:27, Alex Peshkoff wrote:
> Yes I understand that one can put some binary data into string :)
"string" it is only in IDL. After compilation it is "const char*" which
allows to clean
some ugly casts from code. Bits are bits.
--
WBR, SD.
--
On 11/20/2015 03:26 PM, Dimitry Sibiryakov wrote:
> 20.11.2015 13:24, Alex Peshkoff wrote:
>> In case of real key holder, not just sample
> It exists?
>
As far as I know not.
--
Firebird-Devel mailing list, web inter
On 11/20/2015 03:19 PM, Dimitry Sibiryakov wrote:
> 20.11.2015 13:12, Vlad Khorsun wrote:
>> Key holder allows engine to never see encryption key. It is very
>> important as
>> engine is open for everyone while plugins are private\closed code and could
>> protect
>> itself. It is not required
20.11.2015 13:24, Alex Peshkoff wrote:
> In case of real key holder, not just sample
It exists?
--
WBR, SD.
--
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-d
On 11/20/2015 03:20 PM, Dimitry Sibiryakov wrote:
> 20.11.2015 13:17, Alex Peshkoff wrote:
>> in real case it depends upon data passed.
> "Real case"?..
>
In case of real key holder, not just sample
--
Firebird-Devel
20.11.2015 13:17, Alex Peshkoff wrote:
> in real case it depends upon data passed.
"Real case"?..
--
WBR, SD.
--
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird
20.11.2015 13:12, Vlad Khorsun wrote:
>Key holder allows engine to never see encryption key. It is very important
> as
> engine is open for everyone while plugins are private\closed code and could
> protect
> itself. It is not required by design to send the secret key over the wire in
> open
On 11/20/2015 02:49 PM, Dimitry Sibiryakov wrote:
> 20.11.2015 12:42, Alex Peshkoff wrote:
>> They can. Callback format is:
>>
>>uint callback(uint dataLength, const void* data, uint bufferLength,
>> void* buffer);
>>
>> I.e. they can pass any data between each other.
> If you are talki
20.11.2015 12:09, Dimitry Sibiryakov wrote:
> 20.11.2015 9:53, Alex Peshkoff wrote:
>> Yes, and as the result key is passed from holder to crypt plugin via
>> open source code. As it was reasonably suggested by Vlad our code should
>> better never touch keys at all.
>
> That may sound good, but
20.11.2015 12:42, Alex Peshkoff wrote:
> I.e. you suggest as default unsafe opportunity.
BTW, I suggest default which will save us from endless questions and tickets
"why
application callback is not called, something is broken in server".
If you insist, I can add to the tracker the first t
20.11.2015 12:42, Alex Peshkoff wrote:
> They can. Callback format is:
>
> uint callback(uint dataLength, const void* data, uint bufferLength,
> void* buffer);
>
> I.e. they can pass any data between each other.
If you are talking about the case of shipped database or when intruder got a
On 11/20/2015 01:56 PM, Dimitry Sibiryakov wrote:
> 20.11.2015 11:48, Alex Peshkoff wrote:
>>> That may sound good, but in reality cannot gain any additional
>>> security. Besides, the
information was already passed via remote module.
>> Only in some cases. In case of embedded usage (i.
On 11/20/2015 02:30 PM, Alex Peshkoff wrote:
> On 11/20/2015 02:23 PM, Dimitry Sibiryakov wrote:
>> 20.11.2015 9:53, Alex Peshkoff wrote:
>>> key is passed from holder to crypt plugin via open source code.
>> And don't forget that it is passed via CLOOP interfaces in any case.
>>
> Yep, that's
On 11/20/2015 02:23 PM, Dimitry Sibiryakov wrote:
> 20.11.2015 9:53, Alex Peshkoff wrote:
>> key is passed from holder to crypt plugin via open source code.
> And don't forget that it is passed via CLOOP interfaces in any case.
>
Yep, that's a point. Not good.
When it was designed it was passe
20.11.2015 9:53, Alex Peshkoff wrote:
> key is passed from holder to crypt plugin via open source code.
And don't forget that it is passed via CLOOP interfaces in any case.
--
WBR, SD.
--
Firebird-Devel mailing li
20.11.2015 11:48, Alex Peshkoff wrote:
>> That may sound good, but in reality cannot gain any additional
>> security. Besides, the
>> >information was already passed via remote module.
> Only in some cases. In case of embedded usage (i.e. when protection of a
> key from open source code makes
On 11/20/2015 01:09 PM, Dimitry Sibiryakov wrote:
> 20.11.2015 9:53, Alex Peshkoff wrote:
>> Yes, and as the result key is passed from holder to crypt plugin via
>> open source code. As it was reasonably suggested by Vlad our code should
>> better never touch keys at all.
> That may sound good,
20.11.2015 9:53, Alex Peshkoff wrote:
> Yes, and as the result key is passed from holder to crypt plugin via
> open source code. As it was reasonably suggested by Vlad our code should
> better never touch keys at all.
That may sound good, but in reality cannot gain any additional security.
Bes
On 11/19/2015 08:40 PM, Dimitry Sibiryakov wrote:
> Hello, All.
>
> I've finished some modifications in database encryption system:
>
> Crypt plugin interface was made simpler.
Yes, and as the result key is passed from holder to crypt plugin via
open source code. As it was reasonably
Hello, All.
I've finished some modifications in database encryption system:
Crypt plugin interface was made simpler.
Database id generated at creation time is provided to it.
Key holder interface was made simpler.
Management of key holders was moved to Y-valve that enabled using
Hello, All.
For every shadow a database page is encrypted separately. Why?
--
WBR, SD.
--
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
forge.net]
Sent: 19 September 2015 12:04
To: firebird-devel@lists.sourceforge.net
Subject: Re: [Firebird-devel] Database Encryption
19.09.2015 13:21, peter@freeserve wrote:
> Hello all,
>
> I would like to implement the database encryption offered in Firebird 3
but to not have the expertise t
19.09.2015 13:21, peter@freeserve wrote:
> Hello all,
>
> I would like to implement the database encryption offered in Firebird 3 but
> to not have the expertise to develop the required module.
>
> Has anyone successfully developed such a module and prepared to share it with
> me?
First look
Hello all,
I would like to implement the database encryption offered in Firebird 3 but
to not have the expertise to develop the required module.
Has anyone successfully developed such a module and prepared to share it
with me?
Regards
Peter
-
38 matches
Mail list logo
