4 ms·

Making a “proper” encrypted SMS app (Android)

6 points by spokespinner 10y ago

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 - This is cross-posted on another website, but I'm not sure if I'm allowed to share the URL to it.

lawl 10y ago
> I currently know very little about how to properly handle encrypted data. Then don't roll your own crypto. Textsecure had SMS support and there are forks adding websocket support. My suggestion would be to work on untangling TextSecure from Google. I also don't see why you shouldn't be allowed to share where you cross posted this to.
- spokespinner 10y ago
  I'm not planning on implementing my own, just building something that allows people to "hot-swap" whatever algorithm they can find (one that is written as a plugin to this app). For instance, some group of people get together and implement today's current "perfect standard" algorithm as a plugin. Then they release that plugin (TBD how they are distributed) and any user of that app can choose whether or not to use that plugin. Say, 10 days later some security patch was applied to the libraries that group used, they could update the plugin itself without ever having to touch the actual app. Thanks for the Textsecure suggestion, I'll look into this.
  - lawl 10y ago
    I'd say this wasn't always an advantage for SSL/TLS. The crypto will have impact on the protocol design. I.e. OTR wouldn't work on smartphones because of the always online architecture. I'd also rather not have some random group get together and design a crypto plugin... personally.
    - spokespinner 10y ago
      > OTR wouldn't work on smartphones because of the always online architecture. Could you elaborate a bit more on this? Learning a lot of new stuff and the Wikipedia page seems a bit dense... > I'd also rather not have some random group get together and design a crypto plugin... personally. Not even if it were only available open-source?
      - lawl 10y ago
        I'm on a smartphone. But OTR expects the opposite side to respond immediately. So not SMS or anything of that sort. The signal protocol for example was designed to work around that. A client can be offline when you send a message. Different protocol design that involves stuff server side. > Not even if it were only available open-source? No. Very few people can assess if something is cryptographically sane, and a lot of people need to do it for something to be believed secure. I'm not one of those people. I'd rather use state of the art crypto. Thanks.
welder 10y ago
> I'm hoping that by using a plugin system, users are free to choose which algorithm to use... This will just confuse the user and limit adoption in my opinion. Not sure about the quality of security, but it's distributed: https://ring.cx/en https://ring.cx/en - Ring is a secure and distributed voice, video and chat communication platform that requires no centralized server and leaves the power of privacy in the hands of the user.
- spokespinner 10y ago
  Nice! Thanks for the link.

6 points by spokespinner 10y ago

lawl 10y ago

> I currently know very little about how to properly handle encrypted data. Then don't roll your own crypto. Textsecure had SMS support and there are forks adding websocket support. My suggestion would be to work on untangling TextSecure from Google. I also don't see why you shouldn't be allowed to share where you cross posted this to.

spokespinner 10y ago
I'm not planning on implementing my own, just building something that allows people to "hot-swap" whatever algorithm they can find (one that is written as a plugin to this app). For instance, some group of people get together and implement today's current "perfect standard" algorithm as a plugin. Then they release that plugin (TBD how they are distributed) and any user of that app can choose whether or not to use that plugin. Say, 10 days later some security patch was applied to the libraries that group used, they could update the plugin itself without ever having to touch the actual app. Thanks for the Textsecure suggestion, I'll look into this.
- lawl 10y ago
  I'd say this wasn't always an advantage for SSL/TLS. The crypto will have impact on the protocol design. I.e. OTR wouldn't work on smartphones because of the always online architecture. I'd also rather not have some random group get together and design a crypto plugin... personally.
  - spokespinner 10y ago
    > OTR wouldn't work on smartphones because of the always online architecture. Could you elaborate a bit more on this? Learning a lot of new stuff and the Wikipedia page seems a bit dense... > I'd also rather not have some random group get together and design a crypto plugin... personally. Not even if it were only available open-source?
    - lawl 10y ago
      I'm on a smartphone. But OTR expects the opposite side to respond immediately. So not SMS or anything of that sort. The signal protocol for example was designed to work around that. A client can be offline when you send a message. Different protocol design that involves stuff server side. > Not even if it were only available open-source? No. Very few people can assess if something is cryptographically sane, and a lot of people need to do it for something to be believed secure. I'm not one of those people. I'd rather use state of the art crypto. Thanks.

welder 10y ago

> I'm hoping that by using a plugin system, users are free to choose which algorithm to use... This will just confuse the user and limit adoption in my opinion. Not sure about the quality of security, but it's distributed: https://ring.cx/en https://ring.cx/en - Ring is a secure and distributed voice, video and chat communication platform that requires no centralized server and leaves the power of privacy in the hands of the user.

spokespinner 10y ago
Nice! Thanks for the link.