Re: [tor-dev] Timers in Arti?

a notification wakes up the app.) This seems like a discussion worth having once Arti settles and it's easier to build new things again! On Wed Jan 10, 2024, 11:26 AM GMT, Michael Rogers <mailto:mich...@briarproject.org> wrote: On 10/01/2024 01:46, Nick Mathewson wrote: On Tue,

Re: [tor-dev] Timers in Arti?

On 10/01/2024 01:46, Nick Mathewson wrote: On Tue, Jan 9, 2024 at 12:58 PM Micah Elizabeth Scott wrote: Ah. If you want to run an onion service you'll need to keep at least a couple circuits open continuously for the introduction points. I'm not sure where you would meaningfully find time to

Re: [tor-dev] Timers in Arti?

. -beth On 1/9/24 05:19, Michael Rogers wrote: Sorry, I should have said that we're interested in keeping a hidden service running. Without that requirement, I agree we could just close the guard connection via DisableNetwork after some idle period. So the question is about keeping circuits

Re: [tor-dev] Timers in Arti?

penalty and it's visible to anyone who can see network activity. -beth On 1/4/24 04:48, Michael Rogers wrote: Hi, If I understand right, the C implementation of Tor has various state machines that are driven by local libevent timers as well as events from the network. For example, when building

[tor-dev] Timers in Arti?

Hi, If I understand right, the C implementation of Tor has various state machines that are driven by local libevent timers as well as events from the network. For example, when building a circuit, if there hasn't been any progress for a certain amount of time then a timer fires to handle the

Re: [tor-dev] A way to connect quickly to a newly-online hidden service?

Hi Holmes, The Briar team has been working on a new app that creates a hidden service when the app is first launched. What we've found during testing is that the newly published hidden service is usually reachable in the first connection attempt (with a timeout of 2 minutes, based on Tor's

[tor-dev] Latest releases missing from changelog

Hi all, The latest releases (0.4.7.10, 0.4.6.12 and 0.4.5.14) seem to be missing from the changelog: https://gitlab.torproject.org/tpo/core/tor/-/raw/main/ChangeLog Is this file still the right place to look? Cheers, Michael OpenPGP_0x11044FD19FC527CC.asc Description: OpenPGP public key

Re: [tor-dev] Counting HS descriptor uploads

), Michael Rogers wrote: Hi, Better late than never I guess :S... The Briar team is working on a new app that uses Tor hidden services, and we're trying to work out when the server publishing a hidden service should consider the service to be reachable by clients. We've tried counting HS descriptor

Re: [tor-dev] bridge:// URI and QR codes

On 20/07/2022 18:15, Nathan Freitas wrote: On Wed, Jul 20, 2022, at 8:01 AM, meskio wrote: Quoting Torsten Grote (2022-07-19 14:54:01) On Monday, 18 July 2022 13:47:21 -03 meskio wrote: What do you think of the proposal? How can we improve it? A slightly unrelated question: Was there

[tor-dev] Bootstrapping with a very inaccurate clock

Hello again, Apologies for starting two threads in quick succession. First of all I want to say thank you for all the improvements in handling clock skew between 0.3.5 and 0.4.5. We recently migrated Briar to 0.4.5, and some situations that are common on mobile, such as the system clock

[tor-dev] Counting HS descriptor uploads

Hi, The Briar team is working on a new app that uses Tor hidden services, and we're trying to work out when the server publishing a hidden service should consider the service to be reachable by clients. We've tried counting HS descriptor uploads via control port events, but we found that

Re: [tor-dev] Onion Service Intro Point Retry Behavior

Hi David, On 29/10/2019 14:52, David Goulet wrote: > Long story short, couple weeks ago we've almost merged a new behavior on the > service side with #31561 that would have ditch an intro point if its circuit > would time out instead of retrying it. (Today, a service always retry their > intro

Re: [tor-dev] reproducible builds for Android tor daemon

Hi all, Just saw this thread while heading out the door and wanted to mention that we already have a reproducible build setup for Tor and obfs4proxy binaries for Android and Linux. The binaries are published on JCenter. Hans-Christoph, hope this shortens your path! :-)

