Re: [tor-dev] Configuring Single Onion Services

Tim Wilson-Brown - teor writes: > [ text/plain ] > Hi All, > > I'm working on proposal 260's Rendezvous Single Onion Services in #17178. > > They are faster, because they have one hop between the service and the > introduction and rendezvous points. > But this means that

Re: [tor-dev] Update on 259

Ola Bini writes: > [ text/plain ] > Hey, > >> > - OrPort vs DirPort >> > ORPort is used for regular circuits, while DirPort is used when getting >> > directory information. We need to interpret reachable stuff >> > differently depending on the purpose. >> > >> >> I'm not

Re: [tor-dev] Update on 259

George Kadianakis <desnac...@riseup.net> writes: > [ text/plain ] > Ola Bini <ob...@thoughtworks.com> writes: > >> [ text/plain ] >> Hey, >> >>> >>> >>> That's not very nice because the USED_GUARDS set that was created wh

Re: [tor-dev] Proposal 259: New Guard Selection Behaviour

Tim Wilson-Brown - teor writes: > [ text/plain ] > >> On 27 Mar 2016, at 05:42, s7r wrote: >> >> Hello, >> >> teor, asn, see comments inline. >> >> On 3/24/2016 5:00 PM, Tim Wilson-Brown - teor wrote: >> [snip] >> The proposal ignores client bootstrap. >>

Re: [tor-dev] Reviewing prop224 fixes

John Brooks <john.bro...@dereferenced.net> writes: > [ text/plain ] > (Thread forked from [tor-dev] Notes from the prop224 proposal reading group) > >> On Mar 17, 2016, at 7:29 PM, George Kadianakis <desnac...@riseup.net> wrote: >> >> Also, please see my

Re: [tor-dev] Proposal 259: New Guard Selection Behaviour

s7r writes: > [ text/plain ] > Hello, > > teor, asn, see comments inline. > > On 3/24/2016 5:00 PM, Tim Wilson-Brown - teor wrote: > [snip] [snip] >> This isn't how Tor works - it tries multiple guards simultaneously. >> (See below for details.) >> Can we rework this

[tor-dev] Notes from the prop259 proposal reading group

Hello, we had a meeting about proposal 259 "New Guard Selection Behaviour". You can see the logs here: http://meetbot.debian.net/tor-dev/2016/tor-dev.2016-03-23-15.01.log.txt Some notes: - The latest version of the proposal can be found here:

Re: [tor-dev] Proposal 259: New Guard Selection Behaviour

Tim Wilson-Brown - teor <teor2...@gmail.com> writes: > [ text/plain ] > >> On 25 Mar 2016, at 00:31, George Kadianakis <desnac...@riseup.net> wrote: >> >> Tim Wilson-Brown - teor <teor2...@gmail.com <mailto:teor2...@gmail.com>> >> writes:

Re: [tor-dev] Notes from the prop224 proposal reading group

George Kadianakis <desnac...@riseup.net> writes: > [ text/plain ] > Hello, > > so we had a meeting about the future of "Next Generation Hidden Services" aka > prop224. > It was a good meeting. > > We spent most of the time discussing the topics brought u

Re: [tor-dev] Proposal 259: New Guard Selection Behaviour

Tim Wilson-Brown - teor <teor2...@gmail.com> writes: > [ text/plain ] > >> On 24 Mar 2016, at 22:55, George Kadianakis <desnac...@riseup.net> wrote: >> >> - How exactly should directory guards work? Should the guard lists be >> initialized onl

[tor-dev] Proposal 259: New Guard Selection Behaviour

and if it's behavior is good. --- Filename: 259-guard-selection.txt Title: New Guard Selection Behaviour Author: Isis Lovecruft, George Kadianakis, [Ola Bini] Created: 2015-10-28 Status: Draft §1. Overview Tor uses entry guards to prevent an attacker who controls some fraction of the network

[tor-dev] Meeting about the new guard algorithm proposal (prop259)

