Can we use any specific field in inode (VFS inode cache) of a file to store some information such as storing key of encryption for that file?
If possible then how?

Welcome to LQ Security.

In Linux, inodes are a data structure that is used to hold information regarding the file (e.g. location, permissions, access times, etc). As far as I know the structure is semi-fixed. The inode cache is an array of copies of the inodes where the inodes are indexed by a hashing function. By its nature the table would be rather volatile with data being read and written to the it continuously. In essence, it doesn't sound like a good place to store information, even if there were extra padded, or blank fields in the inode structure to store information. You would then have the complications of getting information into and out of the structure and this would need to be built into the kernel itself.

All told, it doesn't sounds like a very safe or efficient practice to me. Perhaps you could expand upon your theory?

1 members found this post helpful.

If you need to store non-sensitive per-file information, consider xattrs.

Storing the key used to encrypt a file anywhere on the disk as-is is insecure.
You could store the public part of a public-private key pair into an xattr, however.

In userspace, you could write wrappers around the file I/O syscalls, to check for the encryption xattr, and if encrypted, ask a keyring manager for the corresponding key; if successful, your library would decrypt the file transparently. Encryption is of course possible too, but specifying which key to use is a bit of a problem unless the user only uses one key for encryption at a time. Without the library, and/or the key, programs can only access the encrypted contents. (Many tools will drop the xattr, though, so you do need to check that backups et cetera retain the public key in the xattr. Otherwise you cannot decrypt the file transparently, and even by hand is tedious since you need to try each of the keys you have to find the one that works.)

You can of course replace the library later on with a kernel module, which overrides the read and write vfs ops, if the file is/should be encrypted at open time, and then underlying fs supports xattrs.

Hope this helps.

1 members found this post helpful.

We can use xattr but it is quite transparent and there are many tools that can give you contents of those attributes.
We will be doing this as a inherent functionality to frequent context switch problem of user space utilities.
Our idea is basically:

The proposed Secure File System (SecFS), we will be providing file data security using cryptographic techniques in a transparent and convenient way. The proposed SecFS pushes encryption services into the Linux kernel space, mounting it between the virtual file system layer and underlying file system. After SecFS is integrated with the Linux operating system (OS), it enables OS to provide file data security as its inherent functionality. SecFS requires that the user creates a directory and name it with the prefix 'ecrypt' to store the encrypted file data, such as ecryptdir. Any directory on the system with the prefix 'ecrypt' will basically tells the system that the newly created directory will contain encrypted data. All files destined to be saved on this directory will be transparently encrypted on the fly without any user intervention. SecFS will be fully compatible with all underlying storage file systems.