[guardian-dev] Blackphone

Thu Apr 10 19:56:53 EDT 2014

Dear Lee,
Are there any step-by-step guides for getting an OSTN-compliant setup 
running?

Also, would it be generally acceptable to run it on a standard-issue VPS 
like Digital Ocean?

Also, what do folks think of Jake's efforts on 'freenote'?

https://github.com/ioerror/freenote

In that, the Icecast server is local.

Cheers,
Pranesh

Lee Azzarello <lee at guardianproject.info> [2014-01-17 12:00:49 -0500]:
> I don't believe there is much use in discussing the design of existing
> synchronous realtime voice/video systems from a "the server reveals
> metadata" security angle since there is only a single answer. The
> server will always reveal metadata because of two core principals,
> Internet Protocol (IP) networking and the speed of light. Because of
> these, this problem is not unique to ostel.co (OSTN is only a
> configuration spec for SIP and a few dependent applications), it
> exists for every single realtime bi-directional voice/video
> communication system that operates on the public Internet.
>
> The solution in this case is not to use IP networking. We could
> reimagine circuit switched networks and bring back the dream of ISDN
> lines in every home in the world, which would be a pretty cool idea
> from a security perspective but our contemporary bandwidth
> requirements exceed the 128kbps max of a BRI. We could also bring back
> the PRI and have 1.5mbps which would work for current video codecs.
> Unfortunately, most telcos in the USA are retiring all the
> infrastructure to support this kind of networking.
>
> Another technique is to use jitter buffers[1], which exist for packet
> switched networks. This problem reaches the ends of known computer
> science as latency standard deviations rise. A common example is that
> of multiplayer video games, which have sophisticated networking code
> to reduce jitter, which in that context is commonly referred to as
> "lag". If you've played a game like Counter Strike you have probably
> experienced the emotions associated with lag. They are not so good.
>
> ostel.co is in a small unique class of public VoIP services in that we
> are transparent about what kind of metadata the server is responsible
> for and what kind of system memory stores that metadata[2]. So with
> current Internet architecture, this is the only appropriate response
> that is known to me.
>
> Regards,
> Lee
>
> [1] https://en.wikipedia.org/wiki/Jitter#Mitigation
> [2] https://ostel.co/privacy
>
> On Fri, Jan 17, 2014 at 10:49 AM, Michael Rogers
> <michael at briarproject.org> wrote:
> Hi Lee,
>
> I don't know of any such system, of course. Does that mean we
> shouldn't discuss the limitations of existing systems?
>
> The OSTN architecture reveals metadata to the server, and to an
> adversary who passively wiretaps either the server or both endpoints
> of a call.
>
> I'm happy to use and recommend OSTN, knowing that that's the case. But
> maybe some other people wouldn't be happy to use the service on that
> basis. I think it's best to be upfront about what the service can and
> can't do, so that people can decide whether it fits their needs.
>
> When I harp on about this metadata issue it's not because I think
> there's some better, metadata-concealing voip system out there that
> everyone should be using. There isn't. People should use OSTN. But
> they should understand that encrypted != invisible, and trusting the
> service provider is still important.
>
> Cheers,
> Michael
>
> On 17/01/14 15:20, Lee Azzarello wrote:
>>>> Good morning,
>>>>
>>>> If you have a suggestion to do p2p real time voice without a
>>>> central registry to locate end points and not use IP addresses
>>>> please share that information! I've been looking for such a system
>>>> for years now. The design challenges are far too abstract to make
>>>> sense of with my understanding of IP networking.
>>>>
>>>> -lee
>>>>
>>>> On Friday, January 17, 2014, Michael Rogers
>>>> <michael at briarproject.org <mailto:michael at briarproject.org>>
>>>> wrote:
>>>>
>>>> On 17/01/14 11:10, Matej Kovacic wrote:
>>>>> Yes, but adversary can see when do you connect to OSTN server to
>>>>> place a call and see who responded to a call. Actually they can
>>>>> only see who is transferring the data and in what amount, but it
>>>>> is enough for correlation. So they can see who is communicating
>>>>> with who.
>>>>
>>>> Yup, an adversary wiretapping both parties can see that they're
>>>> communicating. But the parties' OSTN servers can see that
>>>> _without_ wiretapping them.
>>>>
>>>>> A solution would be to use OSTN with Tor network (OK, it would
>>>>> not work, but you can use ChatSecure's voice messages), while
>>>>> both parties should also generate some additional fake traffic to
>>>>> Tor network to prevent correlation.
>>>>
>>>>> In that case you would have encrypted conversation, server
>>>>> administrator cannot see who is communicationg with who
>>>>> (actually, can only see some identity number like number 1000 is
>>>>> calling number 2000, but without real IP addresses), and
>>>>> adversary can only see that you have connected to Tor network and
>>>>> that you are transferring some data.
>>>>
>>>>> In that case you do not need to trust anyone. Except endpoint
>>>>> devices. :-)
>>>>
>>>> Sounds like a good solution, as long as the OSTN accounts are
>>>> registered and used always through Tor.
>>>>
>>>> IIRC, the Tor protocol allows clients to send padding frames to
>>>> relays - but it doesn't allow clients to ask relays to generate
>>>> padding. So the Tor->Alice direction of the Alice->Tor connection,
>>>> and the Tor->Bob direction of the Tor->Bob connection, could still
>>>> be correlated. And of course, circuit setup and teardown times are
>>>> quite revealing even if the circuits are fully padded.
>>>>
>>>> Cheers, Michael
>>>>
>>>> _______________________________________________ Guardian-dev
>>>> mailing list
>>>>
>>>> Post: Guardian-dev at lists.mayfirst.org <javascript:;> List info:
>>>> https://lists.mayfirst.org/mailman/listinfo/guardian-dev
>>>>
>>>> To Unsubscribe Send email to:
>>>> Guardian-dev-unsubscribe at lists.mayfirst.org <javascript:;> Or
>>>> visit:
>>>> https://lists.mayfirst.org/mailman/options/guardian-dev/lee%40guardianproject.info
>>>>
>>>>   You are subscribed as: lee at guardianproject.info <javascript:;>
>>>>
>
> _______________________________________________
> Guardian-dev mailing list
>
> Post: Guardian-dev at lists.mayfirst.org
> List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
>
> To Unsubscribe
>          Send email to:  Guardian-dev-unsubscribe at lists.mayfirst.org
>          Or visit: https://lists.mayfirst.org/mailman/options/guardian-dev/pranesh%40cis-india.org
>
> You are subscribed as: pranesh at cis-india.org
>

-- 
Pranesh Prakash
Policy Director, Centre for Internet and Society
T: +91 80 40926283 | W: http://cis-india.org
-------------------
Access to Knowledge Fellow, Information Society Project, Yale Law School
M: +1 520 314 7147 | W: http://yaleisp.org
PGP ID: 0x1D5C5F07 | Twitter: https://twitter.com/pranesh_prakash

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.mayfirst.org/pipermail/guardian-dev/attachments/20140410/ce886770/attachment.pgp>