基于填充密钥的XOR加密安全性探讨：RNG填充短密钥的可行性

Great question—let’s break this down clearly to see if this approach meets the high-security bar for XOR encryption.

First, let’s recap the two non-negotiable conditions for XOR encryption to deliver maximum security (on par with a One-Time Pad, OTP):

• The key must be at least as long as the data being encrypted
• The key must be cryptographically indistinguishable from true randomness (no predictable patterns, never reused)

Your proposed scheme uses a short key as a seed for a random number generator (RNG) to expand it into a key matching the data’s length. The security of this approach hinges entirely on the type of RNG you use, and how you manage the seed:

1. If using a non-cryptographic PRNG (e.g., linear congruential generators, standard "random" library functions) #

This does NOT meet the security requirements.

Non-cryptographic PRNGs are built for speed and basic statistical randomness, not to resist adversarial attacks. Their output is fully predictable if an attacker learns the seed (or even a small segment of the key stream). Even though the generated key matches the data length, it has a deterministic pattern that can be reverse-engineered—violating the "no obvious pattern" rule for secure XOR encryption.

2. If using a Cryptographically Secure PRNG (CSPRNG) #

This CAN meet the security requirements—if you follow critical guardrails:

CSPRNGs (like AES-CTR used as a stream cipher, HKDF, or OS-provided generators such as /dev/urandom on Linux) are designed to produce output that’s computationally indistinguishable from true randomness, even if an attacker sees large portions of it. For your scheme to be secure:

• The short seed must have sufficient entropy: It needs to be a true random value (not a human-chosen password) with at least 128 bits of entropy—enough to resist brute-force attacks.
• Never reuse the seed: Just like OTP, reusing the same seed to generate key streams for multiple datasets is catastrophic. If an attacker gets two ciphertexts encrypted with the same key stream, they can XOR the ciphertexts to get the XOR of the plaintexts, which often leaks sensitive information (and can lead to full plaintext recovery).

When these rules are followed, your scheme is effectively a stream cipher—an accepted, secure form of encryption that relies on XOR under the hood. While it’s not a strict OTP (since the key stream is pseudo-random, not true random), it delivers equivalent practical security for most modern use cases.

Key Takeaways #

• Skip non-cryptographic PRNGs for this use case—they’re not secure enough.
• Use a CSPRNG with a high-entropy, single-use seed, and you’ll satisfy the core security requirements for XOR-based encryption.

内容的提问来源于stack exchange，提问作者Chikage