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

Peter Villeneuve petervnv1 at gmail.com
Tue Jul 15 13:22:51 EDT 2014


I didn't know the redphone story. Interesting.
But I agree with you both. Out call is a useful feature to have for the
uses cases Nathan described. Heck, I've been using it myself on my own
server for years now and it works great.
But, of ocurse, I know that the calls aren't secure once they hit the PSTN.
What bothers me is that SC seems to go out of their way to deceive instead
of educate. Now we all know that, unfortunatley, that's the norm in the
industry, but I expected more out of Sallas and Zimmerman.
Perhaps my expectations were too high.


On Tue, Jul 15, 2014 at 6:14 PM, Nathan of Guardian <
nathan at guardianproject.info> 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>
> >>
> >>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mayfirst.org/pipermail/guardian-dev/attachments/20140715/aec2da2a/attachment-0001.html>


More information about the Guardian-dev mailing list