Find the answer to your Linux question:
Results 1 to 2 of 2
I am working on inherent kernel functionality for file encryption and decryption ; directory name with some predefined prefix will be automatically be encrypted. Now I am stucked on storing ...
Enjoy an ad free experience by logging in. Not a member yet? Register.
  1. #1
    Just Joined!
    Join Date
    Sep 2011
    Posts
    1

    Use of inode fields for storing encryption key of file


    I am working on inherent kernel functionality for file encryption
    and decryption ; directory name with some predefined prefix will be automatically be encrypted. Now I am stucked on
    storing encryption key for file securely ,can I use any unused
    field of inode for that? Will it be efficient or please suggest any
    other idea.

  2. #2
    Just Joined!
    Join Date
    Jan 2011
    Location
    Fairfax, Virginia, USA
    Posts
    94
    I'm not a kernel guy, but I think it might be a bad idea to tweak filesystem indoes if you can avoid it. Also, I think a single file can have multiple inodes associated with it (for instance a hard link like the "." directory) which will make your approach more difficult I think.

    Finally, I think inode contents are visible with proper access by reading associated block devices (like /dev/sda1 for instance) which would expose your secret key(s).

    I'm not a cryptography guy either but I think you want to strive to separate your media from its secret key. I don't have a solid grasp on this stuff, but I'm under the impression Microsoft made a mistake like this in the past.

    I think your idea is really great and it would change the world if its possible to do it ... I wish you the best of luck.

    If the kernel had a secret key associated with it near boot time, then I'll bet you could expose a public key in an area like an inode which the kernel; in conjunction with its secret key, could transform into a secure encryption key even though your inode data is public. Come to think of it, just the inode number and some unique information about the block device might be enough assuming hard links aren't a problem.
    Last edited by BrianMicek; 09-27-2011 at 05:05 AM.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •