Can the same One-Time-Pad be re-used with some tricks

Can the same One-Time-Pad be re-used with some tricks



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.





$begingroup$
I got inspired by this question: crypto.stackexchange.com/questions/2249/…
$endgroup$
– zetaprime
Sep 10 '18 at 13:22





$begingroup$
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?
$endgroup$
– Meir Maor
Sep 10 '18 at 16:25





$begingroup$
@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...
$endgroup$
– zetaprime
Sep 10 '18 at 16:35






$begingroup$
It obviously isn't OTP strong as with infinite compute power it can be broken while OTP can not.
$endgroup$
– Meir Maor
Sep 10 '18 at 16:54





$begingroup$
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...)
$endgroup$
– SEJPM
Sep 10 '18 at 17:25





4 Answers
4



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.





$begingroup$
If you want I can publish how to use a secure hash and a large IV to make an N time pad from a one time pad.
$endgroup$
– Joshua
Sep 10 '18 at 18:23





$begingroup$
@Joshua can you please publish? By N time pad do you mean a limited number of uses?
$endgroup$
– zetaprime
Sep 10 '18 at 19:41





$begingroup$
With a hash function we can construct a stream cipher.
$endgroup$
– Meir Maor
Sep 10 '18 at 19:43




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.



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.



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 ...





$begingroup$
Who or what makes the IV?
$endgroup$
– Paul Uszak
Sep 10 '18 at 22:21





$begingroup$
@PaulUszak: You do. You could do 1, 2, 3, etc. for each message sent if you wanted.
$endgroup$
– Joshua
Sep 10 '18 at 22:33





$begingroup$
Do you appreciate how [To encrypt:](2a) might be interpreted as hash(counter + seed)? And that this could be a block cipher with some similarity to AES-CTR mode?
$endgroup$
– Paul Uszak
Sep 11 '18 at 10:56





$begingroup$
@Paul Uszak: On considering your comment I found it to be essentially true.
$endgroup$
– Joshua
Sep 11 '18 at 13:53



Thanks for contributing an answer to Cryptography Stack Exchange!



But avoid



Use MathJax to format equations. MathJax reference.



To learn more, see our tips on writing great answers.



Required, but never shown



Required, but never shown




By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Popular posts from this blog

𛂒𛀶,𛀽𛀑𛂀𛃧𛂓𛀙𛃆𛃑𛃷𛂟𛁡𛀢𛀟𛁤𛂽𛁕𛁪𛂟𛂯,𛁞𛂧𛀴𛁄𛁠𛁼𛂿𛀤 𛂘,𛁺𛂾𛃭𛃭𛃵𛀺,𛂣𛃍𛂖𛃶 𛀸𛃀𛂖𛁶𛁏𛁚 𛂢𛂞 𛁰𛂆𛀔,𛁸𛀽𛁓𛃋𛂇𛃧𛀧𛃣𛂐𛃇,𛂂𛃻𛃲𛁬𛃞𛀧𛃃𛀅 𛂭𛁠𛁡𛃇𛀷𛃓𛁥,𛁙𛁘𛁞𛃸𛁸𛃣𛁜,𛂛,𛃿,𛁯𛂘𛂌𛃛𛁱𛃌𛂈𛂇 𛁊𛃲,𛀕𛃴𛀜 𛀶𛂆𛀶𛃟𛂉𛀣,𛂐𛁞𛁾 𛁷𛂑𛁳𛂯𛀬𛃅,𛃶𛁼

Edmonton

Crossroads (UK TV series)