Only Crypted things in CVS-Repository
Thomas Deselaers
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.
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.
Does anybody think a solution to this problem would be interesting to other
people than to us? If yes, I might try to develop something like this.
Greetings
Thomas
--
tho...@deselaers.de «<>» ICQ# on request «<>» GPG/PGP key on request
«< Unless stated otherwise everything I write is just my opinion >»
Harald Kucharek
> 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.
>
> 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.
Interesting idea, but I guess that the encryption could be easily cracked under your
assumptions, especially: identical lines of code look identical in their encrypted
version. I don't know very much about encryption, but I think that makes the whole
thing vulnerable. Usually, encryption avoids to encrypt the same data into the same
encrypted data. In the extreme (one character per line of code), the encryption would
degenerate into a simple substitution. The shorter the code lines, the easier the
statistical attack.
Just my two cents.
Harald
--
iXpoint Informationssysteme GmbH #
Daimlerstr. 3 # Harald Kucharek
76275 Ettlingen # Harald....@ixpoint.de
Tel/Fax +49 7243 3775-0/77 # www.ixpoint.de
Thomas Deselaers
> Thomas Deselaers wrote:
> > 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.
> >
> > 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.
>
> Interesting idea, but I guess that the encryption could be easily cracked under your
> assumptions, especially: identical lines of code look identical in their encrypted
> version. I don't know very much about encryption, but I think that makes the whole
> thing vulnerable. Usually, encryption avoids to encrypt the same data into the same
> encrypted data. In the extreme (one character per line of code), the encryption would
> degenerate into a simple substitution. The shorter the code lines, the easier the
> statistical attack.
Of course, this is true. And for our purposes there is no need for very
high security, though it would of course be preferred. But if you want
higher security, you have to modify the server's cvs and I think you have to
do the en- and decryption on the server, and thus it will not be very secure either.
This very high vulnerabilty was, why I do not know if this is useful for
anyone beside us.
Kaz Kylheku
>Hello,
>
>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. ;)
Jesus Manuel NAVARRO LOPEZ
Thomas Deselaers wrote:
>
> Hello,
>
> 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.
>
This is a no-no from the very beginning. CVS is mostly about managing
*text* files. They're text files because they're constrained to a short
set of bytes (those for ASCII chars) and because some regularities are
within (end-line markers separate meaningful textlines). You want to
encrypt those which in other words means you want to convert them in an
special case of high entropy binary files (in any other case your
"encryption" wouldn't deserve that name). Well, as anybody would
accept, and people as Greg A. Woods would even print on you on fire (
;^P ) if binary files are the rule, not the exception and you are not
interested *mainly* on the ability to concurrently work on files, then
CVS is not your tool.
> 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.
>
KISS.
This remembers me the issue about ACLs within CVS. It is either a
matter for CVS or it is not: the only part of it CVS is related to (not
trying to argue if it *is* useful or not) is about its semantic objects:
file *revisions*, branches and tags. Once you are asking for CVS to do
things on objects not within its direct interest, like files as a whole,
or directories, then you should go elsewhere (filesystem ACLs ie).
The same goes about encryption: Are you trying to hide this or that
revision/branch from this or that user of the repo? Then it *migth* be a
job for CVS. But this is not the case here. You want to hide
files/file contents on a file system on a box, and you want hide
files/file contents on transit over a network. For the later you have
pretty good solutions, like SSH tunnels or any kind of VPN, for the
former you *can* have partial solutions on encrypted filesystems, or
total solutions (just to say, they are probed to be hidden even for a
malicious power users/administrators for that system) over highly ranked
secured systems.
> Does anybody think a solution to this problem would be interesting to other
> people than to us? If yes, I might try to develop something like this.
>
Don't think so, because it is either not a matter of interest, since
there are already workable solutions, or they are not a matter of
interest because that kind of secrecy is not an issue.
Your case is kindof special one: you use a server controlled by a guy
you're not confident on. As I said it is possible although a nigthmare
to build a B or A class system where nobody is confiable by himself, so
either he cannot do things or at least cannot do without per-procedure
audit to go elsewhere. You have impacted your nose against a wall
pointed out by B security-class orange book specs: cross-boundaries
discrectional access. Though it is usually thougth as regarding spatial
boundaries (like you can't take these papers or any copy of them out
*this* very office) it has temporal aspects too: your system (not being
B classifiable) didn't took this kind of temporal crossboundary into
consideration and you payed the bill. "Sensible" material time-crossed
a security boundary: that from having a server system with a confiable
sysadmin to having your server under non-confiable hands, and data
disclosure is the effect of this security breach (what if instead of
your "friend" cheating you simply the box went out his control because
somebody else decided to give it a new sysadmin, for instance?).
To take the example on a more general environment, you could tell us
your approach migth probe usefull, for instance so you can keep your
project on freshmeat/sourceforge and still protect the code from
undesirable eyes, but if you really thing so, you are misunderstanding
the problem: you can build a secured (to a given standard) system if
time, knowledge, hands and money are properly provided, but you can't
and won't manage to have a rated secure system (albeit a low-rated one)
if the "platform" specs are not at least to that trust level *in
advance*. Even if you can manage to client-side encrypt data and still
have an usable system (remember most CVS work is server-side), still
your own box can be compromised (hey, my own box is suppoused not to be
compromisable. Well then, that's *your* environment, others will
vary). On the other hand as long as some "security" process is at
server side, it will be easily compromisable by server's sysadmin (on
your case, by reading the files within the repo, in other, reading it
from memory prior to its encryption, or trojanizing server apps, or...)
--
SALUD,
Jesús
***
jesus_...@promofinarsa.es
***
Paul Sander
rather the entire RCS file. The user would then be required to somehow
supply the key to whatever low-level software performs that function before
having any kind of meaningful access to the data.
It's not difficult to build this kind of capability into RCS; I've modified
RCS to keep its files compressed, which was about three days' effort
programming and testing after the compress program was munged into
something that looks like the stdio library. (That work remains available
for the old RCS 5.6 at http://www.wakawaka.com/source.html) Adding the
necessary changes to CVS, especially in server mode, is an additional
challenge.
>--- Forwarded mail from jesus_...@promofinarsa.es
>Thomas Deselaers wrote:
>--- End of forwarded message from jesus_...@promofinarsa.es