Score:2

What's bad about idea of public-key/one-time-pad hybrid cryptosystem?

cz flag

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?
kelalaka avatar
in flag
Stream cipher already stretches the keys...
nimrodel avatar
cz flag
@kelalaka so stretching otp key via stream cipher could be indeed implemented?
kelalaka avatar
in flag
Key Exchange with DHKE then use ChaCha20-Poly1305? https://crypto.stackexchange.com/a/67526/18298
DannyNiu avatar
vu flag
See our [reading list](https://crypto.meta.stackexchange.com/a/1535/36960)
fgrieu avatar
ng flag
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](https://en.wikipedia.org/wiki/Hybrid_cryptosystem) is standard practice.
nimrodel avatar
cz flag
@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?
us flag
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.
Score:2
ph flag

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.

nimrodel avatar
cz flag
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 -?
ph flag
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.
ph flag
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⁵⁸⁸⁸
ph flag
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".
us flag
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.
Score:1
in flag

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.

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.