Thanks! Yes, that's correct. We're also looking into implementing forward secrecy in this asynchronous environment with support for large group chats.
Key management is another important aspect, and something that has a high learning curve for the average user. For Subrosa, we've tried to make globally accessible keyrings without compromising security. Each user has a profile blob, which contains their RSA private key, AES-GCM keys, and user settings. The profile blob is encrypted with a PBKDF2-derived key from the user password. The encrypted profile blob is sync'd with the server. When logging in, the client is required to send a hash of the derived key (the server knows this as the client sends the hash during registration) before the server returns the encrypted blob to counter offline brute-forcing attacks on the password. ---- On Wed, 20 Aug 2014 09:10:35 -0700 Tom Ritter wrote ---- >This is cool! I love the combined distribution of providing a hosted >version, and encouraging people to host it themselves. > >I looked into the code to understand more about how it works. Is it >fair to say that you use WebRTC with SRTP for the transport >encryption, and then a homebaked AES-GCM-based protocol with RSA >public keys to do the encrypted chat/actions/invites, and also to >distribute/authenticate the WebRTC fingerprints? > >-tom > >On 19 August 2014 05:33, Subrosa Team <[email protected]> wrote: >> Subrosa is an open source, end to end encrypted messaging / VOIP app focused >> on being easy to use for the general public. We made Subrosa in response to >> the mass surveillance revelations programs, and to address the difficulty of >> current tools for the average user. Oh, and it supports group video chats. >> >> Site, and hosted version to try it out: https://subrosa.io >> >> Why make something new? >> >> We've tried getting our non-techie contacts to use GPG/OTR/etc. Our personal >> experiences are that spending hours per person we want to talk to, teaching >> them how to use the tool, and helping them when they inevitably come across >> an issue (e.g. lose their keys) are just not practical. We think there's a >> place for an end to end encrypted messaging platform usable by *everyone*. >> >> Furthermore, not everyone cares about crypto. Subrosa is just as easy to use >> as making a Skype account, while key generation, etc are all performed >> behind the scenes. For end to end encryption to be widely adopted, it needs >> to convince people who don't care about it as well. And that means it can't >> be any harder, or more confusing than popular offerings. >> >> Subrosa does cryptography transparently, however we don't *hide* information >> such as fingerprints (so you can verify you're not being MITM attacked, by >> us). RSA keypairs are stored on our servers, with the private key being >> passed through PBKDF2 with the user password (not sent). Messages are >> encrypted using exchanged AES keys, with VOIP/video chats encrypted with >> SRTP. >> >> We know web crypto, when executing code from a remote server, has grave >> security implications. For ease of use, we do have a hosted version. >> Subrosa's client is fully open source however, and you can (and should!) run >> a local copy of the client. We use the ForgeJS library. >> http://github.com/subrosa-io/subrosa-client >> >> We're also fully committed to end to end encryption. We don't have any >> "gotchas" like iMessage being end to end for delivery, but storing the >> plaintext of messages in iCloud. We shouldn't have the ability to read any >> messages, in all circumstances (assuming local client). >> >> Please let us know what you think about Subrosa, and pick at this :) >> >
