tor-dev February 2021

tor-dev@lists.torproject.org

9 participants
9 discussions

the consequences of deprecating debian alpha repos with every new major branch
by nusenu 21 Dec '21

21 Dec '21

Hi, tldr: - more outdated relays (that is a claim I'm making and you could easily proof me wrong by recreating the 0.3.3.x alpha repos and ship 0.3.3.7 in them and see how things evolve after a week or so) - more work for the tpo website maintainer - less happy relay operators [3][4] - more work for repo maintainers? (since a new repo needs to be created) When the tor 0.3.4 alpha repos (deb.torproject.org) first appeared on 2018-05-23 I was about to submit a PR for the website to include it in the sources.list generator [1] on tpo but didn't do it because I wanted to wait for a previous PR to be merged first. The outstanding PR got merged eventually (2018-06-28) but I still did not submit a PR to update the repo generator for 0.3.4.x nonetheless and here is why. Recently I was wondering why are there so many relays running tor version 0.3.3.5-rc? (see OrNetStats or Relay Search) (> 3.2% CW fraction) Then I realized that this was the last version the tor-experimental-0.3.3.x-* repos were shipping before they got abandoned due to the new 0.3.4.x-* repos (I can no longer verify it since they got removed by now). Peter made it clear in the past that the current way to have per-major-version debian alpha repos (i.e. tor-experimental-0.3.4.x-jessie) will not change [2]: > If you can't be bothered to change your sources.list once or twice a > year, then you probably should be running stable. but maybe someone else would be willing to invoke a "ln" commands everytime a new new alpha repo is born. tor-alpha-jessie -> tor-experimental-0.3.4.x-jessie once 0.3.5.x repos are created the link would point to tor-alpha-jessie -> tor-experimental-0.3.5.x-jessie It is my opinion that this will help reduce the amount of relays running outdated versions of tor. It will certainly avoid having to update the tpo website, which isn't a big task and could probably be automated but it isn't done currently. "..but that would cause relay operators to jump from i.e. 0.3.3.x to 0.3.4.x alphas (and break setups)!" Yes, and I think that is better than relays stuck on an older version because the former repo no longer exists and operators still can choose the old repos which will not jump to newer major versions. [1] https://www.torproject.org/docs/debian.html.en#ubuntu [2] https://trac.torproject.org/projects/tor/ticket/14997#comment:3 [3] https://lists.torproject.org/pipermail/tor-relays/2018-June/015549.html [4] https://trac.torproject.org/projects/tor/ticket/26474 -- https://twitter.com/nusenu_ https://mastodon.social/@nusenu

4 7

IANA well-known URI suffix registration for tor-relay-fingerprints file
by nusenu 10 Oct '21

10 Oct '21

Hi, to reduce the risk of certain kinds of attacks I'm aiming to submit a short spec (like [1]) in accordance with RFC8615 https://tools.ietf.org/html/rfc8615#section-3.1 for the registration of of a suffix for the verifyurl from https://github.com/nusenu/ContactInfo-Information-Sharing-Specification#ver… The name I have in mind is: tor-relay-fingerprints The file contains comments (lines starting with #) and relay fingerprints. https://www.iana.org/assignments/well-known-uris/well-known-uris.xhtml Let me know if you have any feedback on this and whether you have any opinion on whether you (The Torproject) wants to be the change controller. The only question that came up was: Will there be two types of relay fingerprints in the future (Ed25519)? thanks, nusenu -- https://mastodon.social/@nusenu [1] https://keybase.io/docs/keybase_well_known

5 22

[RFC] Proposal: "Res tokens: Anonymous Credentials for Onion Service DoS Resilience"
by George Kadianakis 13 Jun '21

13 Jun '21

Hello all, after lots of investigation on anonymous credentials, we are glad to present you with a draft of the onion services anti-DoS proposal using tokens. While the basic idea of the proposal should remain reasonably solid, there are various XXX sprinkled around the proposal and some of them definitely need to be addressed before the proposal becomes truly usable. We are particularly looking forward to feedback about: - Token issuance services - The anonymous credential scheme chosen - The XXXs and design decisions of the proposal Hope you have a pleasant read! --- ``` Filename: 331-res-tokens-for-anti-dos.md Title: Res tokens: Anonymous Credentials for Onion Service DoS Resilience Author: George Kadianakis, Mike Perry Created: 11-02-2021 Status: Draft ``` +--------------+ +------------------+ | Token Issuer | | Onion Service | +--------------+ +------------------+ ^ ^ | +----------+ | Issuance | 1. | | 2. | Redemption +------->| Alice |<-------+ | | +----------+ # 0. Introduction This proposal specifies a simple anonymous credential scheme based on Blind RSA signatures designed to fight DoS abuse against onion services. We call the scheme "Res tokens". Res tokens are issued by third-party issuance services, and are verified by onion services during the introduction protocol (through the INTRODUCE1 cell). While Res tokens are used for denial of service protection in this proposal, we demonstrate how they can have application in other Tor areas as well, like improving the IP reputation of Tor exit nodes. # 1. Motivation Denial of service attacks against onion services have been explored in the past and various defenses have been proposed: - Tor proposal #305 specifies network-level rate-limiting mechanisms. - Onionbalance allows operators to scale their onions horizontally. - Tor proposal #327 increases the attacker's computational requirements (not implemented yet). While the above proposals in tandem should provide reasonable protection against many DoS attackers, they fundamentally work by reducing the assymetry between the onion service and the attacker. This won't work if the attacker is extremely powerful because the assymetry is already huge and cutting it down does not help. we believe that a proposal based on cryptographic guarantees -- like Res tokens -- can offer protection against even extremely strong attackers. # 2. Overview In this proposal we introduce an anonymous credential scheme -- Res tokens -- that is well fitted for protecting onion services against DoS attacks. We also introduce a system where clients can acquire such anonymous credentials from various types of Token Issuers and then redeem them at the onion service to gain access even when under DoS conditions. In section [TOKEN_DESIGN], we list our requirements from an anonymous credential scheme and provide a high-level overview of how the Res token scheme works. In section [PROTOCOL_SPEC], we specify the token issuance and redemption protocols, as well as the mathematical operations that need to be conducted for these to work. In section [TOKEN_ISSUERS], we provide a few examples and guidelines for various token issuer services that could exist. In section [DISCUSSION], we provide more use cases for Res tokens as well as future improvements we can conduct to the scheme. # 3. Design [TOKEN_DESIGN] In this section we will go over the high-level design of the system, and on the next section we will delve into the lower-level details of the protocol. ## 3.1. Anonymous credentials Anonymous credentials or tokens are cryptographic identifiers that allow their bearer to maintain an identity while also preserving anonymity. Clients can acquire a token in a variety of ways (e.g. registering on a third-party service, solving a CAPTCHA, completing a PoW puzzle) and then redeem it at the onion service proving this way that work was done, but without linking the act of token acquisition with the act of token redemption. ## 3.2. Anonymous credential properties The anonymous credential literature is vast and there are dozens of credential schemes with different properties [REF_TOKEN_ZOO], in this section we detail the properties we care about for this use case: - Public Verifiability: Because of the distributed trust properties of the Tor network, we need anonymous credentials that can be issued by one party (the token issuer) and verified by a different party (in this case the onion service). - Perfect unlinkability: Unlinkability between token issuance and token redemption is vital in private settings like Tor. For this reason we want our scheme to preserve its unlinkability even if its fundamental security assumption is broken. We want unlinkability to be protected by information theoretic security or random oracle, and not just computational security. - Small token size: The tokens will be transfered to the service through the INTRODUCE1 cell which is not flexible and has only a limited amount of space (about 200 bytes) [REF_INTRO_SPACE]. We need tokens to be small. - Quick Verification: Onions are already experiencing resource starvation because of the DoS attacks so it's important that the process of verifying a token should be as quick as possible. In section [TOKEN_PERF] we will go deeper into this requirement. After careful consideration of the above requirements, we have leaned towards using Blind RSA as the primitive for our tokens, since it's the fastest scheme by far that also allows public verifiability. See also Appendix B [BLIND_RSA_PROOF] for a security proof sketch of Blind RSA perfect unlinkability. ## 3.3. Other security considerations Apart from the above properties we also want: - Double spending protection: We don't want Malory to be able to double spend her tokens in various onion services thereby amplifying her attack. For this reason our tokens are not global, and can only be redeemed at a specific destination onion service. - Metadata: We want to encode metadata/attributes in the tokens. In particular, we want to encode the destination onion service and an expiration date. For more information see section [DEST_DIGEST]. For blind RSA tokens this is usually done using "partially blind signatures" but to keep it simple we instead encode the destination directly in the message to be blind-signed and the expiration date using a set of rotating signing keys. - One-show: There are anonymous credential schemes with multi-show support where one token can be used multiple times in an unlinkable fashion. However, that might allow an adversary to use a single token to launch a DoS attack, since revocation solutions are complex and inefficient in anonymous credentials. For this reason, in this work we use one-show tokens that can only be redeemed once. That takes care of the revocation problem but it means that a client will have to get more tokens periodically. ## 3.4. Res tokens overview Throughout this proposal we will be using our own token scheme, named "Res", which is based on blind RSA signatures. In this modern cryptographic world, not only we have the audacity of using Chaum's oldest blind signature scheme of all times, but we are also using RSA with a modulus of 1024 bits... The reason that Res uses only 1024-bits RSA is because we care most about small token size and quick verification rather than the unforgeability of the token. This means that if the attacker breaks the issuer's RSA signing key and issues tokens for herself, this will enable the adversary to launch DoS attacks against onion services, but it won't allow her to link users (because of the "perfect unlinkability" property). Furthermore, Res tokens get a short implicit expiration date by having the issuer rapidly rotate issuance keys every few hours. This means that even if an adversary breaks an issuance key, she will be able to forge tokens for just a few hours before that key expires. For more ideas on future schemes and improvements see section [FUTURE_RES]. ## 3.5. Token performance requirements [TOKEN_PERF] As discussed above, verification performance is extremely important in the anti-DoS use case. In this section we provide some concrete numbers on what we are looking for. In proposal #327 [REF_POW_PERF] we measured that the total time spent by the onion service on processing a single INTRODUCE2 cell ranges from 5 msec to 15 msecs with a mean time around 5.29 msec. This time also includes the launch of a rendezvous circuit, but does not include the additional blocking and time it takes to process future cells from the rendezvous point. We also measured that the parsing and validation of INTRODUCE2 cell ("top half") takes around 0.26 msec; that's the lightweight part before the onion service decides to open a rendezvous circuit and do all the path selection and networking. This means that any defenses introduced by this proposal should add minimal overhead to the above "top half" procedure, so as to apply access control in the lightest way possible. For this reason we implemented a basic version of the Res token scheme in Rust and benchmarked the verification and issuance procedure [REF_RES_BENCH]. We measured that the verification procedure from section [RES_VERIFY] takes about 0.104 ms, which we believe is a reasonable verification overhead for the purposes of this proposal. We also measured that the issuance procedure from [RES_ISSUANCE] takes about 0.614 ms. # 4. Specification [PROTOCOL_SPEC] +--------------+ +------------------+ | Token Issuer | | Onion Service | +--------------+ +------------------+ ^ ^ | +----------+ | Issuance | 1. | | 2. | Redemption +------->| Alice |<-------+ | | +----------+ ## 4.0. Notation Let `a || b` be the concatenation of a with b. Let `a^b` denote the exponentiation of a to the bth power. Let `a == b` denote a check for equality between a and b. Let FDH_N(msg) be a Full Domain Hash (FDH) of 'msg' using SHA256 and stretching the digest to be equal to the size of an RSA modulus N. ## 4.1. Token issuer setup The Issuer creates a set of ephemeral RSA-1024 "issuance keys" that will be used during the issuance protocol. Issuers will be rotating these ephemeral keys every 6 hours. The Issuer exposes the set of active issuance public keys through a REST HTTP API that can be accessed by visiting /issuers.keys. Tor directory authorities periodically fetch the issuer's public keys and vote for those keys in the consensus so that they are readily available by clients. The keys in the current consensus are considered active, whereas the ones that have fallen off have expired. XXX how many issuance public keys are active each time? how does overlapping keys work? clients and onions need to know precise expiration date for each key. this needs to be specified and tested for robustness. XXX every how often does the fetch work? how does the voting work? which issuers are considered official? specify consensus method. XXX An alternative approach: Issuer has a long-term ed25519 certification key that creates expiring certificates for the ephemeral issuance keys. Alice shows the certificate to the service to prove that the token comes from an issuer. The consensus includes the long-term certification key of the issuers to establish ground truth. This way we avoid the synchronization between dirauths and issuers, and the multiple overlapping active issuance keys. However, certificates might not fit in the INTRODUCE1 cell (prop220 certs take 104 bytes on their own). Also certificate metadata might create a vector for linkability attacks between the issuer and the verifier. ## 4.2. Onion service signals ongoing DoS attack When an onion service is under DoS attack it adds the following line in the "encrypted" (inner) part of the v3 descriptor as a way to signal to its clients that tokens are required for gaining access: "token-required" SP token-type SP issuer-list NL [At most once] token-type: Is the type of token supported ("res" for this proposal) issuer: A comma separated list of issuers which are supported by this onion service ## 4.3. Token issuance When Alice visits an onion service with an active "token-required" line in its descriptor it checks whether there are any tokens available for this onion service in its token store. If not, it needs to acquire some and hence the token issuance protocol commences. ### 4.3.1. Client preparation [DEST_DIGEST] Alice first chooses an issuer supported by the onion service depending on her preferences by looking at the consensus and her Tor configuration file for the current list of active issuers. After picking a supported issuer, she performs the following preparation before contacting the issuer: 1) Alice extracts the issuer's public key (N,e) from the consensus 2) Alice computes a destination digest as follows: dest_digest = FDH_N(destination || salt) where: - 'destination' is the 32-byte ed25519 public identity key of the destination onion - 'salt' is a random 32-byte value, 3) Alice samples a blinding factor 'r' uniformly at random from [1, N) 4) Alice computes: blinded_message = dest_digest * r^e (mod N) After this phase is completed, Alice has a blinded message that is tailored specifically for the destination onion service. Alice will send the blinded message to the Token Issuer, but because of the blinding the Issuer does not get to learn the dest_digest value. XXX Is the salt needed? Reevaluate. ### 4.3.3. Token Issuance [RES_ISSUANCE] Alice now initiates contact with the Token Issuer and spends the resources required to get issued a token (e.g. solve a CAPTCHA or a PoW, create an account, etc.). After that step is complete, Alice sends the blinded_message to the issuer through a JSON-RPC API. After the Issuer receives the blinded_message it signs it as follows: blinded_signature = blinded_message ^ d (mod N) where: - 'd' is the private RSA exponent. and returns the blinded_signature to Alice. XXX specify API (JSON-RPC? Needs SSL + pubkey pinning.) ### 4.3.4. Unblinding step Alice verifies the received blinded signature, and unblinds it to get the final token as follows: token = blinded_signature * r^{-1} (mod N) = blinded_message ^ d * r^{-1] (mod N) = (dest_digest * r^e) ^d * r^{-1} (mod N) = dest_digest ^ d * r * r^{-1} (mod N) = dest_digest ^ d (mod N) where: - r^{-1} is the multiplicative inverse of the blinding factor 'r' Alice will now use the 'token' to get access to the onion service. By verifying the received signature using the issuer keys in the consensus, Alice ensures that a legitimate token was received and that it has not expired (since the issuer keys are still in the consensus). ## 4.4. Token redemption ### 4.4.1. Alice sends token to onion service Now that Alice has a valid 'token' it can request access to the onion service. It does so by embedding the token into the INTRODUCE1 cell to the onion service. To do so, Alice adds an extension to the encrypted portion of the INTRODUCE1 cell by using the EXTENSIONS field (see [PROCESS_INTRO2] section in rend-spec-v3.txt). The encrypted portion of the INTRODUCE1 cell only gets read by the onion service and is ignored by the introduction point. We propose a new EXT_FIELD_TYPE value: [02] -- ANON_TOKEN The EXT_FIELD content format is: TOKEN_VERSION [1 byte] ISSUER_KEY [4 bytes] DEST_DIGEST [32 bytes] TOKEN [128 bytes] SALT [32 bytes] where: - TOKEN_VERSION is the version of the token ([0x01] for Res tokens) - ISSUER_KEY is the public key of the chosen issuer (truncated to 4 bytes) - DEST_DIGEST is the 'dest_digest' from above - TOKEN is the 'token' from above - SALT is the 32-byte 'salt' added during blinding This will increase the INTRODUCE1 payload size by 199 bytes since the data above is 197 bytes, the extension type and length is 2 extra bytes, and the N_EXTENSIONS field is always present. According to ticket #33650, INTRODUCE1 cells currently have more than 200 bytes available so we should be able to fit the above fields in the cell. XXX maybe we don't need to pass DEST_DIGEST and we can just derive it XXX maybe with a bit of tweaking we can even use a 1536-bit RSA signature here... ### 4.4.2. Onion service verifies token [RES_VERIFY] Upon receiving an INTRODUCE1 cell with the above extension the service verifies the token. It does so as follows: 1) The service checks its double spend protection cache for an element that matches DEST_DIGEST. If one is found, verification fails. 2) The service checks: DEST_DIGEST == FDH_N(service_pubkey || SALT), where 'service_pubkey' is its own long-term identity pubkey. 3) The service finds the corresponding issuer pubkey 'e' based on ISSUER_KEY from the consensus or its configuration file 4) The service checks: TOKEN ^ e == DEST_DIGEST Finally the onion service adds the DEST_DIGEST to its double spend protection cache to avoid the same token getting redeemed twice. Onion services keep a double spend protection cache by maintaining a sorted array of truncated DEST_DIGEST elements. If any of the above steps fail, the verification process aborts and the introduction request gets discarded. If all the above verification steps have been completed successfully, the service knows that this a valid token issued by the token issuer, and that the token has been created for this onion service specifically. The service considers the token valid and the rest of the onion service protocol carries out as normal. # 5. Token issuers [TOKEN_ISSUERS] In this section we go over some example token issuers. While we can have official token issuers that are supported by the Tor directory authorities, it is also possible to have unofficial token issuers between communities that can be embedded directly into the configuration file of the onion service and the client. In general, we consider the design of token issuers to be independent from this proposal so we will touch the topic but not go too deep into it. ## 5.1. CAPTCHA token issuer A use case resembling the setup of Cloudflare's PrivacyPass would be to have a CAPTCHA service that issues tokens after a successful CAPTCHA solution. Tor Project, Inc runs https://ctokens.torproject.org which serves hCaptcha CAPTCHAs. When the user solves a CAPTCHA the server gives back a list of tokens. The amount of tokens rewarded for each solution can be tuned based on abuse level. Clients reach this service via a regular Tor Exit connection, possibly via a dedicated exit enclave-like relay that can only connect to https://ctokens.torproject.org. Upon receiving tokens, Tor Browser delivers them to the Tor client via the control port, which then stores the tokens into a token cache to be used when connecting to onion services. In terms of UX, most of the above procedure can be hidden from the user by having Tor Browser do most of the things under the scenes and only present the CAPTCHA to the user if/when needed (if the user doesn't have tokens available for that destination). XXX specify control port API between browser and tor ## 5.2. PoW token issuer An idea that mixes the CAPTCHA issuer with proposal#327, would be to have a token issuer that accepts PoW solutions and provides tokens as a reward. This solution tends to be less optimal than applying proposal#327 directly because it doesn't allow us to fine-tune the PoW difficulty based on the attack severity; which is something we are able to do with proposal#327. However, we can use the fact that token issuance happens over HTTP to introduce more advanced PoW-based concepts. For example, we can design token issuers that accept blockchain shares as a reward for tokens. For example, a system like Monero's Primo could be used to provide DoS protection and also incentivize the token issuer by being able to use those shares for pool mining [REF_PRIMO]. ## 5.3. Onion service self-issuing The onion service itself can also issue tokens to its users and then use itself as an issuer for verification. This way it can reward trusted users by giving it tokens for the future. The tokens can be rewarded from within the website of the onion service and passed to the Tor Client through the control port, or they can be provided in an out-of-bands way for future use (e.g. from a journalist to a future source using a QR code). Unfortunately, the anonymous credential scheme specified in this proposal is one-show, so the onion service cannot provide a single token that will work for multiple "logins". In the future we can design multi-show credential systems that also have revocation to further facilitate this use case (see [FUTURE_RES] for more info). # 6. User Experience This proposal has user facing UX consequences. Ideally we want this process to be invisible to the user and things to "just work". This can be achieved with token issuers that don't require manual work by the user (e.g. the PoW issuer, or the onion service itself), since both the token issuance and the token redemption protocols don't require any manual work. In the cases where manual work is needed by the user (e.g. solving a CAPTCHA) it's ideal if the work is presented to the user right before visiting the destination and only if it's absolutely required. An explanation about the service being under attack should be given to the user when the CAPTCHA is provided. # 7. Security In this section we analyze potential security threats of the above system: - An evil client can hoard tokens for hours and unleash them all at once to cause a denial of service attack. We might want to make the key rotation even more frequent if we think that's a possible threat. - A trusted token issuer can always DoS an onion service by forging tokens. - Overwhelming attacks like "top half attacks" and "hybrid attacks" from proposal#327 is valid for this proposal as well. - A bad RNG can completely wreck the linkability properties of this proposal. XXX Actually analyze the above if we think there is merit to listing them # 8. Discussion [DISCUSSION] ## 8.1. Using Res tokens on Exit relays There are more scenarios within Tor that could benefit from Res tokens however we didn't expand on those use cases to keep the proposal short. In the future, we might want to split this document into two proposals: one proposal that specifies the token scheme, and another that specifies how to use it in the context of onion servicves, so that we can then write more proposals that use the token scheme as a primitive. An extremely relevant use case would be to use Res tokens as a way to protect and improve the IP reputation of Exit relays. We can introduce an exit pool that requires tokens in exchange for circuit streams. The idea is that exits that require tokens will see less abuse, and will not have low scores in the various IP address reputation systems that now govern who gets access to websites and web services on the public Internet. We hope that this way we will see less websites blocking Tor. ## 8.2. Future improvements to this proposal [FUTURE_RES] The Res token scheme is a pragmatic scheme that works for the space/time constraints of this use case but it's far from ideal for the greater future (RSA? RSA-1024?). After Tor proposal#319 gets implemented we will be able to pack more data in RELAY cells and that opens the door to token schemes with bigger token sizes. For example, we could design schemes based on BBS+ that can provide more advanced features like multi-show and complex attributes but currently have bigger token sizes (300+ bytes). That would greatly improve UX since the client won't have to solve multiple CAPTCHAs to gain access. Unfortunately, another problem here is that right now pairing-based schemes have significantly worse verification performance than RSA (e.g. in the order of 4-5 ms compared to <0.5 ms). We expect pairing-based cryptography performance to only improve in the future and we are looking forward to these advances. When we switch to a multi-show scheme, we will also need revocation support otherwise a single client can abuse the service with a single multi-show token. To achieve this we would need to use blacklisting schemes based on accumulators (or other primitives) that can provide more flexible revocation and blacklisting; however these come at the cost of additional verification time which is not something we can spare at this time. We warmly welcome research on revocation schemes that are lightweight on the verification side but can be heavy on the proving side. ## 8.3. Other uses for tokens in Tor There is more use cases for tokens in Tor but we think that other token schemes with different properties would be better suited for those. In particular we could use tokens as authentication mechanisms for logging into services (e.g. acquiring bridges, or logging into Wikipedia). However for those use cases we would ideally need multi-show tokens with revocation support. We can also introduce token schemes that help us build a secure name system for onion services. We hope that more research will be done on how to combine various token schemes together, and how we can maintain agility while using schemes with different primitives and properties. # 9. Acknowledgements Thanks to Jeff Burdges for all the information about Blind RSA and anonymous credentials. Thanks to Michele Orrù for the help with the unlinkability proof and for the discussions about anonymous credentials. Thanks to Chelsea Komlo for pointing towards anonymous credentials in the context of DoS defenses for onion services. --- # Appendix A: RSA Blinding Security Proof [BLIND_RSA_PROOF] This proof sketch was provided by Michele Orrù: ``` RSA Blind Sigs: https://en.wikipedia.org/wiki/Blind_signature#Blind_RSA_signatures As you say, blind RSA should be perfectly blind. I tried to look at Boneh-Shoup, Katz-Lindell, and Bellare-Goldwasser for a proof, but didn't find any :( The basic idea is proving that: for any message "m0" that is blinded with "r0^e" to obtain "b" (that is sent to the server), it is possible to freely choose another message "m1" that blinded with another opening "r1^e" to obtain the same "b". As long as r1, r0 are chosen uniformly at random, you have no way of telling if what message was picked and therefore it is *perfectly* blind. To do so: Assume the messages ("m0" and "m1") are invertible mod N=pq (this happens at most with overwhelming probability phi(N)/N if m is uniformly distributed as a result of a hash, or you can enforce it at signing time). Blinding happens by computing: b = m0 * (r0^e). However, I can also write: b = m0 * r0^e = (m1/m1) * m0 * r0^e = m1 * (m0/m1*r0^e). This means that r1 = (m0/m1)^d * r0 is another valid blinding factor for b, and it's distributed exactly as r0 in the group of invertibles (it's unif at random, because r0 is so). ``` --- [REF_TOKEN_ZOO]: https://tokenzoo.github.io/ [REF_INTRO_SPACE]: https://gitlab.torproject.org/legacy/trac/-/issues/33650#note_2350910 [REF_CHAUM]: https://eprint.iacr.org/2001/002.pdf [REF_PRIMO]: https://repo.getmonero.org/selene/primo https://www.monerooutreach.org/stories/RPC-Pay.html [REF_POW_PERF]: https://gitlab.torproject.org/tpo/core/torspec/-/blob/master/proposals/327-… [REF_RES_BENCH]: https://github.com/asn-d6/res_tokens_benchmark

5 5

A new idea for email encryption on tor
by Keifer Bly 28 Mar '21

28 Mar '21

Hi there, So I have a new email encryption system which requires that the user has the specific key file generated for a message rather than the password, specifically this software generates a unique key file for a specific message every time a message is created. The user then enters the date and time the message was created. Without the original key file the message can't be opened; https://www.youtube.com/watch?v=R0W7OVdNrOA Here is a video showing the software. I've built it for Windows and Mac OS. I was wondering if this could be implemented in tor. I think it would be an interesting idea for a tor based email system to make the messages unrecoverable after use. OS: Windows, Mac OS What do you think? --Keifer

4 5

Proposal 328: Make Relays Report When They Are Overloaded
by David Goulet 03 Mar '21

03 Mar '21

Greetings, Attached is a proposal from Mike Perry and I. Merge requsest is here: https://gitlab.torproject.org/tpo/core/torspec/-/merge_requests/22 Cheers! David -- uSxMMaJozH7GAo7qjzhVUm5FDynPYtBfOeZcLS88XeU=

7 12

Best way to reload config on Windows?
by Holmes Wilson 22 Feb '21

22 Feb '21

Hi everyone, We’re building a Ricochet-inspired chat app, and there are situations where we want to create a new hidden service URL. On macOS and Linux we can send a SIGHUP to make Tor reload its config. What’s the best way to do this on Windows? I found an old issue for this (https://gitlab.torproject.org/tpo/core/tor/-/issues/10052 <https://gitlab.torproject.org/tpo/core/tor/-/issues/10052>) but it looks like it never got addressed. Thoughts? Holmes

3 4

Proposal 330: Modernizing authority contact entries
by Nick Mathewson 10 Feb '21

10 Feb '21

(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, to better support load balancing and denial-of-service resistance. (In an appendix, it also suggests an improvement to the description of authority identity keys, to avoid a deprecated cryptographic algorithm.) # Background There are, broadly, three good reasons to make a directory request to a Tor directory authority: - As a relay, to publish a new descriptor. - As another authority, to perform part of the voting and consensus protocol. - As a relay, to fetch a consensus or a set of (micro)descriptors. There are some more reasons that are OK-ish: - as a bandwidth authority or similar related tool running under the auspices of an authority. - as a metrics tool, to fetch directory information. - As a liveness checking tool, to make sure the authorities are running. There are also a number of bad reasons to make a directory request to a Tor directory authority. - As a client, to download directory information. (_Clients should instead use a directory guard, or a fallback directory if they don't know any directory information at all._) - As a tor-related application, to download directory information. (_Such applications should instead run a tor client, which can maintain an up-to-date directory much more efficiently._) Currently, Tor provides two mechanisms for downloading and uploading directory information: the DirPort, and the BeginDir command. A DirPort is an HTTP port on which directory information is served. The BeginDir command is a relay command that is used to send an HTTP stream directly over a Tor circuit. Historically, we used DirPort for all directory requests. Later, when we needed encrypted or anonymous directory requests, we moved to a "Begin-over-tor" approach, and then to BeginDir. We still use the DirPort directly, however, when relays are connecting to authorities to publish descriptors or download fresh directories. We also use it for voting. This proposal suggests that instead of having only a single DirPort, authorities should be able to expose a separate contact point for each supported interaction above. By separating these contact points, we can impose separate access controls and rate limits on each, to improve the robustness of the consensus voting process. Eventually, separate contact points will allow us do even more: we'll be able to have separate implementations for the upload and download components of the authorities, and keep the voting component mostly offline. # Adding contact points to authorities Currently, for each directory authority, we ship an authority entry. For example, the entry describing tor26 is: "tor26 orport=443 " "v3ident=14C131DFC5C6F93646BE72FA1401C02A8DF2E8B4 " "ipv6=[2001:858:2:2:aabb:0:563b:1526]:443 " "86.59.21.38:80 847B 1F85 0344 D787 6491 A548 92F9 0493 4E4E B85D", We extend these lines with optional contact point elements as follows: - `upload=http://IP:port/` A location to publish router descriptors. - `download=http://IP:port/` A location to use for caches when fetching router descriptors. - `vote=http://IP:port/` A location to use for authorities when voting. Each of these contact point elements can appear more than once. If it does, then it describes multiple valid contact points for a given purpose; implementations MAY use any of the contact point elements that they recognize for a given authority. Implementations SHOULD ignore url schemas that they do not recognize, and SHOULD ignore hostnames addresses that appear in the place of the IP elements above. (This will make it easier for us to extend these lists in the future.) If there is no contact point element for a given type, then implementations should fall back to using the main IPv4 addr:port, and/or the IPv6 addr:port if available. As an extra rule: If more than one authority lists the same upload point, then uploading a descriptor to that upload point counts as having uploaded it to all of those authorities. (This rule will allow multiple authorities to share an upload point in the future, if they decide to do so. We do not need a corresponding rules for voting or downloading, since every authority participates in voting directly, and since there is no notion of "downloading from each authority.") # Authority-side configuration We add a few flags to DirPort configuration, indicating what kind of requests are acceptable. - `no-voting` - `no-download` - `no-upload` These flags remove a given set of possible operations from a given DirPort. So for example, an authority might say: DirPort 9030 no-download no-upload DirPort 9040 no-voting no-upload DirPort 9050 no-voting no-download We can also allow "upload-only" as an alias for "no-voting no-download", and so on. Note that authorities would need to keep a legacy dirport around until all relays have upgraded. # Bridge authorities This proposal does not yet apply to bridge authorities, since neither clients nor bridges connect to bridge authorities over HTTP. A later proposal may add a schema that can be used to describe contacting to a bridge authority via BEGINDIR. # Example uses ## Example setup: Simple access control and balancing. Right now the essential functionality of authorities is sometimes blocked by getting too much load from directory downloads by non-relays. To address this we can proceed as follows. We can have each relay authority open four separate dirports: One for publishing, one for voting, one for downloading, and one legacy port. These can be rate-limited separately, and requests sent to the wrong port can be rejected. We could additionally prioritize voting, then uploads, then downloads. This could be done either within Tor, or with other IP shaping tools. ## Example setup: Full authority refactoring In the future, this system lets us get fancier with our authorities and how they are factored. For example, as in proposal 257, an authority could run upload services, voting, and download services all at separate locations. The authorities themselves would be the only ones that needed to use their voting protocol. The upload services (run on the behalf of authorities or groups of authorities) could receive descriptors and do initial testing on them before passing them on to the authorities. The authorities could then vote with one another, and push the resulting consensus and descriptors to the download services. This would make the download services primarily responsible for serving directory information, and have them take all the load. # Appendix: Cryptographic extensions to authority configuration The 'v3ident' element, and the relay identity fingerprint in authority configuration, are currently both given as SHA1 digests of RSA keys. SHA1 is currently deprecated: even though we're only relying on second-preimage resistance, we should migrate away. With that in mind, we're adding two more fields to the authority entries: - `ed25519-id=BASE64` The ed25519 identity of a the authority when it acts as a relay. - `v3ident-sha3-256=HEX` The SHA3-256 digest of the authority's v3 signing key. (We use base64 here for the ed25519 key since that's what we use elsewhere.)

1 0

Proposed changes to Tor long-term-support (LTS) policy
by Nick Mathewson 04 Feb '21

04 Feb '21

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 fewer promises about how well they will work on the network.) ===================== # Background and summary: I'm proposing a change to Tor's long-term support (LTS) policies. For reference, our current policy is described at https://gitlab.torproject.org/tpo/core/team/-/wikis/NetworkTeam/CoreTorRele… We've been struggling with our LTS policies for a while. In brief: we backport too many fixes, and we promise too much support for LTS releases. The developers don't like it, because the amount of things that we keep trying to fix in our LTS releases keeps us working on old crufty code for a long time. Many packagers don't like it, because they have a policy of auditing security backports, and we backport too much to our LTS releases for them to audit carefully. And our network maintenance group doesn't like it, because our commitment to supporting very old protocol versions keeps us from implementing performance and security improvements on a rapid schedule, unless we backport those changes to the LTS releases. Therefore, we're going to propose these changes: - That once a release becomes LTS-only, its code no longer gets anything but security patches (narrowly defined), and minimal patches to keep it working on the network. - We will no longer guarantee that an LTS-only release will work (or work well) on the mainline Tor network for its entire LTS lifetime. We'll try to deliver this if we can, but it won't be a definite guarantee. # In more detail We propose the following release statuses: - Development. (Every series starts out in this state as an alpha.) - Stable. (Once a series is officially 'ready', we call it stable.) - Old-stable. (Every supported stable release, except the most recent one, is in this state.) - Long-term support only. (Any LTS release, once a newer release has become old-stable. Only certain releases will get LTS support.) Every series starts out in "development". Once it's officially ready, we call it "stable". All stable releases besides the most recent one are "old-stable". Allowed in all releases: - Updates to authorities list - Updates to fallbackdirs list - Updates to geoip database LTS-only (any LTS release, once an newer release is oldstable): - Only two kinds of changes are allowed: - Security fixes, narrowly defined. (See below for a definition.) - _Simple_ patches that keep the release functional on the network. - Relays are not guaranteed to be supported on the network, although we'll try not to remove them gratuitously. - Clients and onion services are not guaranteed to work on the network, although we'll try not to break them gratuitously. In other words, with an LTS release there will be no guarantee that the software works on the network. The promise is that we will keep it working on the network when we can do so with simple low-risk patches, and that _if_ it works, we will fix security problems in it. Oldstable (All stable releases besides the most recent stable release): - Stability fixes are also allowed. - Relays will be supported on the network. - Clients and onion services will be supported on the network. - Dirauths may be supported. Stable (The single most recent stable release): - All fixes are allowed. - Relays will be supported on the network. - Clients and onion services will be supported on the network. - Dirauths will be supported. Development: - All fixes are allowed. - Relays will be supported on the network. - Clients and onion services will be supported on the network. - Dirauths will be supported. ============================== What is a security fix? - It is a _bugfix_ that resolves a vulnerability. _Features_ that make Tor more private, anonymous, or more secure won't count. ============================== The LTS policy above will apply to 0.3.5 _starting with 0.3.5.14_, since we've already made backports that will appear in 0.3.5.13. We have already committed to making 0.3.5 an LTS release until Feb 1, 2022. We also now commit to making 0.4.5 an LTS release until _at least_ Feb 15, 2023. Whether we continue to do this LTS for longer will depend on our experiences with this new policy. ============================== So, any proposed amendments to this? best wishes, -- Nick

1 0

(no subject)
by Jithin S 02 Feb '21

02 Feb '21

Hi, I have recently started running a TOR node with the nickname *CostlyOnion2. *At the time of writing of this email, the details of the node are as follows: *Uptime*: 14 days 3 hours 18 minutes and 0 second *Advertised Bandwidth*: 3.35 MiB/s *Flags*: *Fast Running Stable V2Dir Valid* *First Seen*: 2021-01-18 17:00:00 (14 days 19 hours 13 minutes and 32 seconds) *Last Restarted*: 2021-01-19 08:55:32 For current details, click here <https://metrics.torproject.org/rs.html#details/19EDB4798A4C170D603F86D8862B…> . My concern is how soon we will get a Guard status for our relay. I have read this <https://blog.torproject.org/lifecycle-new-relay> blog post regarding the life cycle of a relay. As it says, for a relay aged 8-68 days to get "Guard" status, we need to keep an eye on three factors *viz. *bandwidth, weighted fractional uptime, and time known. Suppose we keep running the relay all the time with the above-mentioned bandwidth(3.35 MiB/s), I would like to know about following - How long it will take to get the guard status? - My link bandwidth is quite high (close to 50MBytes/s), still the advertised is around 3.35MiB/s. What could be the possible factors for this? - As I am doing some analysis studies, we would also like to know what all factors we should take into account for the users to make use of our relay? I also request you to share any relevant resources for getting more information regarding the above questions, especially on the calculation of consensus weight. Thanks and regards, Jithin S

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-dev February 2021