Re: [tor-dev] Key Blinding Secrets

On Tue, Apr 30, 2024 at 8:07 AM Bellebaum, Thomas wrote: > > Hello everyone, > > I am a researcher currently looking into different schemes for what you call > Keyblinding in the rendevouz spec. Hello and welcome! > https://spec.torproject.org/rend-spec/keyblinding-scheme.html > > I noticed

Re: [tor-dev] Timers in Arti?

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 deep sleep in that > scenario. There

[tor-dev] Proposal 347: Domain separation for certificate signing keys

To see this rendered, go to https://spec.torproject.org/proposals/347-domain-separation.html ``` Filename: 347-domain-separation.md Title: Domain separation for certificate signing keys Author: Nick Mathewson Created: 19 Oct 2023 Status: Open ``` ## Our goal We'd like to be able to use

[tor-dev] Proposal 346: Clarifying and extending the use of protocol versioning

Note: we've updated our specs website! You can read a rendered version of this proposal at https://spec.torproject.org/proposals/346-protovers-again.html . ``` Filename: 346-protovers-again.md Title: Clarifying and extending the use of protocol versioning Author: Nick Mathewson Created: 19 Oct

Re: [tor-dev] Two features that would help load-balanced bridges

On Wed, May 24, 2023 at 9:10 PM David Fifield wrote: > > Linus Nordberg and I will have a paper at FOCI this summer on the > special way we run tor on the Snowflake bridges to permit better > scaling. It discusses the two workarounds from the post below, namely a > shim for predictable ExtORPort

Re: [tor-dev] Is Arti expected to have better multi-CPU support than C-tor?

On Tue, Mar 7, 2023 at 4:07 PM David Fifield wrote: > Linus Nordberg and I are preparing a submission for FOCI about the > special way we run tor on the Snowflake bridge. We run many tor > processes with the same identity and onion keys, because otherwise tor > being limited to one CPU would be

Re: [tor-dev] The future of Tor client software?

On Mon, Feb 13, 2023 at 9:40 AM Nick Mathewson wrote: > > > Right now, we're starting a working group of interested people to talk > about getting all of these APIs right. You can see an initial thread at > https://forum.torproject.net/t/defining-an-interface-to-arti/64

Re: [tor-dev] The future of Tor client software?

On Mon, Feb 13, 2023 at 4:20 AM Steven Engler wrote: > Hi tor-dev, > > In the past, there were generally two options for supporting Tor in an > application. > > 1. Require the user to install the tor daemon (ex: apt install tor, Tor > Expert Bundle, etc) and configure the application to use its

Re: [tor-dev] Proposal 342: Decouple hs_interval and SRV lifetime

