Howdy there,
In vernamcipher.c, when the tunnel runs out of key bytes it simply rewinds to the beginning and starts using them again.
Observe lines 218 and 219:
if (CurrentFP + count > FileSize)
fseek(fp, 0L, SEEK_SET);
Its important to keep in mind that the security of a OTP relies on the key being generated by a CSPRNG, to obscure patterns in the plaintext, and never reused.
This is because, just like (cipherText ⊕ key) -- ie, ((clearText ⊕ key) ⊕ key) -- cancels out the key and leaves you with plaintext, when you take two different ciphertexts encrypted with the same key and ⊕ them -- (cipherTextA ⊕ cipherTextB), or ((clearTextA ⊕ key) ⊕ (clearTextB ⊕ key)) -- the key cancels out, and you're left with (clearTextA ⊕ clearTextB).
With care, you can often untangle the cleartexts from each other and break the cipher.
Howdy there,
In vernamcipher.c, when the tunnel runs out of key bytes it simply rewinds to the beginning and starts using them again.
Observe lines 218 and 219:
Its important to keep in mind that the security of a OTP relies on the key being generated by a CSPRNG, to obscure patterns in the plaintext, and never reused.
This is because, just like (cipherText ⊕ key) -- ie, ((clearText ⊕ key) ⊕ key) -- cancels out the key and leaves you with plaintext, when you take two different ciphertexts encrypted with the same key and ⊕ them -- (cipherTextA ⊕ cipherTextB), or ((clearTextA ⊕ key) ⊕ (clearTextB ⊕ key)) -- the key cancels out, and you're left with (clearTextA ⊕ clearTextB).
With care, you can often untangle the cleartexts from each other and break the cipher.