Not really, the idea would be to hide data by using different amounts of spaces in text files, in the least significant bits of pixels in images, or in the access pattern to a certain service. The data looks like legitimate traffic. You could run the tool on absolutely all traffic, but that would be computationally intensive. And the data you get out is still encrypted, so ideally you can't tell if it is random (from extracting data where none is hidden) or real encrypted data.
Also, you would have dozens or hundreds of kernels, and you could generate them by analyzing innocent traffic, or hiring a bunch of students to write them quickly. My idea is that the kernels are not part of the source code per se, but rather distributed by the protocol. To contact somebody you need to speak a common kernel, but then they can send you new kernels automatically. You could come up with a measure of how well kernels survive censorship and use that to decide which to pass on.
It's a bit like auto updating malware, but for good :-). My only novel idea is to make a DSL or bytecode for the kernels, so that you can prove that they are benign and correct, and autogenerate them or use kernels from strangers. I don't know at all if this is feasible or not, but I have a couple of ideas how to make it work. No where near a POC yet so this is all still wishful thinking though.
"the idea would be to hide data by using different amounts of spaces in text files, in the least significant bits of pixels in images, or in the access pattern to a certain service" is not appropriate for the claimed use case, i.e. activists in totalitarian regimes.
In such an environment, the traffic of suspected activists will be analyzed.
Assuming the kernels are open, it's possible to see in analysis of certain data that "amounts of spaces in text files, in the least significant bits of pixels in images, or in the access pattern to a certain service" have encoded information, even if the extracted information looks like random/encrypted data. At this point you don't have plausible deniability and rubber hose cryptoanalysis can be used.
Switching to new kernels happens too late since you don't know when they've identified a kernel until they start arresting people - it's not like they're simply going to block it immediately.
i.e., the described service is resistant to mass censorship and automated filtering, but these use cases actually need to be able to resist attribution and retaliation, which are quite different problems.
Also, you would have dozens or hundreds of kernels, and you could generate them by analyzing innocent traffic, or hiring a bunch of students to write them quickly. My idea is that the kernels are not part of the source code per se, but rather distributed by the protocol. To contact somebody you need to speak a common kernel, but then they can send you new kernels automatically. You could come up with a measure of how well kernels survive censorship and use that to decide which to pass on.
It's a bit like auto updating malware, but for good :-). My only novel idea is to make a DSL or bytecode for the kernels, so that you can prove that they are benign and correct, and autogenerate them or use kernels from strangers. I don't know at all if this is feasible or not, but I have a couple of ideas how to make it work. No where near a POC yet so this is all still wishful thinking though.