As the saying goes: The proof is in the pudding (or plugin, in our case ...).
Having the plugin skeleton (from the KeyProviderTest
code sample) ready in the repository, and a plan in my mind (and in the project wiki) about what cryptographic steps are required, I think it is time to flesh out the source code a bit.
For the time being, I will postpone wrestling with the vagaries of card readers and will simply use stub routines which return faked and constant "card content" data bytes - similar to what the KeyProviderTest
plugin now does with the provided keys.
The point of this initial coding effort is twofold:
To check whether I did understand the KeePass documentation correctly concerning the derivation of the master key from the "key material" input by the user rsp. plugin.
To validate the cryptographic concept: ie, that the "card content" and the associated key file can indeed be used alternatively on the same database.
Note that the security of the system can of course not be estimated by "trying out" the implementation like that!.