Hello there, seems like the prop259 algorithm has kind of stabilized and you guys have jumped into implementation. That's great! A small problem in this process is that I'm probably the only person in Tor who understands the new algorithm right now. We could fix this by doing a small proposal

Re: [tor-dev] Meeting about the new guard algorithm proposal (prop259)

_t that has networking capabilities. Cheers! > The proposal implementation currently manipulate lists of entry_guard_t > but when we need to call functions in existing tor code > (node_sl_choose_by_bandwidth) we need to convert from guard do node, > using node_get_by_id(). > > As a c

Re: [tor-dev] Notes from the prop224 proposal reading group

George Kadianakis <desnac...@riseup.net> writes: > [ text/plain ] > Hello, > > so we had a meeting about the future of "Next Generation Hidden Services" aka > prop224. > It was a good meeting. > Also, please see my torspec branch `prop224-fixes` for some t

Re: [tor-dev] Meeting about the new guard algorithm proposal (prop259)

Reinaldo de Souza Jr writes: > [ text/plain ] > Thank you. > > Another thing I'm interested in is how the proposed algorithm structure > fits into current tor code. The proposed algorithm is: > > OPEN_CIRCUIT: > context = ALGO_CHOOSE_ENTRY_GUARD_START(...) >

Re: [tor-dev] Next version of the algorithm

Ola Bini <ob...@thoughtworks.com> writes: > Hi, Here are some more comments to the latest version of the proposal, as seen here: https://github.com/twstrike/torspec > Filename: 259-guard-selection.txt > Title: New Guard Selection Behaviour > Author: Isis Lovecruft, George Kad

Re: [tor-dev] Support for mix integration research

Katharina Kohls writes: > Hi everyone, > > we are a team of 4 PHD students in the field of IT security, working at > the Ruhr-University Bochum at the chair for systems security and the > information security group. > > Currently we work on a research project with the

Re: [tor-dev] Next version of the algorithm

Reinaldo de Souza Jr <rjun...@thoughtworks.com> writes: > On 2/16/16 12:20, George Kadianakis wrote: >> The >> very latest prop259 basically forgets the unreachable guard status as soon as >> the algorithm terminates. I wonder if we actually want this. Hopefully >

Re: [tor-dev] Next version of the algorithm

Ola Bini writes: > Hey, > >> >> Returning to this for a bit. I think it would be good to decide whether we >> should keep the unreachable status of guards on permannet disk state or >> not. The >> very latest prop259 basically forgets the unreachable guard status as soon

Re: [tor-dev] Prop259 simulator and results

Reinaldo Junior <rjun...@thoughtworks.com> writes: > imentinOn Wed, Feb 17, 2016 at 8:29 AM, George Kadianakis < > desnac...@riseup.net> wrote: > >> Hello there, >> >> I'm not sure what kind of statistics we get out of the current guard >> simul

Re: [tor-dev] Prop259 simulator and results

Reinaldo Junior writes: > - number of guards we tried until the first successful circuit > - time until the first successful circuit is built > > A successful circuit is one which we succeeded to find a guard using the > algorithm AND we succeeded to connect to it. > >

[tor-dev] Prop259 simulator and results

Hello there, I'm not sure what kind of statistics we get out of the current guard simulator. In general, we are interested in security and performance. For security we are trying to minimize our exposure to network. For performance, we want to minimize our downtime when our current guard becomes

Re: [tor-dev] Next version of the algorithm

> Hi there, > > > > > > > ALGO_CHOOSE_ENTRY_GUARD keeps track of unreachable status for guards in state > private to the algorithm - this

Re: [tor-dev] Next version of the algorithm

Ola Bini writes: > Hi George, > > Sorry I've been slow to answer and send more info - was spending all > day Saturday and Sunday, and this week I'll be in all day meetings. > > Anyway, just to avoid confusion - After getting the algorithm to the > latest stage you saw

Re: [tor-dev] Next version of the algorithm

