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
Saturday, January 10, 2009
Data synchronization via an untrusted third-party
Hi!
This is my first blog post ever, so... let's start softly :-)
Imagine you need to keep data sync'd between different locations but you have nowhere safe to centralize it: how would you do?
It's actually pretty simple, well, at least in theory. The straightforward answer is of course cryptography, but the tricky part is getting the synchronization software to work with an encrypted repository (in addition to encrypting the connection) .
In the case of pure data synchronization, this can be achieved using EncFS and Rsync. Create an encrypted directory using the former, work in the (cleartext) mount point, and synchronize the encrypted directory with the repository using the latter.
When it comes to complex data synchronization, such as version control (e.g. CVS), the support for an encrypted repository has to be intrinsic to the synchronization software. I don't know of any version control system capable of that at the moment... which calls for contribution! :-D Which one shall I choose first: CVS, Subversion, Git or OpenCVS? I'll let you know ;-)
This is my first blog post ever, so... let's start softly :-)
Imagine you need to keep data sync'd between different locations but you have nowhere safe to centralize it: how would you do?
It's actually pretty simple, well, at least in theory. The straightforward answer is of course cryptography, but the tricky part is getting the synchronization software to work with an encrypted repository (in addition to encrypting the connection) .
In the case of pure data synchronization, this can be achieved using EncFS and Rsync. Create an encrypted directory using the former, work in the (cleartext) mount point, and synchronize the encrypted directory with the repository using the latter.
When it comes to complex data synchronization, such as version control (e.g. CVS), the support for an encrypted repository has to be intrinsic to the synchronization software. I don't know of any version control system capable of that at the moment... which calls for contribution! :-D Which one shall I choose first: CVS, Subversion, Git or OpenCVS? I'll let you know ;-)
Subscribe to:
Posts (Atom)
