Ok, but how is relative and absolute pathnames handled when opening or
creating a new directory or file.
On Tue, Jul 31, 2012 at 1:18 PM, Anthony Thyssen
<a.thys...@griffith.edu.au>wrote:
> 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
>
--
*Regards,
Santosh*
------------------------------------------------------------------------------
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
