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:
- Encrypt plaintext with a block cipher (something with strong avalanche effect and strong pseudo random output.)
- 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).
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?