Re: [tor-dev] Proposal Waterfilling

Hi Florentin, Thanks for the thoughtful response! > So why is it working? I come up the following conclusion: OVH is a big enough > company not to lie with "unlimited, unmetered 100Mbits". I did not try other > big providers, but that would be likely the same result. > > Conclusion: we can ru

Re: [tor-dev] Proposal Waterfilling

> On Mar 7, 2018, at 5:12 PM, Florentin Rochet > wrote: > > Hello, > > > On 2018-03-07 14:31, Aaron Johnson wrote: >> Hello friends, >> >>> 1) The cost of IPs vs. bandwidth is definitely a function of market >>> offers. Your $500/Gbps/month seems quite expensive compared to what >>> can be f

Re: [tor-dev] Proposal Waterfilling

Sorry, that link should have been <https://my.hiformance.com/cart.php?a=add&pid=165 <https://my.hiformance.com/cart.php?a=add&pid=165>>. Best, Aaron > On Mar 7, 2018, at 4:18 PM, A. Johnson wrote: > > OVH and OVH resellers do seem to have some insane price

Re: [tor-dev] Proposal Waterfilling

OVH and OVH resellers do seem to have some insane prices. On the other end, the waterfilling assumption we were working off of was a water level of 10Mbps. A server that can sustain that seems quite cheap. In fact, a quick Google search for “cheap vps” yielded this offer of a VPS with one IPv4

Re: [tor-dev] Proposal: Merging Hidden Service Directories and Introduction Points

> FWIW, I was running a simulation of this algorithm with the first week > of July's consensuses when Isis posted the following way smarter > algorithm: > >> A better algorithm would be a Consistent Hashring, modified to dynamically >> allocate replications in proportion to fraction of total bandw

Re: [tor-dev] Proposal: Merging Hidden Service Directories and Introduction Points

> 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 Introduction Points the same a

Re: [tor-dev] Proposal 246: Defending Against Guard Discovery Attacks using Vanguards

>> Here's another crazy idea that would potentially bring this Vanguards >> idea closer to "Virtual Circuits": What if you divided your third-level >> Vanguards into NUM_SECOND_GUARDS isolated buckets, and mapped exactly >> one these buckets to each of your second-level guards? ... >> That way, i

Re: [tor-dev] Draft of proposal "Direct Onion Services: Fast-but-not-hidden services"

FYI, I have been collecting the proposed names at . I also just added two suggestions that haven’t been on this thread: “flagrant onion service” and “open onion service”. Thanks for Alec Muffett for the former. Apo

Re: [tor-dev] Draft of proposal "Direct Onion Services: Fast-but-not-hidden services"

> I think new users might not appreciate the difference between similarly named > terms and then choose the wrong one to their detriment. It seems better that > they should later learn of shared technology that's not clear from the naming > differences than be surprised by differences in securi

Re: [tor-dev] Draft of proposal "Direct Onion Services: Fast-but-not-hidden services"

> The problem with "fast", "direct", and maybe "bare" is that they > describe some property we're trying to provide with these. Like > hidden, I think the chance that they will evolve or be applied in some > way for which these terms won't apply is too great. I disagree in general. Hidden service

Re: [tor-dev] Draft of proposal "Direct Onion Services: Fast-but-not-hidden services"

> Following on Aaron's suggestion, and further pushing my own wee agenda, > what about PS? it works because even if someone confused the acronym for > something else, it still works. And it matches well with HS/OS. > - Public (Onion) Service > - Peeled (Onion) Service > - Pseudo (Onion) Service <--

Re: [tor-dev] Draft of proposal "Direct Onion Services: Fast-but-not-hidden services"

>> >> Why not simply "onion service"? > > Because we have already started using "onion service" to cover what we > previously called "hidden services” Right. > My latest thinking about the terminology is that we should call them > something like "client side onion service" (CSOS, suggested > pr

