mschultheiss

Yes, exactly :)

1. The web crypto api was indeed made to secure communications, such as stated by the W3C on http://www.w3.org/TR/WebCryptoAPI/ (...) "Uses for this API range from user or service authentication, document or code signing, and the confidentiality and integrity of communications. "

2. Yes, you are definetly right, an detailed audit of the protocol is necessary by more than one expert.

3. Here is a short description of the basic concept: Client and server are seperated. The client software is basically what is hosted on Github. Its source code must be protected from MITM attacks of course, so it is best to ship it as standalone, downloadable application in the final release. THE CLIENT CODE WILL NOT BE OFFERED BY A SERVER IN A PRODUCTION VERSION.

So at sign up, the client software now generates a (RSA) public key pair and some symmetric keys used for (AES) encryption and integrity protection locally and encrypts it with a passphrase. The passphrase is only known by the user, but not by the server. The encrypted string is also integrity protected. It is sent to the server, stored there, and decrypted with the passphrase at login again. This way we ensure only the client software can see secrets, such as the private key, but not the server software.

Next, you have a key directory. It is signed after every modification with a secret salt which was generated by the client (and not known by the server) at signup. The keydirectory contains all the verified public keys of the user. (Protecting it from replay attacks would be worth another essay here) Now when you write messages for example, you get the public key from this directory and encrypt/sign it basically like in PGP. So the focus of this preview is not on the crypto primitives, but rather on the concept itself.

Edit: I hope this does not sound too unfriendly, I am very happy about your feedback and I promise I will look for further advice regarding the crypto/protocol ;)

It has end-to-end encrpytion - so if you are hosted on a friend's server for example, the friend can not read your messages, which might be useful :)

Yes, as written on top this is a technology preview, so it is not safe yet. Furthermore the production version will use the web crypto api. The client software must be shipped packaged as a standalone application (Apache Cordova etc.) with integrity protection or hosted on your own server and served via https. Yeah, the goal is actually to get some feedback about the crypto design and improve it :)

1. Thats wrong, the variable sendingText is generated of Intent.EXTRA_TEXT (see http://developer.android.com/training/sharing/send.html for details) so it is definitely for handling shared content.

2. error=true is set in the else if case, which can not be stepped into anymore after having checked if the text contains "WhatsApp"

I guess this code is only used when sharing something from WhatsApp to Telegram. If you share a picture for example, it removes the "Sent from Whatsapp" advertisment message. Correct me if i am wrong...