codeandsec
commented
9 years ago Actually attacker needs to know plain_text and guess all key used, which is really hard. In this case, attacker would be able to modify partial data. Real impact cannot be huge, for example attacker cannot inject an exploit or a malware into your secure channel.
1) Main purpose of this application is to achive maximum encryption. So vernamtunnel alone is not so good, user will be using vernamtunnel + SSH/SSL/RDP. 2) At best attacker will be able corrupting packets. As corrupting packets will corrupt SSH/SSL/RDP which does have checksum and integrity and decryption checks, it shouldn't be an issue. 3) It's a stream cipher, so application never knows size of packet or whatsoever. Implementing another hashing/encryption algorithm for each packet, to prevent data alteration, which wouldn't get attacker no where, seems a little bit overkill. Instead, as I said, user vernamtunnel + SSH/SSL which does have integrity checks.
VernamTunnel provides no integrity protection for data sent through the tunnel. This means that an attacker with knowledge of some of the plaintext can easily modify the ciphertext to be the plaintext he wants it to be instead: He just has to replace the ciphertext with
ciphertext ⊕ real_plaintext ⊕ fake_plaintext. You might want to use a MAC or so.