It's necessary to be able to provide different keys to dbcrypt plugin for different databases. In case when invalid key is provided an error should be reported (segfault in server due to damaged ODS is not accepted to be good way to report such errors).
No, you said exactly that: "key holder must never be configured in (common) firebird.conf, they have to be set in databases.conf for each encrypted database separately, so no problem with keys because every single key holder is used for exactly one database".
That time I didn't agree and now in Avalerion every database has unique id and this id is provided to crypt plugin and key holder for db/key identification.
I can't find that phrase in Sent email...
Taken exactly it's certainly wrong. If one wants all encrypted databases to use same KeyHolder plugin it certainly may be configured in firebird.conf. If one wants to use different key holders for different databases they must be configured in databases.conf.
What about Avalerion features - sorry, on my mind use of named keys is better option. For example they may be preconfigured in advance. And are definitely better reaqdable than GUIs.
Your implementation is plain wrong. You must not remove key name and hash from header until complete database decode. Otherwise you lose ability to resume the process if it is aborted in a half and leave database broken.
BTW, to make from 128 bits sample 160 bits hash and then blow it even more with base64 - also not a perfect idea. You'd better use sample of a page size at least and store the hash as is (header clumplet can keep binary data w/o problem).
What about sample size - 128 bits are needed only to run crypt plugins that require at least that data size, to get crypt key plus plugin footprint sizngle byte is enough.
Storing big integer as base64 (or even hex) string is much safer than use of binary bigint - internal binary representation may depend upon endianess and/or implementation details. What about space in header page - we have for sure enough.