ve an updated document here- > https://github.com/twstrike/tor_guardsim/blob/develop/original_algorithm.md > > Looking forward to seeing what you think! > Chelsea > > On Mon, Feb 15, 2016 at 10:15 AM, George Kadianakis <desnac...@riseup.net> > wrote: > >> Ola Bini

Re: [tor-dev] Next version of the algorithm

Ola Bini writes: > Hi again, > > Here is the newest version of the algorithm: > https://gist.github.com/olabini/343da01de8e01491bf5c > Thanks! Looks better! I think we are reaching the point that we need good simulations and actually running and stepping through the

Re: [tor-dev] Existing Tor Guard Selection Algorithm

Reinaldo Junior <rjun...@thoughtworks.com> writes: > On Thu, Feb 11, 2016 at 7:55 AM, George Kadianakis <desnac...@riseup.net> > wrote: > >> Chelsea Komlo <cko...@thoughtworks.com> writes: >> >> > Hi George, >> > >> > Th

Re: [tor-dev] Existing Tor Guard Selection Algorithm

Chelsea Komlo writes: > Hi George, > > Thanks for your help with this! > > We wrote up our high-level understanding of the current Tor guard selection > algorithm here: > > https://gist.github.com/chelseakomlo/2acbe15314b5a809c6f4 > > This has more than our python

Re: [tor-dev] Entry guards, primary guards, dir guards

Ola Bini writes: > Hi, > >> So maybe the simple answer here is that if prop247 is enabled (this could be >> a >> NumGuards=N argument to our algorithm), instead of always returning the first >> reachable guard, we instead build a list of the first N reachable guards, and

Re: [tor-dev] Next version of the algorithm

Ola Bini writes: > Hi, > > Here is the next version of the algorithm - put it in a gist to make > it easier to look at: > https://gist.github.com/olabini/343da01de8e01491bf5c > > Cheers Thanks for this. Here we go with another review! > The full algorithm is referred

Re: [tor-dev] Entry guards, primary guards, dir guards

Ola Bini writes: > Hey, > > Maybe I misunderstood the hard part - I thought the problem was to > choose the NUM longlived vanguards - since there are only ever NUM > possible guards at each level, not to choose which one to use among > the NUM guards. For the first, it

Re: [tor-dev] Detailed algorithm

Ola Bini writes: > OK, with your feedback and thinking a bit more about it, here is a > revision of the algorithm from yesterday. I think we are starting to > get close so we will rip out the original simulation code and > implement something that matches this now.

Re: [tor-dev] Entry guards, primary guards, dir guards

Ola Bini writes: > Hi again, > > Two questions - first, hopefully I simple one. What are directory > guards, exactly? > > Second, we found a weird behavior in the current code > base. Specifically, when Tor first downloads the microdescriptors, it > chooses 3 guards for

Re: [tor-dev] Entry guards, primary guards, dir guards

Ola Bini writes: > Hey, > > Thanks- this is very helpful. > > When it comes to vanguards, I've already read through the > proposal. I'm not exactly sure I understand how much different 259 > would need to be to support the 247 needs. It seems we should be able > to just

Re: [tor-dev] Detailed algorithm

> Hey, > > So - thinking through your comments and thoughts, I realized that the > better way to proceed was to describe the algorithm, and then put it > into a proposal format. The following is updated with most of your > comments and should be a bit clearer. I decided to remove #241 again, >

Re: [tor-dev] Guards selection - current algorithm simulation

Iván Pazmiño <ipazm...@thoughtworks.com> writes: > Hello, thanks for your reply. > > On 02/04/2016 04:28 PM, George Kadianakis wrote: >> We don't actually and it's a pity because it would have been very useful for >> this particular case indeed. > We wi

Re: [tor-dev] Hashring understanding

Ola Bini writes: > Hi, > > Sorry for the string of emails! > > Hopefully a simple question: > The current proposal contains logic for keeping track of network > up/down and setting timeouts for exponential backoff to test the > network again. But if I understand

