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 <[email protected]> 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 <[email protected] > <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 > >>> <[email protected] <javascript:;> <mailto: > [email protected] <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 > >>> <[email protected] <javascript:;> <mailto: > [email protected] <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, [email protected] <javascript:;> > >>> <mailto:[email protected] <javascript:;>> <[email protected] > <javascript:;> > >>> <mailto:[email protected] <javascript:;>>> wrote: > >>> > > >>> >> > >>> >> > >>> >> Nathan of Guardian: > >>> >> > > >>> >> > > >>> >> > On Mon, Jul 14, 2014 at 1:36 PM, Lee Azzarello > >>> >> > <[email protected] <javascript:;> <mailto: > [email protected] <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, [email protected] <javascript:;> > >>> <mailto:[email protected] <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: [email protected] <javascript:;> > >>> <mailto:[email protected] <javascript:;>> > <javascript:;> > >>> >> List info: > >> https://lists.mayfirst.org/mailman/listinfo/guardian-dev > >>> >> > >>> >> To Unsubscribe > >>> >> Send email to: > >>> [email protected] <javascript:;> > >>> <mailto:[email protected] <javascript:;> > > > >>> >> <javascript:;> > >>> >> Or visit: > >>> >> > >>> > >>> > https://lists.mayfirst.org/mailman/options/guardian-dev/lee%40guardianproject.info > >>> >> > >>> >> You are subscribed as: [email protected] <javascript:;> > >>> <mailto:[email protected] <javascript:;>> <javascript:;> > >>> >> > >>> > > >>> > > >>> > >>> > ------------------------------------------------------------------------ > >>> > > >>> >_______________________________________________ > >>> >Guardian-dev mailing list > >>> > > >>> >Post: [email protected] <javascript:;> > >>> <mailto:[email protected] <javascript:;>> > >>> >List info: > >> https://lists.mayfirst.org/mailman/listinfo/guardian-dev > >>> > > >>> >To Unsubscribe > >>> > Send email to: > >> [email protected] <javascript:;> > >>> <mailto:[email protected] <javascript:;> > > > >>> >Or visit: > >>> > >>> > https://lists.mayfirst.org/mailman/options/guardian-dev/nathan%40guardianproject.info > >>> > > >>> >You are subscribed as: [email protected] <javascript:;> > >>> <mailto:[email protected] <javascript:;>> > >>> > >>> _______________________________________________ > >>> Guardian-dev mailing list > >>> > >>> Post: [email protected] <javascript:;> > >>> <mailto:[email protected] <javascript:;>> > >>> List info: > >> https://lists.mayfirst.org/mailman/listinfo/guardian-dev > >>> > >>> To Unsubscribe > >>> Send email to: > >> [email protected] <javascript:;> > >>> <mailto:[email protected] <javascript:;> > > > >>> Or visit: > >>> > >> > https://lists.mayfirst.org/mailman/options/guardian-dev/petervnv1%40gmail.com > >>> > >>> You are subscribed as: [email protected] <javascript:;> > >> <mailto:[email protected] <javascript:;>> > >>> > >>> > > > > _______________________________________________ > > Guardian-dev mailing list > > > > Post: [email protected] <javascript:;> > > List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev > > > > To Unsubscribe > > Send email to: [email protected] > <javascript:;> > > Or visit: > https://lists.mayfirst.org/mailman/options/guardian-dev/hans%40guardianproject.info > > > > You are subscribed as: [email protected] <javascript:;> > > > > -- > PGP fingerprint: 5E61 C878 0F86 295C E17D 8677 9F0F E587 374B BE81 > _______________________________________________ > Guardian-dev mailing list > > Post: [email protected] <javascript:;> > List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev > > To Unsubscribe > Send email to: [email protected] > <javascript:;> > Or visit: > https://lists.mayfirst.org/mailman/options/guardian-dev/lee%40guardianproject.info > > You are subscribed as: [email protected] <javascript:;> >
_______________________________________________ Guardian-dev mailing list Post: [email protected] List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev To Unsubscribe Send email to: [email protected] Or visit: https://lists.mayfirst.org/mailman/options/guardian-dev/archive%40mail-archive.com You are subscribed as: [email protected]
