[guardian-dev] silent circle out-of-circle (PSTN) calls

Natanael natanael.l at gmail.com
Tue Jul 15 15:26:01 EDT 2014


Regarding the point about infrastructure, public key based addressing
solves that part.

The address is a public key or a hash of a key, and your software asks for
how to connect to the node, and then sends an encrypted request which only
the intended recipient is capable of responding to.

CJDNS (designed for mesh network routing, provides an IPv6 interface for
software) and Tor's Hidden Services and I2P (both custom anonymizing
protocols, relies on local proxies which translates the DNS requests;
although onioncat/garlicat provides an IPv6 interface on top) all does that.

Tor gets the routing data from official directory servers. I2P uses DHT and
floodfill nodes (randomly selected, changes over time) where server nodes
sign the data of which peers was chosen as tunnel endpoints. CJDNS is far
more complex and I won't describe how it routes traffic in here, but the
short version is that it tries to map out the network and selects routes
for all outgoing packets.

Once you have that public key based address for any of those three, then
you can know the node you're connecting to its the one who has the private
key corresponding to the address. If the keypair is kept secure, that means
you're talking to the intended recipient.

- Sent from my phone
Den 15 jul 2014 20:42 skrev "Lee Azzarello" <lee at guardianproject.info>:

> Until we design and implement a new global network infrastructure,
> addressing system, and session protocol we'll have to accept that endpoint
> metadata is required for establishing a synchronous session between
> endpoints a on an IP network.
>
> Otherwise, use async audio as file transfer.
>
> -lee
>
> On Tuesday, July 15, 2014, Hans-Christoph Steiner <
> hans at guardianproject.info> wrote:
>
>>
>> Unfortunately, RedPhone only completely encrypts the voice stream, lots of
>> metadata is very much visible.  Same goes with any existing secure call
>> system.
>>
>> .hc
>>
>> On 07/15/2014 01:14 PM, Nathan of Guardian wrote:
>> > Not sure agree Redphone is the same story, in that what they created
>> was a user experience which felt like a standard phone call but was still
>> completely encrypted, but I get your point about user perception.
>> >
>> > Ultimately I think the SC out call feature is 100% for western
>> travellers or business people going to eastern, middle eastern, etc
>> countries. It is a money making feature that solves a user need that does
>> not require end to end crypto because the adversary is not global.
>> >
>> > On July 15, 2014 1:09:26 PM EDT, Lee Azzarello <
>> lee at guardianproject.info> wrote:
>> >> Heh, I hadn't seen their new web site. I guess the marketing agency
>> >> decided the "powered by ex-Navy Seals" wasn't their target market :)
>> >>
>> >> Regarding PSTN connectivity, I understand what they are doing. That's
>> >> the most frequently requested feature at ostel.co as well. I remember
>> >> when RedPhone was being lauded as "secure phone calls" and the press
>> >> picked up the story but neglected to mention the calls weren't going
>> >> over a cellular voice network. RedPhone engaged in similar deception
>> >> but
>> >> on a technology level. The calling app would intercept an incoming
>> >> call,
>> >> check a list of contacts, do a key exchange and move the call over to
>> >> the data channel. Since it was integrated into the Android dialer, it
>> >> appeared that you were calling a cellular number but really you were
>> >> calling a proprietary URI over IP data.
>> >>
>> >> So yeah, voice. Full of mystery.
>> >>
>> >> -lee
>> >>
>> >> On 7/15/14, 1:01 PM, Peter Villeneuve wrote:
>> >>> This is actually quite telling, not so much from a technical point of
>> >>> view (Lee and Nathan's comments are absolutely right - once you enter
>> >>> PSTN land your call is as tappable as any other), but from a
>> >>> marketing/business and specially ethics view. Basically, it seems
>> >> that
>> >>> SC are taking advantage of the lack of knowledge among 99% of the
>> >>> population to sell them "snake oil". Now maybe that's a little strong
>> >>> and unfair, but if you go to their snazzy new website you'll read
>> >> about
>> >>> all the wonderful benefits of Out Circle, and if you didn't know any
>> >>> better, you'd be convinced that your calls to PSTN were also secure.
>> >> How
>> >>> many people are going to get hurt by talking freely through their SC
>> >> out
>> >>> circle, convinced that their conversation in truly private? Not only
>> >> is
>> >>> it not secure, it is even more expensive than most VoIP calling
>> >>> solutions out there, so I don't see any real benefit except for the
>> >>> owners of SC and their bank acounts. In fact, one could even argue
>> >> that
>> >>> out circle calls are even less secure than PSTN calls because they
>> >> will
>> >>> likely be the target of special attention by the usual suspects. To
>> >>> quote Top Gun, that's a target rich environment, and most will speak
>> >>> freely because they're "protected" by super duper cripto, right?
>> >>>
>> >>> Bottomline: I understand SC is a business and its objective is to
>> >> make
>> >>> money. Nothing wrong with that. But "deceiving" (or at least failing
>> >> to
>> >>> properly educate its clients about the true protection they afford)
>> >>> their customers and lulling them into a false sense of security for
>> >> the
>> >>> sake of a buck, is extremely dissapointing. After all, what they're
>> >>> really selling is trust, not so much tech. And by proceeding as
>> >> they've
>> >>> done, it shows they care a lot more about image and marketing rather
>> >>> than substance and security. I'm specially disappointed in the likes
>> >> of
>> >>> Callas and Zimmerman. It takes a life time to build a reputation, and
>> >> it
>> >>> takes a second of letting greed take over to ruin it.
>> >>>
>> >>>
>> >>>
>> >>>
>> >>> On Tue, Jul 15, 2014 at 3:53 AM, Nathan of Guardian
>> >>> <nathan at guardianproject.info <mailto:nathan at guardianproject.info>>
>> >> wrote:
>> >>>
>> >>>     Exactly... Once you go "out of circle" all of that zrtp
>> >> encryption
>> >>>     and "we aren't affected by calea" talk goes out the window.
>> >>>
>> >>>     On July 14, 2014 9:20:48 PM EDT, Lee Azzarello
>> >>>     <lee at guardianproject.info <mailto:lee at guardianproject.info>>
>> >> wrote:
>> >>>     >SS will not encrypt your PSTN calls. ZRTP is an end to end
>> >> protocol.
>> >>>     >There
>> >>>     >are no PSTN devices which have ZRTP capabilities.
>> >>>     >
>> >>>     >If someone were to wiretap a conversation like this the
>> >> requirement
>> >>>     >would
>> >>>     >be to target the PSTN endpoint and record. That would produce
>> >> both
>> >>>     >sides in
>> >>>     >the clear.
>> >>>     >
>> >>>     >-lee
>> >>>     >
>> >>>     >On Monday, July 14, 2014, shmick at riseup.net
>> >>>     <mailto:shmick at riseup.net> <shmick at riseup.net
>> >>>     <mailto:shmick at riseup.net>> wrote:
>> >>>     >
>> >>>     >>
>> >>>     >>
>> >>>     >> Nathan of Guardian:
>> >>>     >> >
>> >>>     >> >
>> >>>     >> > On Mon, Jul 14, 2014 at 1:36 PM, Lee Azzarello
>> >>>     >> > <lee at guardianproject.info <mailto:lee at guardianproject.info>
>> >>>     <javascript:;>> wrote:
>> >>>     >> >> -----BEGIN PGP SIGNED MESSAGE-----
>> >>>     >> >> Hash: SHA1
>> >>>     >> >>
>> >>>     >> >> There's no advantage to use SS for PSTN calls from a
>> >> security
>> >>>     >> >> perspective. If the pricing is attractive to you, give it a
>> >> shot.
>> >>>     >> >
>> >>>     >> > It also opens them up to a bunch CALEA-like requirements
>> >> since they
>> >>>     >are
>> >>>     >> > now operating as a "plain old telephone service". I am
>> >> curious how
>> >>>     >they
>> >>>     >> > are managing this.
>> >>>     >>
>> >>>     >> their thinking:
>> >>>     >>
>> >>>     >> https://www.silentcircle.com/faq-zrtp
>> >>>     >>
>> >>>     >>  4. Is ZRTP CALEA compliant?
>> >>>     >>     Only Silent Phone’s end users are involved in the key
>> >>>     >negotiation,
>> >>>     >> and CALEA does not apply to end users.
>> >>>     >>
>> >>>     >>     Our architecture likely renders that question moot. The
>> >>>     >> Communications Assistance for Law Enforcement Act applies in
>> >> the US
>> >>>     >to
>> >>>     >> the PSTN phone companies and VoIP service providers, such as
>> >> Vonage.
>> >>>     >> CALEA imposes requirements on VoIP service providers to give
>> >> law
>> >>>     >> enforcement access to whatever they have at the service
>> >> provider,
>> >>>     >which
>> >>>     >> would be only encrypted voice packets. ZRTP does all its key
>> >>>     >management
>> >>>     >> in a peer-to-peer manner, so the service provider does not
>> >> have
>> >>>     >access
>> >>>     >> to any of the keys. Only the end users are involved in the key
>> >>>     >> negotiation, and CALEA does not apply to end users.
>> >>>     >>
>> >>>     >>     Here is the operative language from CALEA itself:
>> >>>     >>
>> >>>     >>     47 U.S.C. 1002(b)(3): ENCRYPTION - A telecommunications
>> >> carrier
>> >>>     >> shall not be responsible for decrypting, or ensuring the
>> >> government’s
>> >>>     >> ability to decrypt, any communication encrypted by a
>> >> subscriber or
>> >>>     >> customer, unless the encryption was provided by the carrier
>> >> and the
>> >>>     >> carrier possesses the information necessary to decrypt the
>> >>>     >> communication. [emphasis added]
>> >>>     >>
>> >>>     >>     Also, from the CALEA legislative history :
>> >>>     >>
>> >>>     >>     Finally, telecommunications carriers have no
>> >> responsibility to
>> >>>     >> decrypt encrypted communications that are the subject of
>> >>>     >court-ordered
>> >>>     >> wiretaps, unless the carrier provided the encryption and can
>> >> decrypt
>> >>>     >it.
>> >>>     >> This obligation is consistent with the obligation to furnish
>> >> all
>> >>>     >> necessary assistance under 18 U.S.C. Section 2518(4). Nothing
>> >> in this
>> >>>     >> paragraph would prohibit a carrier from deploying an
>> >> encryption
>> >>>     >service
>> >>>     >> for which it does not retain the ability to decrypt
>> >> communications
>> >>>     >for
>> >>>     >> law enforcement access. [...] Nothing in the bill is intended
>> >> to
>> >>>     >limit
>> >>>     >> or otherwise prevent the use of any type of encryption within
>> >> the
>> >>>     >United
>> >>>     >> States. Nor does the Committee intend this bill to be in any
>> >> way a
>> >>>     >> precursor to any kind of ban or limitation on encryption
>> >> technology.
>> >>>     >To
>> >>>     >> the contrary, section 2602 protects the right to use
>> >> encryption.
>> >>>     >>
>> >>>     >> >
>> >>>     >> >>
>> >>>     >> >>
>> >>>     >> >> - -lee
>> >>>     >> >>
>> >>>     >> >> On 7/13/14, 7:40 PM, shmick at riseup.net
>> >>>     <mailto:shmick at riseup.net> <javascript:;> wrote:
>> >>>     >> >>>  has anybody tested or used silent circle for what they
>> >> call
>> >>>     >> >>>  out-of-circle calls ?
>> >>>     >> >>>
>> >>>     >> >>>  what's been your quality experience ? anyone know their
>> >> server
>> >>>     >> >>>  addresses ?
>> >>>     >> >>>
>> >>>     >> >>>  some claim the quality is better than their own mobile
>> >> carrier
>> >>>     >and
>> >>>     >> >>>  use it entirely for outbound calls
>> >>>     >> >>>
>> >>>     >> >
>> >>>     >> > +n
>> >>>     >> _______________________________________________
>> >>>     >> Guardian-dev mailing list
>> >>>     >>
>> >>>     >> Post: Guardian-dev at lists.mayfirst.org
>> >>>     <mailto: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
>> >>>     <mailto: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
>> >>>     <mailto:lee at guardianproject.info> <javascript:;>
>> >>>     >>
>> >>>     >
>> >>>     >
>> >>>
>> >>>
>> ------------------------------------------------------------------------
>> >>>     >
>> >>>     >_______________________________________________
>> >>>     >Guardian-dev mailing list
>> >>>     >
>> >>>     >Post: Guardian-dev at lists.mayfirst.org
>> >>>     <mailto: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
>> >>>     <mailto:Guardian-dev-unsubscribe at lists.mayfirst.org>
>> >>>     >Or visit:
>> >>>
>> >>>
>> https://lists.mayfirst.org/mailman/options/guardian-dev/nathan%40guardianproject.info
>> >>>     >
>> >>>     >You are subscribed as: nathan at guardianproject.info
>> >>>     <mailto:nathan at guardianproject.info>
>> >>>
>> >>>     _______________________________________________
>> >>>     Guardian-dev mailing list
>> >>>
>> >>>     Post: Guardian-dev at lists.mayfirst.org
>> >>>     <mailto: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
>> >>>     <mailto:Guardian-dev-unsubscribe at lists.mayfirst.org>
>> >>>             Or visit:
>> >>>
>> >>
>> https://lists.mayfirst.org/mailman/options/guardian-dev/petervnv1%40gmail.com
>> >>>
>> >>>     You are subscribed as: petervnv1 at gmail.com
>> >> <mailto:petervnv1 at gmail.com>
>> >>>
>> >>>
>> >
>> > _______________________________________________
>> > 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/hans%40guardianproject.info
>> >
>> > You are subscribed as: hans at guardianproject.info
>> >
>>
>> --
>> PGP fingerprint: 5E61 C878 0F86 295C E17D  8677 9F0F E587 374B BE81
>> _______________________________________________
>> 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/lee%40guardianproject.info
>>
>> You are subscribed as: lee at guardianproject.info
>>
>
> _______________________________________________
> 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/natanael.l%40gmail.com
>
> You are subscribed as: natanael.l at gmail.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mayfirst.org/pipermail/guardian-dev/attachments/20140715/04ef0649/attachment-0001.html>


More information about the Guardian-dev mailing list