(Thread forked from [tor-dev] Notes from the prop224 proposal reading group)
> On Mar 17, 2016, at 7:29 PM, George Kadianakis wrote:
>
> Also, please see my torspec branch `prop224-fixes` for some torspec changes
> on prop224.
> My branch is sitting on top of the prop224 branch of special/dgoul
> On Mar 28, 2016, at 9:44 PM, David Goulet wrote:
>
> On 24 Mar (16:55:57), George Kadianakis wrote:
>>
>>
>> First of all, the UPDATE-KEYS-SUBCMD mechanism does not actually prevent
>> replay
>> attacks at all. It's a performance feature. It's there so that if the HS
>> rotates its replay c
> On Jan 16, 2016, at 4:52 AM, George Kadianakis wrote:
>
> Yes, I think I agree with this evaluation for now. Seems prop246 is more
> complicated than we can handle, and we should probably postpone it, except if
> someone can analyze it well soon.
I agree. There are too many open questions wit
tordev...@safe-mail.net wrote:
>> The final circuit looks like:
>>
>> Client -> Guard -> Middle -> Middle -> Single Onion
>>
>> The client’s traffic is encrypted through to the single onion server as
>> well.
>
> IMO, the second Middle relay can be considered serving as an exit with
> regards t
Yawning Angel wrote:
> I have two objections to this, one political, one technical:
>
> * (The political objection) While this is "cool" and probably(?)
> "funded", it seems like a poor thing to work on in terms of
> developmental priority when there are other things Hidden Service
> relat
tordev...@safe-mail.net wrote:
> Doesn't your proposal imply that you are turning all relays into
> exit-nodes lite? The last relay in the path will know what service you are
> connecting to (at least if that service is hosted with a unique relay),
> right?
A single onion service operates its own
-
Filename: xxx-single-onion.txt
Title: Single Onion Services
Author: John Brooks, Paul Syverson, Roger Dingledine
Created: 2015-07-13
Status: Draft
1. Overview
Single onion services are a modified form of onion services, which
trade
service-side location privacy for improved performance
A. Johnson wrote:
>> This proposal doubles the default number of IPs and reduces the “cost"
>> of being an IP since the probability of being selected is no longer
>> bandwidth-weighted. Is this a fair tradeoff for the performance
>> improvement?
>
> That seems easy to fix. Make the number of Int
Nicholas Hopper wrote:
> On Sun, Jul 12, 2015 at 4:48 PM, John Brooks
> wrote:
>> Comments are encouraged, especially if there are downsides or side
>> effects
>> that we haven’t written about yet, or that you have a different opinion
>> on.
>> The intent is
teor wrote:
>
>> On 13 Jul 2015, at 07:48 , John Brooks
>> wrote:
>
>> 4.2. Restriction on the number of intro points and impact on load
>> balancing
>>
>> One drawback of this proposal is that the number of introduction points
>> o
/torspec/224-no-hsdir/proposals/ideas/xxx-merge-hsdir-and-intro.txt
Thanks!
- John
Filename: xxx-merge-hsdir-and-intro.txt
Title: Merging Hidden Service Directories and Introduction Points
Author: John Brooks, George Kadianakis
Created: 2015-07-12
1. Overview and Motivation
This document
Michael Rogers wrote:
> Something like this was suggested last May, and a concern was raised
> about a malicious IP repeatedly killing the long-term circuit in order
> to cause the HS to rebuild it. If the HS were ever to rebuild the
> circuit through a malicious middle node, the adversary would l
It occurred to me that with proposal 224, there’s no longer a clear reason
to use both HSDirs and introduction points. I think we could select the IP
in the same way that we plan to select HSDirs, and bypass needing
descriptors entirely.
Imagine that we select a set of IPs for a service using the
Proposal 227 added a method for putting non-little-t-tor package versions
and digests in the consensus, intended to authenticate Tor Browser updates.
This is done in tor 0.2.6, although it’s not yet in use by Tor Browser or
the consensus.
I propose using this feature to notify Ricochet[1] users of
ke and there
> is no problem in having lots of them. People are wondering how well
> these applications scale and whether they are using the Tor network
> the right way. See John Brooks' mail for a small analysis:
> https://moderncrypto.org/mail-archive/messaging/2014/000434.htm
On Oct 7, 2014, at 2:35 AM, Michael Rogers wrote:
> Hi all,
>
> I've been experimenting with small changes to Tor to improve the
> performance of mobile hidden services. The following patches for Tor
> and jtorctl make two performance improvements:
>
> 1. Each time the network's enabled, don't
16 matches
Mail list logo
