Why in one time pad must the key distribution to be truly random One time pad required a truly random key.
Why canwt it be a psudo-random key?
For example, if the key distribution is that for each bit the probability to get 1 is 0.6 and the probability to get 0 is 0.4, and the eavesdropper knows it, how can he decrypt the message (assuming that the key length is at least as big as the message length)?
Thank you
For an OTP to provide perfect secrecy it is required that the key stream is indeed purely random. A pure OTP is largely a theoretical construct because it is almost impossible to generate a key stream that is provably random. Any kind of information on the key stream may leak information on the plaintext, which means it is not perfectly secure. Practical OTP's that provide close to perfect secrecy on the other hand are, on the other hand, relatively common, see the comment from Paul below my answer.

Note that leaking information does not necessarily mean decryption; for instance if I encrypt the same message twice with a block cipher you won't know the input, but you can tell that the same message was encrypted because the resulting ciphertext blocks are identical. Any kind of information about the plaintext is enough for perfect secrecy to be broken.



Of course it is perfectly possible to use a pseudo random stream while maintaining practical security. Basically, this is what a stream cipher or block cipher in stream mode (e.g. CTR mode) does. However pseudo random streams indicate that there is some kind of mathematical relationship between the bits of the key stream. And this could be exploited by an attacker. The fact that such a relationship exists in itself is enough to break perfect secrecy.

There are obviously secure stream ciphers right now. We can however not prove them secure. So we cannot guarantee that they won't be broken in the future. Hence the perfect security premise doesn't hold, so they do not represent OTPs. Fortunately, if they are secure enough they don't need to.



It is possible to use a PRNG to create a practically secure key stream. PRNG and stream ciphers are closely related. Stream ciphers however have been especially designed to provide this functionality; they have advantages with regards to the API (treating the input key as key, having an explicit IV) and efficiency.

Beware that some random functions in programming applications may have implementations of PRNG's that are definitely not suitable for this kind of functionality. The shenanigans around "SHA1PRNG" in Java / Android should provide enough of a warning to anyone.



Way TL;DR: use a secure stream cipher