2
$\begingroup$

i wondered what the security implications are if I do the following. If I had a large file encrypted with a OTP and want to change only a few bytes in the plaintext. what security vulnerabilities do I get if I only generate a new OTP for the changing bytes leave the old OTP as is and substitute the new OTP, and do this every time i make a change to the plaintext.

To be clear:

  • plaintext p;
  • OTP o;
  • cyphertext c

Start with…

p = 1111 1111 1111 1111  
o = 0001 0001 0001 0001  
c = 1110 1110 1110 1110

change plaintext…

p = 1111 1111 1111 __1010__

generate new OTP for the last 4 bit 0101 und substitute it in the "old" OTP…

o = 0001 0001 0001 __0101__  
c = 1110 1110 1110 1111

What are the problems ( if there are any ) resulting from this?

I know that if I want to use OTP, I have to generate a hole new pad. But if I have a huge file (multiple GBs), it is hard to generate a new pad of this size if I only want to change a few bytes.

I haven't found material about this topic so far and analyzing attacks against some cypher application is a hard task, but maybe someone has read an article about that OTP application and why you should not do this.

Improve this question
$\endgroup$
1
  • $\begingroup$ I'm wondering how you are going to keep track on what you changed, and which OTP bits you used for that particular change. $\endgroup$
    – Maarten Bodewes ♦
    Jun 3, 2014 at 22:37

2 Answers 2

Reset to default
2
$\begingroup$

If you only ever use a particular OTP block to encrypt one plaintext block, there is no way to decrypt it.

However, with your approach anyone looking at multiple versions of the file will be able to tell which parts have changed. For example, if the file contained secret messages stored by users, it would leak the length of each message added. Maybe that's a problem, maybe not. Depends on your application.

Improve this answer
$\endgroup$
2
  • 3
    $\begingroup$ That is a good point. Maybe a countermeasure could be to randomly recreate other parts of the OTP in varying length to related plaintext parts that have not been changed at all. But now you could average the changes :/ still don't know if its a problem to know the length of a change. $\endgroup$
    – dustin.b
    May 31, 2014 at 9:07
  • 2
    $\begingroup$ Extra points for thinking about the averaging trick yourself :) $\endgroup$
    – Maarten Bodewes ♦
    Jun 3, 2014 at 22:32
2
$\begingroup$

You're on a middle path here, and the main question is: What do you want to hide? What can the attacker see before/after the change?

The least secure one is: Just XOR the bit changes on the ciphertext and be done with it. The information theoretic property still holds: If the attacker has exactly $0.5$ chance of guessing a single bit, and it was changed with XOR 1, he still has a $0.5$ chance to guess correctly. But the attacker will be able to see the fact that you changed it with probability $1$.

Your way is the middle way: If the ciphertext bit doesn't change ($0.5$ chance), the attacker wont realize the bit was flipped.

Changing the entire OTP: Well, the attacker can't know any more which bits were flipped, but he knows that a change has occurred.

Change nothing in the ciphertext: Instead of changing a bit in the ciphertext, just keep it and flip the bit in the plaintext and the pad. The result is that the attacker can't know you changed something.

The real question tho: Why do you even use OTP? Besides the information theoretic security, it has pretty terrible properties. OTP serves as a theoretic tool, but it's pretty much useless for actual practice. A few reasons: It has no way to secure integrity, unless you use some heavy expansion. If the attacker can flip bits, he automatically flips plaintext bits. The scheme is only secure as long as the entire pad is securely saved and never used again. And it's as long as saving the plaintext itself. And then there's the randomness: Only true randomness provides information theoretic security, which is not that easy to achieve in the needed amount (multiple GB of true randomness.... not going to happen on any normal computer).

edit:

Especially since you're doing some kind of file storage: You have the pad o somewhere, and you have to keep it confidential. It is as long as the plaintext itself. And you need to have a way of accessing it when you want to access the file. Why not just save the plaintext in that secure storage?

Improve this answer
$\endgroup$
2
  • 1
    $\begingroup$ I disagree that the information-theoretic property still holds. For example, one could determine through the pattern of flipped bits, whether or not the contents are likely to be (for instance) ASCII data (say if every 8th bit never changes). $\endgroup$
    – Stephen Touset
    Jun 5, 2014 at 0:25
  • $\begingroup$ Well, that's what I said. The first one holds the property for every single bit, since we don't look at the larger scale at all.If you want to hide bit patterns, you either need to refresh everything or apply the changes to the pad( without changing the ciphertext). $\endgroup$
    – tylo
    Jun 5, 2014 at 8:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.