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

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP











up vote
0
down vote

favorite
1












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.










share|improve this question























  • I got inspired by this question: crypto.stackexchange.com/questions/2249/…
    – zetaprime
    Sep 10 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 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 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 at 16:54






  • 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 at 17:25















up vote
0
down vote

favorite
1












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.










share|improve this question























  • I got inspired by this question: crypto.stackexchange.com/questions/2249/…
    – zetaprime
    Sep 10 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 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 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 at 16:54






  • 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 at 17:25













up vote
0
down vote

favorite
1









up vote
0
down vote

favorite
1






1





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.










share|improve this question















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.







hash cryptanalysis one-time-pad key-reuse






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Sep 11 at 12:24









raya

287




287










asked Sep 10 at 13:11









zetaprime

19112




19112











  • I got inspired by this question: crypto.stackexchange.com/questions/2249/…
    – zetaprime
    Sep 10 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 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 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 at 16:54






  • 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 at 17:25

















  • I got inspired by this question: crypto.stackexchange.com/questions/2249/…
    – zetaprime
    Sep 10 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 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 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 at 16:54






  • 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 at 17:25
















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




I got inspired by this question: crypto.stackexchange.com/questions/2249/…
– zetaprime
Sep 10 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 at 16:25




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 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 at 16:35





@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 at 16:35





2




2




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




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




2




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 at 17:25





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 at 17:25











4 Answers
4






active

oldest

votes

















up vote
10
down vote



accepted










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.






share|improve this answer






















  • 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.
    – Joshua
    Sep 10 at 18:23










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






  • 2




    With a hash function we can construct a stream cipher.
    – Meir Maor
    Sep 10 at 19:43


















up vote
6
down vote













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.






