On Tue, 31 Jul 2012 11:52:32 +0530 SaNtosh kuLkarni <santosh.yesop...@gmail.com> wrote: | How does encrypted directory and filename lookups take place in encfs.Does | encfs decode all the directory names and filename upon encfs mount.Can | someone brief me on this.Thanks |
The directory name is just another filename, and each name along a directory path is decrypted separately (using the same key), before moving to the next directory along the path. WARNING: directory IV chaining option causes each parent directory to change the encryption of contained filenames and file data. It is normally turned off, as enabling this breaks the use of symbolic links. Each filename is encrypted than a checksum prepended. This is then converted to a base64 encoding (ascii) and the characters '.' (which can make a file hidden), and '/' (one of the 2 illegal characters in a filename, NUL being the other) replaced with ',' and '-' respectively. For the specific details of encoding a filename http://www.ict.griffith.edu.au/anthony/info/crypto/encfs.hints section "Filename Encryption Algorithm" When reading a directory, each filename in the encrypted directory is decrypted with the key, and if the checksum matches the filename (or sub-directory name) is displayed, otherwise it is ignored, and that file is not included in the resulting decrypted directory listing. This means that if you have extra 'chaff' files, or unencrypted files like ".encfs6.xml" in the encrypted directory these are not visible in the decrypted directory. (I think the ".encfs6.xml" file is passed as is for 'Reversed-EncFS handling'. Another reason to keep that datafile separate to the actual encryption! It also means that you could interleave two sets of encrypted files in the same encfs encrypted directory (though sub-directories remain separated by 'key'. Only those filename that your current key decrypts will be made visible! The rest remains only visible in the encrypted directory with only filename length, data length, and timestamps to indicate which file was maade visible. See my notes on EncFS techniques http://www.ict.griffith.edu.au/anthony/info/crypto/encfs.hints Section "Interleaved EncFS Filesystems, for Plausible Deniablity" Note that the final encrypted filename length is actually roughly dependant on the original filename length. That is: filename length rounded up to the blocking factor of the encryption, plus 2 bytes for the checksum, the result is base64 encoded (3 binary bytes -> 4 ascii bytes), to get the finale encrypted filename length. As such a super-long filenames will be obvious in the EncFS encrypted directory tree as also being super-long, unless other equally super-long filenames are also present in the same directory. ASIDE: directory structure, time-stamps, permissions, filename length, and file data length are currently known 'visibility' problems in EncFS, that allows you to compare decrypted files against encrypted files in EncFS, and work out a correspondance. But you need the 'key' to decrypt, and with that you can ask "encfsctl" to map the files anyway. The solution is for a new generation of EncFS that stores large files in multiple smaller 'chunk' files, and replace directory structures with encrypted directory files that also hold 'permission' and 'time stamp' info. That is replicate the normal 'inode' type structure of a block filesystem, in actual files. I have however yet to here of anyone developing such a 'next-generation' Directory Level Encrypted Filesystem. Anthony Thyssen ( System Programmer ) <a.thys...@griffith.edu.au> -------------------------------------------------------------------------- "Never Fear, Smith Is Here!" Doctor Smith, "Lost in Space" -------------------------------------------------------------------------- Anthony's Castle http://www.ict.griffith.edu.au/anthony/ ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Encfs-users mailing list Encfs-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/encfs-users
