4 ms·

Android app for end-to-end encrypted calls

37 points by rcamera 15y ago

rcamera 15y ago
This wiki entry has more information on it: https://guardianproject.info/wiki/Ostel https://guardianproject.info/wiki/Ostel
pagekalisedown 15y ago
Cool. Is an iOS version comming?
- calciphus 15y ago
  As soon as you write one!
  - n8fr8 15y ago
    Actually, it works just fine with a variety of iOS, Linux, Windows and Mac clients: https://guardianproject.info/wiki/OSTN#Client_Software https://guardianproject.info/wiki/OSTN#Client_Software It is just SIP over TLS, and RTP media with ZRTP encryption - all open protocols.
cypherpunks01 15y ago
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 15y ago
  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 http://freeborn.devio.us/doku.php?id=freeswitchfreebsd
ajb 15y ago
[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/ http://www.musiquetactile.fr/android-is-far-behind-ios/ [2] http://code.google.com/p/android/issues/detail?id=3434 http://code.google.com/p/android/issues/detail?id=3434
- loverobots 15y ago
  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.
  - n8fr8 15y ago
    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 https://guardianproject.info/wiki/OSTN#Client_Software Your standard phone calls still go through the standard dialer and public phone network.
- n8fr8 15y ago
  The CSipSimple solved the latency issue by utilizing the native PJSIP C library for all heavy lifting: http://www.pjsip.org/ http://www.pjsip.org/ http://code.google.com/p/csipsimple/ http://code.google.com/p/csipsimple/
  - rdtsc 15y ago
    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.
kruhft 15y ago
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 15y ago
  Perhaps we should audit: http://trac.pjsip.org/repos/browser/pjproject/trunk/pjmedia/src/pjmedia/transport_srtp.c?rev=3191#L352 http://trac.pjsip.org/repos/browser/pjproject/trunk/pjmedia/... and http://svn.pjsip.org/repos/pjproject/trunk/third_party/srtp/include/srtp.h http://svn.pjsip.org/repos/pjproject/trunk/third_party/srtp/... ?
  - kruhft 15y ago
    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 15y ago
      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).

37 points by rcamera 15y ago

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

pagekalisedown 15y ago

Cool. Is an iOS version comming?

calciphus 15y ago
As soon as you write one!
- n8fr8 15y ago
  Actually, it works just fine with a variety of iOS, Linux, Windows and Mac clients: https://guardianproject.info/wiki/OSTN#Client_Software https://guardianproject.info/wiki/OSTN#Client_Software It is just SIP over TLS, and RTP media with ZRTP encryption - all open protocols.

cypherpunks01 15y ago

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 15y ago
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 http://freeborn.devio.us/doku.php?id=freeswitchfreebsd

ajb 15y ago

[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/ http://www.musiquetactile.fr/android-is-far-behind-ios/ [2] http://code.google.com/p/android/issues/detail?id=3434 http://code.google.com/p/android/issues/detail?id=3434

loverobots 15y ago
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.
- n8fr8 15y ago
  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 https://guardianproject.info/wiki/OSTN#Client_Software Your standard phone calls still go through the standard dialer and public phone network.
n8fr8 15y ago
The CSipSimple solved the latency issue by utilizing the native PJSIP C library for all heavy lifting: http://www.pjsip.org/ http://www.pjsip.org/ http://code.google.com/p/csipsimple/ http://code.google.com/p/csipsimple/
- rdtsc 15y ago
  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.

kruhft 15y ago

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 15y ago
Perhaps we should audit: http://trac.pjsip.org/repos/browser/pjproject/trunk/pjmedia/src/pjmedia/transport_srtp.c?rev=3191#L352 http://trac.pjsip.org/repos/browser/pjproject/trunk/pjmedia/... and http://svn.pjsip.org/repos/pjproject/trunk/third_party/srtp/include/srtp.h http://svn.pjsip.org/repos/pjproject/trunk/third_party/srtp/... ?
- kruhft 15y ago
  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 15y ago
    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).