Srry forgot to add . My idea is to create a Voip client optimised for TOR , to build a voip client with tor in mind and not getting a client to work with tor.
On Thu, Dec 23, 2010 at 8:00 PM, hhhh xhdhx <johncalis...@gmail.com> wrote: > My plan goes like this . > > 1.) Build a barebones SIP client based on SofiaSip. > 2.) Support only codec2 ( audio codec ) > 3.) No encryption is implemented by the SIP client ( like ZRTP etc ) as the > hidden service takes care of that. > 4.) Each SIP client will be a hidden service , using authentication similar > to torchat , as it is the most natural way . > 5.) Hopefully with codec2 , it can be sent through Tcp , the idea is to > keep the network traffic as low as possible . > > Comments & Brickbats pls . > > > On Tue, Dec 21, 2010 at 11:43 PM, hhhh xhdhx <johncalis...@gmail.com>wrote: > >> >> >> On Tue, Dec 21, 2010 at 3:58 AM, grarpamp <grarp...@gmail.com> wrote: >> >>> > From reading on OnionCat , the clients are essentially hidden services >>> > once a connection is made it is bidirectional. >>> >>> No, OC is just a daemon shuffling data back and forth across a >>> Tor HiddenServicePort. Tor provides a bidir return path to the >>> source, which the listener (OC) can use, if it thinks it should... >>> >>> > If A initiates a connection >>> > to B , A can be sure he/she is talking to B >>> >>> Yes, up to the 80-bit addressing of Tor. OC translates your request >>> for a v6 address into an onion address and puts that stream through >>> Tor. >>> >>> > but the opposite isnt true .So >>> > if B has to sure he/she is indeed talking to A , he/she has to initiate >>> a >>> > connection to A [..... to query and confirm it .....]. >>> >>> Yes. Because B's onion is seeing no onion source address. And B's >>> OC is seeing an arbitrary v6 source address. >>> >>> Since most protocols require a reverse channel, it's actually B that >>> is more at risk of sending their data off to onions unknown. Luckily, >>> that is where B (if human and not a dolt) usually notices something >>> is broken and quits it. >>> >>> And it's kind of pointless to do such spoofing because if A wanted >>> B's return stream, it should have just asked for it. So it would just be >>> for the lol's of A blindly convincing B (or B's computer, app, etc) to >>> disclose something to C. >>> >>> > Which is what torchat does to authenticate both the parties >>> > , even if OnionCat is being used the same has to be done to ensure both >>> the >>> > people know who they are talking to. Am I right in my observation ?? >>> >>> Yes, and as before, OC had plans to do a little OCtoOC ping pong too. >>> If running IPSEC, etc over v6, learning or making stashes of source >>> key-v6 associations, that might do it too, more work, same thing. >>> >>> So what intrigeri was talking abt was the torifying of voip and not >> necessarily a fully authenticated peer to peer commuincation where A is sure >> of B & B is sure of A. >> >>> OC is just another app that plugs into Tor, no different than TorChat. >>> It just happens to present the user with a cool and immensely useful >>> v6 address instead of a cute little chat prompt. >>> *********************************************************************** >>> To unsubscribe, send an e-mail to majord...@torproject.org with >>> unsubscribe or-talk in the body. http://archives.seul.org/or/talk/ >>> >> >> >