As you may have seen, you have the possibility to send a so-called "virtual message" to the webmaster. You can choose between sending it in plain text (mandatory without javascript), or using encryption. The latter option relies on a public key cryptography infrastructure, and its underlying architecture is summarized here.

The overall security of the system depends on which kind of access to the channel linking the sublunar circus to you a potential eavesdropper has.

• If the spy has both read and write access, there is no security at all, since the spy can apply a "man in the middle" attack. Here it would consist, for example, to modify the public key sent by the http server at step (5), retrieve the data encrypted with this altered key at step (8), then decrypt the original message, and finally reencrypt it with the genuine key and transmit the result (step (9)). Notice that the duration of step (8) depends on your computing power and therefore it's difficult for the server to detect the presence of a spy using timing considerations.


• If the spy has only write access, what (s)he basically can do is flooding the channel or breaking it, impeding a correct communication between both parties. So, no mean to intercept the message, but some capacity to harm.


• If the spy has only read access (e.g. using a clip-on coupler and a traffic analyzer), the security essentially relies on the absence of extraordinary computing power (or groundbreaking mathematical theory) to him/her. Indeed the message is encrypted with a 4096 bit El Gamal key, so it should be in principle safe for a while, but it is very likely that in a few years the spy will be able to crack it.


• If the spy has neither read nor write access, one cannot really talk about a spy. However, the eavesdropper could be located elsewhere. This could be the case, for instance, if the keystrokes are recorded while you're typing the message, or if some data are stolen (or communicated) after having being decrypted...

Step (8) is actually based on a javascript port of some gpg encryption algorithms, which has been written by Herbert Hanewinkel. Many thanks to him! The source code of the client-side part is available (exercise: find it) if you want to see that more in details.

Of course if you choose not to encrypt your message, or if you can't, the above architecture is irrelevant; data are basically transmitted in plain text, then simply echoed.

Little Neo, 2009