On Tue, Jan 24, 2023 at 9:02 AM David Goulet wrote: > On 23 Jan (13:31:49), Nick Mathewson wrote: > > On Tue, Jan 10, 2023 at 8:22 AM Nick Mathewson > wrote: > > > > > ``` > > > Filename: 342-decouple-hs-interval.md > > > Title: Decoupling hs

Re: [tor-dev] Proposal 342: Decouple hs_interval and SRV lifetime

On Tue, Jan 10, 2023 at 8:22 AM Nick Mathewson wrote: > ``` > Filename: 342-decouple-hs-interval.md > Title: Decoupling hs_interval and SRV lifetime > Author: Nick Mathewson > Created: 9 January 2023 > Status: Draft > ``` > > # Motivation and introduction > &

Re: [tor-dev] Proposal 342: Decouple hs_interval and SRV lifetime

On Tue, Jan 10, 2023 at 8:41 AM Holmes Wilson wrote: > Apologies if I missed this in the proposal, but what are the benefits of > this beyond decoupling? Will onion service users see benefits? Or is it > just about simplifying the code? > There's no immediate benefit to users; it's entirely

[tor-dev] Proposal 342: Decouple hs_interval and SRV lifetime

``` Filename: 342-decouple-hs-interval.md Title: Decoupling hs_interval and SRV lifetime Author: Nick Mathewson Created: 9 January 2023 Status: Draft ``` # Motivation and introduction Tor uses shared random values (SRVs) in the consensus to determine positions of relays within a hash ring

[tor-dev] Proposal 341: A better algorithm for out-of-sockets eviction

``` Filename: 341-better-oos.md Title: A better algorithm for out-of-sockets eviction Author: Nick Mathewson Created: 25 July 2022 Status: Open ``` # Introduction Our existing algorithm for handling an out-of-sockets condition needs improvement. It only handles sockets used for OR connections

Re: [tor-dev] Shrink Tor binary size

On Mon, Jun 27, 2022 at 5:03 AM Sergey Ponomarev wrote: > I’m working on a firmware for routers based on OpenWrt and it needs > Tor out of the box for NAT punching i.e. SSH and Web admin access. It > will expose a Single Onion Service i.e. not "hidden" with just 3 hop > for a better

[tor-dev] Proposal 340: Packed and fragmented relay messages

``` Filename: 340-packed-and-fragmented.md Title: Packed and fragmented relay messages Author: Nick Mathewson Created: 31 May 2022 Status: Open ``` # Introduction Tor sends long-distance messages on circuits via _relay cells_. The current relay cell format allows one _relay message_ (e.g

Re: [tor-dev] Proposal 338: Use an 8-byte handshake in NETINFO cells

On Mon, Mar 14, 2022 at 3:18 PM Jim Newsome wrote: > On 3/14/22 11:44, Nick Mathewson wrote: > > > > > Currently Tor relays use a 4-byte timestamp (in seconds since the Unix > > epoch) in their NETINFO cells. Notoriously, such a timestamp will > &g

[tor-dev] Proposal 338: Use an 8-byte handshake in NETINFO cells

``` Filename: 338-netinfo-y2038.md Title: Use an 8-byte timestamp in NETINFO cells Author: Nick Mathewson Created: 2022-03-14 Status: Open ``` # Introduction Currently Tor relays use a 4-byte timestamp (in seconds since the Unix epoch) in their NETINFO cells. Notoriously, such a timestamp

Re: [tor-dev] proposal 328: consensus parameters

On Wed, Nov 17, 2021 at 4:39 PM nusenu wrote: > Hi, > > > https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/proposals/328-relay-overload-report.md > > For DNS timeouts, the X and Y are consensus parameters > > (overload_dns_timeout_scale_percent and overload_dns_timeout_period_secs) > >

[tor-dev] Arti report 8: October 14 through October 27

# Arti Report 7: October 14 through October 27 # Towards Arti 0.0.1 On Monday November 1, we're planning to put out Arti version 0.0.1. Our goal is to include all the features that are needed for reasonable security, and a top-level API that isn't _so_ far from completely wrong. Right now, it

[tor-dev] Proposal 337: A simpler way to decide, "Is this guard usable?"

``` Filename: 337-simpler-guard-usability.md Title: A simpler way to decide, "Is this guard usable?" Author: Nick Mathewson Created: 2021-10-22 Status: Open ``` # Introduction The current `guard-spec` describes a mechanism for how to behave when our primary guards are unreachable, an

[tor-dev] Proposal 336: Randomized schedule for guard retries

``` Filename: 336-randomize-guard-retries.md Title: Randomized schedule for guard retries Author: Nick Mathewson Created: 2021-10-22 Status: Open ``` # Introduction When we notice that a guard isn't working, we don't mark it as retriable until a certain interval has passed. Currently

Re: [tor-dev] Proposal 335: An authority-only design for MiddleOnly

On Sun, Oct 10, 2021 at 12:39 PM nusenu wrote: > > Hi, > > has this proposal any implications wrt to making the MiddleOnly > feature available to clients (without requiring DA actions)? > > With ExcludeExitNodes/ExitNodes + ExcludeGuardNodes [1] > tor clients basically can get the "MiddleOnly"

[tor-dev] Arti report 7: September 30 through October 13

# Arti Report 7: September 30 through October 13 ## Guards are working! Finally, at long last, we've got Guard nodes working in Arti! When we first made our roadmap, we set our first milestone as "Arti has all the features necessary for basic anonymity." Now that Guards are implemented, all of

Re: [tor-dev] How do Ed25519 relay IDs look like?

On Sun, Oct 10, 2021 at 5:13 PM nusenu wrote: > > > On Tue, Aug 4, 2020 at 6:41 PM nusenu wrote: > >> > >> nusenu: > >>> I'll wait until you (Tor developers) decided on the final naming and > >>> format > >> > >> Is there any interest to move this topic forward to come to some decision > >> in

Re: [tor-dev] ed25519_master_id_public_key -> ed25519 id

On Sun, Oct 10, 2021 at 8:44 AM nusenu wrote: > > Hi, > > given a relay's ed25519_master_id_public_key > file, is there a simple way to generate the > 43 chars long ed25519 identity string (also found in fingerprint-ed25519)? > Yes, there is! First you verify that the file is really 64 bytes

[tor-dev] Proposal 335: An authority-only design for MiddleOnly

``` Filename: 335-middle-only-redux.md Title: An authority-only design for MiddleOnly Author: Nick Mathewson Created: 2021-10-08 Status: Open ``` # Introduction This proposal describes an alternative design for a `MiddleOnly` flag. Instead of making changes at the client level, it adds a little

[tor-dev] (Short) Arti Report 6: September 15 through September 30

# Arti Report 6: September 15 through September 30 ## Activities since our last report Hello! Lots of code since last time, but not so much to say about it. I'm chugging ahead on the Guard nodes implementation, but it isn't done yet. Most of the code is there, but I need to write tests, chase

Re: [tor-dev] Proposal 332: Ntor protocol with extra data, version 3.

On Fri, Jul 16, 2021 at 8:31 AM Ian Goldberg wrote: [...] > But this post from Trevor also made me realize a bigger issue with the > protocol Nick proposed: > > If you want the protocol to work with Walking Onions, it needs to be > *post-specified peer*. That is, contrary to: > > > The client

[tor-dev] Arti report 5: August 18 through September 15

# Arti Report 5: August 4 through September 15 ## Activities since our last report I'm back, with updates from the last month! We've spent a lot of time over the last on cleaning up technical debt issues in our code that had accumulated as I wrote it. There are more tests and warnings enabled

[tor-dev] No arti report this week.

Hi! Usually I do Arti reports every other Wednesday, but this week I'm on vacation. I'll send the next report on September 15, so that the reports can be offset from the Arti meetings. cheers, -- Nick ___ tor-dev mailing list

[tor-dev] Arti report 4: August 4 through August 18

# Arti Report 3: August 4 through August 18 At last we're done with circuit timeout inference! See the last weeks update for an overview of what this was, and why it was hard. As of last Friday, we've finally got an Arti implementation that builds testing circuits as appropriate, infers

[tor-dev] This week's arti meeting rescheduled: 18 August, 1600 UTC

Hi! Because of a scheduling conflict, our biweekly Arti meeting is rescheduled (for this Wednesday only). The time this week will be at 18 August, 1600 UTC, at https://tor.meet.coop/gab-sis-ldw-xad . This week we'll be brainstorming API ideas, use cases, and user stories. Don't worry if you

[tor-dev] Arti Report 3: July 21 through August 4

Still quiet here for the last couple of weeks. I've been moving ahead on circuit timeout inference, and reviewing _lots_ of volunteer-submitted code (and job applications). The quiet part is coming to an end: Two of the engineers who have been on vacation or leave are back, and we're all trying

[tor-dev] Arti development report: July 7 through July 21

# Arti Report 2: July 7 through July 21 It's been a quiet couple of weeks. Most of the team has been on vacation or leave for the last two weeks, so the Arti hacking has been down to me (nick) for this period. Our last report went out on the same day that our [announcement] went public, and

Re: [tor-dev] Proposal 332: Ntor protocol with extra data, version 3.

On Mon, Jul 12, 2021 at 3:04 PM Ian Goldberg wrote: > > On Mon, Jul 12, 2021 at 12:01:47PM -0400, Nick Mathewson wrote: > > Both parties know that they used the same verification string; if > > they did not, they do not learn what the verification string was. > > (This fe

[tor-dev] Proposal 332: Ntor protocol with extra data, version 3.

``` Filename: 332-ntor-v3-with-extra-data.md Title: Ntor protocol with extra data, version 3. Author: Nick Mathewson Created: 12 July 2021 Status: Open ``` # Overview The ntor handshake is our current protocol for circuit establishment. So far we have two variants of the ntor handshake in use

[tor-dev] Arti development report: 23 June through July 7

# Arti Report 1: 23 June through July 7 We started with a project kickoff meeting. We're planning to continue meeting every 2 weeks, making our meetings increasingly public, and posting them on youtube. We wrote up an announcement to explain what Arti is and why we're doing it. The

[tor-dev] Proposal 330: Modernizing authority contact entries

(I'm using 330 for this proposal, since 329 is reserved for conflux.) ``` Filename: 330-authority-contact.md Title: Modernizing authority contact entries Author: Nick Mathewson Created: --- Status: Draft ``` This proposal suggests changes to interfaces used to describe a directory authority

[tor-dev] Proposed changes to Tor long-term-support (LTS) policy

Hi, all! I've been working on a proposed change to Tor's LTS policies. I've run it by a few people already, and now I'm posting it here for wider comment. (summary: If we decide to do this, we will still be able to do LTS releases, but we will backport fewer things to them, and we will make

Re: [tor-dev] Has Core Tor Development Slowed? Or Are We Moving To Rust/arti?

On Fri, Jan 8, 2021 at 7:43 PM Neel Chauhan wrote: > > Hi tor-dev@, > > I hope you all had a great holiday season. > > I noticed that Core Tor development, especially with the tor daemon, has > slowed down significantly since the COVID crisis. > > Sorry if I have been less active in the Tor

[tor-dev] Arti (was Re: ARTI)

On Fri, Dec 11, 2020 at 12:31 PM Zaphoid wrote: > > Greetings Tor-Dev, > > I've watched Nick's presentation on State of the Onion and have read the "Tor > in 2021" blog post searching for more details on A Rust Tor Implementation > (ARTI). I think Rust is a fascinating language and looking to

Re: [tor-dev] Proposal 328: Make Relays Report When They Are Overloaded

On Wed, Dec 9, 2020 at 10:10 AM David Goulet wrote: > > On 07 Dec (15:36:53), Ian Goldberg wrote: > > On Mon, Dec 07, 2020 at 03:06:43PM -0500, David Goulet wrote: > > > Greetings, > > > > > > Attached is a proposal from Mike Perry and I. Merge requsest is here: > > > > > >

Re: [tor-dev] Update to Proposal 316: FlashFlow

Hi! We had a meeting about FlashFlow today, including several of the authors. Here are the notes we wound up with for ideas and next straps. Easy changes: * Just use a PRNG; assume we can make them arbitrarily fast. (example candidates: chacha8, shake128.) * Use relay identities as the

Re: [tor-dev] new home for trac/CoreTorReleases?

On Thu, Sep 17, 2020 at 4:50 PM nusenu wrote: > > Hi, > > in the past > https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam/CoreTorReleases > > used to be the canonical place for tor EoL information. > Since Trac is no longer used: Is there a new home for this kind of >

Re: [tor-dev] proposal for "tor-relay" well-known URI

On Mon, Aug 17, 2020 at 11:19 AM David Goulet wrote: > > On 14 Aug (12:17:50), nusenu wrote: > > Hi, > > > > I'm submitting this as a proposal according to: > > https://github.com/torproject/torspec/blob/master/proposals/001-process.txt > > > > I made a PR request for you: > >

Re: [tor-dev] Update to Proposal 316: FlashFlow

On Fri, Sep 4, 2020 at 8:26 AM Matt Traudt wrote: > > Hi all > > I polished up the FlashFlow proposal based on the feedback provided by > Teor, Nick, and Mike. I converted it to markdown, and pasted the new > text at the bottom of this email. The updated proposal is also in my > fork of torspec

Re: [tor-dev] Can "ExcludeNodes" be used multiple times in torrc?

On Mon, Aug 10, 2020 at 6:13 PM nusenu wrote: > > Hi, > > it is not clear to me whether ExcludeNodes and other similar options > (ExcludeExitNodes) > can be used multiple times in a torrc file. > > Are all of the lines merged like multiple "MyFamily" lines or > how does it behave? No, only one

Re: [tor-dev] How do Ed25519 relay IDs look like?

On Tue, Aug 4, 2020 at 6:41 PM nusenu wrote: > > nusenu: > > I'll wait until you (Tor developers) decided on the final naming and format > > Is there any interest to move this topic forward to come to some decision > in the near future? (before the end of the month) I don't think that'd be too

Re: [tor-dev] Safe Alternative Uses of Onion Service Keys

but it's trivial to verify the certificate if you know what the On Mon, Aug 10, 2020 at 9:00 AM Nick Mathewson wrote: > > On Wed, Jul 29, 2020 at 1:15 AM Matthew Finkel wrote: > > > > Hello everyone, > > Hi, Matt! > > There's a part of this that I'm still trying t

Re: [tor-dev] Safe Alternative Uses of Onion Service Keys

On Wed, Jul 29, 2020 at 1:15 AM Matthew Finkel wrote: > > Hello everyone, Hi, Matt! There's a part of this that I'm still trying to figure out: > The safest usage of the long-term keys for alternative purposes I see > appears to be by deriving a (fixed/deterministic) blinded key pair using >

Re: [tor-dev] How do Ed25519 relay IDs look like?

On Sat, Aug 1, 2020 at 6:10 AM nusenu wrote: > > nusenu: > >> The only question that came up was: Will there be two types of relay > >> fingerprints > >> in the future (Ed25519)? > > > > I assume the correct proposal for the Ed25519 keys is this: > >

Re: [tor-dev] Proposal 325: Packed relay cells: saving space on small commands

On Fri, Jul 10, 2020 at 2:07 PM Ian Goldberg wrote: > > On Fri, Jul 10, 2020 at 01:52:00PM -0400, Nick Mathewson wrote: > > After receiving a packed relay cell, the relay know that the client > > typo: "know" -> "knows" thanks! > > struct

[tor-dev] Proposal 325: Packed relay cells: saving space on small commands

``` Filename: 325-packed-relay-cells.md Title: Packed relay cells: saving space on small commands Author: Nick Mathewson Created: 10 July 2020 Status: Draft ``` # Introduction In proposal 319 I suggested a way to fragment long commands across multiple RELAY cells. In this proposal, I suggest

Re: [tor-dev] Implementing an embeddable C++ Tor client, advice requested

On Fri, Jun 19, 2020 at 3:59 PM The Paranoia Project wrote: > > Hello everyone, I'm a long time user of Tor, first time poster here. > > Over the last few months, I have been working on a light weight C++ client > only implementation of the Tor protocol, intended to be used as an embedded >

Re: [tor-dev] Reproducing #33598 "chutney does not fail on some SOCKS errors"

On Mon, Jun 15, 2020 at 8:53 AM c wrote: > > I asked on ticket https://bugs.torproject.org/33598 how to reliably > reproduce SOCKS errors so that it would be easier to determine when the > underlying issue is properly fixed, rather than running into the > possibility of race conditions (as the

Re: [tor-dev] #32888 IPv6 and 'Address' option

On Sun, Jun 14, 2020 at 6:42 AM c wrote: > > Trac describes > that "we should also log [for] IPv4 and IPv6: the Address torrc option" > and as tor(1) states, 'Address' takes only an IPv4 address and port. > > So what is suggested here? Make

[tor-dev] Walking onions specifications: Project wrap-up

On a grant from the zcash foundation, I've been working on a full specification for the Walking Onions design. This is the last update for the spec project. My previous updates are linked below: Week 1: formats, preliminaries, git repositories, binary diffs, metaformat decisions, and

Re: [tor-dev] Proposal 316: FlashFlow: A Secure Speed Test for Tor (Parent Proposal)

On Thu, Apr 23, 2020 at 2:48 PM Matt Traudt wrote: > Hi! I've got some comments on the FlashFlow proposal; I'll start with the ones that I think are most important, so that we can try to get them out of the way. First off, I'm concerned about the approach where measurers get to consume a

Re: [tor-dev] Moving key material out of the main tor process

On Wed, May 20, 2020 at 11:46 AM Linus Nordberg wrote: > > Hi, > > tl;dr How to move key material out of tor? > > ## The idea of a vault component > > ahf and others in the network team have been discussing the > possibility of a "vault" component in tor, for moving private keys out > of the tor

[tor-dev] Proposal 322: Extending link specifiers to include the directory port

``` Filename: 322-dirport-linkspec.md Title: Extending link specifiers to include the directory port Author: Nick Mathewson Created: 27 May 2020 Status: Open ``` ## Motivation Directory ports remain the only way to contact a (non-bridge) Tor relay that isn't expressible as a Link Specifier. We

[tor-dev] Proposal 321: Better performance and usability for the MyFamily option (v2)

``` Filename: 321-happy-families.md Title: Better performance and usability for the MyFamily option (v2) Author: Nick Mathewson Created: 27 May 2020 Status: Open ``` ## Problem statement. The current family mechanism allows well-behaved relays to identify that they all belong to the same 'family

Re: [tor-dev] Proposal 320: Removing TAP usage from v2 onion services

On Wed, May 13, 2020 at 10:09 AM David Goulet wrote: > > On 11 May (16:47:53), Nick Mathewson wrote: > > Hello! > > > ``` > > Filename: 320-tap-out-again.md > > Title: Removing TAP usage from v2 onion services > > Author: Nick Mathewson &g

