in last year’s EOS workshop there was a presentation about a new encryption feature for EOS, based on the new XRootD library. At JRC we would be interested to test this functionality as possible solution for storing more sensitive data. Are there any news and possible documentation about this ?
if files are read via FUSE, the files are decrypted on client side, if you use eoscp/xrdcp they are decrypted in the FST, but you can use TLS connections with XRootd5 with encryption on the wire, so the risk is low, but in this case it is possible to ‘catch’ the encryption key in the FST, because you have to add it to the URL for remote access, for FUSE access it never has to leave the client.
use grcyptfs on top of /eos/ mounts, this does not allow remote access
Be aware that we haven’t used that yet in production!
It would be nice to have some documentation for the functionality, especially for the part mentioned under item 2. I will ask Franck to check then the possible configurations for running a test. Our interest is related to usage via FUSE mounts since we’re using only this access up to now.
did you add some details to the EOS documentation page for the native encryption support?
In addition, we would also be interested to get an idea about the usage of the gocryptfs on top of EOS if you could provide some example commands or configurations.
Concerning the EOS built-in obfuscation and encryption functionality, this is very easy to set up and try. Besides the presentation already linked above by Andreas, you can also use the steps outlined here to try it out: https://gitlab.cern.ch/dss/eos/-/tree/master/fusex#file-obfuscation
When it comes to gocryptfs this is even simpler as you just need to have eosxd mounted on the machine and then create a new gocryptfs mount that acts as an over-layer that encrypts both data and metadata. This quickstart guide from gocryptfs is very easy to follow: https://nuetzlich.net/gocryptfs/quickstart/
Let us know if you have any issues and I will update this thread once we further extend out documentation concerning this functionality.
Thank you for having given the information about the encryption, I have indeed observed
We might however indeed prefer the option that sets the key per mount, it would be easier to handle and keep transparent to the users.
In fact, when using environment variable, it seems easy to mess up if not setting it correctly. For instance, with the fact that obfuscation and encryption are managed by the same parameter, I managed to create an obfuscated file by not setting the secret key, then after setting it and adding content to the file (with bash redirection) getting a corrupted file.
In general, when changing the key several times during the same session, it seems that some data are kept in cache, and a content that shouldn’t be readable do display content, but sometimes altered content.
So using one single key in a same session would for sure be more easy for us. Is there any way to already test the future 5.2 client version ?
A question that our security team might ask us is the performance of the encryption algorithm. It is written that it “does not meet the highest security standards”, but is there some way to evaluate if that would be enough for what it is requested for our sensitive data ?