On 04/12/18 18:20, Mark Rotteveel wrote:
On 12-4-2018 16:51, Alex Peshkoff via Firebird-devel wrote:
On 04/12/18 16:51, Mark Rotteveel wrote:
On 12-4-2018 15:31, Alex Peshkoff via Firebird-devel wrote:
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.
Technically the Firebird client code also uses a loop though.
Yes, but instead of sending same key it's passing data from server to
the passed by client interface and returns an answer from it to
server. In case of no intreface it returns empy answer, and be sure -
server knows that it means 'no key from client'.
But does this mean that there is only a single op_crypt_key_callback
from server to client, or can there actually be multiple (eg if there
is a more complex handshake?)?
Number of rounds of crypt_key_callback handshake is plugin-dependent and
is not limited by firebird.
Other question: how does this work with named keys? Is it still a
responsibility from the server-side plugin to communicate this in a
implementation specific way?
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
And how would a client do that?
For example - KeyHolder has a private key of RSA pair, client
software - a public one. Before sending something over the wire it's
encrypted with public RSA, to decrypt it private part of pair is
needed. Servers that do not have right private RSA key can receive
the message but it's a garbage for them. Actual protocol should
better be more complex - at least with salt to avoid sending same
packet for same key.
To me it sounds like parts of this should have been defined within the
Firebird implementation and protocol itself, it is now very easy to
write plugins that are vulnerable to replay attacks.
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