0
$\begingroup$

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?

Improve this question
$\endgroup$
5
  • 4
    $\begingroup$ "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? $\endgroup$
    – CodesInChaos
    Dec 16, 2015 at 19:15
  • 2
    $\begingroup$ "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 $\endgroup$
    – Richie Frame
    Dec 16, 2015 at 20:40
  • $\begingroup$ 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) $\endgroup$
    – Richie Frame
    Dec 17, 2015 at 1:53
  • $\begingroup$ 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 $\endgroup$
    – Richie Frame
    Dec 17, 2015 at 1:58
  • $\begingroup$ This scheme is not information-theoretically secure, thus losing the only advantage of OTP over conventional block/stream ciphers. $\endgroup$
    – Ilmari Karonen
    Dec 17, 2015 at 3:51

1 Answer 1

Reset to default
3
$\begingroup$

There's quite a few things wrong with this. For starters, a block cipher does not imply authentication. Common block cipher modes such as CTR, CBC, and (god forbid) ECB provide nothing but pure encryption. If you want authentication, look into the GCM block cipher. AES-GCM is possibly the better way to go here.

You state that it is built on the idea that every bit is important when deciphering the data, but this is simply not true. It is difficult (to my knowledge) to have a block cipher rely on every bit of the ciphertext for decryption to be successful. The best thing you can get is having a block cipher rely on every previous bit, meaning you can decrypt the first half of the data just fine while ignoring the second half.

If you have a working OTP, why are you bothering with a block cipher? Just digitally sign it or use a MAC and it will be authenticated. Other than that, an OTP provides perfect secrecy. (Don't be fooled, this is for a perfect OTP, which is virtually impossible to do correctly)

If you are dead set on your OTP & block cipher combo, then I suggest using AES in GCM mode as your block cipher, followed by a newly generated OTP (or a removed section of an existing OTP generated for use in encryption).

However, AES-GCM alone will do what you are looking for without the need of a OTP. And considering how difficult it is to pull off using a real OTP, it's probably more secure just sticking with AES.

Improve this answer
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.