I am currently working on implementing a cryptographic file system using FUSE. It is different from EncFS and similar in that it just mirrors a normal directory tree, but encrypts the contents of the files as they are read or decrypted as they are written.
My use case is backups. I have some machines where I and only I have access, machines which may contain proprietary information, personal emails and so on. Of course, I want backups of those, so when the hard drives stop working, I don’t lose any data. The machine(s) I am backing up to, however are not always machines where I trust all the people with physical access to not make a copy of my data. In addition, I don’t want broken hard drives returned under warranty to contain unencrypted data. This use case is the reason for why I’m encrypting on read rather than on write.
I have chosen to use CTR (counter) mode together with AES which should give acceptable security. One of the requirements CTR needs to work well is a nonce, typically 64 bits (for 128 bit AES) which must not ever be used twice. If you use it twice, you leak information about your plaintext, which is, for obvious reasons, bad.
My current design headache is how to choose a good nonce. Ideally, I
believe it should be persistent for each version of the file and unique
per file. Using the inode number takes up 64 bits (on AMD64 at any
take, or when using -D_FILE_OFFSET_BITS=64 on 32 bit platforms). So
while this gives me the latter, it doesn’t give me the former at all. I
am wondering if I should use the inode number modulo 2^32 (effectively
choosing the lower 32 bits of the inode number) and then something which
is fairly sure to never be the same, such as mtime (or at least the
lower 32 bits of it, when time_t becomes 64 bit). The reason for not
just choosing a completely random value is I don’t want a command like
diff file1 file1 to claim there are differences in the file.
My hope was I’d get a great idea on how to solve the problem as part of writing it down. Alas, that hasn’t happened, so if you happen to come across a great solution (or a reason to avoid a particular choice), feel free to email me