https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34976 Marcel de Rooy <m.de.rooy@rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dcook@prosentient.com.au, | |jonathan.druart+koha@gmail. | |com, | |martin.renvoize@ptfs-europe | |.com, tomascohen@gmail.com -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34976 --- Comment #2 from David Cook <dcook@prosentient.com.au> --- Having a single master key isn't uncommon, but it could be nice to be able to have multiple encryption keys and to specify which one is needed for what feature. I think that this mechanism could be especially useful for key rotation. (I notice Marcel has already commented on bug 32078 where we had talked a bit about key rotation.) I've used other systems where I've rotated encryption keys in this way. Another future use could be data interchange. Perhaps you'd want to share encrypted data with another system without giving that other system your master key. You could just encrypt that particular information with a shared key while keeping most other data encrypted using a master key. This scenario is pretty hypothetical though. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34976 Liz Rea <wizzyrea@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |wizzyrea@gmail.com --- Comment #4 from Liz Rea <wizzyrea@gmail.com> --- At the point you have access to root to get the koha-conf, you have everything including the database and all of the keys anyway (because you can become koha-mysql or koha-dump the whole thing) and all of the keys are right there in the koha-conf. While I agree that one key does allow access to more things, the added complexity of multiple keys... the idea of it makes me very tired, for a really negligible gain in security. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34976 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=40349 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34976 --- Comment #7 from David Cook <dcook@prosentient.com.au> --- (In reply to Marcel de Rooy from comment #3)

Interesting question though would be: How would you get one key and not the others? And underlying, is koha-conf the best place to save them?

(In reply to Liz Rea from comment #4)

At the point you have access to root to get the koha-conf, you have everything including the database and all of the keys anyway (because you can become koha-mysql or koha-dump the whole thing) and all of the keys are right there in the koha-conf.

While I agree that one key does allow access to more things, the added complexity of multiple keys... the idea of it makes me very tired, for a really negligible gain in security.

Yeah, multiple keys doesn't help if an attacker has access to all the keys. There are a few pros to having multiple keys though. One is that if an attacker cracks 1 key, they only get access to some of the information. They have to keep cracking keys to get the rest of the info. Another pro is that having multiple keys allows you to change keys and encryption methods. (Earlier in the year, OpenAthens changed their encryption keys for their SAML communications. While they advertised multiple available public keys, unfortunately, Keycloak's SAML functionality could only store and use 1 public key, and so I had to manually change the keys around the same time that they changed the private key they used. Fortunately, the decryption was for on demand responses and not stored thousands of rows of encrypted database data, but still a pain especially given the different timezones...) I've also recently been involved in some Keycloak upgrades recently, and they've re-hashed their passwords to use different hashing algorithms. To do that, they stored metadata about the crypto options alongside the hashed passwords. (At some point, we'll have to do the same thing in Koha.) Eventually, the encryption algorithms we're using will no longer be safe, and we'll need to re-encrypt the data, and we'll effectively need to use multiple keys: 1 to decrypt and a new 1 to re-encrypt. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34976 --- Comment #9 from David Cook <dcook@prosentient.com.au> --- (In reply to David Cook from comment #8)

(In reply to Marcel de Rooy from comment #3)

...

Interesting question though would be: How would you get one key and not the others? And underlying, is koha-conf the best place to save them?

To answer this question... I don't think we have many options. If we don't store them in koha-conf.xml then we'd need to store them in plain text in some other file.

Ok I say that... but yeah maybe koha-conf.xml isn't great because we can't update it programmatically. That is, if we need to update encryption algorithms, we currently don't have a way of doing that automatically. It could be worth moving the keys into a separate file. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34976 Saiful Amin <saiful@semanticconsulting.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |saiful@semanticconsulting.c | |om -- You are receiving this mail because: You are watching all bug changes.