Re: [tor-dev] Draft of proposal "Direct Onion Services: Fast-but-not-hidden services"

> I've been hesitant to weigh in on the naming conversation for hidden > services. But I am concerned about the issues raised in the previous few > emails on the topic. > > Matt @ Speak Freely has a strong point about acronym collisions - they only > serve to confuse users and dilute the search

Re: [tor-dev] Tor Browser 4.5a5 will change circuit expiry to 2hrs

>> Would you still set a max lifetime for a circuit to accept new streams of 2 >> hours, or would the circuit potentially persist forever? > > Nick set a max lifetime in his updated version of the patch that also > deals with non-Tor Browser activity, but I am not convinced that a max > is a grea

Re: [tor-dev] Tor Browser 4.5a5 will change circuit expiry to 2hrs

Hi Mike, Would you still set a max lifetime for a circuit to accept new streams of 2 hours, or would the circuit potentially persist forever? Security losses that such a change would result in (some of which you mention) include: 1. Making it easier for an exit to profile the user because it

Re: [tor-dev] Two protocols to measure relay-sensitive hidden-service statistics

magnitude he set for that HSDir. Does this just kill this whole idea? Maybe true aggregation is the only thing that can work. Sorry! Aaron > On Feb 18, 2015, at 10:42 AM, George Kadianakis wrote: > > "A. Johnson" writes: > >> Hello tor-dev, >> >>

Re: [tor-dev] Using Traceroute for AS-Path prediction

Hello Simon, > I am a student at the saarland university and currently workin on my bachelor > thesis concerning AS-path prediction using traceroute. > I want to correlate open-source BGP data and corresponding traceroute > measurements. In the end I want to argue whether or not traceroute > can

Re: [tor-dev] A proposal to change hidden service terminology

>> It is interesting that you raise this, because we at I2P have been >> thinking the same thing. We discussed the issue of I2P terminology at >> 31C3 and decided that after 12 years of Tor/I2P coexistence, Tor had >> the upper hand with regard to commonplace terminology. >> >> In our next release

Re: [tor-dev] A proposal to change hidden service terminology

and can make an intentional choice now. And for some things, words just didn’t even exist. Best, Aaron > On Feb 10, 2015, at 2:22 PM, Adam Shostack wrote: > > On Tue, Feb 10, 2015 at 01:13:26PM -0500, A. Johnson wrote: > | Hello all, > | > | Several of us [0] working on hi

Re: [tor-dev] A proposal to change hidden service terminology

/Terminology > On Feb 10, 2015, at 2:11 PM, Paul Syverson wrote: > > On Tue, Feb 10, 2015 at 01:41:35PM -0500, Roger Dingledine wrote: >> On Tue, Feb 10, 2015 at 01:13:26PM -0500, A. Johnson wrote: >>> 1. '''onion service''' should be p

[tor-dev] A proposal to change hidden service terminology

Hello all, Several of us [0] working on hidden services have been talking about adopting better terminology. Some of the problems with current terms are 1. '''Hidden''' and '''Dark''' have a negative connotations. 2. '''Hidden-service website''' is too long; '''hidden site''' is t

Re: [tor-dev] Discussion on further hidden service statistics

Hi George, I’m glad you’re putting serious thought into these stats. I’ll give you my perspective on some of the issues you raise. > I will now enumerate the stats that Aaron considers interesting and > low-hanging-fruit: I should mention that all of these came out of a list that came out of Ro

Re: [tor-dev] Two protocols to measure relay-sensitive hidden-service statistics

> I am beginning to think that AnonStats2 is not secure enough to use. But I have come up with a possible replacement. Let’s call it AnonStats3. AnonStats3 works in conjunction with AnonStats1. It provides a rough estimate of the statistic that probably is most useful as a sanity check on AnonSt

Re: [tor-dev] Two protocols to measure relay-sensitive hidden-service statistics

