Not exactly as inoccuous as hiding information in the minor bits of an image, and you would need exponentially more data.
First, a rough O() statement: log2n! is approximately n log n. Now I am going to pull a lot of numbers out of my ass....
If you use a hiding document -- say a photograph -- of size H bits, you could probably hide H/24 bits in it, let's call that a 1/24 ratio. If you have a list of n things, each (on average) of size K, you could hide n log n bits in it, for a ratio of log n / K. For this to be innocuous, K is probably a list of titles, and I'd guess that an average human title is about 20 characters or 160 bits. As n increases, the ratio improves. The ratios are the same for log n = 160 / 24, which makes n = 26.66 -- about 100.
In other words, you could hide about 640 bits in a "Top-100" list that was a total of 20KB (that's kilobytes) long; or in an image that was about 20KB.
Given that n items always take log 2 n bits to represent, the process is pretty close to optimal.
Well, you can't just send a binary encoded version of the sequence -- that's just a substitution cipher! If you want it to be innocuous (steganography implies that an eavesdropper does not know that a message is being sent) -- you have to send the actual list itself.
Please check my argument (and my arithmetic!) in my first section above. The argument would be much refined if log 100! was calculated exactly instead of using a O() simplification. I think it makes sense that using list order to hide information is a reasonable way of doing things.
Faster, faster, until the thrill of...
[ Parent ]