[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Only Crypted things in CVS-Repository

From: Kaz Kylheku
Subject: Re: Only Crypted things in CVS-Repository
Date: Tue, 09 Oct 2001 16:28:59 GMT
User-agent: slrn/ (Linux)

In article <address@hidden>, Thomas Deselaers wrote:
>I am new to this list, but I have checked the archives and as far as I could
>see, until now there was nothing similar to my idea discussed.
>The situation I have is the following.
>Together with some friends of mine I am developing to win a small contest at
>our university. We are 4 persons and thus we decided to use CVS to manage
>our sources. For the Repository we used the server of a friend of us who
>said he would not be taking part in this contest. But now he is taking part
>an he obviously stole code from our CVS-Repository.
>This brought us to the idea if it is possible to store crypted sources in a
>CVS-Repository without losing the funktionality of diffs etc. Of course it
>would be absolutely easy to encrypt everything and store them binary.

The question is, how to use the servers hosted by some untrusted party
to store data in such a way that the untrusted party can do backups for us
and all that, but not be able to read any of the information.

One tool for doing this is CFS (Cryptographic File System) from AT&T's
research labs. Unfortunately, this is implemented using NFS, which means
that you would be accessing CVS files as an NFS mount. CFS acts as an
encrypting/decrypting NFS server: you run it locally and mount it to
get a plaintext local view on the data, and it does encrypted I/O to
some other directory, which itself can be mounted on a remote server.
This is fine for many applications, but CVS is sensitive to the integrity
of various filesystem operations whose semantics subtly break under NFS.

>I thought about this, and came to the conclusion that this would be possible
>by only changing the client.
>If the source is encrypted line by line, diff will still work and decryption
>may find place at the client.

That may be a workable idea. If I understand it correctly, you want to
encrypt and text-encode each line of your text prior to committing it,
such that there is a 1:1 mapping between lines in the ciphertext and
plaintext, such that changing, adding or removing a line in the
plaintext only affects the corresponding line of ciphertext.

Independently crypting each line this way weakens the cryptosystem, but
it's probably still strong enough to foil the cheat.  Someone who needs
to cheat in a programming contest probably couldn't crack pig latin. ;)

reply via email to

[Prev in Thread] Current Thread [Next in Thread]