2

As i know, generally nowadays hybrid protocols are more widely used than either symmetric or public key cryptosystems separately. I read that public key system is used to exchange and share secret via insecure channel so that the key is then used in symmetric cipher.

Also, there is otp, which is unbreakable as its information-theoretic security system. This is such a strong notion of security. However, we are all aware that it has its own drawbacks.

Recently an idea popped up randomly in my head - could we use one time pad instead of, say, AES, once the key is shared via public key? I'm sure that it is unpractical. However, only issue i see rn is requirement of same length key. But could we stretch it?

If we consider that somehow key stretching could be done properly, would there still be any other reason to not use otp and stick with standart symmetric algorithm?

  1. is length requirement only issue in this kinda system?
  2. couldnt we compromise speed a bit (during stretchin) for in return getting such a strong notion of security, making computation irrelevant?
  3. couldnt we not even take away AES part but rather put otp in between as another layer? (note that since there'd be stronger notion it could in return reduce low bound of AES key size)
  4. could otp be considered as security by obscurity - hence very nice reason to not use it?
nimrodel
  • 69
  • 5

2 Answers2

2

A one time pad's information-theoretic security comes from several facts about the key.

  1. The key is as large as the messsage
  2. The key is truly random
  3. The attacker has no information about the key.

Once you break any of those assumptions you no longer have the information theoretic security.

So if you break your one time pad into chunks and encrypt them with RSA, then your overall cryptosystem is still only as secure as RSA.

Similarly if you encrypt a small key and "stretch" it somehow, then your overall cryptosystem is only as secure as RSA and whatever system you use to stretch the key.

Peter Green
  • 1,613
  • 1
  • 11
  • 17
1

Stream ciphers create a key stream that is combined (normally XOR-ed) with the plaintext - just like the key stream for an OTP. AES-CTR (and the derived modes such as AES-GCM) can generate the computationally secure key stream you are looking for.

  1. is length requirement only issue in this kinda system?

For a perfectly y secure OTP, it is maybe the only issue (if you don't include integrity / authenticity, message size & frequency etc. etc.). However, it is also a problem that is theoretically impossible to solve, as it would take as many bits if you want to increase the key size - in other words it is impossible to increase the key size on both sides without destroying the security of the OTP.

  1. couldnt we compromise speed a bit (during stretchin) for in return getting such a strong notion of security, making computation irrelevant?

Computation is irrelevant for AES-128 (or AES-256 if you require quantum safe cryptography), assuming that it isn't used for a specific attack different from brute force.

  1. couldnt we not even take away AES part but rather put otp in between as another layer? (note that since there'd be stronger notion it could in return reduce low bound of AES key size)

No, I suppose, although you have never shown where / how AES is used in your question.

  1. could otp be considered as security by obscurity - hence very nice reason to not use it?

No the theoretical notion of an OTP is exactly the opposite. It requires a lot of key material to obtain perfect security instead of (almost) no key material to simply hide the message instead.

Note that simply applying any of these modes doesn't mean that your protocol is necessarily secure; as an example an attack such as EFAIL relies on altered plaintext to exfiltrate any message from email clients; in general you want to use an authenticated mode of encryption.

Maarten Bodewes
  • 96,351
  • 14
  • 169
  • 323