https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40349
--- Comment #1 from David Cook <[email protected]> --- Sounds good. Of course, it means that we'll have to re-encrypt all the database contents. But that could be a blessing in disguise! At the moment, we just *know* which fields are encrypted based on the code, and how they're encrypted, and we have a single "encryption_key" in koha-conf.xml. But the more time goes on the harder this is going to get to manage. We should update the database schema to store JSON metadata alongside the encrypted values. This is a normal practice these days. I'd suggest things like "kid" (or key_id), "algorithm" (e.g. AES-256-CBC in the case of Koha::Encryption currently), "pbkdf" (e.g. opensslv1 or pbkdf2), "iterations" (e.g. 10,000 - current default value of Crypt::CBC). In theory, we'd want IV and salt as well, but Crypt::CBC stores them as headers in the ciphertext/encrypted value, so we probably don't need to worry about those yet. Instead of "algorithm", we could break it down into "cipher" (e.g. AES), "keysize" (e.g. 256 bits which is a default value from Crypt::Cipher::AES), and "mode" (e.g. CBC). I'd then say we should add an attribute to "encryption_key" in koha-conf.xml. Since we don't currently programmatically update koha-conf.xml, I'd say we just store a value of "default" for kid for existing data. -- You are receiving this mail because: You are watching all bug changes. _______________________________________________ Koha-bugs mailing list [email protected] https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
