- tor-dev - lists.torproject.org

[Metrics Team] Metrics Team mailing list and Metrics Team wiki page
by Karsten Loesing 28 Oct '15

28 Oct '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello Metrics Team members, hello devs, the Metrics Team now has a team wiki page and a team mailing list: https://trac.torproject.org/projects/tor/wiki/org/teams/MetricsTeam https://lists.torproject.org/cgi-bin/mailman/listinfo/metrics-team As described on the wiki page, the mailing list "is public in the sense that anyone can subscribe and read archives. But it's moderated on first post, meaning that your first post will be reviewed to make sure it's not spam and on topic and all further posts will go directly to the list. Feel free to subscribe and just listen if you want, and feel free to post if you have a question that you think is on topic." Everyone here should feel free to subscribe if they're interested in Metrics Team discussions. We should still move all discussions that are interesting to more people in Tor than just the Metrics Team to the tor-dev@ mailing list. Let's see how this works out. Note that future announcements, including meeting reminders, will go to the metrics-team@ list. (FWIW, there will be NO meeting tomorrow but next week.) All the best, Karsten -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJWMIJHAAoJEJD5dJfVqbCrpZcIALEmgZuRxflQHm5mTYhevYAn T5+tbclKDjjo3hfVmMdQOTtJFkLzkoO/jX4zTTuRiN3O+3jtcAcAtQ/xLLxA/wP3 wMJ76aRe6GIJ7lfO1+GQGKQCO1wO8lWDrY5vEr3yARWZB2KiSaFfWofe7nHq1G2V HjlUz+JeuAEWsLTxlkq+g3nrLpGtsEip3h85NA7pIicik35D1/W7S3jy/L1UKKO9 noH2QUBbQpfO0oW+Tjq+aYLO7hp98ThNO6JFDVM5tVOoDsxAnlMWtJQihDAlK7b0 5+sH6ixYBuvOOvoOCRl/3DJqTuQO+IpCcAGI7qLJOpMCIrAcsq0Lwaz5tJrieSk= =8Zhk -----END PGP SIGNATURE-----

1 0

1-1-1 task exchange meeting on Thursday, Oct 29, 15:00 UTC in #tor-dev
by Karsten Loesing 28 Oct '15

28 Oct '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello devs, we'll have another 1-1-1 task exchange meeting on Thursday, October 29, 2015, 15:00 UTC in #tor-dev https://www.timeanddate.com/worldclock/fixedtime.html?iso=20151029T15 Note how this may be a different time in your timezone based on the insight that we have all saved enough daylight for the year. Quick reminder: The idea of the 1-1-1 task exchange meeting is that participants get 1 minute to describe a task that would take somebody else roughly 1 hour and that they will do within 1 week. It could be to review a document, write some analysis code, fix a small bug, and so on. It's best to come prepared with a task or two to get the most out of this. In a perfect world people would give one task for each task they take, but that is not required. https://trac.torproject.org/projects/tor/wiki/doc/1-1-1-task-exchange Talk to you tomorrow. All the best, Karsten -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJWMHz2AAoJEJD5dJfVqbCr5e8H/3hPCDeEmrXuzEX4UZXxHoa+ RAsl5RN/Q2XFXMFayxno5BaGRBclusCDlbadOHcBcJeaZmETrfLmV1pN4OJA0yO9 RpNMcujl5VdOJSNcw5zxXn+QnHQPEqOUX4wFXuj/1BoAVRaek43IuqPTDTECNMRh 92vMaSJIQWxtudk5h0qhzB+DAEJSyTAU3gHH1yFecOITT2Nr69h6//WJIVn83rKW ViwLkQ4CoRfpp3aXyNRmMBEFj08bx09EAhI7bEkXYKf5oug5S/ah/YmHkHtfq+2D L9iz6vV/DdgXja/kcjMkakUvRAcSZPdNmmJwAqym2jCk+8FN9MsLW1ktL/R12xQ= =wU4R -----END PGP SIGNATURE-----

1 0

Desired exit node diversity
by grarpamp 28 Oct '15

28 Oct '15

On Wed, Sep 23, 2015 at 8:44 AM, tor-dev had: > I agree with Roger that ideally all relays can be exits (and since > we're being ideal, we'll assume that 'exit' means to every port). And > the network location distribution of relays by bandwidth is > proportional to both the client destination selection over time and > general Internet traffic over time, which match each other since we're > being ideal, and also matter since we're using an ideal trust-aware path > selection algorithm. And network wide route selection is such that > there is no congestion (generalizing Roger's assumption of infinite > exit capacity). Guessing that... assuming you can ship and calculate all the relay data / DHT / weights / KEX / circuits / preferences without bogging down your network or cpu... More relays being exits yields higher maximum possible path diversity. More relays being exits yields higher potential aggregate throughput between the network and clearnet. More exits yields broader more complete location overlay relavent to users (more relays yields more guards), datacenteres, and clearnet services (though there's as yet no attempt to exit near a service unless done manually). However when subject to global passive adversary tapping lots of the fiber, and you turn up more relays as exits (which are also non-exit relays by nature), you're adding lots more unused bandwidth over the same current consumption, leading to lots of unused quiet portions of the network. Which seems a greater potential for the adversary to "look, user just shot a unique traffic pattern completely through the quiet zone, gotcha". Whereas when the network links are full with clocked traffic (and fill traffic if there would otherwise be slack space) that observation attack is hardly as possible, to relavently impossible. If true, it seems to me adding more [non] exits should be pegged to some metrics and solicited on need / planning rather than turning up 6000 exits all at once. > In our ongoing work on trust-aware path selection, we assume a trust > distribution that will be the default used by a Tor client if another > distribution is not specified. (Most users will not have a reasoned > understanding of who they actually need to worry most about, and even > if they somehow got that right would not have a good handle how that > adversary's resources are distributed.) We call this adversary "The > Man", who is equally likely to be everywhere (each AS) on the > network. For relay adversaries, we assume that standing up and running > a relay has costs so weight a bit to make relays that have been around > a long time slightly more likely to be trusted. tor-relays had talk of individual humans keyparty signing their relays and including that WOT along with other trust and meta metrics in the consensus or other queryable datastore that could be used by the user to select preferred relay sets in whichever sensible or silly ways suited them. An adversary standing up relays has costs. Adversaries standing their human agents in public, even if their undercover is maintained, has additional costs and risks. > You > would then be faced with the political nightmare of issuing default > policies that tells users they should route with a weighting that says > country foo has an x percent chance of being your adversary, but > country bar has a y percent chance. (Likewise also have similar > statements that substitute 'large multinational corp.', 'major > criminal organization', 'specific big government agency that is > getting all the press lately' etc. for "country" in the last > sentence.) ======== In a sense this is like the original 'valid' flag, which you got by mailing me and having me manually approve your relay (and without which you would never be used as the entry or exit point in a circuit). Periodically I wonder if we should go back to a design like that, where users won't pick exit relays that don't have the "socially connected" badge. Then I opt against wanting it, since I worry that we'd lose exactly the kind of diversity we need most, by cutting out the relays whose operators we don't know. But both sides of that are just guessing. Let's find out! ======== These type of things may be better suited to a system where the users contribute their research and knowledge about the network into the network metadata db, and the users can query it to make their own decisions, follow other users prebuilt selection templates, or stick with the provided defaults.

3 3

[FWD: Re: Apple developer account + codesigning]
by Mike Perry 28 Oct '15

28 Oct '15