Re: [tor-dev] Hashring understanding

Spencer <spencer...@openmailbox.org> writes: > Hi, > >> >> George Kadianakis: >> Indeed. [The randomly selected guards] > are saved in the state file. Check: >> https://lists.torproject.org/pipermail/tor-dev/2016-February/010355.html >> also see

Re: [tor-dev] Guards selection - current algorithm simulation

Iván Pazmiño writes: > Hey guys, > > Just wondering if by any chance you have a simulator for the current > algorithm to select guards. It would be very useful to compare against > new algorithm's numbers. > > Thanks, Hello, We don't actually and it's a pity because

Re: [tor-dev] Hashring understanding

Ola Bini writes: > Hi, > > Sorry for this - had some questions about the hashring component of > #259 that I haven't been able to figure out myself. I'm sure it's just > me being unused to the Tor code base and how you write your proposals, > but it would be super helpful

Re: [tor-dev] Hashring understanding

Ola Bini writes: > Hi, > >> I think it's fine to use randomness to generate it for now; that's what tor >> also currently does [0]. > Cool - we have a local clone of the specs and updating it with this > understanding. > Great! For better or worse I think making design

Re: [tor-dev] Hashring understanding

Ola Bini writes: > Hi, > > Thanks for the confirmation of our understanding! Very helpful. > > If I understand things correctly, we are supposed to take > GUARDLIST_FAILOVER_THRESHOLD guards from the list of all guards and > generate the GUARDLIST from that. Is that

Re: [tor-dev] Getting people started on guard selection algorithms [prop259]

> On Tue, Feb 02, 2016 at 02:29:22PM -0500, Ola Bini wrote: >> Hi, >> >> We have now started looking at the proposal and the existing code. Our >> current plan is to first of all code more of the simulations referred >> to in stuff-to-test.txt. We also noticed that the hashring >> implementation

[tor-dev] Notes from 3rd Tor proposal reading group [prop250]

Hello there, yesterday we held another reading group on #tor-dev to discuss proposal 250 (Random Number Generation During Tor Voting). You can find the logs here: http://meetbot.debian.net/tor-dev/2016/tor-dev.2016-01-26-15.58.log.html Here are some code and spec changes that we need to do

[tor-dev] Getting people started on guard selection algorithms [prop259]

Hello Nick, isis and Mike! It seems like some Thoughtworks folks (from here on referred to as FRITO [0]) are interested in helping us with Tor hidden services development for 4 weeks or so. They start early next week! :) They were looking for a coding project that is tractable within a month

Re: [tor-dev] Proposals should have reviews. Let's make sure that happens. Here's a schedule.

Nick Mathewson writes: > So, one of the longstanding problems with Tor's (change) proposal > system has been that proposals sit around for a long time without > sufficient discussion or approval. When they're about to be > implemented, we do an informal "hey did anybody

Re: [tor-dev] Proposal 247: Alternate Path Lengths

Mike Perry <mikepe...@torproject.org> writes: > George Kadianakis: > > Mike Perry writes: > > > > > > > > I have mixed feelings about this. > > > > - If client guard discovery is the main reason we are doing this, I think > > we &

Re: [tor-dev] Proposal 247: Alternate Path Lengths

Mike Perry <mikepe...@torproject.org> writes: > George Kadianakis: >> Mike Perry <mikepe...@torproject.org> writes: >> >> > George Kadianakis: >> > > I have mixed feelings about this. >> > > >> > > - If client guard discover

Re: [tor-dev] Proposal 247: Alternate Path Lengths

Mike Perry writes: > While discussing proposal 247 with George yesterday, we realized that we > still get security benefit from additional ephemeral hops beyond the > vanguards themselves. > > Recall the high-level 247 path design is: > > C - L - M - S -- S - M - L -

[tor-dev] Notes from 1st Tor proposal reading group [prop241, prop247, prop259]

