

Android app for end-to-end encrypted calls - rcamera
https://ostel.me/

======
ajb
[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>

~~~
n8fr8
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/>

~~~
rdtsc
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.

~~~
n8fr8
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.

~~~
rdtsc
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).

------
rcamera
This wiki entry has more information on it:
<https://guardianproject.info/wiki/Ostel>

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

~~~
n8fr8
Perhaps we should audit:

[http://trac.pjsip.org/repos/browser/pjproject/trunk/pjmedia/...](http://trac.pjsip.org/repos/browser/pjproject/trunk/pjmedia/src/pjmedia/transport_srtp.c?rev=3191#L352)

and

[http://svn.pjsip.org/repos/pjproject/trunk/third_party/srtp/...](http://svn.pjsip.org/repos/pjproject/trunk/third_party/srtp/include/srtp.h)

?

~~~
kruhft
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.

~~~
kruhft
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).

------
cypherpunks01
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?

~~~
n8fr8
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>

------
pagekalisedown
Cool. Is an iOS version comming?

~~~
calciphus
As soon as you write one!

~~~
n8fr8
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.

