Re: [tor-dev] [tor-commits] [tor-messenger-build/master] Bug 17492: Include default bridges configuration

On Fri, Nov 06, 2015 at 08:29:19PM -0500, Roger Dingledine wrote: > On Sat, Nov 07, 2015 at 12:13:45AM +, bo...@torproject.org wrote: > > commit 7a1c6fd121dd001eb999ef03ebbbed264da37026 > > Author: Nicolas Vigier > > Date: Sat Nov 7 00:45:48 2015 +0100 > > > > Bug

Re: [tor-dev] [tor-commits] [tor-messenger-build/master] Bug 17492: Include default bridges configuration

On Fri, 6 Nov 2015 19:29:45 -0800 David Fifield wrote: > > This could be a great opportunity for Yawning's recent meek variant > > that doesn't use an actual browser. (It won't work as well as the > > real meek, but maybe no actual adversaries care about the > > difference

[tor-dev] Mail Address Translation Protocol Tor>Internet, Internet

Enter/Exit OnionMail SMTP servers connect the Internet and Tor. The addressed must be translated from hidden service address to Internet address ad viceversa. There are some way to do this: MAT = Mail Address Translation: localpart.hiddenservice.on...@internetserver.tld =

[tor-dev] Changing Rendezvous Single Onion Service at Runtime

Hi all, Is there any reason an onion service would want to temporarily switch from 1-hop to 3-hop paths? Is it ok if we force operators to restart the tor instance when onion service path lengths change? The original proposal for rendezvous single onion services (RSOS) was silent on whether

[tor-dev] Alternate Single Onion Service Designs

Hi all, Do we need both single onion services (Proposal 252) and rendezvous single onion services? We want to enable secure usage by default, and avoid splitting anonymity sets. But we also want to support real-world use cases, because anonymous protocols are safer if more people use them.

Re: [tor-dev] Changing Rendezvous Single Onion Service at Runtime

> On Nov 6, 2015, at 4:16 PM, teor wrote: > Hi all, Hiya! > Is there any reason an onion service would want to temporarily switch from > 1-hop to 3-hop paths? > Is it ok if we force operators to restart the tor instance when onion service > path lengths change? Well - as

Re: [tor-dev] Alternate Single Onion Service Designs

> On Nov 6, 2015, at 4:56 PM, teor wrote: > Do we need both single onion services (Proposal 252) and rendezvous single > onion services? I would say they are both desirable, and that we could/should have both. RSOS is great for adoption, the rendezvous step enables

[tor-dev] Ideas for TorBrowser

Hello. I would like to propose following for the TorBrowser: * request folder structure change because the actual one is a big mess and it's hard to find anything without browsing each folder * add the patches with fix the bugs of not working functions (like by example: options, addons, etc.)

Re: [tor-dev] Update of prop#250: Random Number Generation During Tor Voting

On 06 Nov (15:35:50), George Kadianakis wrote: > George Kadianakis writes: > > > s7r writes: > > > >> Hello, > >> > >> > >> > >> 4.1.1. Computing commitments and reveals [COMMITREVEAL] > >> "The value REVEAL is computed as follows: > >> > >> REVEAL

[tor-dev] DoS resistance for Next-Generation Onion Services

Hi all, I think we can make next-generation onion (hidden) services (proposal #224) more resilient against certain kinds of DoS / client discovery attacks, by using a different blinded public key for each HSDir. Attack Summary: Once a malicious HSDir receives a descriptor, it can locate other

Re: [tor-dev] Alternate Single Onion Service Designs

> On 7 Nov 2015, at 04:36, Alec Muffett wrote: > > These three solutions in aggregate should lower latency and scale tor daemon > bandwidth by a range of 18..60x > > Then: > > 4) (Wishlist) implementation of TVDW's handoff of RP callback > > ...which will resolve any remaining

Re: [tor-dev] Update of prop#250: Random Number Generation During Tor Voting

George Kadianakis writes: > s7r writes: > >> Hello, >> >> >> >> 4.1.1. Computing commitments and reveals [COMMITREVEAL] >> "The value REVEAL is computed as follows: >> >> REVEAL = base64-encode( TIMESTAMP || RN )" >> >> * Maybe it is useful to also