tor-dev January 2016

tor-dev@lists.torproject.org

58 participants
64 discussions

Notes from 1st Tor proposal reading group [prop241, prop247, prop259]
by George Kadianakis 19 Jan '16

19 Jan '16

Today was the first Tor proposal reading group [0] and we discussed the following guard proposals: Prop#241: Resisting guard-turnover attacks [DRAFT] Prop#259: New Guard Selection Behaviour [DRAFT] Prop#247: Defending Against Guard Discovery Attacks using Vanguards [DRAFT] In this mail, I will assume that the reader is familiar with the concepts behind those proposals. We started by discussing prop241 and prop259. These proposals specify how Tor should pick and use entry guards. - We decided that we should merge the remaining ideas of prop241 into prop259. - prop259: The original guardset should also include 80/443 bridges (shouldn't have disjoint utopic/dystopic guard sets). We should specify a behavior on how the fascist firewall heuristic should work. - prop259: Should probably not impose a specific data structure to the implementor except if strictly required. Instead maybe state the properties that such a data structure needs. Maybe we can put the hashring idea in the appendix? - We can simulate the various algorithms we are examining to test their behavior and correctness. Nick and Isis have already written some guard switching code to be simulated: https://github.com/isislovecruft/guardsim.git However, no simulations happen right now. We should code some simulation scenarios and check that the algorithm works as intended in all possible edge cases: https://github.com/isislovecruft/guardsim/blob/master/doc/stuff-to-test.txt We then moved to discussing prop247. Proposal 247 specifies how entry guards should be used by hidden services to avoid various attacks: - We can think of prop241 as the proposal specifying how entry guards work on Tor. It specifies how Tor selects its set of guards and also how it picks and switches between them. Then prop247 could be stacked on top of prop241 specifying how entry guards are used specifically in _hidden services_ and describing how the guardsets from prop241 can be used in the hidden services setting. To achieve this design we should figure out what we need from Tor guardsets to achieve all the needs of prop247, and then we should design the interface of guardsets appropriately in prop241. A stupid Guardset interface that prop247 could use could be: guardset_layer_1 = Guardset(nodes_to_consider, n_guards=1, rotation_period_max, flags, exclude_nodes) guardset_layer_2 = Guardset(nodes_to_consider, n_guards=4, rotation_period_max, flags, exclude_nodes=guardset_layer_1) - We discussed how the HS path selection should happen in prop247. Should layer-2 and layer-3 vanguards be picked from the set of Guard nodes, or should they be middle relays? This is important to figure out both for security and performance! Also, it's clear that layer-2 vanguards should not be the same node as the layer-1 guard. But what about layer-3 vanguards? Can they be the same node as the layer-1 guard? If not, then an attacker learns information about the layer-1 guard by keeping track of the list of layer-3 vanguards by monitoring many layer-3 rotations. Also, should layer-3 guardsets share nodes between them or should they be disjoint? We should be very careful about what kind of relays we allow in each position since it's clear that it has security implications. We should edit the proposal and specify this further. - We should test our design here with a txtorcon test client, and get some assurance about the performance and correctness of the system. Also, we need to see how CBT interacts with it. If you want to help with any of the above, show up for the little-t-tor meeting tomorrow. --- [0]: https://lists.torproject.org/pipermail/tor-dev/2016-January/010219.html

4 3

Re: [tor-dev] Does Orbot use default obfs4 bridges?
by Nathan Freitas 19 Jan '16

19 Jan '16

On Tue, Jan 19, 2016, at 03:33 PM, David Fifield wrote: > On Tue, Jan 19, 2016 at 03:29:38PM -0500, Nathan Freitas wrote: > > > > On Tue, Jan 19, 2016, at 02:52 PM, David Fifield wrote: > > > Does Orbot have a list of default built-in obfs4 bridges? Or do users > > > fetch them dynamically? I looked in the source code and found default > > > meek bridges but not default obfs4. > > > > No we have no default Obfs4 bridges built-in. It has been on my list to > > get done, because we really should, obviously to make the user > > experience better, and to alleviate meek traffic. > > > > > I'm asking because we recently added a few new high-capacity default > > > obfs4 bridges. > > > https://bugs.torproject.org/18071 (1 bridge) > > > https://bugs.torproject.org/18091 (2 bridges) > > > > I will get this built-in ASAP. > > The list of Tor Browser built-in bridges is here: > https://gitweb.torproject.org/builders/tor-browser-bundle.git/tree/Bundle-D… Fantastic. Those will be built into the next release.