Here is some info about OSX codesigning, courtesy of Mike Tigas. It sounds like undoing the codesigning to verify build (and signing machine) integrity will be tricky. If anyone has more info on how to do that, it would be appreciated. ----- Forwarded message from Mike Tigas <mike(a)tig.as> ----- Date: Fri, 10 Jul 2015 01:29:02 -0400 From: Mike Tigas <mike(a)tig.as> To: Mike Perry <mikeperry(a)torproject.org> Subject: Re: Apple developer account + codesigning Hey Mike, Cool seeing y'all at that CPJ thing briefly. Yeah, that account is what you'll need to get the Apple-signed certs that let you codesign an app & allow it to launch unimpeded -- regardless of App Store or not. Used to be separate accounts for Mac vs iOS, but looks like it's just one account for everything Apple. (More info in the middle below on how to get the cert you need, etc.) On another open-source thing I work on <http://tabula.technology/>, we have a cross-platform JRuby program that we turn into a .app for Mac. We avoid the XCode IDE altogether (using a tool called `jarbundler` that turns our jar into a Mac .app bundle for us) and use the command-line "codesign" tool that comes with MacOSX or XCode (can't remember which). The invocation is basically like: codesign -f -s 'Developer ID Application: Mike Tigas (68QUP6KP2C)' /path/to/Foo.app Where the `-s` argument is the ID of the certificate you end up with from Apple -- see my comment here about "For production builds...": https://github.com/tabulapdf/tabula/blob/fe6b105ca4f84ea64975d8ddc876dce8d1… Once you have your Apple Developer account, link 3 in that comment is where you'll get your cert. There's a little wizard for it that walks you through it. (You want to be in Mac Apps -> Certificates -> All, click + to add a certificate, and you want a Production -> Developer ID, for an Application.) In our case we had to manually sign another OSX framework (Java) that we bundled with the app, so there's two invocations of the `codesign` command. We previously didn't do that (in https://github.com/tabulapdf/tabula/blob/c21b27c867ecdb578f97667310ea8b21e0… ), instead invoking `codesign` with the `--deep` flag, which tries to recursively sign all executable binaries inside the target (but there's some peculiarity with the Java OSX framework that prevented us from doing it). So just throwing that out there as another option to try. If this is for TBB or something else with a bunch of binaries inside, you'll have to keep this in mind. I've also discovered that this is a bitch to test, since once you've bypassed codesigning to open an app (doing right-click and open instead of double-clicking shows a prompt that allows a user to bypass the warning https://support.apple.com/en-us/HT202491 ), the app's whitelisted on your system. So I've historically messed up quite a few releases by signing with the wrong key, missing some bundled framework, etc, since my own work opens up fine on my own computer. I remember us vaguely talking about reproducible builds and verification, too. Guessing this ties in to the "removing signatures" part of what you said? Of course anything that happens during and after a codesign isn't reproducible for other users, but here are some notes about what `codesign` and the App Store do to built apps, particularly on iOS (but probably applicable to OSX too). https://github.com/OnionBrowser/iOS-OnionBrowser/issues/58 https://github.com/WhisperSystems/Signal-iOS/issues/641#issuecomment-782027… Essentially, codesign only touches executable binaries in the .app (see that second link for info on how the binary's segments get moved around) and also adds an SC_Info directory for codesign/DRM metadata. For App Store apps, only the SC_Info gets modified for different users for DRM. That makes it possible to actually verify an App Store app's integrity by removing that directory to check hashes -- https://github.com/OnionBrowser/iOS-OnionBrowser/releases/tag/v1.5.11 -- but you won't have this problem since you're not gonna go that route. The design (per that comment) doesn't seem to allow reversing the signing process easily due to DRM encryption of parts of the binary -- though I'm not clear on which parts are due to `codesign` locally versus magic that Apple performs on App Store-submitted applications. If the `codesign` by itself doesn't encrypt the binary (i.e. if it just rearranges the binary's segments & adds metadata & creates the metadata/DRM directory), it might be possible to reverse it. Could be worth someone exploring segment sizes/positions with `size` and `otool` http://www.objc.io/issues/6-build-tools/mach-o-executables/ to determine this for real. Ah holy shit, that is a LOT of words. But hope that helps and isn't too overwhelming. That's just about everything I know about this off the top of my head. Let me know if something isn't clear or if you run into any issues with the Apple account or something like that. Cheers, Mike Tigas Reporter/News Applications Developer, ProPublica https://www.propublica.org/ @mtigas | https://mike.tig.as/ | 0x6E0E9923 ----- End forwarded message ----- -- Mike Perry

8 14

Proposal 257: Refactoring authorities and taking parts offline
by Nick Mathewson 27 Oct '15

27 Oct '15

Filename: 257-hiding-authorities.txt Title: Refactoring authorities and taking parts offline Authors: Nick Mathewson, Andrea Shepard Created: 2015-10-27 Status: Draft 1. Introduction Directory authorities are critical to the Tor network, and represent a DoS target to anybody trying to disable the network. This document describes a strategy for making directory authorities in general less vulnerable to DoS by separating the different parts of their functionality. 2. Design 2.1. The status quo This proposal is about splitting up the roles of directory authorities. But, what are these roles? Currently, directory authorities perform the following functions. Some of these functions require large amounts of bandwidth; I've noted that with a (BW). Some of these functions require a publicly known address; I've marked those with a (PUB). Some of these functions inevitably leak the location from which they are performed. I've marked those with a (LOC). Not everything in this list is something that needs to be done by an authority permanently! This list is, again, just what authorities do now. * Authorities receive uploaded server descriptors and extrainfo descriptors from regular Tor servers and from each other. (BW, PUB?) * Authorities periodically probe the routers they know about in order to determine whether they are running or not. By remembering the past behavior of nodes, they also build a view of each node's fractional uptime and mean time between failures. (LOC, unless we're clever) * Authorities perform the consensus protocol by: * Generating 'vote' documents describing their view of the network, along with a set of microdescriptors for later client use. * Uploading these votes to one another. * Computing a 'consensus' of these votes. * Authorities serve as a location for distributing consensus documents, descriptors, extrainfo documents, and microdescriptors... * To directory mirrors. (BW?, PUB?, LOC?) * To clients that do not yet know a directory mirror. (BW!!, PUB) These functions are tied to directory authorities, but done out-of-process: * Bandwidth measurement (BW) * Sybil detection * 'Guardiness' measurement, possibly. 2.2. Design goals Principally, we attempt to isolate the security-critical, high-resource, and availability-critical pieces of our directory infrastructure from one another. We would like to make the security-critical pieces of our infrastructure easy to relocate, and the communications between them easy to secure. We require that the Tor network remain able to bootstrap itself in the event of catastrophic failure. So, while we can _use_ a running Tor network to communicate, we should not _require_ that a running Tor network exist in order to perform the voting process. 2.3. Division of responsibility We propose dividing directory authority operations into these modules: ---------- ---------- -------------- ---------------- | Upload |======>| Voting |===>| Publishing |===>| Distribution | ---------- ---------- -------------- ---------------- I ^ I ----------- I ====>| Metrics |=== ----------- A number of 'upload' servers are responsible for receiving router descriptors. These are publicly known, and responsible for collecting descriptors. Information from these servers is used by 'metrics' modules (which check Tor servers for reliability and measure their history), and fed into the voting process. The voting process involves only communication (indirectly) from authorities to authorities, to produce a consensus and a set of microdescriptors. When voting is complete, consensuses, descriptors, and microdescriptors must be made available to the rest of the world. This is done by the 'publishing' module. The consensuses, descriptors, and mds are then taken up by the directory caches, and distributed. The rest of this proposal will describe means of communication between these modules. 3. The modules in more detail This section will outline possibilities for communication between the various parts of the system to isolate them. There will be plenty of "may"s and "could"s and "might"s here: these are possibilities, in need of further consideration. 3.1. Sending descriptors to the Upload module We retain the current mechanism: a set of well-known IP addresses with well-known OR keys to which each relay should upload a copy of its descriptors. The worst that a hostile upload server can do is to drop descriptors. (It could also generate large numbers of spurious descriptors in order to increase the load on the metrics system. But an attacker could do that without running an upload server) With respect to dropping, upload servers can use an anytrust model: so long as a single server receives and honestly reports descriptors to the rest of the system, those descriptors will arrive correctly. To avoid DoS attacks, we can require that any relay not previously known to an upload module perform some kind of a proof of work as it first registers itself. (Details TBD) If we're using TLS here, we should also consider a check-then-start TLS design as described in A.1 below. The location of Upload servers can change over time; they can be published in the consensus. (Note also that as an alternative, we could distribute this functionality across the whole network.) 3.2. Transferring descriptors to the metrics server and the voters The simplest option here would be for the authorities and metrics servers to mirror them using Tor. rsync-over-ssh-over-Tor is a possibility, if we don't feel like building more machinery. (We could use hidden services here, but it is probably okay for upload servers and to be known by the the voters and metrics.) A fallback to a non-Tor connection could be done manually, or could require explicit buy-in from the voter/metrics operator. 3.3. Transferring information from metrics server to voters The same approaches as 3.2 should work fine. 3.4. Communication between voters Voters can, we hope, communicate to each other over authenticated hidden services. But we'll need a fallback mechanism here. Another option is to have public ledgers available for voters to talk to anonymously. This is probably a better idea. We could re-use the upload servers for this purpose, perhaps. Giving voters each others' addresses seems like a bad idea. 3.5. Communication from voters to directory nodes We should design a flood-distribution mechanism for microdescriptors, listed descriptors, and consensuses so that authorities can each upload to a few targets anonymously, and have them propagate through the rest of the network. 4. Migration To support old clients and old servers, the current authority IP addresses should remain as Upload and Distribution points. The current authority identity keys keys should remain as the keys for voters. A.1. Check-then-start TLS Current TLS protocols are quite susceptible to denial-of-service attacks, with large asymmetries in resource consumption. (Client sends junk, forcing server to perform private-key operation on junk.) We could hope for a good TLS replacement to someday emerge, or for TLS to improve its properties. But as a replacement, I suggest that we wrap TLS in a preliminary challenge-response protocol to establish that the use is authorized before we allow the TLS handshake to begin. (We shouldn't do this for all the TLS in Tor: only for the cases where we want to restrict the users of a given TLS server.)

2 1

Proposal 256: Key revocation for relays and authorities
by Nick Mathewson 27 Oct '15

27 Oct '15

