0

Let’s say I have a message $m$ of $n$ bits. And a predetermined pad of $k*n$ bits. And for every bit $b$ of this message $m$, I’m creating random sequence $s$ of $k$ bits.

I also have a predetermined boolean random function $f$ (imagine something like this: $f(s) = hash(s)\ mod\ 2$).

For each bit $b_i$, I choose a random value for $s_i$, so that $f(s_i)=b_i$.

So, I can construct a padded version of $m$ like this: $m_p= s_0 || s_1 || ... || s_n$, removing the padding is trivial.

The encryption is also straightforward XOR of the $m_p$ value with the predetermined pad of the same length ($k * n$)

Can this protocol justify/enable reusing of the same pad over and over again providing OTP-Like security?

Equivalent text-based formulation of the scheme:
One comes up with a fresh, random hash pre-image for each message bit that when hashed yields the message bit as the LSB. You then transmit the pre-images and encrypt them with the re-used OTP.

R1w
  • 1,952
  • 4
  • 20
  • 45
zetaprime
  • 591
  • 6
  • 18
  • I got inspired by this question: https://crypto.stackexchange.com/questions/2249/how-does-one-attack-a-two-time-pad-i-e-one-time-pad-with-key-reuse – zetaprime Sep 10 '18 at 13:22
  • You are trying to build a cipher which not only mulitplies the messagr by k it also uses a hash function 2 times per bit for encryption and once for decryption? – Meir Maor Sep 10 '18 at 16:25
  • @Meir Maor that can be optimized, if one can build a cheap/optimum $f$ instead of a hash, I guess your concern on computational cost will be addressed. Essentially what I’m trying to achieve is some cipher which is OTP-Strong and allows the OTP to be re-used... – zetaprime Sep 10 '18 at 16:35
  • 2
    It obviously isn't OTP strong as with infinite compute power it can be broken while OTP can not. – Meir Maor Sep 10 '18 at 16:54
  • @Meir Maor, I would love to read your analysis on how it can be broken. – zetaprime Sep 10 '18 at 17:00
  • 2
    Brute-Force Break of the scheme: Observe all $2^k$ different messages as known-plaintext-ciphertext pairs for all $n$ segments and then do a table-lookup for any "new" ciphertext. I'm somewhat sure this qualifies as a break (but not 100% -> no answer, also it's not very smart for an attack...) – SEJPM Sep 10 '18 at 17:25

4 Answers4

9

Based on comments it seems the question asks if this is as secure as OTP as opposed to finding a practical attack.

It is clearly not as secure as OTP. It is not information thetorical secure. With sufficient messages totalling more than key size we can brute force the key, just iterate over possible keys until you find one which works with all messages.

With a OTP when the total message size never exceeds the key size, no compute power will allow you to brute force the key, all messages are equally likely and knowing part of the message doesn't help as the key is never reused.

Edit: Even an attack with $O(2^{kn})$ is sufficient to make it not information theoretical secure. but we can do at least somewhat better.

With $O(k)$ message pairs we can break the key with O(n*2^k) work. work one segment at a time. Iterate over all $2^k$ possible key segments, and check the messages, each message will exclude a bad key with probability 0.5 so we only need a few message pairs to rule out all false keys.

I reserve judgment regarding security of this with large k, and secure hash.

Meir Maor
  • 11,835
  • 1
  • 23
  • 54
6

A OTP is by definition just that, one time. Reuse allows analysis.

Taking the OTP and applying a fixed algorithm to it, even using different encryption each time to refresh it, simply gives two codes to crack; the encryption key for the OTP, and the algorithm applied to the message using the OTP. Repeatedly reusing the same key, same OTP, or resending the same message with different keys, slightly exposes the underlying algorithms and keys each time.

Taking the OTP and applying two (thought to be) perfect encryption algorithms to it is almost the same as creating a completely new random number, but at the same time it's almost as far away from using a OTP as you could get; so it's no longer a OTP, and you might as well use a true random number (which would be an improvement).

There's no such thing as "new, but slightly used" - that's just used, or slightly used, it's not new.

Rob
  • 290
  • 1
  • 6
  • 12
1

The advantage of OTP is not so much that it can be made secure, but rather that if the pad is generated in truly-random fashion, and no digit of the pad is exposed nor used more than once, those two conditions are sufficient to prove security, without having to prove anything else, and regardless of the quality of the function that combines the plaintext and the pad. From a practical perspective, it may be possible to reuse part of an OTP key without totally undermining security if the combining method is good enough, but any reuse of a key will undermine the OTP's advantage whether or not it renders it insecure.

supercat
  • 349
  • 1
  • 5
1

The correct way to construct an N time pad from a one time pad is as follows:

1) Select N, block size, and a cryptographic hash function with output size = block size

2) Set IV size >= (log2(N))

3) Exchange OTP and parameters; note that this must be done over a secure channel

To encrypt:

1) Pad message to a multiple of block size (the wire protocol may let you omit this step, or it may not ...)

2) For each block of message

2a) Hash IV || block number || block from pad

2b) Xor hash block with message block

to decrypt:

1) For each block of message

1a) Hash IV || block number || block from pad

1b) Xor hash block with message block

2) Remove padding

You have a problem with your scheme: your block size is 1 bit. Since the security is the strength (not length -- a hash that's had its strength reduced by an attack provides less security) of the hash in bits ...

Joshua
  • 441
  • 4
  • 14