Hi, It's always good to see that people are working on tools to protect privacy and open the sourcecode. But i'm a bit disapointed by your approach which is for me a "already seen" centralized encrypted chat. I trully think that we need to do more than reinvent the wheel and build several chat clients that are not compatible between them. We just need to work on standard, decentralized protocols (like XMPP) ad implemented them properly in nice clients. By using a universal standard the users will be able to choose between several solutions which are all compatibles. All theses clients are implemented using several languages on several platforms too. There's already a bunch of tools in XMPP to do that, we are just waiting for nice clients :) P.S.: I'm working on XMPP for a couple of years now Regards, Tim On mar., août 19, 2014 at 3:38 , Subrosa Team wrote:

We just have one client.

The hosted version is the client hosted by us, on our web server. You can access it at https://subrosa.io/app/

You can download the client code, and run it from your computer, or host it on your own web server. It's identical.

The difference is by hosting the code yourself, you can be assured that the correct code is being executed.

For RSA private keys, user settings, etc, they're all encrypted with the user password (through PBKDF2) before being sent to the server. The server is just a dumb pipe that stores and passes encrypted information we don't have the keys to.

(Sorry, didn't cc the mailing list)

---- On Tue, 19 Aug 2014 06:07:10 -0700 Stephan Neuhaus wrote ----

...

Hi Subrosa Team,

sounds like an interesting project! I am however slightly confused about what you mean by "hosted version" and "client". Is this a web app or is it a web app that also has a non-web (= hosted) version, providing the same functionality, but where stuff (like RSA keypairs, for example) is stored locally instead of on your servers? If so, what exactly is the "client"?

Fun,

Stephan

Dnia wtorek, 19 sierpnia 2014 20:20:17 piszesz:

On Tue, Aug 19, 2014 at 11:35:18PM +0200, rysiek wrote:

...

Well,

not trying to be a wet blanket, but why use Subrosa, when RetroShare does almost all of that (sans group video conferences), and does not require a single server, at all?

If RS was able to get crypto right and in a completely decentralised manner, why go back to client-server architecture, with all it's potential single points of failure?

Deployment. Since there is no AGPLv3 hardware that contains all the tools required to design (and validate no trojan circuits), we might as well just use client-server from groups that we have some confidence in their motives, or at least that write good code.

So you either have a situation in which you use free software secure communication project on unverified hardware, or a situation in which you use a free software secure communication project with potential single points of failure, and on unverified hardware. Both situations are not great, but one is a bit less bad. Can you spot, which? ;)

How do I get Retroshare on my phone? (okay, bad question, because Qualcomm has my keys), but if I want my friends to use it, It needs to work on android/ios/etc.

The same way you get Subrosa on any client right now: write a mobile client for it. Instead of writing a new client-server architecture (which *should* be considered obsolete by now, IMVHO) tool, why not expand upon the completely decentralised projects? -- Pozdr rysiek

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 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 :)