Quicksearch

Disclaimer

The individual owning this blog works for Oracle in Germany. The opinions expressed here are his own, are not necessarily reviewed in advance by anyone but the individual author, and neither Oracle nor any other party necessarily agrees with them.

Sunday, February 22. 2009

A lazy afternoon after drinking coffee at my prefered coffee dealer. So i had some time for a proof of concept. Fsck ... i didnīt knew how rusty my Perl knowledge got over the time. I just tried to implement an encrypted twitter client. Itīs really a bad,bad,bad hack just to test the concept. The code isnīt cleaned up ... contains many artifacts of abandoned ideas and its highly probable to fall on its nose just by using it for something other as for the proof of concept.

The idea of sending the crypted message is pretty simple. The text is encypted with the public key of the receiver. The script uses the Gnu Privacy Guard for this task.

One important task is the distribition of the public key. Iīve started to implement the code for using the Biography field in the Account settings of Twitter or identi.ca for storing the fingerprint and the URL of the public key for the distribution part. I didnīt implemented the part suck the public key and importing it to pgp so far but that would be straightfoward. My idea is to encode both informations in a way, that a encryption enabled twitter client would be able to gather the key whereever the user stores it and validate it by the fingerprint if itīs really the one the twitter user wants to use for encryption. In the Biography of one of users in my test you will find the following text:

The actual code assumes that the public key of the the receiver is already in the keyring of the sender system. Actually the receiver and the transmitter were on the same system in my proof of concept. Iīve generated two key pairs for my test:

The realname is the Twitter name respectively the identi.ca name of the user.

Well, after encryption the script strips off all non-cyphertext. The GnuPG delivers the cyphertext in a handy linelength, so we donīt have to seperate them ourself. I used the remaining chars per twitter message for some metainformation to ease the reassembly of the cyphertext.

At first a MD5 hash is calculated over the cyphertext. This is the message id of the encrypted message. After this step the cybertext is seperated in lines. Every line is prepended by the cTweet magic to sign it as a crypted tweet. After this, the message id, the line number, and the number of total lines of the cyphertext ist appended. Finally a line of the cyphertext is appended to the message. This message is send out to twitter.

The message is hardcoded in this example. Iīve choosen a rather long text to show, that you can send direct messages longer than 140 characters. As we need message reassembly in all cases (even a short text is up to 4-5 messages long because of itīs encryption). Iīve inserted some linebreaks in the message for better readability. In my script itīs one long line. The sender and receiver are hardcoded as well. In my example c0t0d0s0alice wants to send c0t0d0s0bob a secret message. Both use the Twitter API compatible service identi.ca.Okay, letīs starting with the sender. This is ./sendencryptedtwitter.pl:

The decryption is simple, too. The receiveencryptedwitter.pl script collects the direct messages containing the encrypted tweet. With the help of the line numbers and the msg-id the cyphertext will be reassembled, the number of total lines as stated in the direct messages is compared with the received number of lines for a message id to ensure all lines were received. As the msg id is the md5 has of the cyphertext, it would be a two- to threeliner to check the integrity of the reassembled cyphertext by calculating its m5 digest and compare it with the message id.

After the successful reassembly of the cyphertext, the script gathers the id of the secret key of the receiver, decrypts it and displays the encrypted message.

Deniable
I just thought about an interesting for the mechanism explained in "Proof of concept hack for encrypted direct messages on Twitter - you could deny that you are the intended receiver of the message. Just post the encrypted stuff as a public tweet. The rec

I believe it is possible to construct a straightforward method of communicating securely and relatively anonymously over the existing micro-blogging services, and have published an outline of how to do this.