Re: [tor-dev] Proposal 320: Removing TAP usage from v2 onion services

On Mon, May 11, 2020 at 8:52 PM teor wrote: > > Hi Nick, > > > On 12 May 2020, at 06:48, Nick Mathewson wrote: > > > > ## Migration steps > > > > First, we implement all of the above, but set it to be disabled by > > default. We use torrc

Re: [tor-dev] Proposal 319: RELAY_FRAGMENT cells

On Thu, May 14, 2020 at 3:15 PM David Goulet wrote: > > On 11 May (16:47:24), Nick Mathewson wrote: [...] > > # Onion service concerns. > > > > We allocate a new extension for use in the ESTABLISH_INTRO by onion > > services, > > to indicate that the

Re: [tor-dev] Chutney code refactoring

On Thu, May 14, 2020 at 7:04 PM c wrote: > > On Sat, 18 Apr 2020 11:02:03 + > c wrote: > > > I came across Node.specialize() which does not seem to be called > > elsewhere, and I cannot guess at its purpose. > > I ran vulture (a static analyzer for dead code), trimmed the output to > omit

[tor-dev] Walking onions: week 10 update

Walking Onions: week 10 update On our current grant from the zcash foundation, I'm working on a full specification for the Walking Onions design. I'm going to try to send out these updates once a week. My previous updates are linked below: Week 1: formats, preliminaries, git repositories,

