Android app for end-to-end encrypted calls | Hacker News Reader

Android app for end-to-end encrypted calls

ostel.me

37 pointsrcamera17 comments

[Edited to add: on reflection, this is a bit negative; it is a really cool app, and I guess if you're worried about security, latency may not be your highest concern. ]

I've put off getting an android device because of the appalling audio latency[1][2]. Given that telephony is the most demanding application as regards latency, I suspect this sadly may not sound very good, depending on the android device. Unless someone has found a cunning workaround?

[1] http://www.musiquetactile.fr/android-is-far-behind-ios/ [2] http://code.google.com/p/android/issues/detail?id=3434

Is it possible to use this only for certain calls? Like using a proxy for certain things online, but visiting CNN and most sites without it.

Yup. For now, you just make calls to other people using the same server or another OSTN compliant server: https://guardianproject.info/wiki/OSTN#Client_Software

Your standard phone calls still go through the standard dialer and public phone network.

The CSipSimple solved the latency issue by utilizing the native PJSIP C library for all heavy lifting: http://www.pjsip.org/

http://code.google.com/p/csipsimple/

Unless it binds directly to the alsa device (which I think you need to have a rooted phone to access) it still uses audioflinger. So the terrible latencies (into the hundreds of milliseconds) will still be there.

From a user standpoint, it is not terrible, especially considering what it is doing. It is definitely not as real time as a standard phonecall, but if you are not in the same room, you hardly notice it.

It is just on the edge of being bad. You can tell if you talk and the other person talks over you because they didn't yet get to hear that you started talking. This happens more in a faster paced conversation, and you might notice if it you talk with someone across a low quality, high latency connections.

I think it is pretty terrible if you try to use android to synthesize audio. Say if you want it to be used for realtime performance. iOS has about 5ms and Android has 100->300ms. There is a huge difference and makes Android completely useless for that kind of purpose (even fast paced games with sounds effects have this if you notice).

This wiki entry has more information on it: https://guardianproject.info/wiki/Ostel

From my last job working on SIP and encrypted SIP I found a flaw in the PJSIP library where they were generating keys using only ASCII characters and not the full range of the unsigned byte type. I found this in a client application phone using PJSIP, informed the developers of the application; I don't know if it ever got back to the PJSIP developers. This was about 3 months ago and I don't know if this has been resolved in PJSIP, but I would be worried about SRTP key strength in this application.

Perhaps we should audit:

http://trac.pjsip.org/repos/browser/pjproject/trunk/pjmedia/...

and

http://svn.pjsip.org/repos/pjproject/trunk/third_party/srtp/...

Might be a good idea. After a quick look at the first link, the key is passed in the opt structure. It's generated before the call to pjmedia_transport_srtp_create. I'll keep looking and see if I can find where it's actually generated.

Might be a good idea. I took a look at the latest 1.* and 2.* version; they look to be using the libsrtp prng for their key generation, so it should be good. The behaviour I was seeing was that the keys coming from the client I was testing with did not ever have any null characters in them, which lead me to believe the keys were only in the ascii range. I'm not sure what type of freedom pjsip gives for key generation; maybe it was a problem with the client I was testing. Looking over the pjsip code it looks to be ok (see generate_crypto_attr_value in trannsport_srtp.c to see the key generation using crypto_get_random).

Great! I think moxie's RedPhone has been shut down for awhile now, since twitter hired him. Any word on whether this is a solid replacement?

RedPhone had some nice optimizations like tying into your existing public phone number (perhaps a privacy issue depending upon your view), and using SMS or Google's Push service to ensure your device is not sleeping when you get a call. OSTN/OStel has no custom modifications, but alternatively then is pure open-standards based.

Voice quality wise they are about the same... the goal is for you to be able to run your own server as well. There is already some info available today on how to do this: http://freeborn.devio.us/doku.php?id=freeswitchfreebsd

Cool. Is an iOS version comming?

As soon as you write one!

Actually, it works just fine with a variety of iOS, Linux, Windows and Mac clients: https://guardianproject.info/wiki/OSTN#Client_Software

It is just SIP over TLS, and RTP media with ZRTP encryption - all open protocols.

Reply on news.ycombinator.com