# Transferring Encrypted One-time pad over the internet

I was working with one-time pad, and as I understand , for one time pad to be 100% secure a key shouldn't be repeated. So assuming Alice and Bob have to exchange messages over the network secured over OTP, they both have to have the same key, which should happen by physically meeting and sharing the key on a drive for a example.

However I thought, if Alice and Bob had another type of encryption, symmetric encryption like AES, and they wanted security over OTP without meeting, couldn't just Bob generate OTP, encrypt it with AES, and send it to Alice over the network, and then it would be equally secure since the encrypted OTP was gibberish and still is gibberish before being encrypted and after being encrypted, therefore it is not susceptible to brute-force or cryptanalysis or other.

Am I correct ?

• I did not get the question clearly. What is meant by Alice and Bob have another encryption like AES without meeting? AES cannot be used without exchanging the symmetric key. So the key has to be first transmitted. To do OTP Alice needs to transfer the key pad to Bob over a secure channel. How is that possible without meeting? Alice is free to generate a key stream by operating AES in counter mode with a secret key which may serve as key pad but then will require secure way to transfer the pad to Bob anyway. In such an OTP the security is no more perfect since the key pad is no more random. In – Viren Sule Feb 9 '19 at 12:43

You would expect the OTP key stream to be secure when encrypted by AES. The reason for that is that it is impossible to determine for an attacker if breaking AES has succeeded or not. The plaintext to the AES cipher should be fully random, so even if the attacker would test the correct AES key, there is no way for the attacker to test that the result is indeed the OTP key stream.

However, this property is immediately cancelled when anything is encrypted with the OTP key stream. In that case if the correct OTP stream is found the result can be tested against the ciphertext generated by the OTP stream. If the AES key is found then the plaintext will be revealed to the attacker. Basically the security of the OTP will be identical to AES security, which definitely is not perfectly secure.

Besides this theoretical point, you should also take in account:

• integrity and authenticity of the messages and the encrypted key stream;
• overhead that needs to be kept confidential;
• repetition of plaintext block input to the AES cipher (which would leak information about the underlying key stream).

And that's the problem with OTP. Even if you can generate a fully random stream, distribution over networks is next to impossible without breaking the perfect security properties of the OTP.

• Added this answer because the impossibility of testing that the AES key is correct or not is not present in the current, accepted answer. – Maarten Bodewes Oct 19 '17 at 8:50
• Totally understood, the result is that it would "weaken" the security of OTP to the level of AES or any other encryption used. – Seaskyways Oct 19 '17 at 8:57
• Note that the repetition of plaintext blocks in AES is already enough to break the perfect security properties of the OTP, however it's not a practical problem so I mentioned it last. Glad you found it useful :) – Maarten Bodewes Oct 19 '17 at 8:59

No, encrypting the key with another cipher (AES) reduces the security of OTP to the security provided by this cipher (AES) or by the security measurement used to protect the encrypted key.

First of all, another requirement for OTP to be 100% secure is, that the key is chosen from random.

Example:

1. Assume Alice and Bob share a secret AES-Key $K_{shared}$. Alice generates a new, random key $K_{OPT}$ and encrypts it using AES: $C = Enc_{K_{shared}}(K_{OPT})$.
2. Alice sends the encrypted key $C$ over to Bob (lets ignore the problem of authentication etc. for the moment).
3. Eve intercepts the message. In order to retrieve $K_{OPT}$, Eve has to decrypt the message $C$. This takes only as much effort as it takes to break the cipher based on the key $K_{shared}$.

The encrypted $K_{shared}$ is supposed to look like gibberish, but only to the extend, that a cipher(AES) is able to achieve.

If you are actually looking into exchanging a OPT key without meeting take a look into Quantum Key Exchange: https://en.wikipedia.org/wiki/Quantum_key_distribution But thats more like the art of black magic than cryptography ;)

A less pedantic answer: if you trust AES to send the OTP why don't you trust it to send the message itself?

As Marcel noted, the security of the OTP would be no stronger than AES. If AES is compromised then so is your OTP and then so is your message encrypted with the OTP.

• If AES was susceptible to cryptanalysis or any other cracking algorithm that would NOT result in the original data , rather than multiple choices, then i would still benefit because all choices would be equal considering they are gibberish, however if one of the choices was plaintext, it would be obvious to be the right result – Seaskyways Oct 19 '17 at 19:34

You suggestion implies the computer used to transfer the key material itself is not compromised, or for that matter the receiver's computer is not compromised. That is an unsafe assumption.

Even if you used Public Key Encryption such a s GPG to transfer the key material using the recipient's public key, if either party has a keylogger running on their machine, it's game-over. OTP is securest when operated in an analog way.

Transferring OTP encrypted text over the 'net is probably fine- as long as the modality to do it doesn't permit the inference of relationships between the parties in the secure channel. But transmitting the key material itself over the Internet? Would be a very bad idea.

• Please refrain from using a signature on your posts. Posting -Terrence is unnecessary; If this is the name you wish for others to see, then you can set your username to that. – Ella Rose Feb 9 '19 at 22:40