Is there an encrypted version control system?

Question

I am looking for an encrypted version management system. Basically i would like

• Before sending to the server, all files are encrypted locally . The server should never receive files or data that is not encrypted.

• Every other function should work in much the same way as today SVN or CVS.

Can someone recommend something like this? I have done a lot of searches, but I can not find anything.

Answer 1

Instead, you should encrypt the data channel (ssl / ssh) and provide access to the server. Data encryption will cause SVN to essentially consider everything as a binary file. It cannot make any differences, so it cannot store delta. This defeats the goal of the delta approach.
Your repository will become huge, very fast. If you upload a file with a size of 100 kbytes, and then change 1 byte again and check, do it another 8 times (a total of 10 revolutions), the storage will store 10 * 100 kb, not 100 kb + 9 small deltas (let’s name it 101 kb).

Update: @TheRook explains that you can do delta with an encrypted repository. Thus, it is possible. However, my initial advice is worth it: it's not worth the hassle, and you're better off with ssl / ssh encryption and server security. that is, "best practices."

Answer 2

You can create a version control system for ciphertext. It would be ideal to use a stream cipher such as RC4-drop1024 or AES-OFB. So far, the same key + iv is used for each revision. This will mean that the same PRNG stream will be generated every time, and then XOR'ed with the code. If any single byte is different from the other, then you have a discrepancy, and the encryption text itself will be combined normally.

A block cipher in ECB mode can also be used, where the smallest discrepancy would be 1 block in size, so it would be ideal to use small blocks. On the other hand, CBC mode can create widely different ciphertext for each revision and, therefore, is undesirable.

I understand that this is not very safe, OFB and ECB modes are usually not used, since they are weaker than CBC mode. Victim IV is also undesirable. Moreover, it is not clear with what the attack is defended. Where using something like SVN + HTTPS is very common and also safe. My post just says that this can be done efficiently.

Answer 3

Why not configure your repo (subversion, mercurial, whatever) on an encrypted file system and use ssh only for connection?

Answer 4

Use rsyncrypto to encrypt files from your plaintext directory into your encrypted directory and decrypt files from the encrypted directory and your plaintext directory using the keys that you hold 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 that you can download now from Sourceforge not only handles changes in bytes, but also inserts and deletes. It implements an approach very similar to that referred to in The Rook.

Single-byte insertions, deletions, and changes to the plaintext file usually cause rsyncrypto to make several K completely different encrypted texts around the corresponding point in the encrypted version of this file.

Chris Thornton points out that ssh is one good solution; rsyncrypto is a completely different solution. Compromise:

• Using rsyncrypto requires transferring multiple Ks for each “trivial” change, rather than the semi-aK that he would use using ssh (or on an unencrypted system). Thus, ssh is slightly faster and requires slightly less diff storage than rsyncrypto.
• Using ssh and standard VCS requires that the server (at least temporarily) have keys and decrypt files. With rsyncrypto, all encryption keys never leave the local computer. Therefore rsyncrypto is a bit more secure.

Answer 5

You can use the Tahoe-LAFS grid to store your files. Because Tahoe is designed as a distributed file system rather than a version control system, you probably need to use a different version control scheme on top of the file system.

Edit: here is a prototype extension for using Tahoe-LAFS as internal storage for Mercurial .

Answer 6

SVN has built-in support for secure data transfer. If you use svnserve, you can safely access it using ssh. Alternatively, you can access it through the apache server using https. This is described in detail in the svn documentation .

Answer 7

What exactly are you trying to protect?

Use Subversion ssh or https for repo access. Use an encrypted file system on clients.

Answer 8

Check out the git. It supports various hooks that can do the job. See git encrypt / decrypt remote repository files, while push / pull .

Answer 9

Have you considered using Duplicity? This is similar to rdiff-backup (delta backup), but encrypted? Not really version control, but maybe you need all the cool stuff, but you don't want to work with anyone else. Or just click / 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 - obviously Truecrypt containers still work well .

Answer 10

Option A

Use distributed VCS and transfer changes directly between different clients using encrypted links. In this case, there is no central server under attack.

For example, using mercurial, you can use the internal web server and connect clients via VPN. Or you can link change sets and distribute them with encrypted emails.

Option B

You can export the encrypted hard disk partition over the network and connect it on the client side and run VCS on the client side. But this approach has many problems, for example:

• possible data loss when two different clients try to access VCS at the same time
• the link itself should be protected from fraudulent write access (when a partition is shared via NFS, it will most likely finish the configuration where anyone can write to the shared partition, so even when it is not possible to read other content, there is an easy hole for destroying content)

There may be other problems with option B, so forget option B.

Option C

Like @Commodore Jaeger, use VCS on top of an encrypted network file system, such as AFS .

Answer 11

As in some comments above, a useful solution could be to encrypt and locally store the entire repository and synchronize it with the remote mailbox. For example. when using git, the entire repository is stored in the '.git' directory in the project directory.

• zip / encrypt entire dir project
• upload it to the server (not sure if just processing .git is enough)
• Before continuing with your project, download this archive.
• decrypt / unzip and sync with git (locally)

This can be done with a simple shell script more comfortable.

pro: You can use any encryption, as well as every VCS that supports local repositories.

minus is missing, obviously, some VCS functions, when several people want to load their code base (merge situation) - although perhaps this could be eliminated by avoiding overwriting remotely and merging locally (which introduces the lock, the nightmare begins here)

However, this solution is a hack and not the right solution.

Answer 12

A secure source stores data in encrypted files. Wait, I'll take this. They are confused. And there is no other security than the front door for obfuscation.

Come on tomato.

Answer 13

Based on my understanding, this cannot be done, because in SVN and other version control systems, the server needs plaintext access to perform version control.