Context based Entropy : How to use keyed-steganography

I have spoken to a couple of people about this idea, those who know a little bit about steg often tell me this idea is pretty cool so I'll make it a little more public, see who catches it and starts doing interesting things before i do. Not saying I came up with this first, totally happy to pass the torch if I am to do so. But I do believe this idea could revolutionize security, cryptography and introduce a level of steganography to communication channels that is as hard to break as a secret key is to guess. I believe this possibly because my faculty for reasoning is flawed OR I'm missing something about my construction (I'm not a cryptographer--not a qualified one at least I'm just a dude who thinks about things a lot and just so happens to work in information security). 

So here I will lay out the idea, will all the notions expressed that I think make it work, and if they are true you should also agree with its advantages should it really work as i propose. 

The problem with steganography

As far as I've seen and very recently discussed with some people that know way more than I do about crypto/steg (steg = steganography) , we are still in the era where steganography isn't such a well developed and supported idea, due to its obvious drawbacks. That being if someone uncovers your scheme you are screwed.

Although cryptography has an analogous flaw, that being if someone discovered your key you are screwed. What led me to the idea I will discuss here was based on the disparity of this very analogy, perhaps the reason steg suffers from this draw back is because we assume it is not a problem in crypto! We need a "key" concept for steg, so why not use the one time pad idea as in crypto? Why not find a way for the scheme to be as hard to guess as a crypto key is to guess? Why not just make it a crypto key?  Well how do you do that? With context!

Context based Entropy

Don't think anyone is really studying this technique so I'll take the lead on making up a cool name ;) Context based entropy - meaning to employ the context as part of the entropy.  

Traditional Steganography works as follows you have essentially three things:

• A cover text to hide a message in.
• A scheme, we can think of this as merely a function on the 
• A message

As I understand it, the way you go about stegging a message is to do the following:

for position,bit in enumerate(message){ embed(bit,position,covertext)}

For each possible contiguous place in the message embed a bit of the message.  The simple question that arises is then, why do we use every single possible "position" why not sparse it out? Why not sparse it out according to a pattern that is secret and only you and your message readers are allowed to know? Why not embed it using a key?

Here's how that would work:

for position,bit in enumerate(message){ 

if key[position] is 1{

embed(bit,position,covertext)}}

So for context-based entropy drive steganography you would then need 4 things:

• A cover text to hide a message in.
• A scheme, we can think of this as merely a function on the 
• A message
• A embedding pattern, rhythm or key that tells you when a message bit is embedded in which part of the substrate or cover-text. 

Lets talk about what is happening here, the algorithm only ever embeds a message bit if the corresponding key bit in the same position (assuming the key is as long as the message) is equal to 1. This is to say that the key is actually a literal road map for indicating the bits that really hold bits to be unstegged.  Immediately this means if you do not have the key bits you will need to guess the key bits to find out which ones hold potential garbage and which ones do not.  And if need to guess they key then we have a system here defined as secure in the same way we define other cryptosystems as secure, forcing the would be attacker to guess the key before they can even begin doing anything really "dangerous".  

Why is it called Context Based Entropy?

So now we know this key can greatly help us in hiding the very existence of our messages, and you are inclined possibly to think that this key must also be bits, must also be constructed to represent the same things the message does "letters" or "sounds" or "images"; basically you think the key must be ascii chars as well as the message. 

Well that is true, we represent everything in a common format although they are not all drawn from the same properties of the nature. A message represents an intent to communicate and the content of the communication, a key represents a secret that you want to use to protect the message which could be anything from: your name, garbage, perfectly random samplings of CPU clock differences, favourite movie etc. People have all kinds of weirdly sourced data for building or collecting entropy but the commonality is that all of this wonderful entropy must come from somewhere, that somewhere according to my understanding is the context in which the message is sent. It must come from the context of the current message because if we can tell that the messages are all of a common context (as you do in cryptanalysis) we can then immediately start to guess the content of the message (your local cryptanalyst would probably talk your ear off with historical examples). 

Theory of the Application of Context Based Entropy

This rhetoric means a couple of things:

• Entropy we collect comes from context i.e. the properties of things  happening at the time 
• Keys that are generated then literally reflect the uniqueness of your context, if your context is not unique enough your keys will not be. 

Your attackers can then beat you by mimicking enough of just the context which your crypto is making decisions. We see this literally in papers about how little entropy common server/machines configurations and usage styles produce and how it has devastated the effectiveness of public key crypto.  What  it doesn't always really matter how well your crypto can make decisions if it cannot operate on good enough entropy. So why not employ the context itself as part of the key?

Timing as entropy

One of the potentially inexhaustible substrates for incorporating context as part of entropy is timing. You can possibly use timing to make your crypto harder to break by pretending that you have context-based key that is actually timing windows to send a message in. So now instead of always sending a message when it is possible, you choose a time to send it and you don't stop then; you choose a couple of slots lets say 10 minutes slots (depending on how secret and how patient you want to be). You then (as in the algorithm above, so it is here below) send a message bit in each timing window, but only if the key bit corresponding to the timing window is 1. i.e. you have selected 10 minutes as your window so then after a given starting time lets say 1300h you say that for every single 10 minutes into infinity after that point each group of 10 minutes could potentially hold a message bit. Only you and your key holding parties will know which groups of 10 minutes will actually hold info and which not.

Other possible context-based entropy sources could be:

• Packet hop counts
• Frequency of timming inside a timming window
• frequency of the changes in frequency inside of timing window
• any bijective function on the frequency of the changes in the frequency inside the timing window

And so you should start to see that within any context there are actually potentially infinite amounts of "windows" or "position" patterns you could choose to embed your message with. It is like choosing a favourite rhythm to dance to, the floor doesn't matter so much, just the music ;)  

Anyway I gotta run, hope some folks out there like this idea too!