Re: [tor-dev] Proposal 320: Removing TAP usage from v2 onion services

On Mon, May 11, 2020 at 5:58 PM Ian Goldberg wrote: > > On Mon, May 11, 2020 at 04:47:53PM -0400, Nick Mathewson wrote: > > ## INTRODUCE cells, RENDEZVOUS cells, and ntor. > > > > We allow clients to specify the rendezvous point's ntor key in the > > INTRODUCE2 cell

[tor-dev] Proposal 319: RELAY_FRAGMENT cells

``` Filename: 319-wide-everything.md Title: RELAY_FRAGMENT cells Author: Nick Mathewson Created: 11 May 2020 Status: Open ``` (This proposal is part of the Walking Onions spec project.) # Introduction Proposal 249 described a system for `CREATE` cells to become wider, in order to accommodate

[tor-dev] Proposal 320: Removing TAP usage from v2 onion services

``` Filename: 320-tap-out-again.md Title: Removing TAP usage from v2 onion services Author: Nick Mathewson Created: 11 May 2020 Status: Open ``` (This proposal is part of the Walking Onions spec project. It updates proposal 245.) # Removing TAP from v2 onion services As we implement walking

[tor-dev] Proposal 318: Limit protover values to 0-63

``` Filename: 318-limit-protovers.md Title: Limit protover values to 0-63. Author: Nick Mathewson Created: 11 May 2020 Status: Open ``` # Limit protover values to 0-63. I propose that we no longer accept protover values higher than 63, so that they can all fit nicely into 64-bit fields

