On 04/12/18 15:18, Mark Rotteveel wrote:
How does the protocol for the database encryption callback work? If I look at the implementation in Firebird ADO.net, it just tries and keep sending the same key in a while loop until Firebird responds with something other than op_crypt_key_callback, which seems a bit weird.
Looks like at the other side there is _VERY_ strange plugin. Certainly having such behavior in the code is serious bug in ADO.net.
So what is in the buffer of the op_crypt_key_callback from server to client, and what should be in the op_crypt_key_callback from client to server? Or is that plugin specific?
Yes - plugin specific.
Also, IIRC, there was a change for database encryption that led to wire protocol v14, exactly what changed between wire protocol v13 and v14?
There was a bug in v.13 - size of respond buffer was not passed over the wire.
On a related note, when using the native API, it looks like the encryption callback registration is process-wide instead of attachment-specific.
In native API it's provider-specific - after getting an instance of provider one (who needs to use database encryption) should pass callback interface to that provider. In ISC API emulation thread-wide approach is used - handler installed by fb_database_crypt_callback() will be used by attaches in given thread.
Isn't that a great way to send encryption keys to the wrong system (if you're using multiple databases and/or systems)?
With right design of plugin this will not happen - interface should make sure there is correct KeyHolder on the server before sending a key. Certainly with an approach described by you in ADO key may get lost. But when crypt is used in this way key may get lost in many other scenarios.
Mark
------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
