Mfcttrf

We use more complex encryption algorithms than the one outlined in the question

• In order to get a short secret key in symmetric encryption. With the technique (One Time Pad) outlined in the question, we need to securely store or/and perhaps transfert a secret keystream the size of the data to encipher, which is utterly impractical. AES-CTR replaces that with a small (16 to 32-byte) shared secret good enough for any practical data size.


• In order to also get assurance of data integrity and origin, which typically turns out to be at least as needed as data confidentiality. Even if we assume a large secret keystream, we need something slightly more complex than XOR with the keystream (e.g. universal hashing) in order to ensure that an adversary did not mess-up with the data (e.g. change "pay $100" to "pay $900").


• In order to get asymmetric encryption, that is the capability to encipher without needing anything secret (beyond the data to encipher) on the side that enciphers.

You could use a one-time pad, which does grant confidentiality when properly employed, but then you would have many non-trivial problems:

1. Your message or messages would have to be quite short because generating letters in a truly random manner usually takes a bit of time and effort (rolling dice).




2. One-time pads only have limited practical use. You cannot use your OTP for the purposes of making payments with your ATM card, using WeChat, establishing a secure link to this website, etc.




3. You might need to make sure that the person you are talking to is who you think they are, and vice versa (authentication). It isn't easy to authenticate a one-time pad without using a modern method such as a Carter-Wegman MAC or an HMAC, etc.




4. How is the receiver going to check the integrity of your message? How will they know that someone else did not add something, move something around, or take something away? How will they know that a technical glitch had not altered the message during transmission?




5. How are you going to securely share your one-time pad?




6. Physical security. How are you going to keep that one-time pad safe twenty-four hours a day? How about the person you are going to talk to? How will they keep their OTP safe?




7. How are you going to explain to someone who was watching that you enjoy communicating like a Cold War spy?

Modern cryptography can solve all of these problems well--key exchange, authentication, integrity checks, confidentiality, encrypted storage, establishing a shared secret--and that is why we use it.

The other answers are great, but I wanted to call out an interesting feature of modern cryptography. Your question asked:

I thought, why even use AES or DES or any other complex way for encrypting data when there are far simpler ways, like just generating a random (pseudorandom) bitstream, and XOR'ing it with the data or secret message?

In point of fact, many modern encryption schemes do exactly that. Both ChaCha20 and AES in any counter mode (CTR and GCM both come to mind) actually generate a pseudorandom bitstream (usually called a keystream) and XOR it with the input data to encipher it.

As you can see, and as Paul's answer correctly points out, this observation hasn't actually made anything particularly simpler. We've just changed the problem: the problem isn't "how to encipher data", it's now "how to generate good pseudorandom bits". It turns out that doing that well from a relatively small amount of key material is fundamentally difficult.

...random enough..

Let's just focus on that as it forms the nub of your question. Yes,$$textrandom (pseudorandom) bitstream oplus textsecret message$$ is very simple, works and is in common usage. But the first term in this encryption function masks great (and necessary) complexity. In order to be secure, the bitstream must comprise independent and uniformly distributed numbers, typically with bias not exceeding $2^-64$. How do you obtain them? Therein lies your complexity.

You can make them with a physical device. If we exclude zany methods like dice and aquarium fish, we're left with some type of electromagnetic apparatus. These days, that will take the form of either a laser or diode. Both create the original entropy for distillation into random numbers based on quantum indeterminacy. Quantum mechanics are pretty complex.

Or you can expand a little entropy like say a password, into a long stream of pseudo random numbers with a CSPRNG (and perhaps a key derivation function). The need for non invertability/non predictability of the output and to guarantee acceptable bias, requires complexity. And so cryptographic primitives are complex. If it wasn't complex, you could just roll it backwards.

Therefore, what you've really asked is:- $$textcomplex to make random (pseudorandom) bitstream oplus textsecret message$$

You've simply moved the complexity upstream of the XOR operator.

What you're describing would be a One-Time-Pad. The OTP would actually be perfectly secure, but the first problem is in the issue that you have to generate a bit stream using a cryptographically secure pseudorandom number generator (CSPRNG) instead of a usual pseudorandom number generator. But even that doesn't pose a particularly large problem. Keep also in mind that a OTP is only secure if you use it once, using a OTP with the same bit stream would be insecure.

So let's assume generating a random bit stream isn't a problem:

The big problem lies in the process of sharing the key with others. That's the real issue, because a public cryptosystem like RSA-2048 can for example only encrypt a message of size 245 bytes, as described in this answer on securitySE.

You could therefore also only generate a random bit stream for the OTP of equal size. And each time you would have to transmit a new bit stream for a new OTP, all the time until you're finished. That's a very slow process. At that point you could even ask: "Why am I even using a OTP anymore, I could just send the actual message using RSA instead the key!".

So generally we transmit a key for a symmetric cryptosystem like AES using something like RSA. AES has (practically) no limit of data to encrypt for it to still be secure.