Re: [tor-dev] Proposal 315: Updating the list of fields required in directory documents

On Thu, Apr 23, 2020 at 5:26 PM teor wrote: > > Hi Nick, > > This proposal is missing the "bridge" case. > > Bridges are more complicated, because we have at least > 3 kinds of bridges: > * bridges distributed by BridgeDB > * bridges distributed with apps (such as Tor Browser) > * private bridges

[tor-dev] (No walking onions update for last week)

Hi all! Sending a short note that I won't be doing a walking onions update from the past week -- my time went to follow-on tasks for personnel transitions, and I didn't make much progress to speak of on the walking onions specs. I hope to get more done this week, and send an update then. --

[tor-dev] Walking onions status update: week 8

Walking Onions: week 8 update On our current grant from the zcash foundation, I'm working on a full specification for the Walking Onions design. I'm going to try to send out these updates once a week. My previous updates are linked below: Week 1: formats, preliminaries, git repositories,

Re: [tor-dev] Support for full DNS resolution and DNSSEC validation

On Sun, Apr 26, 2020 at 4:32 PM Christian Hofer wrote: > > Hi there, > > I have a proposal regarding DNS name resolution. > > Ticket: https://trac.torproject.org/projects/tor/ticket/34004 > Proposal: >

Re: [tor-dev] Proposal XXX: FlashFlow: A Secure Speed Test for Tor (Parent Proposal)