Re: [tor-dev] Onion Service - Intropoint DoS Defenses

On 04/07/2019 12:46, George Kadianakis wrote: > David Goulet writes: >> Overall, this rate limit feature does two things: >> >> 1. Reduce the overall network load. >> >>Soaking the introduction requests at the intro point helps avoid the >>service creating pointless rendezvous circuits

Re: [tor-dev] Proposal 300: Walking Onions: Scaling and Saving Bandwidth

Argh, I'm really sorry, I thought I'd reached the end of the proposal but my questions were addressed further down. Sorry for the noise. Cheers, Michael On 05/02/2019 17:42, Michael Rogers wrote: > I'm very happy to see this proposal! Two quick questions about relay > selection: >

Re: [tor-dev] Proposal 300: Walking Onions: Scaling and Saving Bandwidth

I'm very happy to see this proposal! Two quick questions about relay selection: * Can a client specify that it wants an exit node whose policy allows something unusual, e.g. exiting to a port that's not allowed by the default policy? If not, does the client need to keep picking exit nodes until

Re: [tor-dev] Upcoming Tor change with application impact: "Dormant Mode"

Sorry, I have one more follow-up question. On 02/01/2019 21:00, Nick Mathewson wrote: > On Fri, Dec 21, 2018 at 6:34 AM Michael Rogers > wrote: >> >> Hi Nick, >> >> Is the guard connection closed when becoming dormant? > > No; it times out independently. I

Re: [tor-dev] Upcoming Tor change with application impact: "Dormant Mode"

Hi Nick, Thanks very much for the reply. Follow-ups inline below. On 02/01/2019 21:00, Nick Mathewson wrote: > On Fri, Dec 21, 2018 at 6:34 AM Michael Rogers > wrote: >> >> Hi Nick, >> >> Is the guard connection closed when becoming dormant? > > No; it t

Re: [tor-dev] Upcoming Tor change with application impact: "Dormant Mode"

Hi Nick, Is the guard connection closed when becoming dormant? On 13/12/2018 20:56, Nick Mathewson wrote: >DormantTimeoutDisabledByIdleStreams 0|1 >If true, then any open client stream (even one not reading or >writing) counts as client activity for the purpose of

Re: [tor-dev] Dealing with frequent suspends on Android

On 26/11/2018 21:46, Nick Mathewson wrote: > On Wed, Nov 21, 2018 at 5:10 PM Michael Rogers > wrote: >> >> On 20/11/2018 19:28, Nick Mathewson wrote: >>> Hi! I don't know if this will be useful or not, but I'm wondering if >>> you've seen this ticket: >&g

Re: [tor-dev] Dealing with frequent suspends on Android

On 20/11/2018 19:28, Nick Mathewson wrote: > Hi! I don't know if this will be useful or not, but I'm wondering if > you've seen this ticket: > https://trac.torproject.org/projects/tor/ticket/28335 > > The goal of this branch is to create a "dormant mode" where Tor does > not run any but the

Re: [tor-dev] Dealing with frequent suspends on Android

On 07/11/2018 09:04, teor wrote: > > >> On 7 Nov 2018, at 04:10, Michael Rogers wrote: >> >> On 06/11/2018 01:58, Roger Dingledine wrote: >>> On Tue, Nov 06, 2018 at 11:38:33AM +1000, teor wrote: >>>>> so if we could ask the guard for >&

Re: [tor-dev] Dealing with frequent suspends on Android

On 06/11/2018 01:58, Roger Dingledine wrote: > On Tue, Nov 06, 2018 at 11:38:33AM +1000, teor wrote: >>> so if we could ask the guard for >>> regular keepalives, we might be able to promise that the CPU will wake >>> once every keepalive interval, unless the guard connection's lost, in >>> which

[tor-dev] Dealing with frequent suspends on Android

Hi all, It's great to see that some children of #25500 have already been released in the 0.3.4 series. Can I ask about the longer-term plan for this work, and whether #23289 (or something similar) is part of it? The context for my question is that we're trying to reduce Briar's power