share|improve this answer





























    up vote
    1
    down vote













    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.






    share|improve this answer



























      up vote
      1
      down vote













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






      share|improve this answer




















      • Who or what makes the IV?
        – Paul Uszak
        Sep 10 at 22:21










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










      • 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?
        – Paul Uszak
        Sep 11 at 10:56










      • @Paul Uszak: On considering your comment I found it to be essentially true.
        – Joshua
        Sep 11 at 13:53










      Your Answer




      StackExchange.ifUsing("editor", function ()
      return StackExchange.using("mathjaxEditing", function ()
      StackExchange.MarkdownEditor.creationCallbacks.add(function (editor, postfix)
      StackExchange.mathjaxEditing.prepareWmdForMathJax(editor, postfix, [["$", "$"], ["\\(","\\)"]]);
      );
      );
      , "mathjax-editing");

      StackExchange.ready(function()
      var channelOptions =
      tags: "".split(" "),
      id: "281"
      ;
      initTagRenderer("".split(" "), "".split(" "), channelOptions);

      StackExchange.using("externalEditor", function()
      // Have to fire editor after snippets, if snippets enabled
      if (StackExchange.settings.snippets.snippetsEnabled)
      StackExchange.using("snippets", function()
      createEditor();
      );

      else
      createEditor();

      );

      function createEditor()
      StackExchange.prepareEditor(
      heartbeatType: 'answer',
      convertImagesToLinks: false,
      noModals: false,
      showLowRepImageUploadWarning: true,
      reputationToPostImages: null,
      bindNavPrevention: true,
      postfix: "",
      noCode: true, onDemand: true,
      discardSelector: ".discard-answer"
      ,immediatelyShowMarkdownHelp:true
      );



      );













       

      draft saved


      draft discarded


















      StackExchange.ready(
      function ()
      StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fcrypto.stackexchange.com%2fquestions%2f62231%2fcan-the-same-one-time-pad-be-re-used-with-some-tricks%23new-answer', 'question_page');

      );

      Post as a guest






























      4 Answers
      4






      active

      oldest

      votes








      4 Answers
      4






      active

      oldest

      votes









      active

      oldest

      votes






      active

      oldest

      votes








      up vote
      10
      down vote



      accepted










      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.






      share|improve this answer






















      • 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.
        – Joshua
        Sep 10 at 18:23










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






      • 2




        With a hash function we can construct a stream cipher.
        – Meir Maor
        Sep 10 at 19:43















      up vote
      10
      down vote



      accepted










      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.






      share|improve this answer






















      • 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.
        – Joshua
        Sep 10 at 18:23










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






      • 2




        With a hash function we can construct a stream cipher.
        – Meir Maor
        Sep 10 at 19:43













      up vote
      10
      down vote



      accepted







      up vote
      10
      down vote



      accepted






      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.






      share|improve this answer














      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.







      share|improve this answer














      share|improve this answer



      share|improve this answer








      edited Sep 10 at 18:00

























      answered Sep 10 at 17:35









      Meir Maor

      4,8601827




      4,8601827











      • 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.
        – Joshua
        Sep 10 at 18:23










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






      • 2




        With a hash function we can construct a stream cipher.
        – Meir Maor
        Sep 10 at 19:43

















      • 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.
        – Joshua
        Sep 10 at 18:23










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






      • 2




        With a hash function we can construct a stream cipher.
        – Meir Maor
        Sep 10 at 19:43
















      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.
      – Joshua
      Sep 10 at 18:23




      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.
      – Joshua
      Sep 10 at 18:23












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




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




      2




      2




      With a hash function we can construct a stream cipher.
      – Meir Maor
      Sep 10 at 19:43





      With a hash function we can construct a stream cipher.
      – Meir Maor
      Sep 10 at 19:43











      up vote
      6
      down vote













      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.






      share|improve this answer


























        up vote
        6
        down vote













        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.






        share|improve this answer
























          up vote
          6
          down vote










          up vote
          6
          down vote









          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.






          share|improve this answer














          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.







          share|improve this answer














          share|improve this answer



          share|improve this answer








          edited Sep 10 at 18:04

























          answered Sep 10 at 17:58









          Rob

          2207




          2207




















              up vote
              1
              down vote













              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.






              share|improve this answer
























                up vote
                1
                down vote













                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.






                share|improve this answer






















                  up vote
                  1
                  down vote










                  up vote
                  1
                  down vote









                  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.






                  share|improve this answer












                  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.







                  share|improve this answer












                  share|improve this answer



                  share|improve this answer










                  answered Sep 10 at 20:26









                  supercat

                  1934




                  1934




















                      up vote
                      1
                      down vote













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






                      share|improve this answer




















                      • Who or what makes the IV?
                        – Paul Uszak
                        Sep 10 at 22:21










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










                      • 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?
                        – Paul Uszak
                        Sep 11 at 10:56










                      • @Paul Uszak: On considering your comment I found it to be essentially true.
                        – Joshua
                        Sep 11 at 13:53














                      up vote
                      1
                      down vote













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






                      share|improve this answer




















                      • Who or what makes the IV?
                        – Paul Uszak
                        Sep 10 at 22:21










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










                      • 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?
                        – Paul Uszak
                        Sep 11 at 10:56










                      • @Paul Uszak: On considering your comment I found it to be essentially true.
                        – Joshua
                        Sep 11 at 13:53












                      up vote
                      1
                      down vote










                      up vote
                      1
                      down vote









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






                      share|improve this answer












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







                      share|improve this answer












                      share|improve this answer



                      share|improve this answer










                      answered Sep 10 at 20:43









                      Joshua

                      22218




                      22218











                      • Who or what makes the IV?
                        – Paul Uszak
                        Sep 10 at 22:21










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










                      • 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?
                        – Paul Uszak
                        Sep 11 at 10:56










                      • @Paul Uszak: On considering your comment I found it to be essentially true.
                        – Joshua
                        Sep 11 at 13:53
















                      • Who or what makes the IV?
                        – Paul Uszak
                        Sep 10 at 22:21










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










                      • 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?
                        – Paul Uszak
                        Sep 11 at 10:56










                      • @Paul Uszak: On considering your comment I found it to be essentially true.
                        – Joshua
                        Sep 11 at 13:53















                      Who or what makes the IV?
                      – Paul Uszak
                      Sep 10 at 22:21




                      Who or what makes the IV?
                      – Paul Uszak
                      Sep 10 at 22:21












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




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












                      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?
                      – Paul Uszak
                      Sep 11 at 10:56




                      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?
                      – Paul Uszak
                      Sep 11 at 10:56












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




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

















                       

                      draft saved


                      draft discarded















































                       


                      draft saved


                      draft discarded














                      StackExchange.ready(
                      function ()
                      StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fcrypto.stackexchange.com%2fquestions%2f62231%2fcan-the-same-one-time-pad-be-re-used-with-some-tricks%23new-answer', 'question_page');

                      );

                      Post as a guest













































































                      Popular posts from this blog

                      How to check contact read email or not when send email to Individual?

                      Displaying single band from multi-band raster using QGIS

                      How many registers does an x86_64 CPU actually have?