Added as proposal 316. ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] Proposal 314: Allow Markdown for proposal format.

``` Filename: 314-allow-markdown-proposals.md Title: Allow Markdown for proposal format. Author: Nick Mathewson Created: 23 April 2020 Status: Open ``` # Introduction This document proposes a change in our proposal format: to allow Markdown. ## Motivation Many people, particularly researchers

[tor-dev] Proposal 315: Updating the list of fields required in directory documents

Filename: 315-update-dir-required-fields.txt Title: Updating the list of fields required in directory documents Author: Nick Mathewson Created: 23 April 2020 Status: Open 1. Introduction When we add a new field to a directory document, we must at first describe it as "optional&qu

Re: [tor-dev] Chutney code refactoring

On Fri, Apr 17, 2020 at 10:03 PM c wrote: > > On Fri, 17 Apr 2020 18:01:42 -0400 > Nick Mathewson wrote: > > > > Though I think this is likely to be an ongoing change that we see > > over time, since > > Was this sentence supposed to be longer? Yeah, I'm afr

[tor-dev] Walking Onions: week 7 update

Walking Onions: week 7 update On our current grant from the zcash foundation, I'm working on a full specification for the Walking Onions design. I'm going to try to send out these updates once a week. My previous updates are linked below: Week 1: formats, preliminaries, git repositories,