1 0

ENGINE_get_default_ECDx missing?
by Gisle Vanem 19 Jan '16

19 Jan '16

Seems these two OpenSSL functions: ENGINE_get_default_ECDSA() ENGINE_get_default_ECDH() have been dropped; in util/libeay32.num: ... ENGINE_get_default_ECDH 3387 1_1_0 NOEXIST::FUNCTION: ENGINE_get_default_ECDSA 3662 1_1_0 NOEXIST::FUNCTION: ... https://raw.githubusercontent.com/openssl/openssl/master/util/libeay.num (not sure exactly what 'NOEXIST' does). So shouldn't common/crypto.c be patched into something like: --- a/src/common/crypto.c 2016-01-14 22:29:59 +++ b/src/common/crypto.c 2016-01-18 17:55:53 @@ -373,8 +373,10 @@ used by Tor and the set of algorithms available in the engine */ log_engine("RSA", ENGINE_get_default_RSA()); log_engine("DH", ENGINE_get_default_DH()); +#if OPENSSL_VERSION_NUMBER < OPENSSL_V_SERIES(1,1,0) log_engine("ECDH", ENGINE_get_default_ECDH()); log_engine("ECDSA", ENGINE_get_default_ECDSA()); +#endif log_engine("RAND", ENGINE_get_default_RAND()); log_engine("RAND (which we will not use)", ENGINE_get_default_RAND()); log_engine("SHA1", ENGINE_get_digest_engine(NID_sha1)); Isn't OpenSSL 1.1.0 supported yet? Scratching head... BTW, I'm using TDM-gcc 5.1 (http://tdm-gcc.tdragon.net/) on Win-10. -- --gv

3 2

Re: [tor-dev] Does Orbot use default obfs4 bridges?
by Nathan Freitas 19 Jan '16

19 Jan '16

On Tue, Jan 19, 2016, at 02:52 PM, David Fifield wrote: > Does Orbot have a list of default built-in obfs4 bridges? Or do users > fetch them dynamically? I looked in the source code and found default > meek bridges but not default obfs4. No we have no default Obfs4 bridges built-in. It has been on my list to get done, because we really should, obviously to make the user experience better, and to alleviate meek traffic. > I'm asking because we recently added a few new high-capacity default > obfs4 bridges. > https://bugs.torproject.org/18071 (1 bridge) > https://bugs.torproject.org/18091 (2 bridges) I will get this built-in ASAP. +n

2 1

Does Orbot use default obfs4 bridges?
by David Fifield 19 Jan '16

19 Jan '16

Does Orbot have a list of default built-in obfs4 bridges? Or do users fetch them dynamically? I looked in the source code and found default meek bridges but not default obfs4. I'm asking because we recently added a few new high-capacity default obfs4 bridges. https://bugs.torproject.org/18071 (1 bridge) https://bugs.torproject.org/18091 (2 bridges)

2 1

Revisiting Proposal 246: Merging Hidden Service Directories and Introduction Points
by George Kadianakis 19 Jan '16

19 Jan '16

