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 quite yet?)
>
> You c
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 17492: Include default
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 17492: Include default bridges configuration
>
> However, we exclude meek from the bridges
> 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 CPU-bandwidth
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
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 = base64-encode( TIMESTAMP || RN )"
> >>
> 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 NAT-punching and yet
lowers
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.) o
> 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 a user of RSOS, give
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.
The
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 pa
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 =
localpart@hiddenservice.
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 sign the REVEAL value with the SR key fo
s7r writes:
> Hello,
>
> Epic work. I agree that the code enforcing commit majority was not
> making a difference in the partition attack. I also agree that the
> partition attack is (almost) useless, expensive and very noisy. An
> attacker can get the same result if, instead of a partition attac
14 matches
Mail list logo