Re: [tor-dev] Chutney code refactoring

On Wed, Apr 15, 2020 at 11:45 PM c wrote: Skipping over some design stuff that seems reasonable. [...] > Here is what I have been considering lately, with the code overall. I > hope that laying it out in points will help both myself and others try > to divy up what could be improved about the

Re: [tor-dev] Choosing a valid Circuit ID for an OR connection

On Tue, Apr 14, 2020 at 9:13 AM Eli Vakrat wrote: > > Hello to the TOR dev team! > > My name is Eli, I'm a high school student from Israel and I'm currently > trying to implement a TOR Client in Python. > Currently, my project is configured so that the python client (OP) has its > guard node

[tor-dev] Walking onions status update: week 6 notes

Walking Onions: week 6 update On our current grant from the zcash foundation, I'm working on a full specification for the Walking Onions design. I'm going to try to send out these updates once a week. My previous updates are linked below: Week 1: formats, preliminaries, git repositories,

[tor-dev] Walking onions status update: week 5 notes

Walking Onions: week 5 update On our current grant from the zcash foundation, I'm working on a full specification for the Walking Onions design. I'm going to try to send out these updates once a week. My previous updates are linked below: Week 1: formats, preliminaries, git repositories,

[tor-dev] Walking onions status update: week 4 notes

Walking Onions: week 4 update On our current grant from the zcash foundation, I'm working on a full specification for the Walking Onions design. I'm going to try to send out these updates once a week. My previous updates are linked below: Week 1: formats, preliminaries, git repositories,

Re: [tor-dev] Walking onions status update: week 3 notes

On Fri, Mar 20, 2020 at 5:09 PM teor wrote: > > Hi Nick, > > On 21 Mar 2020, at 05:38, Nick Mathewson wrote: > > Walking Onions: week 3 update > > As you might recall, the SNIPs need to be nice and small, but they > need to be completely self-contained. The ENDIVE,

Re: [tor-dev] Walking Onions status update: week 2 notes

On Fri, Mar 20, 2020 at 12:38 PM teor wrote: > > Hi Nick, > > > On 20 Mar 2020, at 23:01, Nick Mathewson wrote: > > > > On Wed, Mar 18, 2020 at 11:21 AM teor wrote: > >> > >>> On 14 Mar 2020, at 14:44, teor wrote: > >>> > &

[tor-dev] Walking onions status update: week 3 notes

Walking Onions: week 3 update On our current grant from the zcash foundation, I'm working on a full specification for the Walking Onions design. I'm going to try to send out these updates once a week. My previous updates are linked below: Week 1: formats, preliminaries, git repositories,

Re: [tor-dev] Walking Onions status update: week 2 notes

On Wed, Mar 18, 2020 at 11:21 AM teor wrote: > > Hi Nick, > > > On 14 Mar 2020, at 14:44, teor wrote: > > > >> * As I work, I'm identifying other issues in tor that stand in > >>the way of a good efficient walking onion implementation that > >>will require other follow-up work. This

