> Hi Everybody,
> thanks for all the quick repsonses. I myself wasn't able to answer
> until
> now since we wanted to discuss things in our group.
> 
> We plan to integrate this so that a compromised server does not
> allow
> the attacker to read data, even if he has got access to the
> repositories, no matter how he got it. The "Professor" who gave
> this
> 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.


BOb

> 
> 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
> and
> this is what we hope for. Unfortunately this would require us to
> make
> sure that plain-text blocks' borders aren't moved, when data is
> inserted
> 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
> (pdf,
> html , etc) - thus having plain-text-cypher pairs - we do need to
> mask
> those parts. But this could be aranged by simply adding some random
> number to the plaintext (224 bit plaintext 32 random or something
> like
> that) which is only changed when the plaintext-block is changed.
> This
> way we wouldn't have full feedback encryption, which reduces
> security,
> because it is easier to find pairs, but we would still allow the
> delta
> 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
> started
> trying to understand the SVN library. But we'll keep that in mind
> for
> 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-
> side
> encryption into Tortoise. But we figured that a general solution,
> which
> 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
> feasible.
> 
> 
> 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
> welcome
> and gladly received.
> 
> Best regards
> Jan Peters

Reply via email to