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
Received on 2011-08-01 17:32:03 CEST