Filename: 256-key-revocation.txt Title: Key revocation for relays and authorities Authors: Nick Mathewson Created: 27 October 2015 Status: Open 1. Introduction This document examines the different kinds of long-lived public keys in Tor, and discusses a way to revoke each. The kind of keys at issue are: * Authority identity keys * Authority signing keys * OR identity keys (ed25519) * OR signing keys (ed25519) * OR identity keys (RSA) Additionally, we need to make sure that all other key types, if they are compromised, can be replaced or rendered unusable. 2. When to revoke keys Revoking keys should happen when the operator of an authority or relay believes that the key has been compromised, or has a significant risk of having been compromised. In this proposal we deliberately leave this decision up to the authority/relay operators. (If a third party believes that a key has been compromised, they should attempt to get the key-issuing party to revoke their key. If that can't be done, the uncompromised authorities should block the relay or de-list the authority in question.) Our key-generation code (for authorities and relays) should generate preemptive revocation documents at the same time it generates the original keys, so that operators can retain those documents in the event that access to the original keys is lost. The operators should keep these revocation documents private and available enough so that they can issue the revocation if necessary, but nobody else can. Additionally, the key generation code should be able to generate retrospective revocation documents for existing keys and certificates. (This approach can be more useful when a subkey is revoked, but the operator still has ready access to the issuing key.) 3. Authority keys Authority identity keys are the most important keys in Tor. They are kept offline and encrypted. They are used to sign authority signing keys, and for no other purpose. Authority signing keys are kept online. They are authenticated by authority identity keys, and used to sign votes and consensus documents. (For the rest of section 2, all keys mentioned will be authority keys.) 3.1. Revocation certificates for authorities We add the following extensions to authority key certificates (see dir-spec.txt section 3.1), for use in key revocation. "dir-key-revocation-type" SP "master" | "signing" NL Specifies which kind of revocation document this is. If dir-key-revocation is absent, this is not a revocation. [At most once] "dir-key-revocation-notes" SP (any non-NL text) NL An explanation of why the key was revoked. Must be absent unless dir-key-revocation-type is set. [Any number of times] "dir-key-revocation-signing-key-unusable" NL Present if the signing key in this document will not actually be used to sign votes and consensuses. [At most once] "dir-key-revoked-signing-key" SP DIGEST NL Fingerprints of signing keys being explicitly revoked by this certificate. (All keys published before this one are _implicitly_ revoked.) [Any number of times] "dir-key-revocation-published" SP YYYY-MM-DD SP HH:MM:SS NL The actual time when the revocation was generated. (Used since the 'published' field in the certificate will lie; see below.) [at most once.] 3.2. Generating revocations Revocations for signing keys should be generated with: * A 'published' time immediately following the published date on the key that they are revoking. * An 'expires' time at least 48 hours after the expires date on the key that they are revoking, and at least one week in the future. (Note that this ensures as-correct-as-possible behavior for existing Tor clients and servers. For Tor versions before 0.2.6, having a more recent published date than the older key will cause the revoked key certificate to be removed by trusted_dirs_remove_old_certs() if it is published at least 7 days in the past. For Tor versions 0.2.6 or later, the interval is reduced to 2 days.) If generating a signing key revocation ahead of time, the revocation document should include a dummy signing key, to be thrown away immediately after it is generated and used to make the revocation document. The "dir-key-revocation-signing-key-unusable" element should be present. If generating a signing key revocation in response to an event, the revocation document should include the new signing key to be used. The "dir-key-revocation-signing-key-unusable" element must be be absent. All replacement certificates generated for the lifetime of the original revoked certificate should be generated as revocations. Revocations for master keys should be generated with: * A 'published' time immediately following the published date on the most recently generated certificate, if possible. * An 'expires' time equal to 18 Jan 2038. (The next-to-last day encodeable in time_t, to avoid Y2038 problems.) * A dummy signing key, as above. 3.3. Submitting revocations In the event of a key revocation, authority operators should upload the revocation document to every other authority. If there is a replacement signing key, it should be included in the authority's votes (as any new key certificate would be). 3.4. Handling revocations We add these additional rules for caching and storing revocations on Tor servers and clients. * Master key revocations should be stored indefinitely. * If we have a master key revocation, no other certificates for that key should be fetched, stored, or served. * If we have a master key revocation, we should replace any DirAuthority entry for that master key with a 'null' entry -- an authority with no address and no keys, from which nothing can be downloaded and nothing can be trusted, but which still counts against the total number of authorities. * Signing key revocations should be retained until their 'expires' date. * If we have a signing key revocation document, we should not trust any signature generated with any key in an older signing key certificates for the same master key. We should not serve such key certificates. * We should not attempt to fetch any certificate document matching an <identity, signing> pair for which a revocation document exists. We add these additional rule for directory authorities: * When generating or serving a consensus document, an authority should include a dir-source entry based on the most recent revocation cert it has from an authority, unless that authority has a more recent valid key cert. (This will require a new consensus method.) * When generating or serving a consensus document, if no valid signature exists from a given authority, and that authority has a currently valid key revocation document with a signing key in it, it should include a bogus signature purporting to be made with that signing key. (All-zeros is suggested.) (Doing this will make old Tor clients download the revocation certificates.) 4. Router identity key revocations 4.1. RSA identity keys If the RSA key is compromised but the ed25519 identity and signing keys are not, simply disable the router. Key pinning should take care of the rest. (This isn't ideal when key pinning isn't deployed yet, but I'm betting that key pinning comes online before this proposal does.) 4.2. Ed25519 master identity keys (We use the data format from proposal 220, section 2.3 here.) To revoke a master identity key, create a revocation for the master key and upload it to every authority. Authorities should accept these documents as meaning that the signing key should never be allowed to appear on the Tor network. This can be enforced with the key pinning mechanism. 4.3. Ed25519 signing keys (We use the data format from proposal 220, section 2.3 here.) To revoke a signing key, include the revocation for every not-yet-expired signing key in your routerinfo document, as in: "revoked-signing-key" SP Base64-Ed25519-Key NL Note that this doesn't need to be authenticated, since the newer signing key certificate creates a trust path from the master identity key to the the revocation. [Up to 32 times.] Upon receiving these entries, authorities store up to 32 such entries per router per year. (If you have more than 32 keys compromised, give up and take your router down. Start it with a new master key.) When voting, authorities include a "rev" line in the microdescriptor for every revoked-signing-key in the routerinfo: "rev" SP "ed25519" SP Base64-Ed25519-Key NL (This will require a new microdescriptor version.) Upon receiving such a line in the microdescriptor, Tor instances MUST NOT trust any signing key certificate with a matching key.

1 0

Tor browser for other Projects
by salutarydiacritical23＠ruggedinbox.com 27 Oct '15

27 Oct '15

Hello good people of Tor. As you know, your client side applications like Tor browser are unmatched by anything out there. They are the natural choice for other anonymous networks. Freenet is considering ways to interface with Tor browser for better privacy. Disclaimer: I am not an official spokesperson for them. I am testing the waters first before filing tickets on trac. My idea is for Tor browser to include the FoxyProxy for redirecting browser requests to proxies based on URL patterns. Optionally there's color indicators for every proxy so users know what network they are visiting. You can add rules to block LAN accesses to keep users safe from misbehaving JavaScript. Rules can be added for I2P URLs too. You'll need to disable the ads in the original addon but the code is DFSG compliant. Like the transports, your client side applications are a new area for collaboration beyond your project. What do you say?

2 1

Status of remaining SVN repositories
by Jens Kubieziel 27 Oct '15

27 Oct '15

Hi, Tor has a SVN with several repositories in it. The ticket #4929 deals with migrating them to git (<URL:https://trac.torproject.org/projects/tor/ticket/4929>). I made a table within the ticket to track the current status. Most of the repositories are in git right now. However some remain where I don't know what the current status is. This are: - blossom - bsockets - incognito - libevent-urz - topf - projects (it seems sub repos are in git) - website Should the first five repos also be moved to trac or what do we want to do with them? -- Jens Kubieziel http://www.kubieziel.de Eine schwarze Katze auf dem Weg zum Galgen bringt Unglück. Werner Mitsch

2 1

A layered transport
by Da Feng 26 Oct '15

26 Oct '15

Hi: I've discovered that the GFW normally doesn't block https protocols. We can use a https front tier to distribute connections to actual bridges. The front tier encrypts an internal address identifier with its private key (no matching public key or public algorithm) and returns to user the encrypted identifier, part of which also includes the user's chosen password. Then when submitting requests, the user encrypt again with his password the items such as his timestamp, broswer headers. The request line to https server is no different from an ordinary one and include both the user encrypted item and front tier encrypted item. After the connection is established, data is relayed inside https between bridge and user.

4 3

Onion Services and NAT Punching
by Tim Wilson-Brown - teor 26 Oct '15

26 Oct '15

Hi All, Do you know a use case which needs Single Onion Services and NAT punching? We’re wondering if there are mobile or desktop applications / services that would use a single onion service for the performance benefits, but still need NAT punching. (And don’t need the anonymity of a hidden service.) Single Onion Services: * can’t do NAT punching, (they need an ORPort on a publicly accessible IP address), * locations are easier to discover, and * have lower latency. Hidden Services: * can do NAT punching, * locations are hard to discover, and * have higher latency. Are there any use cases that: * need NAT punching, * don’t need service location anonymity, and * would benefit from lower latency? Thanks Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F

6 6

txtorcon 0.14.0
by meejah 25 Oct '15

25 Oct '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'm happy to announce txtorcon 0.14.0. Changes: * IStreamAttacher handling was missing None and DO_NOT_ATTACH cases if a Deferred was returned. * add .is_built Deferred to txtorcon.Circuit that gets callback()'d when the circuit becomes BUILT * David Stainton ported his "tor:" endpoint parser so now both client and server endpoints are supported. This means **any** Twisted program using endpoints can use Tor as a client. For example, to connect to txtorcon's Web site: ep = clientFromString("tor:timaq4ygg2iegci7.onion:80"). (In the future, I'd like to automatically launch Tor if required, too). * Python3 fixes from Isis Lovecruft (note: needs Twisted 15.4.0+) You can download the release from PyPI or GitHub (or of course "pip install txtorcon"): https://pypi.python.org/pypi/txtorcon/0.14.0 https://github.com/meejah/txtorcon/releases/tag/v0.14.0 Releases are also available from the hidden service: http://timaq4ygg2iegci7.onion/txtorcon-0.14.0.tar.gz http://timaq4ygg2iegci7.onion/txtorcon-0.14.0.tar.gz.asc http://timaq4ygg2iegci7.onion/txtorcon-0.14.0-py2-none-any.whl http://timaq4ygg2iegci7.onion/txtorcon-0.14.0-py2-none-any.whl.asc You can verify the sha256sum of both by running the following 4 lines in a shell wherever you have the files downloaded: cat <<EOF | sha256sum --check d44be978dd9521f22333edea49789fe7e19c4bea9a02d63e6ec826d08fb571d1 dist/txtorcon-0.14.0-py2-none-any.whl a2d0fae65da015840bb392ffc4fd63918168edb6b634941f6b8aa843b338edbf dist/txtorcon-0.14.0.tar.gz EOF thanks, meejah -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJWB3FqAAoJEMJgKAMSgGmn1fsIAOcqJdIFIO5cIvj7TRv9rxFP aEW/Vb0UGN2/A2skWxajzYJLeZ0geZaOmYGFyscs+fguIzRaGRX4G8+7xRuIzzim GqjPd+my2+h79hDpH/RntwQvNmW9K50UCKOH5TiW5fGnjbO0ZkqoK8ln+aGz7WCC HjRmNTJb7iI/vVs6h66evBHjkgib4lBpZSEnJR6H+c1ZC5hJ0uYt1SFch5IF/UsA QeISGyc2SE5wuwjLuiHDyPoFC/Q5IEhDWABFgs3Z6LB/2yfnUFEjrtEla1Uq454H YJ5mWsgxx/apGDXbACQ3p8N5ISA/WDOWHm2Rg+XgZo758KyMyOQIfSy1RrGBld4= =Wffv -----END PGP SIGNATURE-----

1 1

[PATCH] Document our current guard selection algorithm in path-spec.txt.
by isis 23 Oct '15

23 Oct '15

Hey hey, I've been working on documenting our current guard selection algorithm (#17261), [0] which as most of you already know, has some room for improvement. The patch is in my bug17261 branch. [1] However, it's also attached here for reference and discussion. [0]: https://trac.torproject.org/projects/tor/ticket/17261 [1]: https://gitweb.torproject.org/user/isis/torspec.git/log/?h=bug17261 Best, -- ♥Ⓐ isis agora lovecruft _________________________________________________________ OpenPGP: 4096R/0A6A58A14B5946ABDE18E207A3ADB67A2CDB8B35 Current Keys: https://blog.patternsinthevoid.net/isis.txt

1 0

Re: [tor-dev] Load Balancing in 2.7 series - incompatible with OnionBalance ?
by Alec Muffett 23 Oct '15

23 Oct '15

info(a)tvdw.eu wrote: > Hi Alec, Hi Tom! I love your proposal, BTW. :-) > Most of what you said sounds right, and I agree that caching needs TTLs (not just here, all caches need to have them, always). Thank you! > However, you mention that one DC going down could cause a bad experience for users. In most HA/DR setups I've seen there should be enough capacity if something fails, is that not the case for you? Can a single data center not serve all Tor traffic? It's not the datacentre which worries me - we already know how to deal with those - it's the failure-based resource contention for the limited introduction-point space that is afforded by a maximum (?) of six descriptors each of which cites 10 introduction points. A cap of 60 IPs is a clear protocol bottleneck which - even with your excellent idea - could break a service deployment. Yes, in the meantime the proper solution is to split the service three ways, or even four, but that's administrative burden which less well-resourced organisations might struggle with. Many (most?) will have a primary site and a single failover site, and it seems perverse that they could bounce just ONE of those sites and automatically lose 50% of their Onion capacity for up to 24 hours UNLESS they also take down the OTHER site for long enough to invalidate the OnionBalance descriptors. Such is not the description of a high-availability (HA) service, and it might put people off. > If that is a problem, I would suggest adding more data centers to the pool. That way if one fails, you don't lose half of the capacity, but a third (if N=3) or even a tenth (if N=10). ...but you lose it for 1..24 hours, even if you simply reboot the Tor daemon. > Anyway, such a thing is probably off-topic. To get back to the point about TTLs, I just want to note that retrying failed nodes until all fail is scary: I find that worrying, also. I'm not sure what I think about it yet, though. > what will happen if all ten nodes get a 'rolling restart' throughout the day? Wouldn't you eventually end up with all the traffic on a single node, as it's the only one that hadn't been restarted yet? Precisely. > As far as I can see the only thing that can avoid holes like that is a TTL, either hard coded to something like an hour, or just specified in the descriptor. Then, if you do a rolling restart, make sure you don't do it all within one TTL length, but at least two or three depending on capacity. Concur. desnacked(a)riseup.net wrote: > Please see rend_client_get_random_intro_impl(). Clients will pick a random intro point from the descriptor which seems to be the proper behavior here. That looks great! > I can see how a TTL might be useful in high availability scenarios like the one you described. However, it does seem like something with potential security implications (like, set TTL to 1 second for all your descriptors, and now you have your clients keep on making directory circuits to fetch your descs). Okay, so, how about: IDEA: if ANY descriptor introduction point connection fails AND the descriptor's ttl has been exceeded THEN refetch the descriptor before trying again? It strikes me (though I may be wrong?) that the degenerate case for this would be someone with an onion killing their IP in order to force the user to refetch a descriptor - which is what I think would happen anyway? At very least this proposal would add a work factor. > For this reason I'd be interested to see this specified in a formal Tor proposal (or even as a patch to prop224). It shouldn't be too big! :) I would hesitate to add it to Prop 224 which strikes me as rather large and distant. I'd love to see this by Christmas :-P teor2345(a)gmail.com wrote: > Do we connect to introduction points in the order they are listed in the descriptor? If so, that's not ideal, there are surely benefits to a random choice (such as load balancing). Apparently not (re: George) :-) > That said, we believe that rendezvous points are the bottleneck in the rendezvous protocol, not introduction points. Currently, and in most current deployments, yes. > However, if you were to use proposal #255 to split the introduction and rendezvous to separate tor instances, you would then be limited to: > - 6*10*N tor introduction points, where there are 6 HSDirs, each receiving 10 different introduction points from different tor instances, and N failover instances of this infrastructure competing to post descriptors. (Where N = 1, 2, 3.) > - a virtually unlimited number of tor servers doing the rendezvous and exchanging data (say 1 server per M clients, where M is perhaps 100 or so, but ideally dynamically determined based on load/response time). > In this scenario, you could potentially overload the introduction points. Exactly my concern, especially when combined with overlong lifetimes of mostly-zombie descriptors. - alec

3 4

Hello, after about one hour since my Tor browser successfully connected to Tor network with a obfs4 bridge, I couldn't open any webpage through Tor proxy.
by Li Xiaodong 22 Oct '15

22 Oct '15

*Hello, after about one hour since my Tor browser successfully connected to Tor network with a obfs4 bridge, I couldn't open any webpage through Tor proxy. But after I restarted my Tor browser, Tor browser can work normally again. Does China's firewall disturb obfs4 bridges? Thank you very much for your help. I really appreciate it.*

2 1

Faster Bootstrap - Prop #210 (Revised)
by Tim Wilson-Brown - teor 22 Oct '15

22 Oct '15

Hi All, I have revised proposal #210 - Faster Headless Consensus Bootstrapping today, after a number of discussions with Peter Palfrader Nick Mathewson, Mike Perry, and others. This proposal aims to improve tor’s consensus download behaviour when the authorities (or directory mirrors) are down. It has tor initiate multiple concurrent consensus connections, then download the consensus through the first TLS connection that completes. This proposal is a solution to bug #4483 - If k of n authorities are down, k/n bootstrapping clients are delayed for minutes. It is also needed to implement #15775 - Add IPv4 Fallback Directory List to tor... and #8374 - Ship list of fallback directory mirrors on long-term fixed IPv6 addresses. The key changes are: * modify the scheme to perform exponential backoff on connections, rather than connections in batches * modify the scheme to enable IPv6 bootstrap on IPv6-only clients (see also #17217 - Change clients to automatically use IPv6 if they can bootstrap over it) * specify a way that clients can still benefit from clock verification via TLS connections with the authorities, without downloading the entire consensus from the authorities if it is available sooner from a mirror * analyse the expected failure rate and additional connection load imposed by this proposal The full text is included below, and a branch with these changes is available as bootstrap-exponential-backoff in https://github.com/teor2345/torspec.git <https://github.com/teor2345/torspec.git> Please feel free to respond here, or on the #4483 ticket at https://trac.torproject.org/projects/tor/ticket/4483 <https://trac.torproject.org/projects/tor/ticket/4483> Thanks Tim ----- Filename: 210-faster-headless-consensus-bootstrap.txt Title: Faster Headless Consensus Bootstrapping Author: Mike Perry, Tim Wilson-Brown, Peter Palfrader Created: 01-10-2012 Last Modified: 02-10-2015 Status: Open Target: 0.2.8.x+ Overview and Motiviation This proposal describes a way for clients to fetch the initial consensus more quickly in situations where some or all of the directory authorities are unreachable. This proposal is meant to describe a solution for bug #4483. Design: Bootstrap Process Changes The core idea is to attempt to establish bootstrap connections in parallel during the bootstrap process, and download the consensus from the first connection that completes. Connection attempts will be performed on an exponential backoff basis. Initially, connections will be performed to a randomly chosen hard coded directory mirror and a randomly chosen canonical directory authority. If neither of these connections complete, additional mirror and authority connections are tried. Mirror connections are tried at a faster rate than authority connections. We specify that mirror connections retry after half a second, and then double the retry time with every connection: 0, 1, 2, 4, 8, 16, 32, ... We specify that directory authority connections retry after 5 seconds, and then double the retry time with every connection: 0, 10, 20, ... If the client has both an IPv4 and IPv6 address, we try IPv4 and IPv6 mirrors and authorities on the following schedule: IPv4, IPv6, IPv4, IPv6, ... We try IPv4 first to avoid overloading IPv6-enabled authorities and mirrors. Mirrors and auths get a separate IPv4/IPv6 schedule. This ensures that we try an IPv6 authority within the first 10 seconds. This helps implement #8374 and related tickets. The maximum retry time for both timers is 3 days + 1 hour. This places a small load on the mirrors and authorities, while allowing a client that regains a network connection to eventually download a consensus. The retry timers must reset on HUP and any network reachability events, [ TODO: do we have network reachability events? ] so that clients that have unreliable networks can recover from network failures. The first connection to complete will be used to download the consensus document and the others will be closed, after which bootstrapping will proceed as normal. A benefit of connecting to directory authorities is that clients are warned if their clock is wrong. Therefore, when closing a directory authority connection, we check to see if we have successfully connected to an authority during this run of the Tor client. If not, we allow the authority TLS connection to complete, then close the connection. We expect the vast majority of clients to succeed within 4 seconds, after making up to 4 connection attempts to mirrors and 1 connection attempt to an authority. Clients which can't connect in the first 10 seconds, will try 1 more mirror, then try to contact another directory authority. We expect almost all clients to succeed within 10 seconds. This is a much better success rate than the current Tor implementation, which fails k/n of clients if k of the n directory authorities are down. (Or, if the connection fails in certain ways, (k/n)^2.) If at any time, the total outstanding bootstrap connection attempts exceeds 10, no new connection attempts are to be launched until an existing connection attempt experiences full timeout. The retry time is not doubled when a connection is skipped. Design: Fallback Dir Mirror Selection The set of hard coded directory mirrors from #572 shall be chosen using the 100 Guard nodes with the longest uptime. The fallback weights will be set using each mirror's fraction of consensus bandwidth out of the total of all 100 mirrors, adjusted to ensure no fallback directory sees more than 10% of clients. We will also exclude fallback directories that are less than 1/1000 of the consensus weight, as they are not large enough to make it worthwhile including them. This list of fallback dir mirrors should be updated with every major Tor release. In future releases, the number of dir mirrors should be set at 20% of the current Guard nodes (approximately 200 as of October 2015), rather than fixed at 100. Performance: Additional Load with Current Parameter Choices This design and the connection count parameters were chosen such that no additional bandwidth load would be placed on the directory authorities. In fact, the directory authorities should experience less load, because they will not need to serve the consensus document for a connection in the event that one of the directory mirrors complete their connection before the directory authority does. However, the scheme does place additional TLS connection load on the fallback dir mirrors. Because bootstrapping is rare and all but one of the TLS connections will be very short-lived and unused, this should not be a substantial issue. The dangerous case is in the event of a prolonged consensus failure that induces all clients to enter into the bootstrap process. In this case, the number of TLS connections to the fallback dir mirrors within the first second would be 2*C/100, or 40,000 for C=2,000,000 users. If no connections complete before the 10 retries, 7 of which go to mirrors, this could reach as high as 140,000 connection attempts, but this is extremely unlikely to happen in full aggregate. However, in the no-consensus scenario today, the directory authorities would already experience 2*C/9 or 444,444 connection attempts. (Tor currently tries 2 authorities, before delaying the next attempt.) The 10-retry scheme, 3 of which go to authorities, increases their total maximum load to about 666,666 connection attempts, but again this is unlikely to be reached in aggregate. Additionally, with this scheme, even if the dirauths are taken down by this load, the dir mirrors should be able to survive it. Implementation Notes: Code Modifications The implementation of the bootstrap process is unfortunately mixed in with many types of directory activity. The process starts in update_consensus_networkstatus_downloads(), which initiates a single directory connection through directory_get_from_dirserver(). Depending on bootstrap state, a single directory server is selected and a connection is eventually made through directory_initiate_command_rend(). There appear to be a few options for altering this code to retry multiple simultaneous connections. Without refactoring, one approach would be to set a connection retry helper function timer in directory_initiate_command_routerstatus() from directory_get_from_dirserver() if the purpose is DIR_PURPOSE_FETCH_CONSENSUS and the only directory servers available are the authorities and the fallback dir mirrors. (That is, there is no valid consensus.) The retry helper function would check the list of pending connections and, if it is 10 or greater, skip the connection attempt, and leave the retry time constant. The code in directory_initiate_command_rend() would then need to be altered to maintain a list of the dircons created for this purpose as well as avoid immediately queuing the directory_send_command() request for the DIR_PURPOSE_FETCH_CONSENSUS purpose. A flag would need to be set on the dircon to be checked in connection_dir_finished_connecting(). The function connection_dir_finished_connecting() would need to be altered to examine the list of pending dircons, determine if this one is the first to complete, and if so, then call directory_send_command() to download the consensus and close the other pending dircons. connection_dir_finished_connecting() would also cancel the timer. Reliability Analysis We make the pessimistic assumptions that 50% of connections to directory mirrors fail, and that 20% of connections to authorities fail. (Actual figures depend on relay churn, age of the fallback list, and authority uptime.) We expect the first 10 connection retry times to be: Mirror: 0s 1s 2s 4s 8s 16s 32s Auth: 0s 10s 20s Success: 90% 95% 97% 98.7% 99.4% 99.89% 99.94% 99.988% 99.994% 97% of clients succeed in the first 2 seconds. 99.4% of clients succeed without trying a second authority. 99.89% of clients succeed in the first 10 seconds. 0.11% of clients remain, but in this scenario, 2 authorities are down, so the client is most likely blocked from the Tor network. The current implementation makes 1 or 2 authority connections within the first second, depending on exactly how the first connection fails. Under the 20% authority failure assumption, these clients would have a success rate of either 80% or 96% within a few seconds. The scheme above has a greater success rate in the first few seconds, while spreading the load among a larger number of directory mirrors. In addition, if all the authorities are blocked, current clients will inevitably fail, as they do not have a list of directory mirrors.

1 1

Status of Open Hidden Service Proposals (October 2015)
by George Kadianakis 22 Oct '15

22 Oct '15

Greetings, it's well known that hidden services need some love: https://blog.torproject.org/blog/hidden-services-need-some-love For the past 2 years we've been busy designing the upcoming hidden service protocol with improved cryptography, security, and performance. During this time we've written a good amount of improvement proposals and specifications, that have now been floating around our git repositories. In this mail I aim to collect and briefly explain all these proposals in one place so that researchers and developers have easier access to them. Ideally we would also make a wiki page tracking them. Similar efforts have been done for the set of all Tor proposals by Nick: https://blog.torproject.org/blog/tor-design-proposals-how-we-make-changes-o… https://gitweb.torproject.org/torspec.git/tree/proposals/proposal-status.txt This might also make for an informative blog post if I clean it up a bit. Please let me know if I should try to get it posted on the blog so that it reaches a greater audience. Let's start walking over each proposal in a hopefully reasonable order: ======================================================================== == Proposal 250: Random Number Generation During Tor Voting == [Prerequisite proposal] URL: https://gitweb.torproject.org/torspec.git/tree/proposals/250-commit-reveal-… Status: [Under development - https://trac.torproject.org/projects/tor/ticket/16943] This is a prerequisite for the proposals that follow. It specifies how the Tor directory authorities can produce a fresh and unpredictable random value every day. We plan to use this value to randomize the responsible HSDirs of hidden services and make them unpredictable. This will help defend against attacks that require the attacker to become the HSDir of a hidden service. == Proposal 224: Next-Generation Hidden Services in Tor == [Main proposal!] URL: https://gitweb.torproject.org/torspec.git/tree/proposals/224-rend-spec-ng.t… Status: [Under development - https://trac.torproject.org/projects/tor/ticket/12424] This is the master proposal of the "Next Generation Hidden Services" project. It outlines a more or less completely revised version of the Tor hidden services protocol, improved to accomodate better cryptography and defenses for several attacks we'd never considered when we did the original design! The following proposals plug into the protocol specified by this proposal. == Proposal 246: Merging Hidden Service Directories and Introduction Points == [Performance improvement] URL: https://gitweb.torproject.org/torspec.git/tree/proposals/246-merge-hsdir-an… Status: [Research Phase - https://lists.torproject.org/pipermail/tor-dev/2015-July/009079.html] This document describes a modification to proposal 224, which simplifies and improves the architecture by combining hidden service directories and introduction points at the same relays. It will speed up the initial connection to hidden services considerably since only two circuit establishments will be needed instead of three. == Proposal 247: Defending Against Guard Discovery Attacks using Vanguards == [Security improvement] URL: https://gitweb.torproject.org/torspec.git/tree/proposals/247-hs-guard-disco… Status: [Research Phase - https://lists.torproject.org/pipermail/tor-dev/2015-July/009066.html] This document describes a modification to the path selection for hidden service circuits. It aims to defend against attacks where clients try to discover the hidden service's guard relay(s). This proposal also depends on having better and more robust algorithms for guard node selection. This requires another mini-proposal: https://lists.torproject.org/pipermail/tor-dev/2015-August/009297.html == Proposal 255: Controller features to allow for load-balancing hidden services == [Scalability improvement] URL: https://gitweb.torproject.org/torspec.git/tree/proposals/255-hs-load-balanc… Discussion thread: https://lists.torproject.org/pipermail/tor-dev/2015-September/009597.html Status: [Under Development - https://trac.torproject.org/projects/tor/ticket/17254] We have plans for bringing hidden services to the next level. We are talking hidden services with 100x the clients they can currently handle, and with mechanisms that allow operators to load balance and achieve high availability. This proposal defines a way for hidden services to _load balance_ their clients by allowing *multiple hosts* to do the actual rendezvous with the clients. This is something that busy hidden service operators need currently. On the scaling front, we also worked on onionbalance which allows operators to have _high availability_ by allowing multiple hosts that handle introductions. Onionbalance is already usable by operators, and we have various improvements that we want to do in the future: https://github.com/DonnchaC/onionbalance == Proposal 252: Single Onion Services == [Optional Performance improvement] URL: https://gitweb.torproject.org/torspec.git/tree/proposals/252-single-onion.t… Status: [Research Phase - https://lists.torproject.org/pipermail/tor-dev/2015-September/009408.html] Websites like blockchain.info and Facebook are starting to offer hidden services to their clients. They do so to protect their clients from the fundamental exit-node attacks and also to provide them with Tor-specific features. Using hidden services in this context is also good news for the whole Tor, since hidden service circuits don't require exit relays who are the current bottleneck of the network. However, services like blockchain.info don't care about their anonymity; they only care about the anonymity of their clients. For services with this threat model, there are protocol modification that we can do to provide greater performance and load balancing options, since they don't need the 3-hop anonymizing circuits of Tor. Proposal 252 specifies how we can modify the Tor protocol to better accomodate services with this use case. Of course this would be an *opt-in setting* only for the services that want it. == Proposal: Direct Onion Services == [Optional Performance Improvement] URL: https://lists.torproject.org/pipermail/tor-dev/2015-April/008625.html Status: [Under Development - https://trac.torproject.org/projects/tor/ticket/17178] Proposal 252 "Single Onion Services" requires some protocol modifications that render it backwards _incompatible_. This means that Tor clients need to be updated to use these "single onion services". In the meanwhile services with the blockchain.info threat model that want to enjoy greater performance even with the current protocol can simply use 1-hop circuits for their server-side circuits. This should grant better performance with no cost to client anonymity while remaining backwards compatible. The "Direct Onion Services" proposal specifies how this should be done. I hear a newer version of the proposal will soon come out! ========================================================================

1 0

Load Balancing in 2.7 series - incompatible with OnionBalance ?
by Alec Muffett 22 Oct '15

22 Oct '15

So I’ve just had a conversation with dgoulet on IRC, which I will reformat and subedit here as a conversation regarding OnionBalance and issues in 2.6 and 2.7 when a recently rebooted HS publishes a fresh descriptor: […] alecm: consider OnionBalance which - being a bunch of daemons on a bunch of servers - will be a lot more prone to intermittent failures of 1+ daemons yielding a lot of republishing alecm: we tend to move services around, and daemons will be killed in one place and resurrected elsewhere, and then we'll have to bundle up a new descriptor and ship it out dgoulet: hrm so with that new 027 cache behavior, as long as the IP are usable, the descriptor will be kept, if they all become unusable, a new descriptor fetch is triggered and then those IPs will be tried alecm: There's a mandatory refresh [of the descriptor] after N minutes? dgoulet: we'll retry 3 times and after that all HSDir are in timeout for 15 minutes (I think, I'll have to validate) before retrying any HSDirs alecm: I wonder if descriptors should publish a recommended TTL - [number of seconds to live before refresh] dgoulet: yeah we have an idea for a "revision-counter" in the descriptor being incremented at each new version for the 24 hours period dgoulet: a TTL could be useful for load balancing though! alecm: so, here's a scenario: imagine that we run 10 daemons, alecm: call these daemons: A B C D E F G H I J - they all have random onion addresses alecm: we steal one IP from each daemon, and bundle the 10 stolen IPs together to make an onionbalance site descriptor and publish it alecm: people pull that descriptor, it's quite popular alecm: we then lose power in a datacentre, which takes out half of our onions - say, A through E alecm: we reboot the datacentre and restart A-E merely 10 minutes later alecm: everyone who has already loaded our onionbalance site descriptor tests A B C D E and finds them all dead, because the old IPs for A-E are invalid alecm: so they all move to F G H I J - which get overloaded even though (new) A B C D E are back up alecm: and this persists for up to 244, even though the outage was only 10 minutes alecm: net result: large chunks of the world (anyone with an old descriptor + anyone randomly choosing F-J) have a shitty experience, which is not what high-availability is all about :-) dgoulet: that will be what's going to happen - having a TTL in the desc. would help here indeed, I see the issue dgoulet: TTL would be one thing to add, here we could also add a mechanism for a client retrying IPs that failed in the situation where some of the IPs are still working, or making client balance themself randomly could be also an idea dgoulet: definitely there is some content here for tor-dev - I don't have a good answer but it should definitely be addressed alecm: proper random selection of IP would be beneficial for load-balancing; not perfect, but in the long run, helpful — Alec Muffett Security Infrastructure Facebook Engineering London

