[guardian-dev] Blackphone

Michael Rogers michael at briarproject.org
Fri Jan 17 10:49:49 EST 2014


-----BEGIN PGP SIGNED MESSAGE-----
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:;>
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQEcBAEBAgAGBQJS2VEdAAoJEBEET9GfxSfMVsIH/2MHLtWiJ9dA5hqMimZmZa0u
qx00RFHkE4/aW3B6ALz67vt5Yn80ce4MfPM7vvG6gn+YUXpFsmgpgxrtX9dF3Rxu
S8CMRlRVXYa3QBphyo1XCwcETNMC8hp5V6ANn9SwaNMICiaqxXeJwgxOLunhJx9N
M4uMIeGYSt+myvooAJqP95oMGg8lJiaWLRcdAQsuIeRPxNoA2Ln8SVyrHHXlD764
ar0355VMbssDMNXjQ0TutUifr62sOBZopMFJFbniLWOuzxTAmj2CrF7Ti8cdIcWY
fpmwDColyRqOq7Lyu5DeIcyQc6rlAwjZ3MU1Pfy6gRqJqo6M7cOG/vqyePFqTE4=
=Bzek
-----END PGP SIGNATURE-----


More information about the Guardian-dev mailing list