Re: [tor-dev] Walking Onions status update: week 2 notes

equests. > > (I made one comment on a git commit in walking-onions-wip, but > I'm not sure if you see those, so I'll repeat it here.) Thanks, this is really helpful! I missed the repository comments, and I'll probably miss some more. > > On 14 Mar 2020, at 03:52, Nick Mathew

[tor-dev] Fwd: Upcoming Tor security releases to fix a denial-of-service issue

-- Forwarded message - From: Nick Mathewson Date: Mon, Mar 16, 2020 at 1:25 PM Subject: Upcoming Tor security releases to fix a denial-of-service issue To: Hello! Some time this week, we currently plan to put out a set of security updates for all supported versions of Tor

[tor-dev] Walking Onions status update: week 2 notes

Walking onions -- week 2 update Hi! On our current grant from the zcash foundation, I'm working on a full specification for the Walking Onions design. I'm going to try to send these out thee updates once a week, in case anybody is interested. My previous updates are linked below: Week 1:

[tor-dev] Walking Onions status update: week 1 notes

Hi! On our current grant from the zcash foundation, I'm working on a full specification for the Walking Onions design. If you haven't read it, Walking Onions is a set of ideas meant to transition Tor away from its current dependency on a directory system, to improve scaling in the long term, and

Re: [tor-dev] Proposal 313: Relay IPv6 Statistics

On Mon, Feb 10, 2020 at 1:37 AM teor wrote: Hi, Teor! This proposal looks good and thorough to me. I have only a couple of questions on section 3: > 3. Logging IPv6 Relays in the Consensus > >We propose that relays (and bridges) log: > * the number of relays, and > * the

Re: [tor-dev] Proposal 312: Automatic Relay IPv6 Addresses

On Wed, Jan 29, 2020 at 9:04 AM teor wrote: Hello again! This looks like another fine proposal. I'm leaving comments inline, and clipping sections that I'm not commenting on. > > Filename: 312-relay-auto-ipv6-addr.txt > Title: Tor Relays Automatically Find Their IPv6 Address > Author: teor >

Re: [tor-dev] Prop 311: Relay IPv6 Reachability

On Wed, Jan 29, 2020 at 8:56 AM teor wrote: Thanks for the followup, Teor! I have only one comment on the changes: > I made these useful features "may not" in: > https://github.com/torproject/torspec/pull/103/commits/2662c688170696fbed2ba7e4dfa7f33ccf702435 We should avoid "may not" in

Re: [tor-dev] Prop 311: Relay IPv6 Reachability

On Fri, Jan 24, 2020 at 1:31 AM teor wrote: > > Hi, > > Here is an initial draft of Proposal 311: Relay IPv6 Reachability. > > This proposal includes: > * relay IPv6 ORPort extends, and > * relay IPv6 ORPort reachability checks. > > This is the first of 3 proposals: > * Proposal 311: Relay

Re: [tor-dev] Changes to accessing and using MaxMind's databases

On Thu, Jan 9, 2020 at 8:25 AM Karsten Loesing wrote: > > Hi! > > When trying to update tor's geoip databases the other day I found that > MaxMind's GeoLite2 database is not available for download anymore. The > reason is: > >

Re: [tor-dev] Onion DoS: Killing rendezvous circuits over the application layer

On Mon, Dec 2, 2019 at 9:16 AM George Kadianakis wrote: > However, IMO the right way to do this feature, would be to improve the control > port code and design so that it doesn't get so overwhelmed by multiple > events. That said, I'm not sure exactly what kind of changes we would have to > do

Re: [tor-dev] Proposal 271 - improvements

On Tue, Oct 15, 2019 at 5:43 AM Florentin Rochet wrote: > I've opened a trac ticket for 1) > https://trac.torproject.org/projects/tor/ticket/32088 (This is now proposal 310.) ___ tor-dev mailing list tor-dev@lists.torproject.org

[tor-dev] maint-0.4.2 is now a separate branch; master is now 0.4.3.x

Hi! If you're writing a patch that needs to go into Tor 0.4.2.x, please base it on the new "maint-0.4.2" branch. The "master" branch is now for developing the new and exciting Tor 0.4.3.x. If you use git-pull-all.sh, git-push-all.sh, or git-merge-forward.sh, please be sure to update to the

  1   2   3   4   5   6   7   >