4 4

First Tor-wide 1-1-1 task exchange meeting happens on Thursday, Oct 22, 15:00 UTC in #tor-dev
by Karsten Loesing 21 Oct '15

21 Oct '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello devs, The first Tor-wide 1-1-1 task exchange meeting happens on Thursday, October 22, 2015, 15:00 UTC in #tor-dev https://www.timeanddate.com/worldclock/fixedtime.html?iso=20151022T15 The idea of the 1-1-1 task exchange meeting is that participants get 1 minute to describe a task that would take somebody else roughly 1 hour and that they will do within 1 week. It could be to review a document, write some analysis code, fix a small bug, and so on. It's best to come prepared with a task or two to get the most out of this. In a perfect world people would give one task for each task they take, but that is not required. The Measurement Team has been playing the 1-1-1 task exchange game for a few weeks as part of team meetings. But we realized at the Berlin dev meeting that this doesn't have to be team specific. That's why we're opening this up to anyone in Tor who wants to come. For reference, here are our past tasks: https://pad.riseup.net/p/1-1-1-task-exchange We're also planning to put tasks that were not taken on Tor Weekly News to invite new volunteers who wouldn't attend our IRC meetings. Though the general approach will still be to contact the task owner before working on the task to avoid duplicating efforts. Talk to you tomorrow. All the best, Karsten -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJWJ6eEAAoJEJD5dJfVqbCrGoMH/2X0RBY/r/+Ndx+gHTyJtWjM lnjkC1KMckJeUsFI5jCHfgvm8BJJphiV9EHkvR8rIHi3PNlVufNOZywKAKM9j1Kh Gm3sQ2reBJ3BcNhEdi4f+q3/iaANCQG0ePOWLFPg3Vwsfra3jqyurz8C6WBsKyaN sJxPi5SzkHZFA2FkBE88GbJySIR8WKNAzoDpJEVqlxas+VfNuic499J1c/ufTI4R IG2UmLQjeWJOwKBlaSxY7RivTyGEWpJNOAs3xKIho0bZbDqa986ZLe+kHI34QHVJ cfS/wHFPnYIhiloUUuvwyRwrk4NfS3pUY3c5C/Xmzm+80mAHKT8bUFhxsMExqHE= =3O3D -----END PGP SIGNATURE-----

