Existing platforms
Social networks Bulletin
boards Email
Chatrooms Instant
Messaging Newsgroups
Figure 3.3: Popular Internet communication platforms
interfaces - user interfaces that will already be familiar to existing users.
Newsgroups on usenets is an old forum-like platform. It can be thought of as a forerunner to todays bulletin boards on HTTP. Users may discuss topics in designated groups. In contrast to bulletin boards, usenet is a distributed system - making it hard to take down or manipulate. In theory, anyone may set up a new server and subscribe to other servers news feeds. The decentralized structure is certainly positive. We could choose to hide our communication in existing or new groups. Some groups are even reserved for binary content, where we could upload images or videos with embedded messages.
But despite a steady increase in traffic, usenets are a niche for the tech savvy.
It is doubtful that the average internet user even knows of its existence. Using usenets require special software, special in the same way as browser for HTTP.
But today, operating systems ship with browsers build in, and it is fair to assume that people know how to operate them. We will look elsewhere, for a popular service we may extend on.
There are many bulletin boards and fora available online, some more popu-lar than others. Users may create threads or posts for others to comment on.
They are effectively newsgroups through HTTP. Many offer extended markup, which is great for steganography. Some allow users to post images, and some even require images with optional text. As mentioned, images are great for steganography because of their high redundancy. We could easily imagine a steganographic solution based on posting pictures online, where only the inau-gurated would know where and how to extract their messages. However such a solution would quickly be noticed by the operators, if it became popular. We would like to propose a solution that is structured, robust and decentralized.
Storing messages secretly in bulletin boards will not provide that.
Instant messaging has become increasingly popular. Applications like ICQ, Win-dows Messenger and Jabber have all been very popular. Today we have Viber, WhatsApp and more, but the trend seems like a merge between social networks and instant messaging. Twitter offers "Direct Messages" and Facebook has Messenger. While their user bases are huge, and extensions are becoming possible
-3.2 Transmission 39
they own their platforms and control them completely. These companies profit on their ability to listen in on their users chats. It is unlikely they approve of our intentions, that go straight against theirs. It is also inhibiting that com-municating parties must be online simultaneously. We require something more robust.
We will instead extend traditional emails. They are the digital version of tra-ditional mail. They have become so common, that an explanation is not even necessary. Anyone may send an email, anyone can setup an email server. Emails have a distributed architecture and are standardized for interoperability. Even though emails may not be the preferred communication form of many, they most likely have an email address as a fallback solution. Emails are created and viewed by an email client, where we can have extensive control of what is sent out in the other end. There are many different email clients, and anyone may create their own. Emails consist of data and metadata, and support ap-plication extensions by special headers. As long as we conform to the protocol requirements, we are free to incorporate steganography as we like.
The distributed architecture, its popularity and extensibility make us chose to develop our solution with email as transportation
3.2.1 Emails
Emails are a very common digital communication form, to many its preferred.
Emails can hold rich data and files, there are great contact book functionality available. Most companies integrate emails deeply in their IT setup. We believe that allowing users to keep using email, and offer our solution as an extension, is the best way to ease users in and make it popular. An application that alters emails in such a way, that users may still use emails entirely as they used to, and still send emails to recipients not using our application. Recipients outside the scheme should simply ignore any extra information in emails. We offer our extensions as a superset to ordinary emails. This way, users keep using their existing work flows, their existing contacts they simply need to install an extension.
An emails is obviously just some piece of data, structured to comply with the Internet Message Format, defined by RFC 5322[rfc08]. Email semantics are very similar to how physical mail works. You write a letter and put it in the mailbox. After some time, the recipient receives the letter by the mailman, if he is not home - it will remain in his mailbox. Similarly, emails can be written and handed over to a digital mailman, for later (but typically fast) delivery. The recipient does not need to be online to receive it, in contrast to instant message
Sender
Mailman (server 1)
Inbox (server 2)
Recipient SMTP
SMTP
IMAP/POP Internet
Figure 3.4: Email transfer chain
protocols.
For this thesis, it is considered common knowledge how to compose emails, create email accounts at service providers and sending them. Instead we will briefly look into how emails are handled after they are handed to the "mailman"
or service provider. Emails consist of headers and a body. Metadata and data.
The body holds the message, headers hold information like sender, recipient, subject and other fields important to the transfer and readability.
Transfer By choosing emails as vessels for our solution, we may draw on a mature infrastructure. To understand how, we will briefly look at how emails are transferred from sender to recipient, and which protocols take part. We will not detail thoroughly on the matter, or go into how protocols are constructed.
When an email is composed, the client hands it to a email service provider through the SMTP protocol. In a way, the client says: "Mailman, please deliver this email for me". After the email is delivered from sender to the service provider, it may travel many hops before finally arriving at the recipient. An example can be seen in Figure 3.4. The sender speaks with "server 1" that acts as the mailman. Typically the sender has an account at this server. The recipient may use a different provider, his inbox is at least hosted on a different server, "server 2".
Communication between involved parties follow different protocols. The sender uses SMTP to hand it over to the mailman, the mailman forwards it to the inbox with SMTP as well. The strength of standardized protocols shines through, as we can have decentralized email systems that all communicate together.