[guardian-dev] silent circle out-of-circle (PSTN) calls
Lee Azzarello
lee at guardianproject.info
Tue Jul 15 14:37:27 EDT 2014
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
> <javascript:;>> 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 <javascript:;> <mailto:
> nathan at guardianproject.info <javascript:;>>>
> >> 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 <javascript:;> <mailto:
> lee at guardianproject.info <javascript:;>>>
> >> 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 <javascript:;>
> >>> <mailto:shmick at riseup.net <javascript:;>> <shmick at riseup.net
> <javascript:;>
> >>> <mailto:shmick at riseup.net <javascript:;>>> wrote:
> >>> >
> >>> >>
> >>> >>
> >>> >> Nathan of Guardian:
> >>> >> >
> >>> >> >
> >>> >> > On Mon, Jul 14, 2014 at 1:36 PM, Lee Azzarello
> >>> >> > <lee at guardianproject.info <javascript:;> <mailto:
> lee at guardianproject.info <javascript:;>>
> >>> <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 <javascript:;>
> >>> <mailto:shmick at riseup.net <javascript:;>> <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 <javascript:;>
> >>> <mailto:Guardian-dev at lists.mayfirst.org <javascript:;>>
> <javascript:;>
> >>> >> List info:
> >> https://lists.mayfirst.org/mailman/listinfo/guardian-dev
> >>> >>
> >>> >> To Unsubscribe
> >>> >> Send email to:
> >>> Guardian-dev-unsubscribe at lists.mayfirst.org <javascript:;>
> >>> <mailto:Guardian-dev-unsubscribe at lists.mayfirst.org <javascript:;>
> >
> >>> >> <javascript:;>
> >>> >> Or visit:
> >>> >>
> >>>
> >>>
> https://lists.mayfirst.org/mailman/options/guardian-dev/lee%40guardianproject.info
> >>> >>
> >>> >> You are subscribed as: lee at guardianproject.info <javascript:;>
> >>> <mailto:lee at guardianproject.info <javascript:;>> <javascript:;>
> >>> >>
> >>> >
> >>> >
> >>>
> >>>
> ------------------------------------------------------------------------
> >>> >
> >>> >_______________________________________________
> >>> >Guardian-dev mailing list
> >>> >
> >>> >Post: Guardian-dev at lists.mayfirst.org <javascript:;>
> >>> <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 <javascript:;>
> >>> <mailto:Guardian-dev-unsubscribe at lists.mayfirst.org <javascript:;>
> >
> >>> >Or visit:
> >>>
> >>>
> https://lists.mayfirst.org/mailman/options/guardian-dev/nathan%40guardianproject.info
> >>> >
> >>> >You are subscribed as: nathan at guardianproject.info <javascript:;>
> >>> <mailto:nathan at guardianproject.info <javascript:;>>
> >>>
> >>> _______________________________________________
> >>> Guardian-dev mailing list
> >>>
> >>> Post: Guardian-dev at lists.mayfirst.org <javascript:;>
> >>> <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 <javascript:;>
> >>> <mailto:Guardian-dev-unsubscribe at lists.mayfirst.org <javascript:;>
> >
> >>> Or visit:
> >>>
> >>
> https://lists.mayfirst.org/mailman/options/guardian-dev/petervnv1%40gmail.com
> >>>
> >>> You are subscribed as: petervnv1 at gmail.com <javascript:;>
> >> <mailto:petervnv1 at gmail.com <javascript:;>>
> >>>
> >>>
> >
> > _______________________________________________
> > 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/hans%40guardianproject.info
> >
> > You are subscribed as: hans at guardianproject.info <javascript:;>
> >
>
> --
> PGP fingerprint: 5E61 C878 0F86 295C E17D 8677 9F0F E587 374B BE81
> _______________________________________________
> 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:;>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mayfirst.org/pipermail/guardian-dev/attachments/20140715/ef0eec5e/attachment-0001.html>
More information about the Guardian-dev
mailing list