Today was the first Tor proposal reading group [0] and we discussed the following guard proposals: Prop#241: Resisting guard-turnover attacks [DRAFT] Prop#259: New Guard Selection Behaviour [DRAFT] Prop#247: Defending Against Guard Discovery Attacks using Vanguards [DRAFT]

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

Mike Perry <mikepe...@torproject.org> writes: > George Kadianakis: >> Hello there, >> >> we recently finished implementing proposal 250 which is one of the first >> steps >> for the upcoming hidden service redesign [1]. The next steps are implementing &g

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

n the list. > Hm, maybe. But with increased migration and engineering costs. >> On 14 Jan 2016, at 03:50, George Kadianakis <desnac...@riseup.net> wrote: >> >> Hello there, >> ... >> Here are some issues that make this proposal not an obvious

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

Hello there, we recently finished implementing proposal 250 which is one of the first steps for the upcoming hidden service redesign [1]. The next steps are implementing proposal 224 and the other performance and security proposals [2]. On this note, one of the open design issues that we need to

[tor-dev] Needs Code Review: Shared Randomness Generation for Tor

Hello there, we are happy to tell you that we finished coding proposal 250 and our first attempt at implementation is ready for review. You can find the final specification here: https://gitweb.torproject.org/user/dgoulet/torspec.git/log/?h=prop250_final_v1 and the corresponding code here:

Re: [tor-dev] Bitcoin-paid hidden meek relays?

Jacek Wielemborek writes: > List, > > I'm starting this thread in relation to the following discussion: > > https://security.stackexchange.com/questions/107490/how-will-france-block-tor > > I definitely don't have a perfect knowledge of Tor, so correct me if I'm > wrong at any

[tor-dev] Hidden service patch workshop on #tor-dev IRC channel (17/12/2015)

Dear tor-dev, Everyone who is working on any kind of improvement to hidden services or related applications and would like to give or receive assistance (code reviews, advice, etc.) is welcome on: Thursday December 17, 16:00 UTC @ #tor-dev OFTC channel This might become a regular biweekly

Re: [tor-dev] Scaling Tor Metrics

Karsten Loesing writes: > Hello devs, > > the Tor Metrics website [0] claims to be "the primary place to learn > > > > 2.2 Link to external websites > > Somebody might write a website that visualizes Tor network data. The > Tor Metrics team reviews the idea behind it,

Re: [tor-dev] Shared random value calculation edge cases (proposal 250)

Tim Wilson-Brown - teor writes: >> On 21 Nov 2015, at 04:14, Michael Rogers wrote: >> >> On 20/11/15 16:24, David Goulet wrote: >>># Consensus >>>(This goes for both previous and current SRV) >>>if SRV in consensus: >>>dirauth

Re: [tor-dev] Shared random value calculation edge cases (proposal 250)

s7r writes: > Hello, > > > > The idea of adding flags in the votes so each dirauth can advertise if > it is participating (has an opinion for the SR or not) is > great and helps us build more defenses, probably make it easier in the > future too if we decide to change

Re: [tor-dev] Shared random value calculation edge cases (proposal 250)

David Goulet <dgou...@ev0ke.net> writes: > On 19 Nov (14:30:47), Jacob Appelbaum wrote: >> Hi George, >> >> On 11/12/15, George Kadianakis <desnac...@riseup.net> wrote: >> > Hello there believers of prop250, >> > >> > you can fi

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

