Re: [tor-dev] Becoming an Open Source Contributor
> On 13 Aug 2017, at 05:02, John kongtcheu wrote: > > Hello Tor developers, > > I am interested in becoming an open source contributor for Tor, but I don't > know where to start some guidance would be appreciated. Hi John, A list of (some of) Tor's open source projects is here: https://www.torproject.org/getinvolved/volunteer.html.en Have a look through, pick one you like, and follow the instructions there. Please feel free to write back if you have more questions. And welcome! Tim T -- Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n signature.asc Description: Message signed with OpenPGP ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Proposal 281: downloading microdescriptors in bulk
> On 12 Aug 2017, at 03:36, Nick Mathewson wrote: > > Filename: 281-bulk-md-download.txt > Title: Downloading microdescriptors in bulk > Author: Nick Mathewson > Created: 11-Aug-2017 > Status: Draft > > 1. Introduction > > This proposal describes a ways to download more microdescriptors > at a time, using fewer bytes. > > Right now, to download N microdescriptors, the client must send > about 44*N bytes in its HTTP request. Because clients can request > microdescriptors in any combination, the directory caches cannot > pre-compress responses to these requests, and need to use less > space-efficient on-the-fly compression algorithms. > > Under this proposal, clients simply say "Send me the > microdescriptors I need", given what I know. > > 2. Combined microdescriptor downloads > > 2.1. By diff > > If a client has a consensus with base64 sha3-256 digest X, and it > previously had a consensus with base64 sha3-256 digests Y then > it may request all the microdescriptors listed in X but not Y, > by asking for the resource: > /tor/micro/diff/X/Y > > Clients SHOULD only ask for this resource compressed. > > Caches MUST NOT answer this request unless they recognize the > consensus with digest X, and digest Y. > digest Y. Extra "digest Y. " > If answering, caches MUST reply with all of the > microdescriptors that the cache holds that were listed by > consensus X, and MUST omit all the microdescriptors that were > omitted listed in consensus Y. What happens if the consensus versions are different? In particular, what happens if the microdesc algorithms are different in these consensus versions? (What should happen is that the diff is larger than normal, because most microdesc hashes have changed. We should have a test for this.) > 2.2. By consensus: > > If a client has fewer than NMNM% of the microdescriptors listed in a > consensus X, it should fetch the resource > /tor/micro/full/X > > Clients SHOULD only ask for this resource compressed. > > Caches MUST NOT answer this request unless they recognize the > consensus with digest X. They should send all the microdescriptors > they have that are listed in that consensus. > > 2.3. When to make these requests > > Clients should decide to use this format in preference to the > old download-by-digest format if the consensus X lists their > preferred directory cache as using a new DirCache subprotocol > version. (See 5 below.) Don't clients have 3 preferred directory caches? What about fallback directory mirrors? We don't care about diff/X/Y - there is no previous consensus. But knowing when a fallback supports full/X could be handy. Or do we deliberately want to use the legacy protocol to bootstrap, so a single cache can't lie to us? What about bridge clients? Can they find out from the bridge descriptor? > 3. Performance analysis > > This is a back-of-the-envelope analysis using a month's worth of > consensus documents, and a randomly chosen sample of > microdescriptors. > > > On average, about 0.5% of the microdescriptors change between any > two consensuses. Call it 50. That means 50*43 bytes == 2150 > bytes to request the microdescriptors. It means ~24530 bytes of > microdescriptors downloaded, compressed to ~13687 bytes by zstd. > > With this proposal, we're down to 86 bytes for the request, and we > can precompute the compressed output, making it save to use lzma2, > getting a compressed result more like 13362. > > It appears that this change would save about 15% for incremental > microdescriptor downloads, most of that coming from the reduction > in request size. > > For complete downloads, a complete set of microdescriptors is about > 7700 microdesciptors long. That makes the total number of bytes > for the requests 7700*43 == 331100 bytes. The response, if > compressed with lzma instead of zstd, would fall from 1659682 to > 1587804 bytes, for a total savings of 20%. > > > 5. Compatibility > > Caches supporting this download protocol need to advertise > support of a new DirCache subprotocol version. T -- Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n signature.asc Description: Message signed with OpenPGP ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Dir auths using 2x bandwidth in last week
> On 21 Aug 2017, at 14:05, David Fifield wrote: > > On Mon, Aug 21, 2017 at 01:56:16PM +1000, teor wrote: >> >>> On 10 Aug 2017, at 13:36, Roger Dingledine wrote: >>> >>> https://atlas.torproject.org/#details/9695DFC35FFEB861329B9F1AB04C46397020CE31 >>> https://atlas.torproject.org/#details/F2044413DAC2E02E3D6BCF4735A19BCA1DE97281 >>> https://atlas.torproject.org/#details/BD6A829255CB08E66FBE7D3748363586E46B3810 >>> https://atlas.torproject.org/#details/74A910646BCEEFBCD2E874FC1DC997430F968145 >>> https://atlas.torproject.org/#details/7EA6EAD6FD83083C538F44038BBFA077587DD755 >>> all show a big increase in sent bytes starting at the end of July. >>> >>> It isn't growth in Tor users, since those have stayed relatively flat >>> in the last two weeks. >>> >>> And the new rate seems to be the new normal -- it's showing no signs of >>> going back to the old rate. >>> >>> I would assume it's outgoing directory stuff, since that's most of what >>> dir auths do. >>> >>> Any guesses? >> >> In July, Tor 0.3.0 became the most common relay version in the network, >> growing at quite a rapid rate: >> >> https://metrics.torproject.org/versions.html >> >> There doesn't seem to be any corresponding Tor Browser release in that >> timeframe: >> >> 3 July: https://blog.torproject.org/blog/tor-browser-702-released >> 8 August: https://blog.torproject.org/blog/tor-browser-704-released > > 2 July is when deb.torproject.org switched to 0.3.0. We merged a fallback directory mirror change to 0.2.8 and later in mid-May, but I think that's too far back. (The actual releases were up to a month later.) https://trac.torproject.org/projects/tor/ticket/21564 If we want to reduce the load on authorities, we can backport this change, which makes clients try fallbacks before authorities: https://trac.torproject.org/projects/tor/ticket/17750 It's been in master (0.3.2) for almost 2 months now. T -- Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n signature.asc Description: Message signed with OpenPGP ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Dir auths using 2x bandwidth in last week
On Mon, Aug 21, 2017 at 01:56:16PM +1000, teor wrote: > > > On 10 Aug 2017, at 13:36, Roger Dingledine wrote: > > > > https://atlas.torproject.org/#details/9695DFC35FFEB861329B9F1AB04C46397020CE31 > > https://atlas.torproject.org/#details/F2044413DAC2E02E3D6BCF4735A19BCA1DE97281 > > https://atlas.torproject.org/#details/BD6A829255CB08E66FBE7D3748363586E46B3810 > > https://atlas.torproject.org/#details/74A910646BCEEFBCD2E874FC1DC997430F968145 > > https://atlas.torproject.org/#details/7EA6EAD6FD83083C538F44038BBFA077587DD755 > > all show a big increase in sent bytes starting at the end of July. > > > > It isn't growth in Tor users, since those have stayed relatively flat > > in the last two weeks. > > > > And the new rate seems to be the new normal -- it's showing no signs of > > going back to the old rate. > > > > I would assume it's outgoing directory stuff, since that's most of what > > dir auths do. > > > > Any guesses? > > In July, Tor 0.3.0 became the most common relay version in the network, > growing at quite a rapid rate: > > https://metrics.torproject.org/versions.html > > There doesn't seem to be any corresponding Tor Browser release in that > timeframe: > > 3 July: https://blog.torproject.org/blog/tor-browser-702-released > 8 August: https://blog.torproject.org/blog/tor-browser-704-released 2 July is when deb.torproject.org switched to 0.3.0. nusenu noted it here: https://twitter.com/nusenu_/status/884128686764687361 I added a line already to https://trac.torproject.org/projects/tor/wiki/doc/MetricsTimeline ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Dir auths using 2x bandwidth in last week
> On 10 Aug 2017, at 13:36, Roger Dingledine wrote: > > https://atlas.torproject.org/#details/9695DFC35FFEB861329B9F1AB04C46397020CE31 > https://atlas.torproject.org/#details/F2044413DAC2E02E3D6BCF4735A19BCA1DE97281 > https://atlas.torproject.org/#details/BD6A829255CB08E66FBE7D3748363586E46B3810 > https://atlas.torproject.org/#details/74A910646BCEEFBCD2E874FC1DC997430F968145 > https://atlas.torproject.org/#details/7EA6EAD6FD83083C538F44038BBFA077587DD755 > all show a big increase in sent bytes starting at the end of July. > > It isn't growth in Tor users, since those have stayed relatively flat > in the last two weeks. > > And the new rate seems to be the new normal -- it's showing no signs of > going back to the old rate. > > I would assume it's outgoing directory stuff, since that's most of what > dir auths do. > > Any guesses? In July, Tor 0.3.0 became the most common relay version in the network, growing at quite a rapid rate: https://metrics.torproject.org/versions.html There doesn't seem to be any corresponding Tor Browser release in that timeframe: 3 July: https://blog.torproject.org/blog/tor-browser-702-released 8 August: https://blog.torproject.org/blog/tor-browser-704-released (Our estimates suggest that half the load on directory authorities is from relays, and half is from clients.) I wonder if the new guard selection algorithm, or some other relay change, is causing relays to download more descriptors from more directory authorities? T -- Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n signature.asc Description: Message signed with OpenPGP ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Draft patchset for PT2.0 support (ticket #21816)
On Sun, Aug 20, 2017 at 5:48 PM, Robin Tarsiger wrote: > Good day, tor-dev; > > As some of you know, I've been working on a patchset for Tor to allow > it to participate in Pluggable Transports 2.0 configuration, primarily > the new JSON Parameter Block SOCKS method (at least that's what I've > been calling it in the absence of a more official name), almost but > not quite as described in section 3.3.4 of PT2 draft 2 [1]---i.e., > basically #21816 [2]. > > [1] https://www.pluggabletransports.info/assets/PTSpecV2Draft2.pdf > [2] https://trac.torproject.org/projects/tor/ticket/21816 > > I'm attaching a draft patchset which adds this functionality, with the > intent of getting feedback and making remaining cleanups or other > modifications necessary to get it merged into Tor. I have successfully > completed circuits through an obfs4 bridge using both obfs4proxy (PT1) > and a version of shapeshifter-dispatcher (PT2) using a patched Tor. I've > tried to follow the local style, but the preferred implementation > strategies aren't always clear, and of course I'd appreciate any reports > of other problems. > > A forked Git repository is also available on Bitbucket [5][6], which > will be updated as I make remaining changes. > > [5] https://bitbucket.org/DasyatidPrime/tor-rtt2017-21816.git (Git) > [6] https://bitbucket.org/DasyatidPrime/tor-rtt2017-21816/src (Web) > > More implementation details are below if you're interested in this; > thanks for your attention. I'll try to be around on IRC more during > the week, so feel free to ping me there as well. > Hi, Robin! Looks like interesting work. Can you add links to this stuff on ticket #21816, so it can get reviewed We usually don't use the mailing list to track patches for review, since things can tend to get lost. best wishes, -- Nick ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Tor and IP2Location LITE
>> All in all, we (Tor's metrics team) are considering it! But it'll be on >> the order of weeks or maybe months before we can move this forward. No problem. Just let me know if any helps needed. On Mon, Aug 21, 2017 at 4:02 AM, Karsten Loesing wrote: > On 2017-08-16 21:19, Karsten Loesing wrote: > > On 2017-08-16 05:38, KL Liew wrote: > >> All, > > > > Hi Kim, > > > >> My name is Kim, the founder of IP2Location, a geolocation service > >> provider since 2002. > >> > >> It looks like Tor is looking to review other providers for GeoIP service > >> while I was reading one of a meeting minute for a meeting back in March > >> 2017. > >> > >> https://trac.torproject.org/projects/tor/wiki/org/ > meetings/2017Amsterdam/Notes/Metricsin5Years > >> > >> We are very interested in contributing to Tor and work on this matter. > >> Tor can host and integrate IP2Location LITE > >> (http://lite.ip2location.com) into their application. IP2Location has > >> programming libraries in most languages. We can also work with > >> developers if there is any technical issues. > >> > >> In term of accuracy, you can find the latest research paper published by > >> TUM. IP2Location has good accuracy as reported in Table V. > >> > >> Title : HLOC: Hints-Based Geolocation Leveraging Multiple > >> Measurement Frameworks > >> Authors : Quirin Scheitle, Oliver Gasser, Patrick Sattler, Georg > >> Carle from Technical University of Munich (TUM) > >> PDF Access : https://arxiv.org/pdf/1706.09331.pdf > >> > >> Let me know if there is any questions. > > > > Thanks for reaching out to us! > > > > It's indeed on our list to evaluate other geolocation databases and > > possibly switch over. I'll bring this topic up at tomorrow's metrics > > team meeting to discuss possible next steps for such an evaluation. I'll > > get back to you here to share the results. > > So, we discussed this at our team meeting on Thursday and decided to > further evaluate switching to IP2Location. > > That would be a non-trivial project, because we're using geolocation > data in at least two places: 1. shipped with the core Tor program and 2. > deployed on Tor Metrics services like Onionoo. And at least the former > requires close coordination with Tor's network team. > > In any case we'll want to be sure whether this switch is the right move > before starting such a project. The paper is a good start, but we might > want to run more evaluations ourselves. For example, we could involve > relay operators by asking them which resolved location is closer to > reality. But even this evaluation requires writing some code, which puts > it on a long list of things we'd like to do. > > All in all, we (Tor's metrics team) are considering it! But it'll be on > the order of weeks or maybe months before we can move this forward. > > > One question, though, that just came to mind: Are there archives > > available for past IP2Location LITE databases, or do you provide just > > the latest version? Having archives, possibly even back to 2002, would > > be pretty useful for Tor Metrics. (I didn't look around as much on your > > homepage, so please apologize if this question is already answered > there.) > > You replied off-list: > > > We do not have archive for the IP2Location LITE. We just started this > free database a few years back. > > Okay. Maybe we could do something with archive.org in that case. It's > not that we do have a complete history for MaxMind's files, except that > we could probably create our own history from Tor's Git repository which > contains files based on MaxMind's files. > > All the best, > Karsten > > > > > >> - Kim > > > > All the best, > > Karsten > > > > > ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Draft patchset for PT2.0 support (ticket #21816)
Good day, tor-dev; As some of you know, I've been working on a patchset for Tor to allow it to participate in Pluggable Transports 2.0 configuration, primarily the new JSON Parameter Block SOCKS method (at least that's what I've been calling it in the absence of a more official name), almost but not quite as described in section 3.3.4 of PT2 draft 2 [1]---i.e., basically #21816 [2]. [1] https://www.pluggabletransports.info/assets/PTSpecV2Draft2.pdf [2] https://trac.torproject.org/projects/tor/ticket/21816 I'm attaching a draft patchset which adds this functionality, with the intent of getting feedback and making remaining cleanups or other modifications necessary to get it merged into Tor. I have successfully completed circuits through an obfs4 bridge using both obfs4proxy (PT1) and a version of shapeshifter-dispatcher (PT2) using a patched Tor. I've tried to follow the local style, but the preferred implementation strategies aren't always clear, and of course I'd appreciate any reports of other problems. A forked Git repository is also available on Bitbucket [5][6], which will be updated as I make remaining changes. [5] https://bitbucket.org/DasyatidPrime/tor-rtt2017-21816.git (Git) [6] https://bitbucket.org/DasyatidPrime/tor-rtt2017-21816/src (Web) More implementation details are below if you're interested in this; thanks for your attention. I'll try to be around on IRC more during the week, so feel free to ping me there as well. -RTT ... Details: Not visible above, related to the target functionality: - I'm assuming the SOCKS method includes a response with an analogous structure to RFC 1929; PT2 draft 2 doesn't specify one. I've cleared this with blanu, and that's intended for the next draft of the PT2 specification. - Similarly, the length prefix is in fact big-endian; the example in PT2 draft 2 is wrong, though the text is correct. - We're looking into getting an IANA assignment for the method number. Technically this probably meets the requirements for the private use block, but I feel like interop might be easier later on, and it could simplify code paths in places to have a registered number (mainly if it's possible to decouple the method negotiation from the configuration-version plumbing). I believe this is still in limbo. - For the PT2 side, I've been testing against my branch of shapeshifter-dispatcher [3] compiled with my branch of shapeshifter-ipc [4] since there were some breaking changes to Shapeshifter upstream which were otherwise preventing it from interoperating with Tor. I'm planning to help merge fixes into Shapeshifter upstream as I can; it's my current understanding that there aren't any other PT2 managed transport implementations to test against. [3] https://github.com/OperatorFoundation/shapeshifter-dispatcher/tree/rtt2017 [4] https://github.com/OperatorFoundation/shapeshifter-ipc/tree/rtt2017 Issues on my radar currently (comments appreciated): - We probably want unit tests for the (limited) JSON encoding functions, and for the factored-out RFC 1929 encoding functions. Anything else that looks feasibly testable here? - It's not clear to me whether negotiating a PT2 configuration version still allows PT1-style RFC 1929 parameter encoding so that managed transports can support the new configuration version and the new SOCKS method separately. I've assumed it might be possible, so far, but that's not being tested against anything. - I currently restrict parameters to ASCII to avoid either writing a JSON encoder that can spit out invalid JSON or writing a JSON encoder that has to validate incoming UTF-8. The impression I've gotten is that this is probably okay, but if there are counter- examples, I can put in UTF-8 passthrough. - The commit sequence isn't the cleanest. How high a priority is it to reorder/combine patch hunks to make a cleaner one? - We still need a 'changes' file. (What would be an appropriate heading for this? Is this a minor feature, for instance?) A few other questions: - Is there an effective way of doing automated testing of the SOCKS state machine currently in Tor? I didn't see anything obvious in the test directory. This seems like the most fragile part, especially since both the original and modified versions are not very explicit in their state machine nature and are split between multiple files. - Can there ever be more than one managed_proxy_t to a transport name? More generally, is there a relational diagram of the main Tor data structures somewhere? A lot of the way the plumbing for state and configuration information is set up feels kind of fragile. From 56234341be9dcd72768c1f84e130a76d456a9dc5 Mon Sep 17 00:00:00 2001 From: Robin Tarsiger Date: Mon, 24 Jul 2017 20:27:49 -0500 Subject: [PATCH 01/12] PT2.0: Add JSON encoding functions for new arg blocks The
Re: [tor-dev] Tor and IP2Location LITE
On Sun, Aug 20, 2017 at 10:02:20PM +0200, Karsten Loesing wrote:
> Okay. Maybe we could do something with archive.org in that case. It's
> not that we do have a complete history for MaxMind's files, except that
> we could probably create our own history from Tor's Git repository which
> contains files based on MaxMind's files.
I have a script that walks through the history of tor's git geoip files.
#!/usr/bin/env python
import datetime
import getopt
import os.path
import socket
import subprocess
import sys
# Counts the size of per-country geoip allocations in the tor source code.
#
# Usage: ./scrape-geoip.py ~/src/tor > tor-geoip.csv
#
# ~/src/tor (or whatever the path is) must be a tor source repo; i.e. a clone of
# https://git.torproject.org/tor.git.
def usage(f=sys.stdout):
print >> f, """\
Usage: %s /path/to/tor
""" % sys.argv[0]
def history(dirname, filename):
proc = subprocess.Popen(["git", "log", "--reverse", "--date=short", "--pretty=%H %ad", filename],
cwd=dirname, stdout=subprocess.PIPE)
return proc.stdout
def git_show(dirname, filename, commithash):
proc = subprocess.Popen(["git", "show", commithash+":"+filename],
cwd=dirname, stdout=subprocess.PIPE)
return proc.stdout
def parse_geoip(f):
ccs = {}
for line in f:
if line.startswith("#"):
continue
parts = line.strip().split(",")
start = int(parts[0])
end = int(parts[1])
cc = parts[2].lower()
ccs.setdefault(cc, 0)
ccs[cc] += end - start + 1
return ccs
def ipv6_to_int(ipstr):
return long("0x" + socket.inet_pton(socket.AF_INET6, ipstr).encode("hex"), 16)
def parse_geoip6(f):
ccs = {}
for line in f:
if line.startswith("#"):
continue
parts = line.strip().split(",")
start = ipv6_to_int(parts[0])
end = ipv6_to_int(parts[1])
cc = parts[2].lower()
ccs.setdefault(cc, 0)
ccs[cc] += end - start + 1
return ccs
opts, args = getopt.gnu_getopt(sys.argv[1:], "h", ["help"])
for o, a in opts:
if o == "-h" or o == "--help":
usage()
sys.exit()
try:
TOR_PATH, = args
except ValueError:
usage(sys.stderr)
sys.exit(1)
print "date,ipv,country,count"
for line in history(TOR_PATH, "src/config/geoip"):
parts = line.strip().split()
commithash = parts[0]
date = datetime.datetime.strptime(parts[1], "%Y-%m-%d")
try:
ccs = parse_geoip(git_show(TOR_PATH, "src/config/geoip", commithash))
except Exception, e:
print >> sys.stderr, "Skipping %s %s: %s" % ("src/config/geoip", commithash, e)
continue
for cc, count in sorted(ccs.items()):
print ",".join([date.strftime("%Y-%m-%d"), "4", cc, str(count)])
for line in history(TOR_PATH, "src/config/geoip6"):
parts = line.strip().split()
commithash = parts[0]
date = datetime.datetime.strptime(parts[1], "%Y-%m-%d")
try:
ccs = parse_geoip6(git_show(TOR_PATH, "src/config/geoip6", commithash))
except Exception, e:
print >> sys.stderr, "Skipping %s %s: %s" % ("src/config/geoip6", commithash, e)
continue
for cc, count in sorted(ccs.items()):
print ",".join([date.strftime("%Y-%m-%d"), "6", cc, str(count)])
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Tor and IP2Location LITE
On 2017-08-16 21:19, Karsten Loesing wrote: > On 2017-08-16 05:38, KL Liew wrote: >> All, > > Hi Kim, > >> My name is Kim, the founder of IP2Location, a geolocation service >> provider since 2002. >> >> It looks like Tor is looking to review other providers for GeoIP service >> while I was reading one of a meeting minute for a meeting back in March >> 2017. >> >> https://trac.torproject.org/projects/tor/wiki/org/meetings/2017Amsterdam/Notes/Metricsin5Years >> >> We are very interested in contributing to Tor and work on this matter. >> Tor can host and integrate IP2Location LITE >> (http://lite.ip2location.com) into their application. IP2Location has >> programming libraries in most languages. We can also work with >> developers if there is any technical issues. >> >> In term of accuracy, you can find the latest research paper published by >> TUM. IP2Location has good accuracy as reported in Table V. >> >> Title : HLOC: Hints-Based Geolocation Leveraging Multiple >> Measurement Frameworks >> Authors : Quirin Scheitle, Oliver Gasser, Patrick Sattler, Georg >> Carle from Technical University of Munich (TUM) >> PDF Access : https://arxiv.org/pdf/1706.09331.pdf >> >> Let me know if there is any questions. > > Thanks for reaching out to us! > > It's indeed on our list to evaluate other geolocation databases and > possibly switch over. I'll bring this topic up at tomorrow's metrics > team meeting to discuss possible next steps for such an evaluation. I'll > get back to you here to share the results. So, we discussed this at our team meeting on Thursday and decided to further evaluate switching to IP2Location. That would be a non-trivial project, because we're using geolocation data in at least two places: 1. shipped with the core Tor program and 2. deployed on Tor Metrics services like Onionoo. And at least the former requires close coordination with Tor's network team. In any case we'll want to be sure whether this switch is the right move before starting such a project. The paper is a good start, but we might want to run more evaluations ourselves. For example, we could involve relay operators by asking them which resolved location is closer to reality. But even this evaluation requires writing some code, which puts it on a long list of things we'd like to do. All in all, we (Tor's metrics team) are considering it! But it'll be on the order of weeks or maybe months before we can move this forward. > One question, though, that just came to mind: Are there archives > available for past IP2Location LITE databases, or do you provide just > the latest version? Having archives, possibly even back to 2002, would > be pretty useful for Tor Metrics. (I didn't look around as much on your > homepage, so please apologize if this question is already answered there.) You replied off-list: > We do not have archive for the IP2Location LITE. We just started this free > database a few years back. Okay. Maybe we could do something with archive.org in that case. It's not that we do have a complete history for MaxMind's files, except that we could probably create our own history from Tor's Git repository which contains files based on MaxMind's files. All the best, Karsten > >> - Kim > > All the best, > Karsten > signature.asc Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] PQ crypto updates
On Sun, 20 Aug 2017 16:32:17 + Taylor R Campbell wrote: > > ... I'm not seeing your point. Even prior to that paper, AEZ > > wasn't thought to be quantum resistant in anyway shape or form, and > > providing quantum resistance wasn't part of the design goals of the > > primitive, or really why it was being considered at one point for > > use in Tor. > > I would expect AEZ to have essentially the same post-quantum security > as, e.g., AES or any other symmetric crypto -- square root speedup by > Grover. Yes and? My point was that quantum speedups that existed prior to the paper alone, were sufficient to render the primitive insecure in a post quantum setting. Something that's broken being more broken is non-interesting, in particular when the impetus for even considering the something (as is the case for AEZ and Tor), had nothing to do with PQ cryptography in the first place. > However, this paper is not about the conventional notion of > post-quantum security -- what is the cost, to an adversary with large > a quantum computer, of breaking ordinary users of the cryptosystem? -- > but a radically different notion of security for users who > inexplicably choose evaluate AEZ in a quantum superposition of inputs > and reveal that superposition to an adversary. Believe it or not, I did read the paper. > It is not surprising that when users abuse their crypto primitives in > an astoundingly bizarre way, to reveal quantum superpositions of > outputs, the original security claims of the classical crypto > primitives go flying out the window! I'm having trouble parsing that, perhaps my English is failing me. Ultimately none of this matters because Prop. 261 is dead in the water. Assuming people want the new cell crypto to be both fragile and to resist tagging attacks, Farfalle may be a better choice, assuming there's a Keccak-p parameterization such that it gives adequate performance. Regards, -- Yawning Angel pgp8RMxKugm9s.pgp Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] PQ crypto updates
> Date: Sat, 19 Aug 2017 06:55:29 + > From: Yawning Angel > > On Sat, 19 Aug 2017 04:11:16 - > ban...@openmailbox.org wrote: > > Boom headshot! AEZ is dead in the water post quantum: > > > > Paper name: Quantum Key-Recovery on full AEZ > > > > https://eprint.iacr.org/2017/767.pdf > > ... I'm not seeing your point. Even prior to that paper, AEZ wasn't > thought to be quantum resistant in anyway shape or form, and providing > quantum resistance wasn't part of the design goals of the primitive, or > really why it was being considered at one point for use in Tor. I would expect AEZ to have essentially the same post-quantum security as, e.g., AES or any other symmetric crypto -- square root speedup by Grover. However, this paper is not about the conventional notion of post-quantum security -- what is the cost, to an adversary with large a quantum computer, of breaking ordinary users of the cryptosystem? -- but a radically different notion of security for users who inexplicably choose evaluate AEZ in a quantum superposition of inputs and reveal that superposition to an adversary. It is not surprising that when users abuse their crypto primitives in an astoundingly bizarre way, to reveal quantum superpositions of outputs, the original security claims of the classical crypto primitives go flying out the window! ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