1 0

[Measurement Team] Next IRC meeting happens on Thursday, Oct 22, 14:00 UTC in #tor-dev
by Karsten Loesing 21 Oct '15

21 Oct '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello list, This is an announcement/reminder that there will be an IRC meeting of the Measurement Team on Thursday, October 22, 2015, 14:00 UTC in #tor-dev https://www.timeanddate.com/worldclock/fixedtime.html?iso=20151022T14 As usual, we'll decide on the agenda at the beginning of the meeting. Here are some suggestions for topics: - team renaming - analytics server - team mailing list - parsing lib comparison - Roster update - CollecTor website redesign - metrics data visualization If you want to suggest something else, just add it to the pad: https://pad.riseup.net/p/zUNzEIFRq5S4 Talk to you in 24 hours. All the best, Karsten -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJWJ5p7AAoJEJD5dJfVqbCrD6cH/1jU21PDjoseeD1DSy2tHwFr gBtgNf4nNiqa6EFd8xuZPezChXZJeIPQ+COUUII0xERHTgwq3aBfcLq1vNixqyKl WMNbsGWBcjvS6G+kd1DritmnWWM3IiihdTvLCZjgLl4KDkT6qB7Do2ZNhZ7qhUUh NOyTY5Yd2ipjXO3PJJzEPoPjWdofcLlnX7rDerGxfewt+EnkEm1tvdVS4Efjo6pc 5udfuojhUQI7kIiAHyjUSyRSt+gWmLFEz01kj52gdG9Q+YFdZ/Pg0vH7+TCzQlLF 8r4Df594CWUAFUvY5X42ge+hfy7ebAkY7oqzFg0P4ukxqgE7f4sRgPTNlrwuxbk= =XYYl -----END PGP SIGNATURE-----

