So you can't do a direct 1-to-1 mapping of pixels to bytes, because Twitter re-compresses the image. You cannot rely on the binary representation of the image to make that work.
However, there are plenty of other, less funny, options, like QR codes or High Capacity Colour Barcodes.
The resulting message should be much larger than just 140 characters, mostly because it's not only encrypted but also signed with GPG.
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.
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.
Why not use the pixel values themselves to encode the data? Each pixel's RGB can encode three characters (one for each byte value). The resulting image would be much smaller.
(Not sure how twitter might alter the image though, which would corrupt the data).
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.
Yes, just like regular encrypted email would work.
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.
19 comments
[ 3.0 ms ] story [ 54.5 ms ] threadhttps://twitter.com/shazow/status/605748307688890368
However, there are plenty of other, less funny, options, like QR codes or High Capacity Colour Barcodes.
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.
http://www.theverge.com/2014/3/19/5523656/twitter-gives-up-o...
(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.