Hello there, we recently finished implementing proposal 250 which is one of the first steps for the upcoming hidden service redesign [1]. The next steps are implementing proposal 224 and the other performance and security proposals [2]. On this note, one of the open design issues that we need to tackle next is whether we should do proposal 246 or not. Proposal 246 merges HSDirs and Intro Points into a single entity to simplify the protocol and improve its performance. The idea is that HSes will pick their intro points using the hash ring algorithm currently used for picking HSDirs. Clients will do the same and connect directly to the intro points instead of going through the HSDir step. I suggest you read the proposal and the discussion thread to become better informed about this idea: https://lists.torproject.org/pipermail/tor-dev/2015-July/009079.html Proposal 246 changes the hidden service protocol substantially, which is why we need to decide whether to do it soon. The next steps in our implementation plan heavily depend on whether we will do proposal 246 or not. Here are some issues that make this proposal not an obvious pick: 1) Security issues - Professor Hopper pointed out [3] that this proposal will double the number of introduction points of a hidden service (from the current 3 to 6). Introduction points have slightly more attack vectors than HSDirs, so we should not increase their number without analyzing further. That said we could potentially increase the number of intro points by doing proposal 246, and at the same time we could also increase their lifetime period to multiple days (instead of the current 18-24 hours lifetime), to keep the exposure of hidden services to an acceptable value. - It was also pointed out that the HSDir algorithm does not take into account the bandwidth of the nodes, making it easier to launch Sybil attacks. However, the rest of the the mailing list thread suggests various ways to do bandwidth weighted hash ring selections [4], so this might not be an important factor. 3) Load balancing issue - With proposal 246, the Tor network decides which relays will be used as the introduction points of a hidden service. A hidden service cannot pick its own introduction points, similarly to how currently a hidden service cannot pick its own HSDirs. This is a problem because it blocks load balancing solutions like onionbalance from working. Variants of the onionbalance logic can still work as suggested in the proposal [5], at the cost of increased engineering and sysadmin complexity. - Another concern here is that hidden services would not be able to change the number of their introduction points. This is not a big problem currently, but it could become in the future if the network gets more overloaded. As a partial solution to this, #17690 suggests making the number of HSDirs a network-wide consensus parameter that could also be used by proposal 246. 2) Reachability issue A final issue here is that if the relay churn of the network increases, the introduction point hash ring might be changing rapidly and clients might get pointed to the wrong introduction points. However, this does not seem like a greater problem than what hidden services are facing with HSDir reachability currently. Is this right, or does prop246 makes it worse? Personally, I'm not that concerned about the security issues I outlined above. I think the security difference will not be that great, and maybe we can equalize it by using some of the listed solutions. However, more thinking is required. I'm currently more concerned about the load balancing and reachability issues that I outlined above and maybe others that I forget. I would like to have more assurance that relay churn will not cause reachability issues to the proposal 246 system before we commit to it. Feedback is very welcome. Also please post any issues that I forgot to mention. We should try to figure out what to do here as soon as possible. If we fail to come to a conclusion here, our engineering plan is to ignore proposal 246 and continue with proposal 224 like it never happened. Of course this will suck if we later decide that proposal 246 was super important and should have happened. Cheers! [1]: https://lists.torproject.org/pipermail/tor-dev/2016-January/010182.html [2]: https://lists.torproject.org/pipermail/tor-dev/2015-October/009762.html [3]: https://lists.torproject.org/pipermail/tor-dev/2015-July/009093.html [4]: https://lists.torproject.org/pipermail/tor-dev/2015-July/009163.html [5]: https://gitweb.torproject.org/torspec.git/tree/proposals/246-merge-hsdir-an…

7 10

Always up-to-date HSTS preload list for Tor?
by Ivan Ristic 18 Jan '16

18 Jan '16

Dear Tor developers, My SSL Labs server test has a feature where it checks for preloaded HSTS in Chrome, IE, Firefox, and Tor. You can see it near the bottom of this report, for example (under "HSTS Preloading"): https://www.ssllabs.com/ssltest/analyze.html?d=scotthelme.co.uk&s=107.170.2… For Tor, I download the preload list from this URL: https://gitweb.torproject.org/tor-browser.git/plain/security/manager/boot/s… That's the best I could find (when I originally implemented the feature), and I now see that the version number has advanced since. Which brings me to my question: is there a public URL that always contains the latest preload list? Thanks! -- Ivan

2 1

Upcoming Onionoo version 3.1 removes "family" field from details and stops returning code 500 when serving stale data
by Karsten Loesing 18 Jan '16