1 0

Request for comment: AEZ for relay cryptography
by Nick Mathewson 21 Oct '15

21 Oct '15

[This is a draft proposal; I'm not giving it a number yet. I'm hoping it'll receive some good advice.] Filename: xxx-aez-relay.txt Title: AEZ for relay cryptography Author: Nick Mathewson Created: 13 Oct 2015 Status: Draft 1. Summary and preliminaries This proposal describes an improved algorithm for circuit encryption, based on the wide-block SPRP AEZ. I also describe the attendant bookkeeping, including CREATE cells, and several variants of the proposal. For more information about AEZ, see http://web.cs.ucdavis.edu/~rogaway/aez/ For motivations, see proposal 202. 2. Specifications 2.1. New CREATE cell types. We add a new CREATE cell type that behaves as an ntor cell but which specifies that the circuit will be created to use this mode of encryption. [TODO: Can/should we make this unobservable?] The ntor handshake is performed as usual, but a different PROTOID is used: "ntor-curve25519-sha256-aez-1" To derive keys under this handshake, we still use HKDF_SHA256, but we produce 96 bytes of output: struct hkdf_output { u8 key_forward[48]; u8 key_backward[48]; }; These two fields are constant for the lifetime of the circuit. (But see section 4.3 below.) (Also see 4.1 for a variant that uses less storage key material.) 2.2. New relay cell payload We specify the following relay cell payload format, to be used when the exit node circuit hop was created with the CREATE format in 2.1 above: struct relay_cell_payload { u32 zero_1; u16 zero_2; u16 stream_id; u16 length IN [0..498]; u8 command; u8 data[498]; // payload_len - 11 }; Note that the payload length is unchanged. The fields are now rearranged to be aligned. The 'recognized' and 'length' fields are replaced with zero_1, zero_2, and the high 7 bits of length, for a minimum of 55 bits of unambigious verification. (Additional verification can be done by checking the other fields for correctness; AEZ users can exploit plaintext redundancy for additional cryptographic checking.) When encrypting a cell for a hop that was created using one of these circuits, clients and relays encrypt them using the AEZ algorithm with the following parameters: Key = Kf for forward cells, Kb for backward cells. # In theory, we are allowed to use a single key here, but I'm # tau = 0 # We want no per-hop ciphertext expansion. Instead we use # redundancy in the plaintext to authenticate the data. Nonce = struct { u64 cell_number; u8 is_forward; u8 is_early; } # The cell number is the number of relay cells that have # traveled in this direction on this circuit before this cell. # ie, it's zero for the first cell, two for the second, etc. # # is_forward is 1 for outbound cells, 0 for inbound cells. # is_early is 1 for cells packaged as RELAY_EARLY, 0 for # cells packaged as RELAY. # # Technically these two values would be more at home in AD # than in Nonce; but AEZ doesn't actually distinguish N and AD # internally. AD = [ The last 32 bytes of the previous cell's plaintext, if this is not the first cell sent in this direction on this circuit ] # Using this as additional data guarantees that any corrupt # ciphertext received will corrupt the plaintext, which will # corrupt all future plaintexts. Using the last 32 bytes of the # ciphertext would not have the same property. This instantiates a wide-block cipher, tweaked based on the cell index and direction. It authenticates part of the previous cell's plaintext, thereby ensuring that if the previous cell was corrupted, this cell will be unrecoverable. 3. Design considerations 3.1. Wide-block pros and cons? See proposal 202, section 4. 3.2. Given wide-block, why AEZ? It's a reasonably fast probably secure wide-block cipher. In particular, it's performance-competitive with AES_CTR. (How fast is it? To encrypt a 509-byte relay cell with a 16 byte nonce and 32 bytes of additional data, AEZ only uses 360 aes rounds. This is the same number of aes rounds as we'd need to CTR encrypt a 512-byte cell with 11.25 rounds per block. AES128 uses 10 rounds per block; AES256 uses 14 rounds per block. We could chop out 4 of the AES rounds by optimizing the code for the tau=0 case, or with AD shenenegans, but that's probably unwise. Additionally, we would no longer need to maintain a running SHA-1 of cells.) It seems secure-ish too. Several cryptographers I know seem to think it's likely secure enough, and almost surely at least as good as AES. [There are many other competing wide-block SPRP constructions if you like. Many require blocks be an integer number of blocks, or aren't tweakable. Some are slow. Do you know a good one?] 3.3. Why _not_ AEZ? There are also some reasons to consider avoiding AEZ, even if we do decide to use a wide-block cipher. FIRST it is complicated to implement. As the specification says, "The easiness claim for AEZ is with respect to ease and versatility of use, not implementation." SECOND, it's still more complicated to implement well (fast, side-channel-free) on systems without AES acceleration. We'll need to pull the round functions out of fast assembly AES, which is everybody's favorite hobby. THIRD, it's really horrible to try to do it in hardware. FOURTH, it is comparatively new. Although several cryptographers like it, and it is closely related to a system with a security proof, you never know. FIFTH, something better may come along. 4. Alternative designs 4.1. Only one key We already use different nonces for the forward and reverse direction; according to the AEZ design, this is sufficient to give security, even if K_b and K_f are the same. We could generate and store only half as much key material by using only a single key per circuit. 4.2. Authenticating things differently Adding only _a part of the plaintext_ of the previous cell seems a little screwy: that's usually easy information to predict. I believe this is secure, however, since the only purpose here is to ensure that _if_ the previous cell was corrupted, subsequent cells will be corrupted too. We could authenticate more stuff, however. We could, for example, authenticate the _entire_ previous ciphertext cell. Or we could authenticate the last 8 bytes of ciphertext and the last 24 bytes of plaintext. (Another thing we might dislike about the current proposal is that it appears to requires us to remember 32 bytes of plaintext until we get another cell. But that part is fixable: note that in the structure of AEZ, the AD is processed in the AEZ-hash() function, and then no longer used. We can compute the AEZ-hash() to be used for the next cell after each cell is en/de crypted.) 4.3. A forward-secure variant. We might want the property that after every cell, we can forget some secret that would enable us to decrypt that cell if we saw it again. One way to do this, at a little extra expense, is to keep a 16 or 32 byte 'chaining' value that changes after each cell. The initial chaining value in each direction would be another output of the HKDF. We could use it as an extra AD for the AEZ encryption. To update the chaining value, we need a one-way function. One option would be your-favorite-hash-function; blake2b isn't _that_ bad, right? We could also try to XOR it with a function of some hidden value from AEZ: E(S,-1,?) is promising, but it would require that we get our hands inside of our AEZ implementation. Also it would require a real cryptographer to come up with it. :) A more severe option is to update the entire key after each cell. This would conflict with 4.1 above, and cost us a bit more. A positively silly option would be to reserve the last X bytes of each relay cell's plaintext for random bytes, if they are not used for payload. This would help forward secrecy a little, in a really doofy way. Any other ideas? 4.4. SHA256 is stupid We could update the ntor definition used in this to use blake2b as its tweakable hash and for its KDF as well. (This would be faster _and_ more secure, not only because blake2b is lots faster than SHA256, but also because we could use the personalization and salt and key features of blake2b to avoid HMAC.) Or there's sha3 I guess if you want to do that.

5 4

Effect of padding on end to end correlation false positive rate
by s7r 20 Oct '15

20 Oct '15

-----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 lucky and is selected in a certain position of a certain rendezvous circuit and can do an end to end correlation of the traffic (both ends). This is different from one end correlation or website fingerprinting attack. For this scenario: HS -> Guard -> Middle1 -> Middle2 -> RDV -> MiddleC -> GuardC -> Client If the client is the attacker, and Middle1 is an evil relay colluding with him, and it was selected 2nd hop in a rendezvous circuit that connects the HS with the attacker (rendezvous is not colluding), he can learn the guard of the hidden service. The client (attacker) can send traffic over that circuit until he gathers enough data to make a fair assumption about where the traffic is coming from (identify the guard of that HS). I am not sure if there will even be a nonzero false positive rate in this context. Confirmation needed for these assumptions, this is what I think after reading: [0],[1]. Does this change with padding? If yes, how? For the same scenario described above, if padding is used, will the attacker have to own the entire path to the guard (Middle1 and Middle2 in the same circuit, since the rest of the path is under his control to select anyway), in order to make a reasonable guess on which might be the guard he is interested in? Or can he make the difference between the real traffic and the padding / dummy traffic and have the same results as with no padding? [0]: https://blog.torproject.org/blog/one-cell-enough [1]: https://blog.torproject.org/blog/traffic-correlation-using-netflows -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBCAAGBQJWIU5yAAoJEIN/pSyBJlsRlj4H+wcAc958SazmoXgYTtJisK5R dgcWZILgnYTYg17ub8Y3Hsgh0YjJyEgwgXV/r6ftNNir8kMSn3t+KMFAt9OpVhOJ 4W0f3E/X18viJNn3Pcb3FDc41sXxpwMVdUd337wGzqaNb8wsCARspmkDv9gdsLje GTTrz2MUa6lWyZHEuJMp02W2pkPVr48UnOsd0S0lyiDM3uxAAQyEtS9XwQyd+hBE KgLG7DHgwOnNzpBeQYJ5KlTzWi6j/NGxXcnHWcuWkq32ZG/gQsw6I43BNV9DMs6r 3UJbrdHsYJKDq8I16Ir0fblaOjsxmU7cEZZioOVngmw8wG6KevGI7fYKsEcqAhk= =CJly -----END PGP SIGNATURE-----

2 1

ResearchEthics
by grarpamp 19 Oct '15

19 Oct '15

https://trac.torproject.org/projects/tor/wiki/doc/ResearchEthics Any number of problems and obstacles to legitimate research areas exist with this... " Examples of unacceptable research activity It is not acceptable to run an HSDir, harvest onion addresses, and do a Web crawl of those onion services. Don't set up exit relays to sniff, or tamper with exit traffic. " Assuming such bans, how is one supposed to legitimately research and report on the real makeup of onion or exit space? These are significant unanswered questions regarding tor use. Concentrate not on bans, which will be ignored by both legit and illegit researchers anyways, but on proper design for data handling and minimization, particularly being sensitive to the tor users and operators involved lest that data become compromised at any stage before final anonymization and wiping.

5 7

Time-to-first-byte on trac.torproject.org
by Virgil Griffith 19 Oct '15

19 Oct '15

I started using Trac a bit more and the slowness is a little unpleasant. Here are some stats: http://www.webpagetest.org/result/151019_RW_387/ The time-to-first-byte is *painful* on both the first load as well as reload. Are there some ways we could improve this? If it's sever-power I'm willing to contribute to a fund for it, but my first thought is that more internal caching needs to be turned on within Trac. Common queries like the frontpage shouldn't be this difficult. But they are inherently this difficult, then we should at least spread it out among multiple machines. -V

1 0

Another Virtual Network Environment needs your I/O
by Rob van der Hoeven 18 Oct '15

18 Oct '15

Hi folks, During this hot summer I did some cool programming which resulted in... Another Virtual Network Environment (avne) AVNE is a small Linux program that runs other programs inside a virtual network environment. All network traffic from this environment is intercepted and forwarded to the Tor network. Interception is transparent and is guaranteed to be 100% effective. To forward network traffic you can simply type avne followed by a program name. Examples: avne bash avne ip link avne iceweasel -P avne -no-remote avne chromium --disable-cache avne wget https://blog.torproject.org/ Because the network interception takes place at the IP-level, no special Tor configuration is needed. In theory all TCP-clients should now be able to use the Tor network. AVNE is currently in the alpha phase of development. It works quite well, but for the for the first beta version I need input from this community. First of all I want to know if there are programs that do not work with avne. I tested with firefox, chromium, wget etc. and encountered no problems. The second question I have is: are there programs / protocols which should be blocked by avne? For example: I think its a bad idea to support unencrypted POP3. Of course I am also interested in bug-reports and your ideas for improvement. On my blog I wrote an article about avne that explains the technologies it uses (User Space Networking and Lightweight virtualization), and also gives an overview of its implementation. You can find the article here: https://hoevenstein.nl/another-virtual-network-environment The source code can be downloaded at: https://hoevenstein.nl/downloads An on-line viewable version of the code is at: https://hoevenstein.nl/source-code-avne-c Hope you like the ideas and code. And of course, your feedback is much appreciated! Rob. https://hoevenstein.nl

2 5

Re: [tor-dev] Crux: Privacy-preserving statistics for Tor
by Vasilios Mavroudis 18 Oct '15

18 Oct '15

Hi, so you were right the databases were corrupt, but they shouldn't have been there in the first place. :-) I didn't want to include large files in the git repo (~120mb in total), so there is a generation script in the tools directory (now added). I added some instructions on the readme file too. Of course, this procedure is done only once. I tried it and it should work now, but let me know if there is still a problem. There is a plan to optimize the way the pre-computed values are used, and this could potentially shrink the size of the databases by a lot. Vasilis On 17 October 2015 at 15:56, str4d <str4d(a)i2pmail.org> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > str4d wrote: > > Vasilios Mavroudis wrote: > >> Hello, > > > >> I would like to introduce our project "Crux", which enables the > >> computation of privacy preserving statistics on sensitive data. > >> The project was developed at University College London (UCL) by > >> me, in close collaboration with George Danezis. > > > > This is fantastic work. Haven't read all of your thesis yet, but > > it looks similar to the stats collection system that we ran for a > > while inside I2P, but with the privacy protections that I wanted it > > to have. Well done! > > > > > >> "Crux" was designed with Tor hidden services in mind (in > >> accordance with this > >> <https://research.torproject.org/techreports/hidden-service-stats-201 > 5 > > > >> > - -04-28.pdf> > > > > > > Tor > >> Tech Report), but it can be applied on various kinds of data > >> (given an appropriate parser). > > > > Excellent. I want to use this in I2P :) > > > > > >> It supports three statistics (i.e. mean, median, variance) and > >> its threat model is compatible Tor's (see technical document > >> below). > > > > I will look into this, but I doubt there will be any > > insurmountable incompatibilities with I2P's threat model. > > > >> Currently, we don't have a parser specific for the data > >> collected by the Tor relays, but we plan to keep adding > >> functionality. > > > >> The source code can be found here: > >> https://github.com/mavroudisv/Crux The theoretical background, > >> threat model, security argument and technical details can be > >> found here: link <http://mavroudisv.eu/files/thesis.pdf> > > > > > >> Ideas, comments, feedback much appreciated! > > > > Firstly: needs more docs. I shouldn't have to read your entire > > thesis in order to figure out how to run it :P The README is a good > > start, but the command parameters need clarification/definitions, > > and it is not at all obvious how the relays work. An XLS file is > > also mentioned without explanation. > > I have now tried running the code, but the "unit test" run by > authority.py fails because bsbdb.btopen() returns an empty dict. I > don't know if this is because the table files are broken or because of > a local issue with my setup (I am using a virtualenv, but I get the > same empty dict when I try to open the tables manually outside the > virtualenv). I am not going to try and fix the latter on my own, > because bsddb is deprecated since Python 2.6, so you shouldn't really > be using it :) (But it must be something else, because I tried using > bsddb3 instead and that also returns an empty dict). > > str4d > > > > > Secondly, you could probably simplify configuration by managing > > hidden service connections yourself. I believe the Stem library can > > do this? I2P has a python library that can be used to listen on and > > connect to I2P Destinations, with a socket-like interface. > > > > It's not clear to me from your thesis whether you plan to merge > > the relay component into the Tor relay code (and have the Tor > > relays talk directly to the query processors), or have your relays > > running separately and interfacing with the Tor relays to fetch > > stats. This will potentially alter how it would be used with other > > networks. In I2P's case I'd imagine it would be easiest (in terms > > of usability by those setting up relays) to write an I2P plugin in > > Java that performs the relay role, but I wouldn't want to be > > duplicating a lot of logic that subsequently needs to be kept > > in-sync with upstream :) > > > > str4d > > > > > >> Vasilis > > > > > > > >> _______________________________________________ tor-dev mailing > >> list tor-dev(a)lists.torproject.org > >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev > > > > _______________________________________________ tor-dev mailing > > list tor-dev(a)lists.torproject.org > > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev > > > -----BEGIN PGP SIGNATURE----- > > iQIcBAEBCgAGBQJWItIgAAoJEBO17ljAn7PglsQP/3tOrL9EZfYMb5fxxVI6/wJm > qDvA8RpbEJDhoMjOc9sLNyMVgvGGPxEdma8I/R8H37yIPOp2GJg82MoXfUk+AGFe > 5ZIIXwf2EzHH0RFLRI5xaQ4DW3Ru1yIzH+E3vhuGclL87YRKnAM0xkMQcueR5xo5 > /ETe9TI7oPCdETI4J6iFoM+Ob9qsRiEVeuT5HEFFKwQhBvl0NSpfMHV9ftuxQHuu > I2B9jomnBdzF9OXnSQrYXg3ho2rxX4hO1TZfQHg5DgHvkt8TQYQM3cwdGE7/rsqC > d4+kBW2RuAz68wq+fLPeeZ2U2ff2QqmDLqVyUJvpP5RqeUcv66J/iYm7md886tTc > palwVGodKiTJ6DBM0z1K97x6Sl1jJXEAkZQAr2yQ8jrC/BJqQRPu2vHeZILqbMEQ > UU3JLjIk/Jc2RGK6zitvj4kTrLdfACEQMYy3brQUawZhaM42QNQgb3LQq1bJXzUo > vISZckX/CVfF+R63oO085LYOO7oTLyY3EhA1PCXiV09Usl/To66Oh4AVYtz/lPLH > 6uoWR/ic5X9gFIXt1t+617+i/L/ILMfqkqN7GzoSbQ8QfyBJrjIikuj575M7AH3o > RuhRYHUTmaCRL+9niDFG/mSVGBxBqiSfW1eS5pGE3hIAcLQd0eFT/38HRdonkfLP > Ug5ihMFSKfKmCIljQ6mm > =jDmS > -----END PGP SIGNATURE----- >

1 0