基于Lua的轻量加密：HTTP短视频二进制数据等长加解密需求
Hey there! Let's break down the best options for your needs—you want encryption/decryption that never changes the original data size (no extra bytes tacked on the end) and is fast enough for short video streams. Your earlier issue with permutation algorithms likely came from using modes that require padding, so we'll focus on methods that avoid that entirely:
1. XOR-Based Methods (With or Without Key)
XOR is the simplest size-preserving operation—every byte of your video data is XORed with a value (or stream of values), and reversing it just requires XORing again with the same value/stream.
- Without key: Use a fixed byte value (e.g.,
0xAA) to XOR every byte. This is blazingly fast but offers almost no security—only basic obfuscation. Good if you just need to prevent accidental parsing, not true encryption. - With key: Generate a key stream matching the length of your video data (using the key as a seed) and XOR each byte with the corresponding stream byte. For example, use a pseudorandom number generator (PRNG) seeded with your key to produce the stream. This stays fast and adds basic security, though not as strong as dedicated ciphers.
2. Stream Ciphers (High Security, Size-Preserving)
Stream ciphers are built to generate a pseudorandom key stream that's XORed with your plaintext—this means ciphertext length exactly matches plaintext, no padding needed. They’re optimized for speed, making them perfect for video data:
- ChaCha20: A modern, fast stream cipher recommended for use cases like TLS and mobile apps. It operates in constant time, handles arbitrary-length data seamlessly, and requires no padding. You’ll need a 256-bit key and a 96-bit nonce (just ensure the nonce is unique for each encryption with the same key—you can embed it in video metadata or share it out of band without adding extra bytes to the core video data).
- RC4: An older stream cipher that’s extremely fast, but has known security vulnerabilities (weak key streams in some scenarios). Only use this if raw speed is your top priority and you can’t implement ChaCha20.
3. AES in CTR Mode (Block Cipher as Stream Cipher)
AES is a block cipher, but when used in CTR (Counter) mode, it acts like a stream cipher—no padding required, and ciphertext length matches plaintext exactly. Here’s how it works:
- A counter value is encrypted with AES to generate a key stream block.
- This block is XORed with your video data block, and the counter increments for the next block.
- AES-CTR is incredibly fast (especially with hardware acceleration on modern CPUs/GPUs) and provides strong security. Like ChaCha20, you’ll need a unique nonce to initialize the counter—again, pass it via metadata or out of band to avoid adding extra bytes to the video itself.
Why Your Earlier Permutation Algorithm Failed
Most permutation-based approaches that add extra bytes rely on block cipher modes like CBC or ECB, which require padding to force data into fixed-size blocks (e.g., 128 bits for AES). By switching to stream-based modes or true stream ciphers, you eliminate the need for padding entirely.
Quick Implementation Tip
For all these methods, the core operation is byte-wise XOR between your video data and a key stream. As long as you generate the exact same key stream during encryption and decryption (using the same key and nonce/counter), you’ll get back the original data with zero size changes.
内容的提问来源于stack exchange，提问作者Dzmitry
