I am looking for an encrypted version control system . Basically I would like to
Have all files encrypted locally before sending to the server. The server should never receive any file or data unencrypted.
Every other feature should work pretty much the same way as SVN or CVS does today.
Can anyone recommend something like this? I did a lot of searches but I cant find anything.
Why not set up your repo (subversion, mercurial, whatever) on an encrypted filesystem, and use ssh only to connect?
You should encrypt the data pipe (ssl/ssh) instead, and secure the access to the server. Encrypting the data would force SVN to essentially treat everything as a binary file. It can't do any diff, so it can't store deltas. This defeats the purpose of a delta-based approach.
Your repository would get huge, very quickly. If you upload a file that's 100kb and then change 1 byte and checkin again, do that 8 more times (10 revs total), the repository would be storing 10 * 100kb, instead of 100kb + 9 little deltas (let's call it 101kb).
Update: @TheRook explains that it is possible to do deltas with encrypted repository. So it may be possible to do this. However, my initial advice stands: it's not worth the hassle, and you're better off with encrypting the ssl/ssh pipe and securing the server. i.e. "best practices".
Have a look at GIT. It supports various hooks that might do the job. See, http://stackoverflow.com/questions/2456954/git-encrypt-decrypt-remote-repository-files-while-push-pull.
What specifically are you trying to guard against?
Use Subversion ssh or https for the repo access. Use an encrypted filesystem on the clients.
You could use a Tahoe-LAFS grid to store your files. Since Tahoe is designed as a distributed file system, not a versioning system, you'd probably need to use another versioning scheme on top of the file system.
Edit: Here's a prototype extension to use Tahoe-LAFS as the backend storage for Mecurial.
SVN have built-in support for transferring data securely. If you use svnserve, then you can access it securely using ssh. Alternatively you can access it through the apache server using https. This is detailed in the svn documentation.
Source safe stores data in Encrypted files. Wait, I take that back. They're obfuscated. And there's no other security other than a front door to the obfuscation.
C'mon, it's monday.
Based on my understanding this cannot be done, because in SVN and other versioning systems, the server needs access to the plaintext in order to perform versioning.
It is possible to create a version control system of cipher text. It would be ideal to use a stream cipher such as RC4-drop1024 or AES-OFB mode. As long as the same key+iv is used for each revision. This will mean that the same PRNG stream will be generated each time and then XOR'ed with the code. If any individual byte is different, then you have a mismatch and the cipher text its self will be merged normally.
A block cipher in ECB mode could also be used, where the smallest mismatch would be 1 block in size, so it would be ideal to use small blocks. CBC mode on the other hand can produce widely different cipher text for each revision and thus is undesirable.
I recognize that this isn't very secure, OFB and ECB modes shouldn't normally be used as they are weaker than CBC mode. The sacrifice of the IV is also undesirable. Further more it isn't clear what attack is being defended against. Where as using something like SVN+HTTPS is very common and also secure. My post is merely stating that it is possible to do this efficiently.
Use rsyncrypto to encrypt files from your plaintext directory to your encrypted directory, and decrypt files from your encrypted directory and your plaintext directory, using keys that you keep locally.
Use your favorite version control system (or any other version control system -- svn, git, mercurial, whatever) to synchronize between your encrypted directory and the remote host.
The rsyncrypto implementation you can download now from Sourceforge not only handles changes in bytes, but also insertions and deletions. It implements an approach very similar to the approach that that "The Rook" mentions.
Single-byte insertions, deletions, and changes in a plaintext file typically cause rsyncrypto to make a few K of completely different encrypted text around the corresponding point in the encrypted version of that file.
Chris Thornton points out that ssh is one good solution; rsyncrypto is a very different solution. The tradeoff is:
Use a distributed VCS and transport changes direct between different clients over encrypted links. In this scenario is no attackable central server.
For example with mercurial you can use the internal web server, and connect the clients via VPN. Or you can bundle the change sets and distribute them with encrypted mails.
You can export an encrypted hard drive partition over the network and mount it on the client side, and run the VCS on the client side. But this approach has lot's of problems, like:
There might be also other problems with variant B, so forget variant B.
Like @Commodore Jaeger wrote, use a VCS on top of an encryption-aware network file system like AFS.
Have you thought of using Duplicity? It's like rdiff-backup (delta backups) but encrypted? Not really version control - but maybe you want all the cool diff stuff but don't want to work with anyone else. Or, just push/pull from a local Truecrypt archive and rsync it to a remote location. rsync.net has a nice description of both - http://www.rsync.net/resources/howto/duplicity.html http://www.rsync.net/products/encrypted.html - apparently Truecrypt containers still rsync well.