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
  • 71
  • 5
  • 2
    Stream cipher already stretches the keys... – kelalaka Dec 14 '21 at 19:35
  • @kelalaka so stretching otp key via stream cipher could be indeed implemented? – nimrodel Dec 14 '21 at 19:42
  • Key Exchange with DHKE then use ChaCha20-Poly1305? https://crypto.stackexchange.com/a/67526/18298 – kelalaka Dec 14 '21 at 19:43
  • 1
    Once you stretch an OTP's key, the cryptosystem is no longer an OTP: it becomes a stream cipher. Use of stream ciphers in hybrid encryption is standard practice. – fgrieu Dec 15 '21 at 07:17
  • @fgrieu yes, now i searched stream ciphers up and read similiar thing. wiki says that stream ciphers resemble ptp much. however, it adds that it doesnt have as strong notion of security because it's not random anymore but pseudo-random. this confuses me. it means mere switch from random key to pseudorandom key takes away information-theoritic property from stream ciphers? does that mean that if u used pseudorandom key in otp, it would also become same as stream cipher, and also non-information-theoritic anymore? – nimrodel Dec 15 '21 at 13:28
  • The much easier path is to use a random seed to generate the OTP using a random bit generator. But using OTPs doesn't provide the security people think it does. it ONLY provides confidentiality. That is just one part of data security. You also need integrity and authentication (and should have audit as well.) OTP fails at all the others. – adrenalion Feb 09 '22 at 18:45

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,594
  • 1
  • 10
  • 15
  • i get what you mean. however i'm confused. what you mean is if you create otp key (by not creating it randomly in full form but rather) stretching some already-existing shorter key, than otp key posseses information that it's keystretchalgorithm(k) which could be reversed back to k (key shared via public key in this case). this implies we can exploit the fact that stretched key cant be anything cause stretch algorithm has only fixed number of entropy. however is it really exploitable? isnt key stretch algorithm entropy too huge anyway, hence still providing - lots of plausible plaintexts -? – nimrodel Dec 16 '21 at 08:52
  • It's dangerous to assume that the range of plausible plaintexts is more than a tiny fraction of the range of implausible plaintexts. For example english text apparently has an entropy of less than 2 bits per character, but the storage format typically has 8 bits per character. So if you have a kilobyte of english text you have less than 2²⁰⁴⁸ plausable plaintexts, but nearly 2⁸¹⁹² implausible ones. – Peter Green Dec 16 '21 at 18:58
  • So, with a kilobyte of english text, if you were able to enumerate all the values of say a 256 bit key, then the chances of finding a plausible plaintext other than the one that was actually encrypted would be less than one in 2⁵⁸⁸⁸ – Peter Green Dec 16 '21 at 19:06
  • 1
    That's not to say that the scheme isn't secure in practice, just to say that it is not "information theoretically" secure and so is not considered a "one time pad". – Peter Green Dec 16 '21 at 19:08
  • The allure of OTPs is the ensured confidentiality, despite the many implementation issues. For example: With OTP, if an attacker were to change a few bits of the cyphertext, they might change a Yes to a No, or an order quantity from 1 to 1000, and with a OTP, and the recipient will never know. Block ciphers like AES can offer some protection against tampering (if you randomly change a couple of bits of ciphertext, AES decryption will most likely return garbage after that point.) But this is not guaranteed. However there are come block ciphers that can provide integrity. OTPs just sound nice. – adrenalion Feb 09 '22 at 18:41
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
  • 92,551
  • 13
  • 161
  • 313