Re: [tor-dev] obfs4, meek, active probing and the timeline of pluggable transports

On 27/10/2018 12:50, Piyush Kumar Sharma wrote: > 2.) What was the motivation to bring in meek as a pluggable transport, > given the fact that obfs4 works great to cover all the existing problems > with Tor detection. Was the motivation just the fact that, it will be > much easier for the users to

Re: [tor-dev] Temporary hidden services

On 19/10/2018 16:05, Leif Ryge wrote: > On Wed, Oct 17, 2018 at 07:27:32PM +0100, Michael Rogers wrote: > [...] >> If we decided not to use the key blinding trick, and just allowed both >> parties to know the private key, do you see any attacks? > [...] > > If I'm

Re: [tor-dev] Temporary hidden services

On 19/10/2018 14:01, George Kadianakis wrote: > Michael Rogers writes: >> A given user's temporary hidden service addresses would all be related >> to each other in the sense of being derived from the same root Ed25519 >> key pair. If I understand right, the security proof

Re: [tor-dev] Temporary hidden services

On 18/10/2018 13:26, George Kadianakis wrote: > Michael Rogers writes: > >> Hi George, >> >> On 15/10/2018 19:11, George Kadianakis wrote: >>> Nick's trick seems like a reasonable way to avoid the issue with both >>> parties >>> knowing the pr

Re: [tor-dev] Temporary hidden services

Hi George, On 15/10/2018 19:11, George Kadianakis wrote: > Nick's trick seems like a reasonable way to avoid the issue with both parties > knowing the private key. Thanks! Good to know. Any thoughts about how to handle the conversion between ECDH and EdDSA keys? If we decided not to use the key

Re: [tor-dev] Temporary hidden services

On 28/09/2018 02:40, Nick Mathewson wrote: > On Thu, Sep 27, 2018 at 9:26 AM Michael Rogers > wrote: >> >> Hi all, >> >> The Briar team is working on a way for users to add each other as >> contacts by exchanging links without having to meet in person. >&g

Re: [tor-dev] Temporary hidden services

eers, Michael > To your primary question, I to would like to know > that, given the private key of an onion service, the anonymity of the > original publisher is maintained. I would guess that it is (granted > they can overwrite the descriptor and take it over and what not). > > C

[tor-dev] Temporary hidden services

Hi all, The Briar team is working on a way for users to add each other as contacts by exchanging links without having to meet in person. We don't want to include the address of the user's long-term Tor hidden service in the link, as we assume the link may be observed by an adversary, who would

Re: [tor-dev] Alternative directory format for v3 client auth

On 11/07/18 14:22, George Kadianakis wrote: > Michael Rogers writes: > >> On 10/07/18 19:58, George Kadianakis wrote: >>> here is a patch with an alternative directory format for v3 client auth >>> crypto key bookkeeping as discussed yesterday on IRC: >>&g

Re: [tor-dev] Alternative directory format for v3 client auth

On 10/07/18 19:58, George Kadianakis wrote: > here is a patch with an alternative directory format for v3 client auth > crypto key bookkeeping as discussed yesterday on IRC: >https://github.com/torproject/torspec/pull/23 > > Thanks for making me edit the spec because it made me think of

Re: [tor-dev] Proposal 286: Controller APIs for hibernation access on mobile

On 05/12/17 22:18, teor wrote: > >> On 6 Dec 2017, at 05:12, Michael Rogers <mich...@briarproject.org> wrote: >> >> If the service needs to fetch a consensus and microdescs before it can >> respond to a rendezvous cell, the delay could be far longer than the

Re: [tor-dev] Proposal 286: Controller APIs for hibernation access on mobile

On 01/12/17 12:16, teor wrote: > >> On 1 Dec 2017, at 21:56, Michael Rogers <mich...@briarproject.org> wrote: >> >>> On 30/11/17 12:55, Nick Mathewson wrote: >>> >>> When a Tor instance that is running an onion service is IDLE, it >>>

Re: [tor-dev] Proposal 286: Controller APIs for hibernation access on mobile

Hi Nick, On 30/11/17 12:55, Nick Mathewson wrote: > 2. Improvements to the hibernation model > >To present a consistent interface that applications and >controllers can use to manage power consumption, we make these >enhancements to our hibernation model. > >First, we add three

Re: [tor-dev] Action items wrt prop224 onion address encoding (was Re: Proposition: Applying an AONT to Prop224 addresses?)

On 11/04/17 11:45, George Kadianakis wrote: > We basically add the canonical onion address in the inner encrypted > layer of the descriptor, and expect the client to verify it. I made this > feature optional in case we ever decide it was a bad idea. Is the version number also included in the

Re: [tor-dev] [RFC] Proposal for the encoding of prop224 onion addresses

On 05/02/17 07:44, Taylor R Campbell wrote: >> Date: Sat, 04 Feb 2017 20:14:00 -0600 >> From: Vi Grey >> Also, should we consider including a Version option eventually in the >> ADD_ONION control port command when using a KeyBlob? It wouldn't matter >> much for this new

Re: [tor-dev] Is it safe for second_elapsed_callback() to be called less often?

On 02/12/16 16:56, Nick Mathewson wrote: > On Thu, Dec 1, 2016 at 9:54 AM, Michael Rogers <mich...@briarproject.org> > wrote: >> Hi, >> >> When running hidden services on Android I've found it's necessary to >> hold a wake lock to keep the CPU awake. Otherw

[tor-dev] Is it safe for second_elapsed_callback() to be called less often?

Hi, When running hidden services on Android I've found it's necessary to hold a wake lock to keep the CPU awake. Otherwise Tor's second_elapsed_callback() doesn't get called once per second. When the CPU eventually wakes and the callback is called, if 100 seconds or more have passed since the

Re: [tor-dev] Different trust levels using single client instance

On 21/10/16 21:38, ban...@openmailbox.org wrote: > Cons: > *Some unforeseen way malicious VM "X" can link activities of or > influence traffic of VM "Y" > **Maybe sending NEWNYM requests in a timed pattern that changes exit IPs > of VM Y's traffic, revealing they are behind the same client? >

Re: [tor-dev] [prop269] Further changes to the hybrid handshake proposal (and NTor)

On 14/10/16 22:45, isis agora lovecruft wrote: > 1. [NTOR] Inputs to HKDF-extract(SALT, SECRET) which are not secret > (e.g. server identity ID, and public keys A, X, Y) are now removed from > SECRET and instead placed in the SALT. > > Reasoning: *Only* secret data should be placed

Re: [tor-dev] Proposal 273: Exit relay pinning for web services

On 05/10/16 21:09, Philipp Winter wrote: >Web servers support ERP by advertising it in the "Tor-Exit-Pins" HTTP >header. The header contains two directives, "url" and "max-age": > > Tor-Exit-Pins: url="https://example.com/pins.txt;; max-age=2678400 > >The "url" directive points

Re: [tor-dev] stopping the censoring of tor users.

As far as I can tell, this would work, and you could do it without any changes to the Tor network. Just set up a hidden service where the service is an open proxy. It wouldn't be transparent to clients, however - they'd need to do some proxychains-style juggling to connect to their local onion

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

On 13/01/16 20:42, s7r wrote: > After prop 250, a malicious HSDir can not do so much, but a merged > HSDir + IP can for example kill the circuit and force the hidden > service to rebuild it. Under the current design, we retry for some > times and give up if an introduction point is unreliable, but

Re: [tor-dev] Fwd: Orbot roadmap feedback

On 13/01/16 16:04, Nathan Freitas wrote: > On Tue, Jan 12, 2016, at 11:52 AM, Michael Rogers wrote: >> On 12/01/16 16:16, Nathan Freitas wrote: >>> The broader idea is to determine which Tor torrc settings are relevant >>> to the mobile environment, and that coul

Re: [tor-dev] Fwd: Orbot roadmap feedback

On 12/01/16 16:16, Nathan Freitas wrote: > The broader idea is to determine which Tor torrc settings are relevant > to the mobile environment, and that could use a more intuitive user > interface than the empty text input we currently offer in our Settings > panel. This may also mean implement a

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

On 21/11/15 12:05, George Kadianakis wrote: >> If there's no consensus on a fresh SRV, why not just use the disaster >> recovery procedure? >> >> That is: >> >># Consensus >>if majority agrees on SR value(s): >>put in consensus >>else: >>put disaster recovery SR value

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

On 20/11/15 16:24, David Goulet wrote: > # Consensus > (This goes for both previous and current SRV) > if SRV in consensus: > dirauth MUST keep it even if the one they have doesn't match. > Majority has decided what should be used. > else: > dirauth MUST

Re: [tor-dev] Proposal: Padding Negotiation

On 12/09/15 01:34, Mike Perry wrote: > 4.1. Rate limiting > > Fully client-requested padding introduces a vector for resource > amplification attacks and general network overload due to > overly-aggressive client implementations requesting too much padding. > > Current research indicates that

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

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 introduction point maintains a long-lived circuit with the

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

On 12/05/15 20:41, Jeff Burdges wrote: Alright, what if we collaboratively select the RP as follows : Drop the HSDirs and select IPs the way 224 selects HSDirs, like John Brooks suggests. Protect HSs from malicious IPs by partially pinning their second hop, ala (2). An HS opening a

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

On 26/04/15 23:14, John Brooks wrote: 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. ... One notable

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

On 28/05/15 11:28, Jeff Burdges wrote: One small problem with this suggestion (hopefully fixable) is that there's no single current consensus that the client and IP are guaranteed to share: https://lists.torproject.org/pipermail/tor-dev/2014-September/007571.html If I understand, you’re

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

On 21/05/15 14:04, Nathan Freitas wrote: On Thu, May 21, 2015, at 07:16 AM, Martin Florian wrote: 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

Re: [tor-dev] Listen to Tor

On 17/05/15 06:17, Kenneth Freeman wrote: I recently had a brainstorm at Feast VI, a locally crowd sourced micro-grant catered dinner where ten artists each pitch their projects for ten or twelve minutes. The diners vote, and the winner takes home the gate; this time around it was

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

On 26/04/15 23:14, John Brooks wrote: 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

Re: [tor-dev] PT-themed stuffed animals: huggable transports

On 01/04/15 16:50, Rishab Nithyanand wrote: Next, we went on to study possible replacements and found that the Scramblesuit rabbit [1] did significantly better! As a side benefit, it made all the censors go a and let it right through. Expect our full results at USENIX Security. [1]

Re: [tor-dev] Brainstorming ideas for controller features for improved testing; want feedback

On 20/03/15 15:55, Nick Mathewson wrote: 27. Hidden service intropoint changes, desc changes, uploads Many hidden service transitions currently generate no events. We could at minimum generate events for changed inroduction points, changed hidden service descriptors, uploading

Re: [tor-dev] bittorrent based pluggable transport

On 03/03/15 16:54, Tariq Elahi wrote: What I am getting at here is that we ought to figure out properties of CRSs that all CRSs should have based on some fundamentals/theories rather than what happens to be the censorship landscape today. The future holds many challenges and changes and

Re: [tor-dev] RFC: Ephemeral Hidden Services via the Control Port

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 (CCing the hidden-services list.) On 16/02/15 16:11, Leif Ryge wrote: If someone has a suggestion for an alternative interface that can handle applications crashing (possibly before they persist the list of HSes they need to clean up),

Re: [tor-dev] high latency hidden services

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 08/01/15 11:25, Mike Perry wrote: You might also like the Adaptive Padding defense: http://freehaven.net/anonbib/cache/ShWa-Timing06.pdf. It implements pretty much what you describe here. It is one of my current low-resource favorites.

Re: [tor-dev] high latency hidden services

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 09/01/15 14:40, Yawning Angel wrote: I believe most of BuFLO's shortcomings documented in Cai, X., Nithyanand, R., Johnson R., New Approaches to Website Fingerprinting Defenses 5.A. apply to the currently proposed defense, though some of

Re: [tor-dev] high latency hidden services

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 08/01/15 06:03, grarpamp wrote: If that's what you're suggesting, then what happens if a client wants to extend a circuit from relay A to relay B, but A and B aren't exchanging chaff with each other? This doesn't happen. You have a lower

Re: [tor-dev] high latency hidden services

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 04/01/15 09:45, grarpamp wrote: That tells you how much chaff to send in total, but not how much to send on each link. No. Buy or allocate 1Mbit of internet for your tor. You now have to fill that 1Mbit with tor. So find enough nodes from

Re: [tor-dev] high latency hidden services

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Resurrecting a thread from last year... On 11/12/14 16:05, grarpamp wrote: On Thu, Dec 11, 2014 at 8:26 AM, Michael Rogers mich...@briarproject.org wrote: * Which links should carry chaff? First you need it to cover the communicating

Re: [tor-dev] TOR C# application

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, I don't know if it's possible to use Tor as a library, but there are a few Java apps that communicate over Tor by launching a Tor process and using it as a SOCKS proxy. Does that sound like what you're aiming to do? Here's a quick rundown of

Re: [tor-dev] high latency hidden services

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 10/12/14 00:14, grarpamp wrote: Guilty of tldr here, yet similarly, with the easily trackable characteristics firstly above, I'm not seeing a benefit to anything other than filling all links with chaff which then hides all those parameters

Re: [tor-dev] high latency hidden services

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 25/11/14 12:45, George Kadianakis wrote: Yes, integrating low-latency with high-latency anonymity is a very interesting probleml. Unfortunately, I haven't had any time to think about it. For people who want to think about it there is the

Re: [tor-dev] obfs4 questions

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 29/11/14 00:35, Yawning Angel wrote: On Fri, 28 Nov 2014 17:57:26 + Michael Rogers mich...@briarproject.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 28/11/14 15:50, Yawning Angel wrote: A one time poly1305 key

[tor-dev] obfs4 questions

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, In the obfs4 spec I couldn't find a description of how the secretbox nonces for the frames are constructed. A 16-byte nonce prefix comes from the KDF, but what about the remaining 8 (presumably frame-specific) bytes? If an attacker changes the

Re: [tor-dev] obfs4 questions

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 28/11/14 15:50, Yawning Angel wrote: A one time poly1305 key is calculated for each box, based on 32 bytes of zeroes encrypted with a one time Salsa20 key/counter derived from the nonce and the box key. You can view the use of Salsa20 there

Re: [tor-dev] high latency hidden services

. I would love to participate, and encourage everyone to start in this direction (in your copious free time ;). This issue has just come up on the guardian-dev list, so we're moving the conversation over here. Context quoted below. On Thu, Nov 20, 2014, at 09:46 AM, Michael Rogers wrote: On 20/11

Re: [tor-dev] Hidden Service authorization UI

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 09/11/14 12:50, George Kadianakis wrote: I suspect that HS authorization is very rare in the current network, and if we believe it's a useful tool, it might be worthwhile to make it more useable by people. For what it's worth, the reason I

[tor-dev] 5-hop hidden service circuits (was: Potential projects for SponsorR (Hidden Services))

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 20/10/14 14:37, George Kadianakis wrote: On an even more researchy tone, Qingping Hou et al wrote a proposal to reduce the length of HS circuits to 5 hops (down from 6). You can find their proposal here:

Re: [tor-dev] Patches to improve mobile hidden service performance

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 08/10/14 02:55, John Brooks wrote: 1. Each time the network's enabled, don't try to build introduction circuits until we've successfully built a circuit. This avoids a problem where we'd try to build introduction circuits immediately, all

Re: [tor-dev] Patches to improve mobile hidden service performance

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 08/10/14 08:34, grarpamp wrote: I've added a link to this thread to the below ticket. Somewhere therein I and Qingping were describing need and syntax to flush/fetch hidden service descriptors via control. For which your HS descriptor purge

[tor-dev] Patches to improve mobile hidden service performance

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 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 try to build

[tor-dev] Getting the network consensus

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi all, While working on peer-to-peer hidden services I've been wondering how long two clients need to wait before arriving at the same view of the Tor network. The answer, which I find surprising, is that this is never guaranteed to happen. Here's

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

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 13/09/14 14:07, George Kadianakis wrote: a) To reduce the ownage probabilities we could pick a single middle node instead of 6. That will greatly improve guard discovery probabilities, and make us look like this: HS - guard - middle - exit

Re: [tor-dev] Running Tor with static path

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 16/06/14 17:47, Zack Weinberg wrote: On Mon, Jun 16, 2014 at 11:38 AM, mahdi mahdi.it2...@gmail.com wrote: Hi all, I want to execute an experiment on Tor in which i need to fix the ip address of entry,relay and exit onion router. For that i

Re: [tor-dev] Question about HS code

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 29/05/14 19:36, Nick Mathewson wrote: So what's the effect of REND_HID_SERV_DIR_REQUERY_PERIOD? Hello, Michael! This looks like a possible bug to me. Could you open a ticket at trac.torproject.org? Hi Nick, Robert Ransom replied

[tor-dev] Question about HS code

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, I've been trying to get to grips with the hidden service code, and I have a question that I was hoping someone on the list could answer. The constant REND_HID_SERV_DIR_REQUERY_PERIOD is defined as 15 * 60 (15 minutes) in rendclient.c, with the

Re: [tor-dev] RFC: obfs4 (Name not final)

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 23/05/14 13:16, Philipp Winter wrote: - ScrambleSuit's framing mechanism is vulnerable to this attack: http://www.isg.rhul.ac.uk/~kp/SandPfinal.pdf In a nutshell, the receiver needs to decrypt the ScrambleSuit header before it is able to

Re: [tor-dev] Introduction Points and their rotation periods (was Re: Hidden Service Scaling)

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 13/05/14 18:28, Michael Rogers wrote: A fourth possibility is to rank the candidate nodes for each position in the circuit, and build the circuit through the highest-ranked candidate for each position that's currently online. Thus whenever

Re: [tor-dev] Introduction Points and their rotation periods (was Re: Hidden Service Scaling)

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 11/05/14 17:36, George Kadianakis wrote: I think it would be good for the performance of mobile hidden services, but I'm concerned about the attack waldo described eariler in this thread, in which a malicious IP breaks circuits until the

Re: [tor-dev] Introduction Points and their rotation periods (was Re: Hidden Service Scaling)

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 10/05/14 21:09, George Kadianakis wrote: It's interesting that you say this, because we pretty much took the opposite approach with guard nodes. That is, the plan is to extend their rotation period to 9 months (from the current 2-3 months).

Re: [tor-dev] Hidden Service Scaling

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 06/05/14 22:07, Christopher Baines wrote: On 06/05/14 15:29, Michael Rogers wrote: Does this mean that at present, the service builds a new IP circuit (to a new IP?) every time it receives a connection? If so, is it the IP or the service

Re: [tor-dev] Hidden Service Scaling

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 07/05/14 17:32, Christopher Baines wrote: What about the attack suggested by waldo, where a malicious IP repeatedly breaks the circuit until it's rebuilt through a malicious middle node? Are entry guards enough to protect the service's

Re: [tor-dev] Hidden Service Scaling

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi Christopher, I'm interested in your work because the hidden service protocol doesn't seem to perform very well for hidden services running on mobile devices, which frequently lose network connectivity. I wonder if the situation can be improved

Re: [tor-dev] jtorctl

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 04/04/14 15:44, Nathan Freitas wrote: *ahem* Orbot represents 2 million users of jtorctl, and it works just fine for us (in our limited use of it). https://gitweb.torproject.org/orbot.git/tree/HEAD:/external Hehe, I was just this second

[tor-dev] jtorctl

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, I have a patch to improve thread safety in jtorctl. How should I submit it? Cheers, Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBCAAGBQJTPT1vAAoJEBEET9GfxSfM0CMH+wais6E2jteMA0EnrAsV9+K1

[tor-dev] Using the HS protocol for unlinkability only

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi all, (Please let me know if this belongs on tor-talk instead of here.) I'm working on a messaging app that uses Tor hidden services to provide unlinkability (from the point of view of a network observer) between users and their contacts. Users