Can the same One-Time-Pad be re-used with some tricks
Clash Royale CLAN TAG#URR8PPP
up vote
0
down vote
favorite
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
 |Â
show 1 more comment
up vote
0
down vote
favorite
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
I got inspired by this question: crypto.stackexchange.com/questions/2249/â¦
â zetaprime
2 days ago
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
2 days ago
@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
2 days ago
2
It obviously isn't OTP strong as with infinite compute power it can be broken while OTP can not.
â Meir Maor
2 days ago
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â¦
2 days ago
 |Â
show 1 more comment
up vote
0
down vote
favorite
up vote
0
down vote
favorite
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
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
hash cryptanalysis one-time-pad key-reuse
edited yesterday
raya
287
287
asked 2 days ago
zetaprime
10911
10911
I got inspired by this question: crypto.stackexchange.com/questions/2249/â¦
â zetaprime
2 days ago
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
2 days ago
@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
2 days ago
2
It obviously isn't OTP strong as with infinite compute power it can be broken while OTP can not.
â Meir Maor
2 days ago
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â¦
2 days ago
 |Â
show 1 more comment
I got inspired by this question: crypto.stackexchange.com/questions/2249/â¦
â zetaprime
2 days ago
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
2 days ago
@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
2 days ago
2
It obviously isn't OTP strong as with infinite compute power it can be broken while OTP can not.
â Meir Maor
2 days ago
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â¦
2 days ago
I got inspired by this question: crypto.stackexchange.com/questions/2249/â¦
â zetaprime
2 days ago
I got inspired by this question: crypto.stackexchange.com/questions/2249/â¦
â zetaprime
2 days ago
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
2 days ago
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
2 days ago
@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
2 days ago
@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
2 days ago
2
2
It obviously isn't OTP strong as with infinite compute power it can be broken while OTP can not.
â Meir Maor
2 days ago
It obviously isn't OTP strong as with infinite compute power it can be broken while OTP can not.
â Meir Maor
2 days ago
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â¦
2 days ago
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â¦
2 days ago
 |Â
show 1 more comment
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.
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
2 days ago
@Joshua can you please publish? By N time pad do you mean a limited number of uses?
â zetaprime
2 days ago
2
With a hash function we can construct a stream cipher.
â Meir Maor
2 days ago
add a comment |Â
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.
New contributor
add a comment |Â
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.
add a comment |Â
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 ...
Who or what makes the IV?
â Paul Uszak
2 days ago
@PaulUszak: You do. You could do 1, 2, 3, etc. for each message sent if you wanted.
â Joshua
2 days ago
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
yesterday
@Paul Uszak: On considering your comment I found it to be essentially true.
â Joshua
yesterday
add a comment |Â
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.
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
2 days ago
@Joshua can you please publish? By N time pad do you mean a limited number of uses?
â zetaprime
2 days ago
2
With a hash function we can construct a stream cipher.
â Meir Maor
2 days ago
add a comment |Â
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.
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
2 days ago
@Joshua can you please publish? By N time pad do you mean a limited number of uses?
â zetaprime
2 days ago
2
With a hash function we can construct a stream cipher.
â Meir Maor
2 days ago
add a comment |Â
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.
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.
edited 2 days ago
answered 2 days ago
Meir Maor
4,7001726
4,7001726
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
2 days ago
@Joshua can you please publish? By N time pad do you mean a limited number of uses?
â zetaprime
2 days ago
2
With a hash function we can construct a stream cipher.
â Meir Maor
2 days ago
add a comment |Â
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
2 days ago
@Joshua can you please publish? By N time pad do you mean a limited number of uses?
â zetaprime
2 days ago
2
With a hash function we can construct a stream cipher.
â Meir Maor
2 days ago
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
2 days ago
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
2 days ago
@Joshua can you please publish? By N time pad do you mean a limited number of uses?
â zetaprime
2 days ago
@Joshua can you please publish? By N time pad do you mean a limited number of uses?
â zetaprime
2 days ago
2
2
With a hash function we can construct a stream cipher.
â Meir Maor
2 days ago
With a hash function we can construct a stream cipher.
â Meir Maor
2 days ago
add a comment |Â
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.
New contributor
add a comment |Â
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.
New contributor
add a comment |Â
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.
New contributor
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.
New contributor
edited 2 days ago
New contributor
answered 2 days ago
Rob
2115
2115
New contributor
New contributor
add a comment |Â
add a comment |Â
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.
add a comment |Â
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.
add a comment |Â
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.
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.
answered 2 days ago
supercat
1834
1834
add a comment |Â
add a comment |Â
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 ...
Who or what makes the IV?
â Paul Uszak
2 days ago
@PaulUszak: You do. You could do 1, 2, 3, etc. for each message sent if you wanted.
â Joshua
2 days ago
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
yesterday
@Paul Uszak: On considering your comment I found it to be essentially true.
â Joshua
yesterday
add a comment |Â
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 ...
Who or what makes the IV?
â Paul Uszak
2 days ago
@PaulUszak: You do. You could do 1, 2, 3, etc. for each message sent if you wanted.
â Joshua
2 days ago
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
yesterday
@Paul Uszak: On considering your comment I found it to be essentially true.
â Joshua
yesterday
add a comment |Â
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 ...
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 ...
answered 2 days ago
Joshua
22218
22218
Who or what makes the IV?
â Paul Uszak
2 days ago
@PaulUszak: You do. You could do 1, 2, 3, etc. for each message sent if you wanted.
â Joshua
2 days ago
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
yesterday
@Paul Uszak: On considering your comment I found it to be essentially true.
â Joshua
yesterday
add a comment |Â
Who or what makes the IV?
â Paul Uszak
2 days ago
@PaulUszak: You do. You could do 1, 2, 3, etc. for each message sent if you wanted.
â Joshua
2 days ago
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
yesterday
@Paul Uszak: On considering your comment I found it to be essentially true.
â Joshua
yesterday
Who or what makes the IV?
â Paul Uszak
2 days ago
Who or what makes the IV?
â Paul Uszak
2 days ago
@PaulUszak: You do. You could do 1, 2, 3, etc. for each message sent if you wanted.
â Joshua
2 days ago
@PaulUszak: You do. You could do 1, 2, 3, etc. for each message sent if you wanted.
â Joshua
2 days ago
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
yesterday
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
yesterday
@Paul Uszak: On considering your comment I found it to be essentially true.
â Joshua
yesterday
@Paul Uszak: On considering your comment I found it to be essentially true.
â Joshua
yesterday
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
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
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
I got inspired by this question: crypto.stackexchange.com/questions/2249/â¦
â zetaprime
2 days ago
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
2 days ago
@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
2 days ago
2
It obviously isn't OTP strong as with infinite compute power it can be broken while OTP can not.
â Meir Maor
2 days ago
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â¦
2 days ago