[pbatndmo] Avoiding DC offset with encryption

Encode data in binary so that the number of zeros does not significantly differ from the number of ones.  A simple method is to encode 0 as 01 and 1 as 10, but this induces a 2x overhead.  Other similar codes include 8b/10b and 64b/66b; however, all of these also have a multiplicative overhead, though less than 2x.

Randomly choose a key for a stream cipher.  Transmit the key in the clear.  Encrypt the data using the stream cipher.  This yields a constant overhead (not multiplicative).

Assuming the sender cannot see the randomly chosen key before deciding the entirety of the data to send, then statistically, the encoded data is unlikely to have significant DC offset.  However, a statistical guarantee might not be good enough.  Also, runs of consecutive ones or zeros occur at the probabilistically expected rate: this may be too frequent compared to the designed codes mentioned above.

Still assuming the sender cannot see the randomly chosen key, how would an adversarial sender attack such a scheme, wanting to induce (say) more ones than zeros in the ciphertext?  On one hand, this seems seems extremely difficult, wanting to cause something bad to happen over "all", or a statistically large portion of, keys.  On the other hand, it seems an unusual class of attack, one that stream ciphers might not have been designed against.

Of course, all bets are off if the sender can observe the key being transmitted in the header, which is practically very easy (the key is transmitted in the clear), so this is not a good scheme in the presence of an adversary.