18 Jan '16

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello Onionoo users, the upcoming Onionoo [0] version 3.1 will contain two minor changes that are worth announcing in advance: - Details documents will not contain a "family" field anymore but instead two fields "alleged_family" and "effective_family" which together contain the entries in the now removed "family" field. Clients that wish to continue using "family" field entries will need to switch to using the union of the other two fields instead. See #18026 [1] for details. - The Onionoo server will not return status code 500 anymore if its data gets more than 6 hours old but instead continue returning status code 200 with the somewhat stale data in the body. Clients that wish to keep the current behavior will need to check the "Last-Modified" header themselves and see if the contained timestamp is more than 6 hours old. See #16907 [2] for details. I'm planning to deploy version 3.1 in a week from now, by January 19, 2016. If you need to adjust your Onionoo client to these changes, please do that soon. All the best, Karsten [0] https://onionoo.torproject.org/protocol.html [1] https://trac.torproject.org/projects/tor/ticket/18026 [2] https://trac.torproject.org/projects/tor/ticket/16907 -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJWk3T4AAoJEJD5dJfVqbCrSEAH/3nAFXDEzRQn2FgCVMXNGHQ+ NnWNs+56ZPMWnTx3IynAy6QTsF0r8iQ3gdrhoKTjpgI0mcHgfQi1GlAcFfw/+lZ4 VU1kueZvgK4Eja36wzjh5d2W7CQLq/1muj7rWlFyaBESrnAfc0TmLhYC/Ou8hxcu UtmsJHIE6L4MvYtMNzLSUukU0MVKPOpaAhMJ0U144NdekcD9FP5oVvm6u7SmsOJO /0MFwFlaLOT5Hur6cDBgksbkAQt5sXVx5Qbnf5GY+i/Vv6X4ZIwneY2e/dAwQdBe VZUIhl1TGFmCEnt3nYFG6TzxS4IrzetO6/6de4VDRiIu9ukcseY3IJs8rkjQh6k= =pyyb -----END PGP SIGNATURE-----

1 1

How many exits exit from an IP address different than their OR address? (10.7%)
by David Fifield 17 Jan '16

17 Jan '16

