Re: [tor-dev] Proposal 334: A flag to mark Relays as middle-only

Tor Relays wrote: David Goulet: However, I'm not sure we should always let 1 authority dictate that flag regardless of what the others think. I think we need to enforce majority here and not have one single authority dictate it. Thoughts? +1 I can compromise one

Re: [tor-dev] Proposal 334: A flag to mark Relays as middle-only

Neel Chauhan wrote: I believe it shouldn't affect these scenarios, but have mentioned we should look out for them. P.S. Rendezvous point is NOT a less powerful position (at least from an onion service server/operator point of view), unless you are using vanguards plugin by Mike with

Re: [tor-dev] Proposal 334: A flag to mark Relays as middle-only

Neel Chauhan wrote: Hi, As asked in the torspec MR [1] (42) for ticket [2] (40448), I propose a MiddleOnly dirauth flag for relays. The proposal, #334, is attached to this email, and is titled "A dirauth flag to mark Relays as Middle-only". Please comment and review it. Best, Neel

Re: [tor-dev] onionbalance useful on same server / for high-spec non-location hidden servers?

Patrick Schleizer wrote: > Would it be useful to run multiple Tor instances and onionbalance on the > very same server? Or does that totally defeat the purpose of onionbalance? > > In my case, it's not a location hidden service. Just an alternative way > to connect to a server which is available

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

Nick Mathewson wrote: > ``` > 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

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

Mirimir wrote: > On 02/03/2020 02:17 PM, s7r wrote: > > > >> In the current form of this proposal, it looks kind of optional ("We >> propose this optional change, to improve..."). I propose removing the >> line which contains "this optional change&q

Re: [tor-dev] CVE-2020-8516 Hidden Service deanonymization

juanjo wrote: > Since no one is posting it here and talking about it, I will post it. > > https://nvd.nist.gov/vuln/detail/CVE-2020-8516 > > The guy: > http://www.hackerfactor.com/blog/index.php?/archives/868-Deanonymizing-Tor-Circuits.html > > > Is this real? > > Are we actually not

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

Hi teor, teor wrote: > Hi s7r, > > Thanks for bringing up IPv6 address privacy extensions. > >> On 30 Jan 2020, at 02:19, s7r wrote: >> > > I read RFCs 4941 and 3041, looked at the tor directory spec, and did some > analysis: > * tor clients get new relay

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

in relay descriptor. s7r wrote: > Hi teor, > > Thanks for this epic work, some lecture for me to deeply go over this > weekend. > > By briefly reviewing I've noticed something important is missing that > should be a part of this proposal. > > I am not sure under which

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

Hi teor, Thanks for this epic work, some lecture for me to deeply go over this weekend. By briefly reviewing I've noticed something important is missing that should be a part of this proposal. I am not sure under which section it should go under. I guess `3.2.2. Use the Advertised ORPort IPv4

Re: [tor-dev] Probability of Guessing a v3 Onion Address

proc...@riseup.net wrote: > Hi I was wondering what the mathematical probability of guessing an > onion v3 address that is kept secret. > > Or asked differently: what is the entropy of v3 addresses if an > adversary decides to bruteforce the entire keyspace? > > I am struggling to come up with a

Re: [tor-dev] Timing of opening pre-emptive circuits?

> Hi Tor-Dev, > > I'm curious what the timing is of Tor's opening of preemptive circuits. > Specifically, consider the following attack: > > 1. A new stream is assigned to a clean circuit. > 2. Because of the above, that clean circuit is now a dirty circuit. > 3. Because of the above, the

Re: [tor-dev] Per-peer stream isolation for Bitcoin clients

Roger Dingledine wrote: > On Fri, Jun 28, 2019 at 07:53:54AM +1000, teor wrote: >> And you're right, Tor Browser can use lots more than 8 circuits, so >> I wouldn't worry about it. >> >> Do you know how much load Bitcoin places on the Tor network? >> >> If it's a lot, one good answer is to

Re: [tor-dev] Proposal Waterfilling

Hello Florentin Rochet wrote: > Hello, > > > On 2018-03-07 14:31, Aaron Johnson wrote: >> Hello friends, >> >>> 1) The cost of IPs vs. bandwidth is definitely a function of market >>> offers. Your $500/Gbps/month seems quite expensive compared to what >>> can be found on OVH (which is hosting a

Re: [tor-dev] How about capping single operators to max. 10% exit capacity of the network?

Hi, teor wrote: > > On 11 Dec 2017, at 09:25, nusenu wrote: > >>> And I think we should focus our efforts on expanding the pool of exits, >>> and improving bandwidth measurement, rather than limiting operators >>> who are helping the network. (New automatic limits will

Re: [tor-dev] Proposal 287: Reduce circuit lifetime without overloading the network.

Hello, Fernando Fernández Mancera wrote: [...] > Motivation: > > Currently Tor users are reusing a given circuit for ten minutes (by default) > after it's first used. This time is too long because a malicious Exit relay > can > trace a user's pseudonymous profile, especially if connections from

Re: [tor-dev] Open topics of prop247: Defending Against Guard Discovery Attacks using Vanguards

Hi George, George Kadianakis wrote: > Hello s7r, > > and thanks for helping with this and approaching it from a different > direction. > > Personally, I'd be really surprised if any solution that statistically > marks relays or paths as "suspicious" will ever wor

Re: [tor-dev] Open topics of prop247: Defending Against Guard Discovery Attacks using Vanguards

Hello Tim, Thank you very much for the comments. Please see my inline answers as I think I didn't explain good enough, most of the issues are not actually a problem. teor wrote: >> ... >> >> A rendezvous relay is considered suspicious when the number of >> successfully established circuits in

Re: [tor-dev] Open topics of prop247: Defending Against Guard Discovery Attacks using Vanguards

George Kadianakis wrote: > Hello, > > here is some background information and summarizing of proposal 247 > "Defending Against Guard Discovery Attacks using Vanguards" for people > who plan to work on this in the short-term future. > Hello, I have discussed in Amsterdam briefly with David

Re: [tor-dev] [RFC] Directory structure of prop224 onion services

Hi, David Goulet wrote: > On 30 Jan (16:16:07), George Kadianakis wrote: >> David Goulet writes: >> >>> On 26 Jan (15:05:26), George Kadianakis wrote: Hey list, >>> >>> Hi! >>> >>> First, big thanks for this write up! >>> with service-side prop224 implementation

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

Hello, George Kadianakis wrote: > grarpamp writes: > >> Skimming thread... >> >> Version or not is fine, provided if you want versions you >> know you must store the bits somewhere, or ensure regex >> parser rules to recognize and match an intrinsic version >> represented by

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

Hello, David Goulet wrote: > >> >> OK thanks for the useful discussion. I identified at least three feedback >> points: >> >> + Screw base58 it's not gonna work. We stick to base32. Usability will >> be "restored" with a proper name system. >> >> + Move version byte to the end of the address

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

Hello George, George Kadianakis wrote: > Hello list, > > we've had discussions over the past years about how to encode prop224 onion > addresses. Here is the latest thread: > https://lists.torproject.org/pipermail/tor-dev/2016-December/011734.html > > Bikeshedding is over; it's time to finally

Re: [tor-dev] sketch: An alternative prop224 authentication mechanism based on curve25519

ill >> make the life of our users harder if we can avoid it. > > I believe it can be addressed by a good UI in TBB mostly to fit this client > authorization proposal. Answers below. > >> >> s7r: >>> George Kadianakis wrote: >>>> I have a

Re: [tor-dev] [PATCH] torspec: Keep proposal-status.txt up to date

George Kadianakis wrote: > Hello, > > I was in a train yesterday and decided to do some torspec > housekeeping. So I updated the proposals/proposal-status.txt file which > includes a summary of every proposal. > > You can find my changes here: > >

Re: [tor-dev] prop224: What should we do with torrc options?

Hi, David Goulet wrote: > On 24 Nov (11:13:06), teor wrote: >> >>> On 24 Nov. 2016, at 11:04, Yawning Angel <yawn...@schwanenlied.me> wrote: >>> >>> On Thu, 24 Nov 2016 01:43:15 +0200 >>> s7r <s...@sky-ip.org> wrote: >>>&

Re: [tor-dev] sketch: An alternative prop224 authentication mechanism based on curve25519

Hello, George Kadianakis wrote: > Nick Mathewson writes: > >> [ text/plain ] >> Hi! I thought I'd write this up while it was fresh in my mind. It >> could be used as an alternative method to the current proposed client >> authentication mechanism. We could implement

Re: [tor-dev] prop224: What should we do with torrc options?

On 11/24/2016 2:24 AM, Jesse V wrote: > On 11/23/2016 07:04 PM, Yawning Angel wrote: >> Our fix: "Add another command, that does essentially the same thing, >> because people picked the wrong options, then later deal with the >> fallout from people getting used to the temporary command, and

Re: [tor-dev] prop224: What should we do with torrc options?

teor wrote: > >> >> Very good. We can add a new torrc option for ed25519 key based >> authentication for clients (v3) so the current >> HiddenServiceAuthorizeClient (v2) will not break old torrc's until >> everyone upgrades. >> >> However, we could just add an auth-type value after >>

Re: [tor-dev] prop224: What should we do with torrc options?

teor wrote: >>> >>> How does ADD_ONION fit in? >> >> It's forward compatible by design, since you have to specify a key type >> when you handle key management, and Tor gets to do whatever it wants if >> you ask it to generate a key with the `BEST` algorithm. >> >> Assuming people who use it

Re: [tor-dev] prop224: What should we do with torrc options?

Hello David, David Goulet wrote: > Hi everyone! > > We are soon at the stage of implementing the service part of proposal 224 > (next gen. hidden service.). Parent ticket is #20657 but I'll be discussing > here ticket #18054. > > In a nutshell, we need to figure out the interface for the torrc

Re: [tor-dev] Revisiting prop224 client authorization

teor wrote: > >> On 3 Nov. 2016, at 10:37, s7r <s...@sky-ip.org> wrote: >> >> I am very happy with the torspec patch. >> >> Not quoting entirely, only want to add something wrt randomizing the >> value for fake clients based on David's and teor's

Re: [tor-dev] Revisiting prop224 client authorization

I am very happy with the torspec patch. Not quoting entirely, only want to add something wrt randomizing the value for fake clients based on David's and teor's comments: David Goulet wrote: [SNIP] > > - I think "superencrypted" -> "super-encrypted" would be nicer as everything > in the

Re: [tor-dev] Revisiting prop224 client authorization

Hello George, Inline comments: > Hello again, > > I read the feedback on the thread and thought some more about this. Here > are some thoughts based on received feedback. A torspec branch coming > soon if people agree with my points below. > > I'd also like to introduce a new topic of

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

teor wrote: > >> On 7 Oct 2016, at 00:22, s7r <s...@sky-ip.org> wrote: >> >> I don't care about location anonymity because my >> website is clearnet public anyway and I want my website to handle many >> Tor users, just setup a bridge Tor instance on

Re: [tor-dev] Revisiting prop224 client authorization

Hi David, David Goulet wrote: > > Personally, I would really like to be able to hide the fact that a service is > using client authorization. Both could hide that but not that trivially. > > I would pick double encryption for the simple fact that I really want to us to > expose as little as we

Re: [tor-dev] Revisiting prop224 client authorization

Hi, George Kadianakis wrote: [SNIP] > >Some further questions here: > >i) Should we fake the client-auth-desc-key blob in case client > authorization > is not enabled? Otherwise, we leak to the HSDir whether client auth is > enabled. The drawback here is the desc size

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

Won't comment on the entire content because I have one big comment which refers to the entire proposal or better say the concept of the proposal. I would reject this proposal's concept, because we have o excuse to over-engineer and complicate things in this manner. This is just too complicated

Re: [tor-dev] Potential regression when binding sockets to interface without default route

Hello, On 9/19/2016 4:14 PM, René Mayrhofer wrote: [SNIP] > Problem: This worked nicely with Tor 0.2.5.12-1 on Debian Jessie. We > upgraded about two weeks ago to 0.2.8.7-1 from the Tor apt repositories > (mostly in response to > https://blog.torproject.org/blog/tor-0287-released-important-fixes

Re: [tor-dev] "old style" hidden services after Prop224

On 9/13/2016 3:27 PM, David Goulet wrote: [SNIP] > Hello! > > So I 100% share Ivan's concerns. The Hidden Service subsytem of Tor is quite > complex, lots of pieces need to be glued together and prop224 will add a lot > of new code (in the 10 of thousand+). > > We decided a while back to have

Re: [tor-dev] estimating traffic/bandwidth needed to run a Tor node

Razvan, Your email is confusing. To host a Hidden Service you do not need to be a Tor node - we call them relays in the common terminology. So, a relay relays traffic for Tor clients. This will consume as much as you give. You can throttle the relay bandwidth rate / burst or limit the traffic

Re: [tor-dev] prop224: HSDir caches question with OOM

Hello, On 4/16/2016 4:11 PM, David Goulet wrote: [snip] >> >> >> A third alternative is that we can iterate through each time period: >> Set K to the oldest expected descriptor age in hours, minus 1 hour >> Deallocate all entries from Cache A that are older than K hours >> Deallocate all entries

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

Hi, On 3/27/2016 1:00 PM, George Kadianakis wrote: >>[snip] >> >> https://lists.torproject.org/pipermail/tor-dev/2015-November/009871.html >> > > Hmm, this seems like something worth considering. > > IIUC you are basically suggesting using a single guardlist instead of having > two. And then

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

Hello, teor, asn, see comments inline. On 3/24/2016 5:00 PM, Tim Wilson-Brown - teor wrote: [snip] >>> The number of directory guards will increase when 0.2.8-stable is >>> released and relays and clients upgrade. >>> In 0.2.8, relays accept tunnelled directory connections even if they >>> do

Re: [tor-dev] Latency measurement from exits

Hello, I haven't measured that, but maybe this is helpful: I have measured some time ago was the latency in a hidden service (rendezvous) circuit: Client - guard - middle - rendezvous -- middle - middle - guard - HS [6 hops] I did the test by installing an OpenVPN TCP server on the hidden

Re: [tor-dev] Proposal xxx: Filtering malicious rendezvous points at hidden service server side

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi teor, On 1/24/2016 6:33 AM, Tim Wilson-Brown - teor wrote: > Please read the tor man page documentation for the option > Tor2webRendezvousPoints. It's implemented in the function > pick_tor2web_rendezvous_node(). > > Under this proposal, what

[tor-dev] Proposal xxx: Filtering malicious rendezvous points at hidden service server side

better next time. Filename: xxx-malicious-rendezvous-point-filter.txt Title: Filtering malicious rendezvous points at hidden service server side Authors: s7r [ 0x837FA52C81265B11 ] Created: 23 January 2016 Status: Draft 0. Definitions client = an user running Tor as a client, which connects

Re: [tor-dev] Proposal xxx: Filtering malicious rendezvous points at hidden service server side

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 1/24/2016 12:10 AM, Roger Dingledine wrote: > > A few more details about "this is not always enough" would be > helpful here. In particular, is it not always enough because > sometimes even 3 hops is not safe enough, or not always enough >

Re: [tor-dev] Proposal xxx: Filtering malicious rendezvous points at hidden service server side

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hello Mike, Answers inline. On 1/24/2016 1:56 AM, Mike Perry wrote: >>> A) Can I deny service to a hidden service by methodically >>> pretending to attack it from each honest relay, one at a time, >>> causing it to become upset at each of these

Re: [tor-dev] Proposal xxx: Filtering malicious rendezvous points at hidden service server side

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 1/24/2016 1:51 AM, Tim Wilson-Brown - teor wrote: > >> On 24 Jan 2016, at 09:28, s7r <s...@sky-ip.org >> <mailto:s...@sky-ip.org>> wrote: >> >>> * This will break some Tor2Web installations, which

Re: [tor-dev] Proposal xxx: Filtering malicious rendezvous points at hidden service server side

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Sorry for posting 2 times, want to highlight something which doesn't read clear. On 1/24/2016 4:44 AM, s7r wrote: > Consider this. We set the REND_FILTER_TOLERANCE to 4. This means > that any relay, regardless of its middle probability fr

Re: [tor-dev] Much-revised draft, RFC: removing current obsolete clients from the network

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hello, I think the solution to change the consensus format - section 3.3 is by far superior vs changing the ports on directory authorities or disabling old link protocols at relays side. Changing the consensus format is the cleanest way to do it

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

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hello, I am not a big fan of prop 246. I don't have a mindblowing counter argument that it's bad in some way, but I don't like the tradeoffs vs benefits ratio so much. It is a small performance improvement indeed, so clients will not cache

Re: [tor-dev] Quantum-safe Hybrid handshake for Tor

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 1/3/2016 11:24 PM, Ryan Carboni wrote: > > Given the slow time it takes to roll things out, a timeline which > begins with trusted directory keys include post-quantum crypto > first, and which ends in enabling clients to use post-quantum >

Re: [tor-dev] tor ignores --SigningKeyLifetime when keys exist

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 11/28/2015 2:26 PM, nusenu wrote: > The important info for me here is: How is "about to expire" > defined? x days before expiry or I think 24 hours before expiry. > 80% of its lifetime is over? No. > Can it be configured? No. This would not

Re: [tor-dev] tor ignores --SigningKeyLifetime when keys exist

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 11/28/2015 1:48 PM, nusenu wrote: > (thread split from [1]) > > reproducer: mkdir tdata tor --PublishServerDescriptor 0 --orport > 1234 --datadirectory tdata --list-fingerprint --quiet > > (new signing key with default expiry created) > >

Re: [tor-dev] documentation for new offline master key functionality (--keygen is undocumented)

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, I have actually tried this in practice to see what happens. If you replace the ed25519 medium term singing key and certificate in $datadirectory/keys, Tor will re-read keys from disk even if you don't send a SIGHUP when it outputs: [notice]

Re: [tor-dev] OfflineMasterKey / ansible-relayor

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 11/19/2015 12:19 AM, nusenu wrote: >> background: I might want to integrate offline master key >> functionality into ansible-relayor [1]. > > I added (preliminary) OfflineMasterKey support to ansible-relayor > [1] - in fact it will become the

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

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hello, Saw the content of this section in master was corrected, yet the subtitle is little confusing: 4.1.6. Including the ed25519 shared randomness key in votes [SRKEY] - From the content of this section I understand that we are going to include

Re: [tor-dev] possible to run --keygen non-interactively?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Oh, right - sorry, misunderstood. In this case not using --keygen might be a workaround. I do understand the use of --nopass, I'll include it in the ticket and maybe we can have it along with --master-key and --out. On 11/15/2015 5:36 PM, nusenu

Re: [tor-dev] possible to run --keygen non-interactively?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 The "Enter passphrase" request when manually calling --keygen is optional, not mandatory. If you just leave it blank and proceed it will just create an unencrypted master identity key. On 11/14/2015 10:18 AM, nusenu wrote: > Hi, > > is there a way

Re: [tor-dev] documentation for new offline master key functionality (--keygen is undocumented)

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 11/13/2015 8:51 PM, nusenu wrote: > Hi, > > since tor 0.2.7.5 is apparently not very far [1] from being > released I was wondering whether there is any documentation about > the new offline master key functionality? (or is this undocumented >

Re: [tor-dev] Alternate Single Onion Service Designs

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi teor, I like RSOS more and it removes 2 hops from a circuit which is quite A LOT. This is a significant step for operators that require latency. RSOS combined with OnionBalance or rendezvous approval feature which will allow scaling beyond

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

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi isis, I am also not sure if we should have DYSTOPIC_GUARDS and UTOPIC_GUARDS sets disjoint. It hurts the already fragile load balancing for Guards and will cause lighter load on FascistFirewall Guards (ports 80/443). I think usually users behind

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

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 asn, Is it possible to add a field called 'NOTARY' in the COMMIT and REVEAL values where we include the SR pubkey + certificates and everything we need so that we can validate each COMMIT / REVEAL value and tie it to the identity of a directory

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

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hello, Epic work. I agree that the code enforcing commit majority was not making a difference in the partition attack. I also agree that the partition attack is (almost) useless, expensive and very noisy. An attacker can get the same result if,

Re: [tor-dev] adding smartcard support to Tor

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hello Razvan, What you try to achieve is possible. It can be done, but requires code to be written. If you are really interested about this feature you can either sponsor someone to write the code for it either code it yourself. The 1024 bit RSA

[tor-dev] Effect of padding on end to end correlation false positive rate

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hello, I have an idea which I want to put into a proposal, but need a clarification first so I won't be working on something which doesn't make a big difference. I am describing something like a Sybil attack where the adversary runs relays, gets

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

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, I like this very much. See comments inline. On 9/14/2015 2:07 AM, Mike Perry wrote: > I spent some time trying to clean up proposal 247 based on > everyone's comments, as well as based on my own thoughts. Please > have a look if you commented

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

tamp, without requiring the > whole vote signature. This is required to do shared-rand-conflict > and might be useful in any case in the future. > > I made a patch that implements this for prop250 at: > > https://gitweb.torproject.org/user/asn/torspec.git/commit/?h=prop250-nosrdoc-s

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

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 I disagree. can you describe how exactly? What exactly can be gamed, if we use the protection described by me? It will provide the same security as directory authorities already have for voting about relays. It's true that ultimately anything can be

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

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, Sending the comments from #tor-dev here as well. This is related to the attack where exactly half of the directory authorities commit to some values, and the last directory authority can send different values to both camps, and have the

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

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, On 8/20/2015 2:28 PM, George Kadianakis wrote: Hello there, recently we've been busy specifying various important improvements to entry guard security. For instance see proposals 250, 241 and ticket #16861. Unfortunately, the current

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

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, Worth mentioning, after #15745 we rotate the introduction points after between 16384 and 32768 (random) introductions and/or a lifetime of 18 to 24 hours (random). If we merge introduction points with HSDirs, we have no option but to use the

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

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, Thanks for the input! On 8/20/2015 4:59 PM, l.m wrote: b) ... Retrying guards is the crux of the problem. If you blindly retry guards, even to prevent rotation, you eventually come to a hard place where this will backfire badly. Even

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

, s7r wrote: Hi, On 8/20/2015 2:28 PM, George Kadianakis wrote: Hello there, recently we've been busy specifying various important improvements to entry guard security. For instance see proposals 250, 241 and ticket #16861. Unfortunately, the current guard codebase is dusty and full

Re: [tor-dev] Tor's default behavior for ed25519 identities

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, Things look good in ed25519_keygen - git-018082ef88b688e2. I can confirm the last defect was fixed (now it saves to disk ed25519_master_id_public_key if it only has ed25519_signing_cert - valid and ed25519_signing_secret_key). Log messages

Re: [tor-dev] Tor's default behavior for ed25519 identities

/2015 12:18 AM, s7r wrote: Thanks; this is incredibly helpful! I've started a branch to do a test case to demonstrate all these bugs ; it's called ed25519_keygen in my public repository. It also adds a couple more features to '--keygen'. It does cases 2...4 so far; I want to make it cover 5

Re: [tor-dev] Tor's default behavior for ed25519 identities

and signing_secret_key and/or even if it has the ed25519_master_id_secret_key unencrypted). These commands would be useful as well: --getpubkey; --encryptkey; - --decryptkey; --newpass; --gensignkey. On 8/6/2015 4:14 AM, Nick Mathewson wrote: On Tue, Aug 4, 2015 at 8:24 PM, s7r s...@sky-ip.org

Re: [tor-dev] Tor's default behavior for ed25519 identities

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 8/4/2015 5:42 PM, Nick Mathewson wrote: Hi, s7r! This is an impressive writeup; thanks! One thing that makes it hard for me to follow this document is that I'm not sure which parts are describing how things work _now_, and which parts

[tor-dev] Tor's default behavior for ed25519 identities

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, Tor 0.2.7.x will support Ed25519 router identities along with the traditional 1024-bit RSA ones which will be used simultaneously for some time, until we will completely deprecate RSA router identities. I would like to document what Tor needs

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

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 7/19/2015 9:26 AM, Roger Dingledine wrote: On Sat, Jul 18, 2015 at 03:11:26AM +0300, s7r wrote: I still see the third hop (speaking from hidden service server start point) is the weak part here. An attacker can connect to a hidden service

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

at this point. Best, Aaron On Jul 17, 2015, at 8:11 PM, s7r s...@sky-ip.org wrote: Signed PGP part On 7/18/2015 12:49 AM, A. Johnson wrote: Not having the thir d guards be selected by every second guard makes sense when you consider that the adversary may not be able to compromise all relays

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

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 7/18/2015 12:49 AM, A. Johnson wrote: Not having the third guards be selected by every second guard makes sense when you consider that the adversary may not be able to compromise all relays equally. That was not a consideration I had in

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

Comments inline. On 7/16/2015 7:26 AM, Mike Perry wrote: George Kadianakis: Hello, I'm attaching a proposal draft that should help us defend against guard discovery attacks. There are a few pieces left unfinished (see the XXXs) but I decided to release early and release often for the sake

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

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hello, Estimations look good. I think second_guard_set third_guard_set should not have the same requirements like how any Tor client chooses the guard (first hop). We can select second guards and third guards by requiring for example just Stable

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

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 I find it better to add a new consensus flag called 'Vanguard' which will be assigned to relays with lower requirements than the 'Guard' (less bandwidth, just the Stable flag). We will then select second_guard_set and third_guard_set from relays

[tor-dev] update obfs4proxy in deb.torproject.org

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, An update is needed in http:// deb.torproject.org/torproject.org obfs4proxy main to version 0.0.5 (we currently have 0.0.4). armel and amrhf packages for obfs4proxy would be nice too, for mobiles/tablets/raspberrys etc. Also, why do we have

Re: [tor-dev] valid MyFamily syntax variations ('$FP=nick' ?)

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, That would be invalid. I know there are some families which do it. You are free to enter a nickname at MyFamily parameter in your torrc, but it won't actually work for clients. Tor will still start on relay side and go on with it. It used to

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

On 3/28/2015 4:34 AM, A. Johnson wrote: Would you still set a max lifetime for a circuit to accept new streams of 2 hours, or would the circuit potentially persist forever? Nick set a max lifetime in his updated version of the patch that also deals with non-Tor Browser activity, but I am

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

Indeed, it would be better if this customization will only apply to circuits requested by Tor Browser (web pages, etc.). Many people just keep Tor Browser running in order to open the Tor socks5 port on localhost, and use that socks proxy with other applications/protocols. Are there any clear

Re: [tor-dev] Tor Attack Implementations (Master's Thesis: Tor Mixes)

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2/8/2015 11:39 PM, George Kadianakis wrote: Florian Rüchel florian.ruechel@inexplicity.de writes: Hi everyone, I have taken some time and considered my topic for the Master's Thesis. I have finally decided to write it on

[tor-dev] Vidalia Relay Bundle(win) Tor version, obfs4proxy package in deb.tp.o

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 1. I have noticed that the Vidalia Relay Bundles for Windows available to download on torproject.org are using Tor 0.2.4.23, while we are on 0.2.5.10 as stable branch. I know 0.2.4.23 is still on the recommended list in the consensus, but since

Re: [tor-dev] obfs4proxy package in deb.tp.o

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/26/2014 7:56 PM, Lunar wrote: s7r: 2. Configured some obfs4 bridges using obfs4proxy. They work very good, however it's a little bit complicated since package obfs4proxy exists in Debian sid, but not in deb.torproject.org, so you have