# Combining a block cipher with a (pseudo) OTP

One of the drawbacks of OTP is that it can require an inconveniently long key. Besides that, it doesn’t provide data authentication. Therefore, I have been working on an algorithm idea, which I hope to be more powerful and efficient than OTP:

1. Encrypt plaintext with a block cipher (something with strong avalanche effect and strong pseudo random output.)
2. Encrypt a random part of the ciphertext with a random pad which has a random length.

I hope my idea to have the following advantages over OTP:

• it requires a short key consisting of three parts: one for the block-cipher, one that tells which part of the OTP to use, and the OTP itself. It's extremely small when compared to the key length of an actual OTP, but I think it is worth the burden.
• It provides data authentication (due to the usage of a block-cipher).

So, the idea is built on the fact that each and every ciphertext bit is required to decrypt, or even break, a block cipher encryption. With some unknown part locked away with OTP, it will be impossible to obtain each tiny bit of the block-cipher-text, without the key.

Besides that, I think additional security may come from the fact that the part that was encrypted with OTP can not be recognised, because the block cipher output is (better: has to be) pseudo random. Bruteforce seems to be out of reach, as there are more possible chances than OTP (that's because the attacker doesn't know where the OTP was used).

TL;DR

All in all, you could say I have this idea of combining a block cipher with a (pseudo) OTP, trying to gain security and data authentication from that combination. Is there anything that seems obviously wrong with that? Some crucial aspect I may be missing? Are there any specific security issues?

• "The algorithm is built on the fact that each and every ciphertext bit is required to decrypt, or even break, a block cipher encryption." Why do you believe that? – CodesInChaos Dec 16 '15 at 19:15
• "every ciphertext bit is required to decrypt, or even break, a block cipher encryption" - False. "provides data authentication (block-cipher)" - False. If the "random part" of the ctext was the last block, all previous blocks can still be recovered in your scheme, even if it was as secure as claimed – Richie Frame Dec 16 '15 at 20:40
• based on your TLDR I do have some ideas. Use block sized OTP in XEX scheme; C = E_k(P xor OTP1) xor OTP2, and A = HMAC_k(C) xor OTP3, where OTP1,2,3 are sequential sequences from your larger shared pad, and the keys are also from the pad, this would need about 1024-bits from the pad per message, and use a CBC mode of operation with no IV (OTP2 outside of mode) – Richie Frame Dec 17 '15 at 1:53
• or if you have lots of CPU power, $C = AES128{-}ECB_{OTP2}(P \ xor \ AES128{-}CTR_{OTP1}(ctr)) \ xor \ AES128{-}CTR_{OTP3}(ctr)$ with each 128-bit OTP sequence used as a one time key – Richie Frame Dec 17 '15 at 1:58
• This scheme is not information-theoretically secure, thus losing the only advantage of OTP over conventional block/stream ciphers. – Ilmari Karonen Dec 17 '15 at 3:51