Fuckup as a Service (and poor? blame Larry Summers)

In the wake of SnowdenLeaks, a number of services have shut down (in the US) and a number of new ones have popped up (in somewhat more privacy-loving jurisdictions).

Unfortunately, “don’t trust what you don’t understand” still applies, no matter whether they’re branded for the post-PRISM set or not.

In this case, the architecture of one service (whistle.im) has all the usual pitfalls of central hosted SaaS crypto (as we’ve learned from Hushmail and Cryptocat) plus a few more… like the fact that the programmers don’t seem to understand crypto very well. Thus it’s vulnerable to MITMing of even the most amateur stripe, plus stores chats on the server so the admin could decrypt them later if they crack the password…

Feeling poor? If you live in Greece or any other number of countries that got unfairly sodomized by the Ponzi scheme implosion known as the global financial crisis, blame Larry Summers.

It seems Summers was the point man heading up the plot to infect the rest of the world with toxic securities, to ensure everyone else would be hurt so bad the dollar would remain the world reserve currency.* http://www.vice.com/en_uk/read/larry-summers-and-the-secret-end-game-memo

* (The dollar is an Achilles heel, literally — when it gets replaced by the Euro or Yuan, the US loses effective financial invincibility and the whole place collapses as it’s become dependent on that “license to steal.” Hence all the machinations to stay on top. It’s like the bus in “Speed.” Gotta keep driving!)

The memo at first glance looks far less damning than the world-banker-conspiracy columnist makes it out to be… whether he’s making a mountain of a molehill or whether this is a great example of “deniable communication” / “powertalk” as covered earlier — I’ll leave that up to you.

http://hannover.ccc.de/~nexus/whistle.en.html

“Before going into the technical Details, there are a few points to state from an overall design perspective:

The service provider runs a key server on which the RSA-keys of all participants are stored. This means that the service provider delivers the keys to the users. Of course a false key could be delivered, and the messages decrypted and read.
DThe private keys of the communicating partners are stored (albeit encrypted) on the server of the service provider. Once he gains knowledge of the password, he can decrypt all previous communications
This is a central service. As a consequence the service provider is able to find out who chatted with whom, how often, and how long.
The cryptographic code may lay open as JavaScript but not so the application itself. The label OpenSource is misleading. The code the application itself runs remains hidden.

After an analysis of the Software further points of critique emerge:

Basic concepts of state-of-the-art encryption methods have not been understood.
The communication to the server is not safe against Man-in-the-middle attacks
All keys are, from the beginning of the communication, exchanged via the key server. So an attacker running a man-in-the-middle-attack can at all times read the communication and manipulate it. This possibility is only limited by the cryptic display of the rsa-keys fingerprint.
An attacker can hijack a session and become partner of communication itself.”

Advertisements
%d bloggers like this: