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 l

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

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), appl

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 get

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, uploadi

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. > >

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 th

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

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 approxima

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 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 unde

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 notab

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 wit

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 thi

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 disc

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] 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 sl

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] 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] 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 pro

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

On 04/04/16 11:47, George Kadianakis wrote: > I wonder what would happen there if FascistFirewall gets toggled on and off. > > If our guardlist was sampled when FascistFirewall was on, shouldn't we sample > from the beginning if FascistFirewall goes off? That's terrible though since > we > lose a

Re: [tor-dev] Revisiting prop224 time periods and HS descriptor upload/downloads

On 11/04/16 12:42, George Kadianakis wrote: > FWIW, I'm personally not sure how to choose the best "maximum acceptable > clock skew" > value here. My intuition tells me to choose a big number so that even very > skewed clients can visit hidden services. Sorry for the late reply. I just wanted to

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] [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 in

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? > **May

[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 last

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 > wrote: >> 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 >> se

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 version and probably would

[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 k

[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 jx08ypBNtE7qTYehe3m4s

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

Re: [tor-dev] jtorctl

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 04/04/14 16:45, Nathan Freitas wrote: > On 04/04/2014 11:34 AM, Damian Johnson wrote: >> Nathan, should Michael go ahead and file his pull request with >> the Orbot component then? > > Sure! We can keep the JtorCtl repo on its own, and perhaps mo

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 by

Re: [tor-dev] Hidden Service Scaling

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 06/05/14 22:17, Christopher Baines wrote: > On 06/05/14 22:07, Christopher Baines wrote: >> On 06/05/14 15:29, Michael Rogers wrote: >>> I'm interested in your work because the hidden service >>> protocol doesn

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

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'

Re: [tor-dev] Hidden Service Scaling

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 08/05/14 14:40, Christopher Baines wrote: >> Perhaps it would make sense to pick one or more IPs per guard, >> and change those IPs when the guard is changed? Then waldo's >> attack by a malicious IP would only ever discover one guard. > > If you

Re: [tor-dev] Hidden Service Scaling

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 09/05/14 14:31, Christopher Baines wrote: > How do you see the guards being "scheduled" for replacement? Two possibilities (there are probably others): 1. Periodically select a new guard by hashing a secret key and the date, similar to the way H

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] 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 t

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

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: > In a nutshell, the > receiver needs to decrypt the ScrambleSuit header before it is able > t

[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] 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 repl

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 > 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 need to determi

[tor-dev] Hidden services mailing list

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi all, Several projects use Tor hidden services for peer-to-peer communication, including TorChat, TORFone, Ricochet, Ploggy, OnionShare, Invisible.im, Ciboulette and Briar. I suspect many of us are running into similar issues because the hidden se

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 -

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

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 13/09/14 15:34, George Kadianakis wrote: > Michael Rogers writes: >> Hi George, >> >> Could you explain what it means to say that HS traffic isn't >> counted in the load balancing equations? Why is that so,

[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

[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 intr

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

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 pu

[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: > https://lists.torproject.org/piper

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

Re: [tor-dev] high latency hidden services

gt; starting points. 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, Michae

[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 Thanks for the quick response! On 28/11/14 13:39, Yawning Angel wrote: >> 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

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 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 +0000 Michael Rogers > wrote: > >> -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 >> >> On 28/11/14 15:50, Yawning Angel wrote: >>> A one

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 t

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 parameter

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 wh

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 > wrote: >> * Which links should carry chaff? > > First you need it to cover the communicating end

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

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 blind

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 n

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 wrote: >> >>> On 30/11/17 12:55, Nick Mathewson wrote: >>> >>> When a Tor instance that is running an onion service is IDLE, it >>> does the minimum to try to rem

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 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 >> difference in latency betwee

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 va

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

[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 th

Re: [tor-dev] Temporary hidden services

ons to both approaches. Cheers, 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 ov

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

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 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 t

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

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&#x

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

[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 consumption.

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 c

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 >>&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 mos

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

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] 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"

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] 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 it

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 > se

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 whi

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! :-) https://code.briarproject.o

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 poi

[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 whe

[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 being

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 an

Re: [tor-dev] Counting HS descriptor uploads

8 Jun (13:27:03), 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 tri

[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] 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 in

[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] Timers in Arti?

got a latency 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 exam

  1   2   >