I wanted to know how many exits exit from an address that is different from their OR address. The answer is about 10.7%, 109/1018 exits. The interesting part is that of those 109 mismatches, 87 have an exit address that differs from the OR address in all four octets; i.e., the IP addresses used by the exit are not even in the same /8. Also, there are several groups of exits whose OR addresses *are* in a related subnet, but which all exit through the same, unrelated, IP address. See for example 109.236.82.* (all exiting through 185.108.128.7), 178.17.171.* (all exiting through 37.48.65.71), and 217.23.11.* (all exiting through 85.17.31.120) in the table below. I wrote an exitmap module that hits an IP-checker website. The module wrote a CSV file where each row included the exit's OR address and the address as reported by the remote web site. I ignored IPv6 OR addresses. I did not find any fingerprint that had more than one IPv4 address (considering the .fingerprint and .or_addresses members from Stem). Percentages are just raw counts, not weighted by exit probability. Total number of exits: 1018 (100.0%) Number of failures: 18 (1.8%) Number of matches: 891 (87.5%) Total number of mismatches: 109 (10.7%) Number of 1-octet mismatches: 19 (1.9%) Number of 2-octet mismatches: 3 (0.3%) Number of 3-octet mismatches: 0 (0.0%) Number of 4-octet mismatches: 87 (8.5%) Table of mismatches * = mismatch 1 octet ** = mismatch 2 octets *** = mismatch 3 octets **** = mismatch 4 octets fingerprint or_address remote_address mark B060482C784788B8A564DECD904E14CB305C8B38 176.10.104.241 176.10.104.240 * DC41244B158D1420C98C66F7B5E569C09DCE98FE 176.10.104.241 176.10.104.240 * 487092BA36F4675F2312AA09AC0393D85DAD6145 176.10.104.244 176.10.104.243 * DE7DE889E0D1A5F397AE35642060B84999581203 176.10.104.244 176.10.104.243 * 7A65CC8F45134F3393A0295EFFD2980DD885E8E2 176.123.6.157 176.123.6.155 * A7E78D9880BB0793409D386D15E83B3B1236B19F 178.175.128.54 178.175.128.50 * 8BF22BEA5F854F2BB2E09C71260ADF590D355E36 213.61.149.125 213.61.149.100 * 80D73E75A30BEEF627604B7014753304764E0723 213.61.149.126 213.61.149.100 * 5D263037FC175596B3A344132B0B755EB8FB1D1C 31.185.27.203 31.185.27.1 * C974508A98446F36169FB248655BCD50DF17F14C 37.130.227.134 37.130.227.133 * 170EC06D58E9094A027F4169514ADD98D30983A6 46.235.226.27 46.235.226.226 * D3BE73ECE50DA9243DC0DF9DA6ED25027B82D385 50.7.178.101 50.7.178.100 * FEDEF82551BB49DB54BE6C77D27AD0E20A8D6FD6 50.7.178.102 50.7.178.100 * 10E13E340651D0EF66B4DEBF610B3C0981168107 77.247.181.164 77.247.181.162 * 06E123865C590189B3181114F23F0F13A7BC0E69 77.247.181.166 77.247.181.162 * 664BDC0344771122FC6C4F577BF0AEC3F4ED5456 80.73.242.142 80.73.242.130 * 9E3E47D7B92144CBAB0D487CCE192531F6A55833 81.209.35.111 81.209.35.112 * 410C286061266C562049178C6BF1E04060F51F7C 94.103.175.85 94.103.175.86 * F4B72EA6FD0EACF652B6C200611F37244F2B31F3 94.242.228.107 94.242.228.108 * 62BEE61EB88D4A81C3BA3931D6FA999D706AC4D5 62.149.13.57 62.149.12.153 ** 1BC17B72F90998F0BAEE25E36FFC140C9D7A8D7A 85.119.82.4 85.119.84.57 ** AA60D088E8317BBA3D2CF96C706AB4452FB2F57D 90.182.128.100 90.182.235.46 ** 4E915A5CCDBBDD4BD4B7F09A5AFB581AB1AD7EF2 107.181.178.204 104.156.228.72 **** 03B4386E579BEBCF7605D0FB17A688B35C342D5D 109.236.82.50 185.108.128.7 **** C3B1E12BCA2F307B64737AB84993E7B414FD3D09 109.236.82.50 185.108.128.7 **** B9DC592CBC10EC7428730BF658F9211B8773800F 109.236.82.51 185.108.128.7 **** DE89B3B6954FFC0F76F6B37A05E2AD6EF3B046F1 109.236.82.51 185.108.128.7 **** CF9F5B88C0F95EB6C5547CE5FB38503049DF784D 109.236.82.52 185.108.128.7 **** 57275A9356CFB1D36E64B117D44AB9F67711E483 109.236.82.53 185.108.128.7 **** D1E52741A7DCB4D51C7EFC82A654E2527516E1B0 109.236.82.53 185.108.128.7 **** 7837F5B740223D19D8A0D3127D2A8EB9FDA59F67 148.163.73.112 206.217.208.162 **** B6045286F21E7078203E1B03C8E00669A2154724 148.163.73.112 206.217.208.162 **** D225C2EC81E044E3947BC49929E46003ED62C89F 151.80.164.147 46.166.186.238 **** 23A69F271ACBFACB20467559D1C04F13DEF74B4B 153.92.126.135 128.127.105.94 **** 4236DF494DC91E1245234AA676F1F993ECB067F5 153.92.126.135 128.127.105.94 **** 27CE487BABE6C2128FB2D1A801C7CB715B48EC6B 153.92.126.19 168.1.6.34 **** C369EB6BFDFB996864746944544B82C9684C46EA 153.92.126.19 168.1.6.34 **** 5453CAF677B8E754C4D5EFA1FEDD8ABB16950FCB 153.92.127.143 168.1.10.226 **** 756F68024C6E55FF7142AD933C135F88B552A932 153.92.127.143 168.1.10.226 **** B0E7C83FA0C728997BB60CB0C758A3A3FDC3C1DB 173.243.112.148 162.216.46.165 **** E6BE2BEAAF4A543F9D94CD20CB459ECFEA3AD1B1 173.243.112.148 162.216.46.165 **** 7585DDCEB14783C69960E777BA258F5B3948F1C9 176.126.85.175 159.122.133.198 **** CBBCD92AD9479C8FBB8AA17FF22C7EC206FF5B1A 176.126.85.175 159.122.133.198 **** 9634A0F1FBE02EBF6E0D59CA7835928D6D55CBCA 176.126.85.176 161.202.72.152 **** C68988E3DD72549AD9C3D1A67FAD056241154775 176.126.85.176 161.202.72.152 **** 58287449DDAD3CF4020071E1139CB4A22BB02D02 178.17.171.140 37.48.65.71 **** 7E2AFD5EA1FD32B0EBA4BDC3C102B9DC67B882E7 178.17.171.140 37.48.65.71 **** 59DE28A0D0A5529CEA9FC4B90DFCFCEC980C4139 178.17.171.156 37.48.65.71 **** E94FA1FDEDF7FC10208C51DABD4EC5045C0A4EC4 178.17.171.156 37.48.65.71 **** 52F6510B5D59678B77DF351C0F7F9B5A2070F393 178.17.171.157 37.48.65.71 **** A566EBAC657485F3D0AEE70C021EA2658D9F0B09 178.17.171.157 37.48.65.71 **** BCF9B6FA788E7F74DD77724D205C46195688D748 178.17.171.159 37.48.65.71 **** D41C2006D7C461BDC22B9D236CC93F5D366C1388 178.17.171.159 37.48.65.71 **** 5CECC5C30ACC4B3DE462792323967087CC53D947 178.32.181.96 37.187.129.166 **** 65F9944338C684109EB975D0EC7489B30E191E87 178.32.181.97 37.187.129.166 **** 66AA1EB64AAFEDC1EA8E49A701F6C472102C5E1A 178.32.181.98 37.187.129.166 **** 4F0003EAB0E8712B94B29A84BF8B8F34C95927BC 185.106.120.153 216.185.103.139 **** 4287D0C57CEFBE7E06B24A0E9370DC671FED5462 185.62.190.38 93.115.87.78 **** D96F409E59D5C41F3761F1F23438131BDE57C538 185.62.190.38 93.115.87.78 **** 8E15D869D266DF5B08351122185F9660CA6D0FA2 185.82.202.178 216.185.103.139 **** BF6379111EC2C29C104ED0239D5709D08BC3B9EB 188.209.52.109 5.149.249.10 **** 184E9215A97F21323BF8661329FCB6F89305CDAC 192.3.24.227 173.225.119.156 **** 9AC41D1DCA4A1BB5D52708E9EE00CED129567B7C 192.3.24.227 173.225.119.156 **** 7DF1BD29A7F927B61F31688395D39F75FC541647 209.141.43.84 67.212.234.181 **** 86D3FECC084BE5611B3F7F4791DAB6204C2E2996 209.141.43.84 67.212.234.181 **** 5F2F5B0014BE0C36E98EEAD5FC35A100FCCEDD4B 217.23.11.95 85.17.31.120 **** CC8C96DF58EFC67662FF751425D2A4D6C7D0F8F0 217.23.11.95 85.17.31.120 **** 1BE59B741F6DAECF29F13226C33B3282316BD81C 217.23.11.97 85.17.31.120 **** 83FCB9E1BE894C3947686AB6C11074B4AAA959B7 217.23.11.97 85.17.31.120 **** AB802EDBD1CF49CDE5A03394AC1B20C5DC1E17CE 217.23.11.98 85.17.31.120 **** C8D9AD239C658121999E56196A8AF74FF586A073 217.23.11.98 85.17.31.120 **** A478E6F4F193BDE43C3BD2BC6A5BC90DA5472FE8 217.23.7.25 168.1.99.217 **** B3233E96418C4E89AF22FC9A1F2392C0D194117B 217.23.7.25 168.1.99.217 **** 4AF6CEC4351DE02BB5A7CBBC82607171832C687B 217.23.7.79 168.1.99.217 **** 26ABA62FBEE9A751790C31AA9EE9E5014439769C 217.23.7.98 168.1.99.217 **** 382248E9E99857109B14344CF2B88166B41297A3 217.23.7.98 168.1.99.217 **** 137AEDE28D9E0BBABE2A5B2F476096740EF1A226 217.23.7.99 168.1.99.217 **** 69ABCEEE7117BBBBF74BA03C09963D28A4F7376F 217.23.7.99 168.1.99.217 **** FA4E22CFC0802D6738837DE980AFC7199F7DB040 217.34.135.225 136.0.2.226 **** 68F70BFCB2A5400ED6F98C8DB30C41A36743962D 217.37.19.115 95.211.184.197 **** C9A7289A94FF30C8772D7E70B56EACA330B95D08 31.220.42.170 95.211.148.154 **** D8082DFB5E22F23D60DE1F6A80986323FF86C027 31.220.42.170 95.211.148.154 **** D90ED0B491FB089EEA827188891BB47EBE13DC14 37.48.124.116 85.17.31.120 **** 276A7ACA7515E90ABB2AB36D4F3421B1C7FB4501 37.48.124.117 85.17.31.120 **** 5FEA88EFEDC5897F7094A1759CE25BA0D3DA87E7 37.48.124.117 85.17.31.120 **** 1F85C11528B6C599EDC488A68DF045F73D29CB18 37.48.64.48 109.201.143.40 **** F712F85AFA84A4D68A40A7AC20416D0B426969CD 37.48.64.48 109.201.143.40 **** 0C7A04579C0A53D99389333D2F9BAE35589F0F84 37.48.64.49 109.201.143.40 **** 71AE6B66F521BD5E6F304A08FB2ABADF4557D815 37.48.64.49 109.201.143.40 **** B9C49DBE93D7D70B41CF95C4F91EFDFC73FC5E60 46.105.183.141 108.61.123.75 **** D3DA6122AA416B8D7AB02CA9858DC3F206C656D2 46.105.183.142 108.61.123.75 **** D85E3FFE70BCBC6964969CDF1065457736D99DE4 50.7.124.238 161.202.72.185 **** 1AE0B173A9FA95D4258B9FC181FDB2BBF040F913 50.7.124.243 161.202.72.185 **** C5325DED0CFEA73F381920FADF5F1220B72841B8 50.7.124.243 161.202.72.185 **** 68D9005982673F068B7844D60915FD141155A8AC 51.254.83.238 108.61.123.75 **** 7774C0F736E02AD48C7A4F3BDFE636A21BBE0255 51.254.83.238 108.61.123.75 **** 4F154FF308400D5BDFB791FAD4C7577547BAA5CA 74.122.198.101 168.1.6.28 **** C75EC9CB9667CEC47BB155DD322789DBE0384ED8 74.122.198.101 168.1.6.28 **** 308D5B726051761D40DB31C7E89254A3CD3F27E0 78.142.19.59 85.17.25.22 **** 3D28E5FBD0C670C004E59D6CFDE7305BC8948FA8 78.142.19.59 85.17.25.22 **** 70119F72F2609BA1CC12640BF66905FE21768152 79.143.87.204 104.238.169.126 **** 83D664A8216DBE4BD48F71BDC61E8F7D8AB68517 79.143.87.204 104.238.169.126 **** C7E75D7D968C2355791EC29A420F69AF2737DA58 93.158.215.174 31.7.56.133 **** 0FAE6840763B2C9DDBCDD9DBA7C1A0549FF0155A 94.242.206.183 93.115.83.253 **** 13DFA359319F34F3FFC55154BDBC499FB5822C1C 94.242.206.183 93.115.83.253 **** 0760C0A34CCBCB2614075E27B88151FCC7D047EC 94.242.206.35 93.115.83.253 **** BFD74D651690324DCA9FB744E2D54DDC814DD3FB 94.242.206.35 93.115.83.253 **** 0BE8EBA01005974782C4573037F4F82D915166C5 96.43.142.28 80.82.215.199 **** A9FEB4AD16FC0ECCF5B01885374E4243E0981384 96.43.142.28 80.82.215.199 ****