>> AnonStats1 doesn’t leak the relay identity. The relay probability is sent >> over a separate circuit (at a random time). I intentionally did that just to >> avoid the problem you describe. >> > > Ah, I see, that makes sense. > > Some more notes from reading AnonStats1 then: > > a) How do r

Re: [tor-dev] Two protocols to measure relay-sensitive hidden-service statistics

Hi George, Thanks for the really thoughtful comments. >> Two HS statistics that we (i.e. people working on Sponsor R) are interested >> in collecting are: >> 1. The number of descriptor fetches received by a hidden-service directory >> (HSDir) >> 2. The number of client introduction requests

Re: [tor-dev] Two protocols to measure relay-sensitive hidden-service statistics

> I think that there are some details to work out, but the general > approach you describe sounds reasonable. IMO it doesn't need to be > directory authorities who are StatsAuths, and we could use a "blinded > token once per relay per period" scheme for other stuff too down the > line. I wonder w

[tor-dev] Two protocols to measure relay-sensitive hidden-service statistics

Hello tor-dev, While helping design ways to publish statistics about hidden services in a privacy-preserving manner, it has become clear to me that certain statistics cannot be safely reported using the current method of having each relay collect and report measurements. I am going to describe

Re: [tor-dev] Internet-wide scanning for bridges

There are even better solutions than this: 1. Port knocking: 2. Single-packet authorization: ScrambleSuit has implemented something like #2, and its paper (http://www.cs.kau.se/phil

Re: [tor-dev] Proposal draft: Better hidden service stats from Tor relays

> Can you be more explicit with regard to privacy guarantees of the > obfuscation schema that is currently implemented: 1) binning, 2) add > Laplace noise, 3) no second binning. I’ll discuss this in terms of attacks on the stats of the number of HS descriptors. Binning: Suppose an adversary know

Re: [tor-dev] Proposal draft: Better hidden service stats from Tor relays

> But I don't see the value of binning the result once more. In a > sense, we're already binning signal + noise by cutting off the float > part. I don't see what we gain by reducing resolution even more. It > seems just unnecessary. In principle releasing the number could result in different d

Re: [tor-dev] Proposal draft: Better hidden service stats from Tor relays

> This indeed seems plausible under the powerful assumption that the > underlying stat is constant. Actually it applies to any known relative pattern, for example, that the number increases by 1 each time. > where the additive noise is applied to the center of the first bin? Yes, you can look a

Re: [tor-dev] Proposal draft: Better hidden service stats from Tor relays

Hi George, I recommend a change to the way that these statistics are obfuscated. The problem is that new noise is used every day, and from the distribution of the reported bins, the exact location within the bin (assuming the stat stats constant) can be reported. So instead of this >

Re: [tor-dev] Feedback on obfuscating hidden-service statistics

> The next problem is how to find the proper parameters for the Laplace > distribution. I guess the mean μ needs to be 0, but the hard part is > 'b'. In a few papers I read, they set 'b' to (Δf/ε). > > In the above, Δf is the "largest change a single participant could > have on the output" of the

Re: [tor-dev] Feedback on obfuscating hidden-service statistics

pdf> On Nov 25, 2014, at 5:14 PM, A. Johnson wrote: > Hi George, > >> I posted an initial draft of the proposal here: >> https://lists.torproject.org/pipermail/tor-dev/2014-November/007863.html >> Any feedback would be awesome. > > OK, I’ll have a chance

Re: [tor-dev] Potential projects for SponsorR (Hidden Services)

I agree as well and have discussed this use case with NRL colleagues for a while now. Some thoughts that we have had: 1. “Encrypted service” is a terrible name because it sounds like its only providing encryption and also is too generic. The idea needs a name that communicates that it is diffe

Re: [tor-dev] Feedback on obfuscating hidden-service statistics

Hi George, > I posted an initial draft of the proposal here: > https://lists.torproject.org/pipermail/tor-dev/2014-November/007863.html > Any feedback would be awesome. OK, I’ll have a chance to look at this in the next few days. > Specifically, I would be interested in undertanding the concept

