As Chris Lee judiciously pointed out to me, synchronizing block-ciphered data (typically Rsync + EncFS in aes-256-cbc mode, which I mentioned yesterday) will induce a slight overhead on the amount of transferred data, because of block padding. This means software like Rsync could indeed benefit from internal support for repository-encryption...
But, considering the fact that AES has a block size of 16 bytes and that EncFS works on a file-per-file basis, the overhead is insignificant enough (at least on most of today's Internet connections) to not consider this development a priority, especially compared to the complete lack of support in version control systems.
On a side note (also thanks to Chris), it appears that "repository encryption" is definitely not a non-topic, as this paper from the University of California and IBM shows.
Finally, about EncFS: if you're like me and like to use everything with security settings tuned to the max, you might experience problems with running software relying on hard-links (such as mpop) in your EncFS directory. The thing is, when the filename to IV header chaining feature is enabled in EncFS, the file data encoding depends on the filename, and therefore hard-links are not supported: you will most-likely see "Operation not permitted" errors. So you have a choice between lessening the security and changing your software...
Personally, since I don't find the former acceptable, I changed mpop.
Monday, January 12, 2009
More on encrypted repositories and the usage of EncFS
Libellés : cryptology
Subscribe to: Post Comments (Atom)
Post a Comment