8 12

Re: [tor-dev] Comparing Stem, metrics-lib, and zoossh
by Karsten Loesing 17 Jan '16

17 Jan '16

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello Philipp and iwakeh, hello list, Damian and I sat down yesterday at the dev meeting to talk about doing a comparison of the various descriptor-parsing libraries with respect to capabilities, run-time performance, memory usage, etc. We put together a list of things we'd like to compare and tests we'd like to run that we thought we'd want to share with you. Damian and I will both be working on these for metrics-lib for a short while and then switch to Stem. Please feel free to join us in these effort. The result is supposed to live on Stem's home page unless somebody comes up with a better place. Thanks! All the best, Damian and Karsten On 30/09/15 10:57, Karsten Loesing wrote: > 1. capabilities - supported descriptor types - all the ones on > CollecTor's formats.html - hidden service descriptors (have an > agreed @type for that) - getting/producing descriptors - reading > from file/directory - reading from tarballs - reading from > CollecTor's .xz-compressed tarballs - fetching from CollecTor - > downloading from directories (authorities or mirrors) - generating > (for unit test) - recognizing @type annotation - inferencing from > file name - keeping reading history - user documentation - > validation (format, crypto, successful sanitization) - packages > available - how much usage by (large) applications > > 2. performance (CPU time, memory overhead) - compression: > .xz-compressed tarballs/decompressed tarballs/plain-text - > descriptor type: consensus, server descriptor, extra-info > descriptor, microdescriptors - validation: on or off (allows lazy > loading) > > 3. tests by descriptor type - @type server-descriptor 1.0 - Stem's > "List Outdated Relays" - average advertised bandwidth - fraction of > relays that can exit to port 80 - @type extra-info 1.0 - sum of all > written and read bytes from write-history/read-history - number of > countries from which v3 requests were received - @type > network-status-consensus-3 - average number of relays with Exit > flag - @type network-status-vote-3 - Stem's "Votes by Bandwidth > Authorities" - @type dir-key-certificate-3 - @type > network-status-microdesc-consensus-3 1.0 - @type microdescriptor > 1.0 - look at single microdesc cons and microdescs, compile list > of extended families - fraction of relays that can exit to port 80 > - @type network-status-2 1.0 - @type directory 1.0 - @type > bridge-network-status - @type bridge-server-descriptor - @type > bridge-server-descriptor 1.0 - @type bridge-extra-info 1.3 - @type > bridge-pool-assignment - @type tordnsel 1.0 - @type torperf 1.0 > > 4. action items - get in touch with Dererk for packaging > metrics-lib for Debian > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJWDOCYAAoJEJD5dJfVqbCrwAMIAJ0Chlui/Qv5kiGy9WZVkoKU UsxiK1IGVh/eGrpunzKdWQtVhvv+285Ab0OUB4URTK5mpOE+bKD3vcFy3ziXvpke xl5X2rZ/MtzJpRrGcAue0+2YZBrmOsGtGbclH9LcnTRgs65AKFMUp/SPf30LS0Pw l8tg6xUtB7/97qxwNDj08J9Yp/YtWaankE0zuI3py10qa/2RTXBSjZ0JkemLmhxL zVy2yUirNdC+bq9rNh+qh2LMIIEEVbGX2sHJx4JdbLjrJAyrSPtyFhXaih4jkIz3 TptTymRwX8Peny7zEJkkGojH6FkOW0gwpfaZBd4vkphLUbyupHIt3k9aKS15Je0= =uGPS -----END PGP SIGNATURE-----

3 23

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-dev January 2016