Making an encrypted SMS app (Android)

Question

From my limited googling I've noticed that a lot of the mainstream encrypted messaging apps all are either (or a combination of!) closed-source, run through an uncontrolled third-party server, use a proprietary algorithm, or use out-dated algorithms. In my opinion, this is just straight up unacceptable.

My plan was to build an open-source skeleton app that implements a basic messaging UI, then build a system that handles custom encryption algorithms by way of open-sourced plugins.

I'm hoping that by using a plugin system, users are free to choose which algorithm to use and that the plugins themselves will be facing serious scrutiny by the general security community.

Why I'm posting this here: I currently know very little about how to properly handle encrypted data. What are the weak points in this implementation? How does one enforce open-source plugins?

General notes:

• I know that SMS from a service provider counts as a third-party service. I'm thinking of including functionality to point the app at a server of your choice, so you have more control over your channels of communication (though I guess your ISP can still track meta-data and what-have-you)
• Initially, my plan is to only support in-person key exchanges (or whatever method of authentication is required). Over time, if the app proves useful and used then the custom server implementation mentioned above could be used for remote authentications

Answer 1

You are reinventing the wheel. I don't think the state of art really warrants creating a new app from scratch (OTOH if you want to do so for other reasons, like practising creating an app, then go for it).

Note that with secure encryption, the third-party server wouldn't be able to snoop on the conversations (albeit it would be able to record metadata). And if it is open-source, you could replace the server quite easily with your own one.

It would be interesting that you detailed the apps you evaluated along the reasons you had for discarding them, as I suspect the panorama is not so bad.

I'm hoping that by using a plugin system, users are free to choose which algorithm to use and that the plugins themselves will be facing serious scrutiny by the general security community.

You need a baseline. You can easily end up with users split by their election of incompatible plugins. It is also generally accepted that most layman people make poor security decisions.

What you propose is right as a design, but you could simply offer a single secure algorithm, then upgrad the app with a stronger one when needed.

If the user can point the apps to a server of their choice, how are they going to communicate? Does everyone need to set the same server? What if I have several contacts in disjoint ones? Are you going to design a federated service?

Working on top of SMS has some nice properties, but it also means you have to fit everything at the sms, keep track of the contacts that have the program installed and thus should have the communication encrypted. And that they did not uninstall it or change the terminal. This was a problem for TextSecure (which ended up removing encrypted sms) or even Blackberry when people change terminals.

the custom server implementation mentioned above could be used for remote authentications

I don't see a mention of that custom server implementation for remote authentication in your question, but I should note that remote authentication is IMHO the weakest part on most of these messaging apps (unlike their encryption itself -when they do have end-to-end encryption-) as the server could quite easily vouch for someone completely different.

Using ids other than telephone numbers (like a key fingerprint) would be slightly more annoying, but preferable in both security and privacy terms.