Key Bytes are Reused

[ghost]

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.

[codeandsec]

Hey, Yes. It rewinds to beginning just to make sure there is something to use. Usually user will start the code with a beginning offset, then application will rewind to beginning. Also even if that's not the case, it will rewind to beginning to continue. User is responsible for generating secure random enough data and HUGE key file for their usage. If they want to send/receive 1000 kb, they need at least 1000 kb of key. That's why I have a 256GB USB disk, so I can change my key around once a week only.

Also I highly recommend this VernamTunnel along with a secondary encrypted protocol, not standalone. So I would recommend users to use vernamtunnel + SSH/SSL/RDP.

[ghost]

I understand what you're saying, and I'm sure you use your tool correctly, but I think the fact that it is willing to copy more data than it can securely transport is a dangerous failure mode.

Consider an adversary who can monitor network activity, and has realized you're about to download an Apache log file; while the download is in progress, they flood the server with requests with the same request repeatedly to force you into reusing key bytes. A similar adversary who has hacked into the same system (and if you're there, its pretty certain there is a way in) but who hasn't yet escalated priviliges could do the same with any globally writable file you download.

But I'm also perplexed by your threat model (if our adversaries can break SSH/SSL/RDP or our proxy can't be trusted, surely they can monitor the key file in transit?), so perhaps I'm just not familiar enough with the use case.

I'd propose you keep track of where you started in the file, and fail before repeating key bytes. I'd be happy to make the changes and submit a pull request.

[codeandsec]

We are not going to use SSL/SSH/RDP for key transmission at all. You put the key in local storage, then run the server. Next, in secondary location you run the same code with same key you carried yourself. So key will never be transmitted.

I think we should put an option like --break-otp, so when OTP file ends, break the connection, instead of rewinding.

Feel free to submit pull requests, I'll try to add the --break-otp option. Also it seems users needs a secure random file generator, I'll be doing that too.

Thanks