> Hi Everybody,
> thanks for all the quick repsonses. I myself wasn't able to answer
> now since we wanted to discuss things in our group.
> We plan to integrate this so that a compromised server does not
> the attacker to read data, even if he has got access to the
> repositories, no matter how he got it. The "Professor" who gave
> task to us, is willing to accept the loss in performance for the
> enhanced security.
Is this just an academic exercise? I think putting the repository on a truecrypt drive would solve the above requirement.
> Tom Widmer, Peter Samuelson, Markus Schaber:
> We are allowed a loss in performance, and more explicitly the
> delta-functionality. But as Peter Samuelson pointed out delta
> transmission might still work on a block-basis with block-ciphers
> this is what we hope for. Unfortunately this would require us to
> sure that plain-text blocks' borders aren't moved, when data is
> or removed.
> We know that, since we do not want attackers to analyze the data by
> assuming that the first x byte are some kind of constant header
> html , etc) - thus having plain-text-cypher pairs - we do need to
> those parts. But this could be aranged by simply adding some random
> number to the plaintext (224 bit plaintext 32 random or something
> that) which is only changed when the plaintext-block is changed.
> way we wouldn't have full feedback encryption, which reduces
> because it is easier to find pairs, but we would still allow the
> handler to at least work on "blocks".
> Philip Martin
> You might like to look atsvn:eol-style=native on Windows
> We are going to check that out. Regarding the checksums: We aren't
> storing the checksums for the encrypted data yet, since we only
> trying to understand the SVN library. But we'll keep that in mind
> the future. We assumed that transmitting those checksums would be
> necessary for the server to accept the file.
> Markus Schaber
> Concerning the RA solution: Our task is to integrate the client-
> encryption into Tortoise. But we figured that a general solution,
> worked on all clients would be the best way to handle this. Having
> an RA
> solution for every RA solution currently in existence didn't seem
> Thanks for the replies.
> Next we are going to follow Philip Martin's idea and have a look at
> those line-ending-conversions. But other ideas how and where to
> manipulate data, directly after it is received when updating are
> and gladly received.
> Best regards
> Jan Peters
Received on 2011-08-01 16:29:20 CEST