3 ms·

> 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 ad

by 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.

by lawl 10y ago

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.