It appears that this problem is solved by creating an image with the encrypted text and adding that image to the tweet. The decryption uses a simple character recognition algorithm to read the message back from the image.
Then it relies on the fixed grid [0] and font to do a "poor man's OCR" [1] when decoding.
[0] http://git.io/vIWll [1] http://git.io/vIWln [2] https://twitter.com/Lukasaoz/status/607632001210925056
The interesting thing about the poor man's OCR is that it works way better than out of the box OCR tools. They're all built around handling arbitrary, often quite noisy input, so their handling of 1s and ls in this data is often not great.
Doing the cheap OCR works really well because we can overfit our data: we know the font, we know the grid, and we know the orientation, so our problem is way simpler than generic OCR.
(Not sure how twitter might alter the image though, which would corrupt the data).
As I said elsewhere, there are other options, like QR codes or high capacity colour barcodes, but those aren't funny.
Revolt and rejoice!
But... if this relies on fixed-ish protocol (fixed grid & font), can't The Man Upstairs censor it just as easily?
Remember, signing/encryption do not ensure that you can communicate, only that if you communicate you can do so with integrity, authenticity, and privacy. The same limitation applies here, with the added bonus of this particular method being totally stupid.
Is it just standard public/private key?
Instead of sending the encrypted text this script is rendering an image (just like the screenshot of an encrypted email) and posting that. The other party is just running OCR on that image (Just like a regular scanner software would do) to convert the text visible in the posted image back to text which will be decrypted and displayed to the user.
http://www.theverge.com/2014/3/19/5523656/twitter-gives-up-o...