Re: [tor-dev] Feedback on obfuscating hidden-service statistics

> Roger's branch was a PoC that wrote stats on the log file. I don't > think we have newer data than what is in #13192. It's unclear whether > the relays stopped collecting statistics, or they just haven't updated > the trac ticket. If we could check on that and get that data, that would be really

Re: [tor-dev] Feedback on obfuscating hidden-service statistics

out a branch for stats collection and get it generating data within a week. It’s pretty pathetic if we can’t do better ;-) Cheers, Aaron On Nov 20, 2014, at 9:49 PM, Karsten Loesing wrote: > On 20/11/14 13:42, George Kadianakis wrote: >> "A. Johnson" writes: >> >>

Re: [tor-dev] Defending against guard discovery attacks by pinning middle nodes

>> As I was saying above, a fixed exit would allow compromise in the time >> it takes to begin surveillance (times three). We can likely do better >> than that. > > Ok, this was my assumption behind arguing for staggering these rotation > periods, too. I don't think that having a fixed exit is a g

Re: [tor-dev] Defending against guard discovery attacks by pinning middle nodes

> It's interesting to reduce the HS path length, but that would reduce > the length of the chain that the adversary has to walk, which is bad :/ Yeah, security in this attack model pushes towards a long path. > The rendezvous model is a bit restricting isn't it :( Agreed, modifying path selectio

Re: [tor-dev] Defending against guard discovery attacks by pinning middle nodes

speeds, instead of making it fragile to the possibility that your rotation speed is *just* slower than what would have stymied the adversary. Aaron On Nov 11, 2014, at 7:22 PM, A. Johnson wrote: > >> HS -> Guard_1 -> Guard_2 -> Guard_3 -> RP. >> >> The idea is t

Re: [tor-dev] Defending against guard discovery attacks by pinning middle nodes

> HS -> Guard_1 -> Guard_2 -> Guard_3 -> RP. > > The idea is that Guard_1 is a single node that you choose and keep for > O(6 months, or as long as possible), but Guard_2 actually comes from a > set of 3-6 or so nodes that you keep for O(weeks), and Guard_3 you > rotate something like O(hours). .

Re: [tor-dev] Defending against guard discovery attacks by pinning middle nodes

>> The idea would be that Guard_3 would rotate on the order of hours, >> Guard_2 would come from a set that is rotated on the order of days >> (based on the expected duration for the adversary to become Guard_3), and >> Guard_1 would rotate on the order of months (based on the expected >> duration

Re: [tor-dev] Defending against guard discovery attacks by pinning middle nodes

>> And yes again. In this model, an ultra-mega-secret HS should use a >> long chain of guards. Of course, at some point, it is easier to do a >> congestion attack to identify the first guard being used by the HS. >> That is still a win, though, in that such an attack takes more >> technical skill

Re: [tor-dev] [tor-internal] HS attack blog post (was Re: Hidden services and drug markets takedown)

I think the option to rate-limit guard selection is a great idea to defend against guard DoS. The downside is possible connection loss even if you’re not under attack and you just happen to pick flaky guards. In case you’re interested, I examined this defense and how often such benign service lo

Re: [tor-dev] Defending against guard discovery attacks by pinning middle nodes

> It seems to me that we want to defend against (at least) two different > attacks here: > > Sybil attack: ... > Coercion attack: Yes, I also am currently thinking about the problem in this way. > Unfortunately, it doesn't really make sense to add two '5 day > guards' in a circuit, since a Syb

Re: [tor-dev] Defending against guard discovery attacks by pinning middle nodes

> As I've suggested before, I really really think you should also analyze > an I2P-like scheme where HSs try really hard to maintain path > persistence to their RPs for some fixed time period on the order of an > hour (but which can be parameterized and analyzed to give the expected > time for guar