Steganography

[globalcitizen]

Use of this application IMMEDIATELY renders people's communications 'interesting' to any surveillance apparatus.

This is a major drawback and should more prominently discussed for the security of the user base.

Steganography and/or alternative delivery paths (ie. not via SMS, but perhaps with a stego-SMS as a push notify to pull from a drop location) could help to resolve this problem.

[moxie0]

Hey @globalcitizen, if using the data channel were an option, then it wouldn't seem necessary to bother with stenography. But I'm also not sure how pulling data from a static location is any more subtle than what's happening now.

[globalcitizen]

It doesn't have to be a static location. The point is that you have a volume restriction on the SMS channel due to cost and normal traffic patterns (not wanting to be the only creature sending a veritable essay over SMS, which would also make you stick out). You also have a plaintext expectation that's impossible to hide many bits in. Therefore, it is pretty hard to make the communications anything less than PAINFULLY OBVIOUS to an observer: the current situation.

If you use an external (eg. IP based) channel out of band, whilst leveraging a simple stenanographically obfuscated message as a trigger for the remote party to poll for messages, you have all sorts of potential complexity as standard traffic on the channel that you can more easily hide within. You also have no cost related concerns in doing so.

PS. Steganography ("the art and science of writing hidden messages in such a way that no one, apart from the sender and intended recipient, suspects the existence of the message") != Stenography ("short hand") http://en.wikipedia.org/wiki/Steganography vs. http://en.wikipedia.org/wiki/Stenography

PPS. The former article refuses to load from Thailand. HTTPS works immediately. Other wikipedia articles load fine. Hah!

[moxie0]

What would you suggest?

[globalcitizen]

Years ago I began thinking that a wide range of systems could benefit from a suitable pluggable communications layer that would allow the seamless exchange of communications channels for higher layers. Qualities of security, privacy, latency, bandwidth, reliability and endpoint-reachability would provide objective metrics for automated decisions as to their employment. This would, for instance, allow you to wrap both the text and voice encryption projects in to a larger and more flexible entity.

This becomes similar to some private networking projects such as Tor, however there is no need from an architectural standpoint to surrender the control and efficiency provided by the aforementioned objective measurements and throw your lot in with TCP/IP as Tor has done.

I believe that Tor does however offer some degree of pluggable obfuscation these days, as they have had problems with their entire published entry-point database being blocked by certain governments (eg. the Chinese). While they now take an approach of issuing not publicly announced endpoint location information to individuals via an automated email process, I do believe they may have some code similar to this within the endpoints themselves.

A quick look over at their site suggests they call this 'pluggable transports', they implement via python, and they currently have a job opening for developers: https://www.torproject.org/about/jobs-pluggabletransport.html.en

Regardless of what direction you choose to take the projec - if any - with regards to communications secrecy (steganography) ... I believe at the very least you should loudly and repeatedly inform users that the use of either the phone or text applications is very likely attract attention to their communications from surveilling parties.

[globalcitizen]

PS. You could also implement your text and voice channels as pluggable transports for Tor.

[moxie0]

When applying Tor to censorship circumvention, it has two problems:

1) The nodes are listed in a public consensus.

2) The traffic itself is identifiable as Tor traffic.

The solution to the first problem requires not publishing "guard" nodes, while somehow disseminating them to users without disseminating them to the censors. This doesn't generally work very well, and so they need a constantly rotating supply of new guard nodes.

Meanwhile, even if they manage to make the endpoints unidentifiable, the traffic itself has distinctive characteristics, which is why they are beginning to use obfu (as you mention) in some circumstances.

The overall result is a high friction solution that works unreliably. If this were a case of simple detection (what you're trying to avoid) rather than censorship, the situation would be even worse, since it would not be possible to know when a guard node had been discovered, and thus there would never be certainty as to the invisibility of your traffic.

In my opinion, doing all of that would actually be worse than the situation as it is today. When using the SMS transport, simple filtering techniques (such as mapping against known hosts) can't be applied. Given that the protocol goes out of its way to avoid easy-to-compute tags, the only recourse is to try searching messages for what "looks like" ciphertext.

In any case, I don't think it's a reasonably solvable problem to the extent that I think you'd be satisfied with. If you have suggestions for how the UI could better indicate what you'd like, feel free to suggest changes with a pull request.

[globalcitizen]

I agree with your criticisms of Tor.

Problem 2 in your description also applies to this application and is the subject of this issue.

I still think that pluggable steganographic transports would benefit this application. For example, selecting 'English [youth]' as a steganographic transport module might trigger specific bits to be encoded within a message resembling those sent by young English speakers: ":) cool cya 2moro" etc. By carefully constructing traffic that reasonably imitates a wide range of more popular SMS content, traffic would become very hard to identify.

With regard to a warning, just a simple "WARNING: Please be aware that the use of this application might have the effect of attracting the attention of authorities." then force and OK at install time.

[moxie0]

If what you're doing is taking bits and encoding them using a format that resembles speech, how is that ultimately less detectable than base64? In both cases, you just "unencode" all messages and see if the result resembles ciphertext.

[globalcitizen]

The point is, a state surveillance system is less likely to detect that there is an intent to communicate in private if the attempt is made in such a way that component messages exhibit a completely 'normal' range of message content. Normal message content does not look like base64.

[moxie0]

Unless that's what they're looking for. If the encoding is a simple translation, any surveillance system could just as easily translate it back. Just like base64.

I don't personally think this is appropriately solvable, but in any case I'm unlikely to work on it myself. If you'd like to take it on, I'd be happy to review a pull request.