On 01/08/2011 11:09, Jan Peters wrote:
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.
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".
I guess you could have an extra clever block cipher. Each 64 byte block
could have, say, a minimum of 4 bytes of random data, and a maximum of
62 bytes. Each block could have the following bytes:
1 number of bytes of random data, R (>= 4)
2:R-1 random data (at least 4 bytes)
R:64 the real data
Then you could just add in (or remove) extra random data around
insertions/deletions in the plaintext as necessary to round them up to
multiples of 64 bytes, and thus avoid the cost of re-encrypting
surrounding blocks. Probably tricky to implement though!
Kind regards,
Tom
