[guardian-dev] Blackphone

Lee Azzarello lee at guardianproject.info
Fri Jan 17 12:00:49 EST 2014

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.


[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:
> Hash: SHA1
> 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:;>
> Version: GnuPG v1.4.10 (GNU/Linux)
> qx00RFHkE4/aW3B6ALz67vt5Yn80ce4MfPM7vvG6gn+YUXpFsmgpgxrtX9dF3Rxu
> S8CMRlRVXYa3QBphyo1XCwcETNMC8hp5V6ANn9SwaNMICiaqxXeJwgxOLunhJx9N
> M4uMIeGYSt+myvooAJqP95oMGg8lJiaWLRcdAQsuIeRPxNoA2Ln8SVyrHHXlD764
> ar0355VMbssDMNXjQ0TutUifr62sOBZopMFJFbniLWOuzxTAmj2CrF7Ti8cdIcWY
> fpmwDColyRqOq7Lyu5DeIcyQc6rlAwjZ3MU1Pfy6gRqJqo6M7cOG/vqyePFqTE4=
> =Bzek

More information about the Guardian-dev mailing list