Is XORing a random stream of bytes a secure way to obscure a file?

Question

Long ago I created a very simple program that used the C library's rand method to generate bytes to XOR with the bytes of a file. This was a reversible (just run it through again) method to make a file unreadable.

In my simple implementation, I did not change the seed, so it always created the same "random" stream, but if I had given a seed as a command line argument, would this be a reasonable way to obscure a file?

This question is not about the merits of any particular pseudo-random number generator, just assume a good one. The point is: does it provide a sound obscuration using a very simple algorithm?

Answer 1

XORing a plaintext with a random stream of the same size is a secure way to encrypt it. A stream cipher works in this way.

The issue in your design is the random source. If the random stream does not have the security properties one expects, the systems is not secure. In your implementation, the seed has the role of the key (and potentially the initialization value) of a regular stream cipher.

If someone can encrypt something with your method (or recover a couple plaintext/ciphertext) he will be able to decrypt every past/present/future encryption generated with the same key. Only for messages shorter than known one (but the remaining part could be guessed if the file is, e.g.:, an english text).

Answer 2

If these things are enough to obscure a file very much depends on who you are obscuring it for. As indicated in the previous question, there are still quite a few people that have ample knowledge on bits and bytes. If you are targeting not-so-tech-savy people then basically anything would suffice (as long as it doesn't show much in the default application or text editor you'd be safe).

The seed in this case can be seen as a key for an algorithm to create a key stream. Now you assume a "good" pseudo random number generator (PRNG). This is a cryptography form, so we would translate that into a Cryptographically Secure PRNG or CSPRNG. If the PRNG isn't a CSPRNG we can retrieve information about the state and reverse the process. If the seed is too small (less than, say, 64 bit or smaller) then we might be able to brute force it given enough CPU time.

Finally, if you ever repeat a key stream you are lost. Chances are that very high that files contain known plaintext (e.g. a JPEG header). In that case the key stream is leaked and any other information can be directly decrypted. Otherwise frequency analysis and crib dragging will quickly reveal the key stream with the same result. Any crypto student will have such a program available to them (it's often the first programming assignment).

Basically you are inventing your own stream cipher here. Using a well known one (AES-CTR with a random IV) is probably easier than all the trouble you are going through. Or simply use PGP for file encryption.

Answer 3

If your pseudorandom generator is good, then yes, this is secure (against passive attacks, for a single encryption). In fact, you can make that "if and only if": the questions of whether a pseudorandom generator is good and of whether this encryption method is secure (against passive attacks, for a single encryption) are fundamentally the same.

Answer 4

What you are describing is called a stream cipher, and is a common technique, but there are two important requisites that you are missing.

First, you need a cryptographically secure random byte generator.

Second, you must never reuse a keystream (the sequence of pseudorandom bytes) for more than one message. Real-world stream ciphers usually provide a second parameter, called a nonce, to facilitate this; the generator is seeded with both a secret key and a non-secret nonce.

There are several own-source implementations of stream ciphers, so you really shouldn't roll your own. The Sodium library is a popular one with a relatively simple interface.