Tim Wilson-Brown - teor writes: > Hi All, > > prop224 salts the encrypted portion of each descriptor with a random value. > If we use the same "salt" for every replica/spread, the encrypted portions of > the descriptor will be identical. > (In the spec, it looks like the

Re: [tor-dev] Shared random value calculation edge cases (proposal 250)

s7r writes: > Hello, > > Saw the content of this section in master was corrected, yet the > subtitle is little confusing: > > 4.1.6. Including the ed25519 shared randomness key in votes [SRKEY] > > From the content of this section I understand that we are going to > include the

Re: [tor-dev] Weird interactions between TBB and Hidden Services upon HS kill/restart

Alec Muffett writes: > For the sake of documentation I thought I would share this here: > > I have a (test) Hidden Service, running vanilla tor 0.2.6.10 > > > > The TBB logfile contains the following sequence, pertinent to the second > connection attempt: > > start >

[tor-dev] Shared random value calculation edge cases (proposal 250)

Hello there believers of prop250, you can find the latest version of the proposal in the upstream torpec repo: https://gitweb.torproject.org/torspec.git/tree/proposals/250-commit-reveal-consensus.txt Implementation is also constantly moving forward as you can see in the ticket:

[tor-dev] Hidden service patch workshop on #tor-dev IRC channel

Dear tor-dev, Everyone who is working on any kind of improvement to hidden services or related applications and would like to give or receive assistance (code reviews, advice, etc.) is welcome on: Thursday November 12, 16:00 UTC @ #tor-dev OFTC channel This might become a regular biweekly

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

George Kadianakis <desnac...@riseup.net> writes: > s7r <s...@sky-ip.org> writes: > >> Hello, >> >> >> >> 4.1.1. Computing commitments and reveals [COMMITREVEAL] >> "The value REVEAL is computed as follows: >> >> REVEAL

[tor-dev] Special handling of .onion domains in Chrome/Firefox (post-IETF-standarization)

Hello, as you might know, the IETF recently decided to formally recognize .onion names as special-use domain names [0]. This means that normal browsers like Chrome and Firefox can now handle onion domains in a special manner since they know that they only correspond to Tor. How would we like

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

Jesse V writes: > David, > > I'm in the midst of reworking my OnioNS design around prop250 (and the > security > analysis therein) and as far as I can tell these changes make sense. I like > the > 00:00 -> 24:00 change as it's more intuitive as you said. I was at first

Re: [tor-dev] [proposal] New Entry Guard Selection Algorithm

ection Behaviour > Author: Isis Lovecruft, George Kadianakis Thanks for adding me as a co-author! Would also be great if you could link to my original post for reference: https://lists.torproject.org/pipermail/tor-dev/2015-August/009328.html > Created: 2015-10-28 > Status: Draft > Exten

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

teor writes: >> On 29 Oct 2015, at 05:26, David Goulet wrote: >> >> Finally, we would like your opinion also on if we should keep the >> conflict mechanism or not?. Since those partition attacks are basically >> dumb, do not achive much result for an

Re: [tor-dev] Load Balancing in 2.7 series - incompatible with OnionBalance ?

Alec Muffett writes: > typo: > >> alecm: and this persists for up to 24h, even though the outage was only 10 >> minutes > > Also, I neglected to observe that linear polling of A-E seeking a descriptor > suggests A will be hammered whilst J is nearly idle. > > Some entropy in IP

Re: [tor-dev] Proposal: Load-balancing hidden services by splitting introduction from rendezvous

Tom van der Woerdt writes: > Op 04/10/15 om 06:46 schreef Tim Wilson-Brown - teor: >> >>> On 3 Oct 2015, at 13:34, Tom van der Woerdt >> > wrote: >>> ... >>> 3. Compatibility and security >>> >>> The implementation of these methods should,

[tor-dev] Status of Open Hidden Service Proposals (October 2015)

Greetings, it's well known that hidden services need some love: https://blog.torproject.org/blog/hidden-services-need-some-love For the past 2 years we've been busy designing the upcoming hidden service protocol with improved cryptography, security, and performance. During this time we've

Re: [tor-dev] Trac priorities and severities

David Goulet writes: > On 07 Oct (11:56:32), David Goulet wrote: >> Hello tor-dev! >> >> While 028 bug triaging, we realized that we *really* need priorities to >> not be a banana field deprive of useful meaning. If you are unaware or >> don't remember, the priority field in

Re: [tor-dev] Draft Proposal: Random Number Generation During Tor Voting

George Kadianakis <desnac...@riseup.net> writes: > Hello there, > Hello, I'm inlining the latest version of proposal250. It includes various improvements, like completely removing the need for an SR doc (which will make implementation much much easier), and switching to sig

Re: [tor-dev] Proposal 247 (Hidden Service Vanguards) Overhaul

Mike Perry writes: > Mike Perry: >> I spent some time trying to clean up proposal 247 based on everyone's >> comments, as well as based on my own thoughts. Please have a look if you >> commented on the original proposal, and complain if I've not taken your >> thoughts

Re: [tor-dev] Proposal 247 (Hidden Service Vanguards) Overhaul

Mike Perry writes: > Mike Perry: >> I spent some time trying to clean up proposal 247 based on everyone's >> comments, as well as based on my own thoughts. Please have a look if you >> commented on the original proposal, and complain if I've not taken your >> thoughts

Re: [tor-dev] [RFC] On new guard algorithms and data structures

Mike Perry <mikepe...@torproject.org> writes: > George Kadianakis: >> Hello there, >> >> recently we've been busy specifying various important improvements to entry >> guard security. For instance see proposals 250, 241 and ticket #16861. >> >> Unfor

[tor-dev] Partitioning Attacks on Prop250 (Re: Draft Proposal: Random Number Generation During Tor Voting)

Nick Mathewson writes: > On Tue, Sep 8, 2015 at 7:10 AM, David Goulet wrote: >> On 08 Sep (01:04:36), Tim Wilson-Brown - teor wrote: >>> >>> > On 7 Sep 2015, at 23:36, David Goulet wrote: >>> > ... >>> > Please review it, mostly format

Re: [tor-dev] Towards a new version of the PT spec...

Yawning Angel writes: > So, we currently have a Pluggable Transport (PT) spec, and it kind-of > sort-of works (The documentation is a mess that I'm working on > cleaning up, but it's an orthogonal issue for how well it works). > > There are a number of problems with the

Re: [tor-dev] [RFC] On new guard algorithms and data structures

s7r s...@sky-ip.org writes: Hi, Hello, thanks for the feedback! I pushed some small updates to my branch based on your comments. You can check them out here: https://gitweb.torproject.org/user/asn/tor.git/tree/src/or/guardlist.c?h=bug12595 On 8/20/2015 2:28 PM, George Kadianakis wrote

Re: [tor-dev] Number of directory connections

tordev...@safe-mail.net writes: Original Message From: Mike Perry mikepe...@torproject.org Subject: [tor-dev] Proposal: Padding for netflow record resolution reduction Date: Thu, 20 Aug 2015 21:12:54 -0700 Tor clients currently maintain one TLS connection to their Guard

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

Michael Rogers mich...@briarproject.org writes: On 12/07/15 22:48, John Brooks wrote: 1.3. Other effects on proposal 224 An adversarial introduction point is not significantly more capable than a hidden service directory under proposal 224. The differences are: 1. The

[tor-dev] [RFC] On new guard algorithms and data structures

Hello there, recently we've been busy specifying various important improvements to entry guard security. For instance see proposals 250, 241 and ticket #16861. Unfortunately, the current guard codebase is dusty and full of problems (see #12466, #12450). We believe that refactoring and cleaning

Re: [tor-dev] Hash Visualizations to Protect Against Onion Phishing

Jacek Wielemborek d33...@gmail.com writes: W dniu 20.08.2015 o 15:49, George Kadianakis pisze: Some real UX research needs to be done here, before we decide something terrible. Just curious, has anybody seen any cognitive studies on the SSH randomart visualisation? I always found them

[tor-dev] Hash Visualizations to Protect Against Onion Phishing

Hello, this mail lays down an idea for a TBB UI feature that will make it slightly harder to launch phishing attacks against hidden services. The idea is based on hash visualizations like randomart [0] and key poems: --- | o=. |

Re: [tor-dev] Draft Proposal: Random Number Generation During Tor Voting

teor teor2...@gmail.com writes: Another implementation note on directory caching of the SR doc: I just noticed the following code in update_consensus_networkstatus_downloads(): for (i=0; i N_CONSENSUS_FLAVORS; ++i) { /* need some way to download unknown flavors if we are

Re: [tor-dev] Draft Proposal: Random Number Generation During Tor Voting

teor teor2...@gmail.com writes: On 4 Aug 2015, at 00:03 , George Kadianakis desnac...@riseup.net wrote: … 3.1.2. Shared Random Document During Commitment Phase [SRDOCCOMMIT] … Hello, and thanks for the comments. I uploaded a new version of the proposal that addresses some of your

[tor-dev] Some statistics on introduction point stability and correctness

Hello, during the past months we have been working on evaluating and confirming the stability and correctness of Tor hidden services. The hidden services protocol has multiple steps, and its soundness depends on various components of the Tor network. Throughout this document, we assume that the

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

is greatly appreciated. Thanks! Filename: 246-hs-guard-discovery.txt Title: Defending Against Guard Discovery Attacks using Vanguards Author: George Kadianakis Created: 2015-07-10 Status: Draft 0. Motivation A guard discovery attack allow attackers to determine the guard node

Re: [tor-dev] Hidden Services and IP address changes

Martin Florian flor...@kit.edu writes: Hello everyone, I think I've found one or more bugs that appear when Tor clients hosting HSes change their IP address during operation. I'm slightly overwhelmed from reading the Tor source code and not sure how to best fix them. The central issue

Re: [tor-dev] Did GuardFraction stuff break bandwidth weights?

Karsten Loesing kars...@torproject.org writes: Hi asn, hi weasel, could it be that the recently added GuardFraction stuff broke something that led to removing the bandwidth-weights line? All the best, Karsten It does seem like this is the case. I filed a bug here:

Re: [tor-dev] (Draft) Proposal 224: Next-Generation Hidden Services in Tor

Jeff Burdges burd...@gmail.com writes: On 12 May 2015, at 10:39, Michael Rogers mich...@briarproject.org 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

Re: [tor-dev] (Draft) Proposal 224: Next-Generation Hidden Services in Tor

John Brooks john.bro...@dereferenced.net writes: 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.

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

Alec Muffett al...@fb.com writes: On Apr 10, 2015, at 1:58 PM, George Kadianakis desnac...@riseup.net wrote: Jacob H. Haven ja...@jhaven.me writes: […deletia...] Hi All, I’m actually drafting a diff regards the sorts of thing where you’re discussing nomenclature; but I am new to the Tor

[tor-dev] [PATCH] Defences against the recent hidden service DoS attacks

Hello, we recently received more reports of Denial of Service attacks on hidden services. You can find our ticket here: https://trac.torproject.org/projects/tor/ticket/16052 After some debugging, we found the attack vector and identified a few ways to fix or mitigate it. In this attack, the

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

-direct-services.txt Title: Direct Onion Services: Fast-but-not-hidden services Author: Roger Dingledine, George Kadianakis Created: 2011-01-12 Status: Draft 1. Motivation Hidden services can cover multiple use cases and threat models. They offer server-side anonymity by default because that's

[tor-dev] Should popularity-hiding be a security property of hidden services?

Hello, Tor hidden services are meant to primarily provide server anonymity but they also provide various other properties. For example, their addresses are self-authenticated and their connections punch NAT. This post is about another property, which is that Tor does not reveal the popularity of

[tor-dev] Getting visuals out of bridge bandwidth statistics

Hello, I recently discovered that bridges report detailed bandwidth histories in their extrainfo descriptors. We should think about the privacy implications of these statistics since they are quite fine grained (multiple measurements per day) and some bridges don't have many clients (hence small

Re: [tor-dev] Getting visuals out of bridge bandwidth statistics

George Kadianakis desnac...@riseup.net writes: Hello, I recently discovered that bridges report detailed bandwidth histories in their extrainfo descriptors. We should think about the privacy implications of these statistics since they are quite fine grained (multiple measurements per day

<    1   2   3   4   5   >