- tor-dev - lists.torproject.org

Re: [tor-dev] Feature Request: please consider ship default, Tor bridges
by iry 19 Aug '17

19 Aug '17

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Roger: > On Thu, Aug 17, 2017 at 07:57:53PM +0000, iry wrote: >> Btw, Collateral Freedom seems to be one of the most effective >> ways to circumvent Internet censorship in China. Circumvention >> tools that depend on Collateral Freedom usually works fine, >> including meek, lantern, psiphon3 etc. Therefore, I see a lot of >> potential work which may benefit the Internet freedom in China. >> For example: 1. package meek into Debian 2. host (part of the) >> BridgeDB mirror on Github or AWS 3. #22402: >> https://trac.torproject.org/projects/tor/ticket/22402 > Some hopefully useful thoughts along these lines: > Hi Roger! Thank you for sharing your insights! > A) Most places around the world that need bridges these days need > pluggable transport bridges, not just vanilla bridges. So if we > want to bundle bridge addresses, we should bundle PT bridge > addresses. > I agree! This also makes me think about a small potential improvement on the design of BridgeDB web. When users click the big "Just give me some bridge" on https://bridges.torproject.org/options , they will be provided with vanilla bridges instead of obfs4 bridges. However, those users who choose not to use "Advanced Options" are most likely to be inexperienced and have no idea on what obfd4, PT etc are. Therefore, is it a good idea to provide obfs4 bridges, rather than vanilla ones, in "Just give me some bridge" for better usability and higher success rate? > B) ...and that means we need to make sure that those PTs are well > packaged in Debian too, since the Tor deb by itself would not be > able to use them. > Agreed. I can help to report a bug against obfs4proxy on Debian BTS when the idea is mature. > C) I wonder if we could use the new %include torrc directive in > this situation: https://bugs.torproject.org/1922 I don't have a say on the final decision, but this is also what I am thinking about:> 3. "Bridge" + plain text which is ready to be appended to a torrc file > or to be one of the torrc files in /etc/torrc.d/ (or whatever > torrc.d path Debain decides to use) > That is, when you apt-get install obfs4proxy, is that the right > time to populate /etc/torrc.d/obfs4-bridges with some (probably > commented out to start) lines that let you use those bridges if > you want? How about not commenting out the bridge info as the switch? Instead, user who would like to use bridge can comment out or add the following two lines in /etc/tor/torrc: #UseBridges 1 #ClientTransportPlugin obfs4 exec /usr/bin/obfs4proxy I have being considering /etc/torrc.d/ as a place to store all the available settings and considering /etc/tor/torrc as a panel that let user decide what they would like to enable and disable. But I am not sure if this is a good way to think about the relationship between /etc/tor/torrc and /etc/torrc.d/ One thing I am concerned about is, when applying the method above, how can user choose different PTs in the future? For example, when meek in packaged into Debian, the meek package will probably also have a /etc/torrc.d/meek-bridges file. Can we just choose to use obfs4 or meek in /etc/tor/torrc by switching between the following two lines? #ClientTransportPlugin obfs4 exec /usr/bin/obfs4proxy #ClientTransportPlugin meek exec /usr/bin/meek-client (I can test with that, but people who is familiar with the mechanism behind it can probably answer that.) Best, iry -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJZmHZUAAoJEKFLTbxtzdU8Y2gP+wfDoSOTprVqe4rByzHVhUup LXvy4WnfHeUq03t+H8W5QwJCPdsFssFZae/EsfUU5Q490GqhAFryi8rHmOHluSGl FmX9SIxQXT3RV7iEFN7w4qKqYHLEKrRTklWOLrDauHZe3eJEUyn49VCROtBat88Y bdnrav4D443fFD/ugk8C3K5u4oNEWgtaq9natsLkPFbXpNcB06gd/S23Vj4VsOP0 +FUmIHmtzzMk0iTAVjGrW8X/z6/lyqk6Nj/lvwfNhdIJ5gbk5F848sl71VBeK3of Q7rdCjglZ3/tPRfrE+d40cfQWmOpw7doozC7LKdDbxCtx/LJ0WFq2PvwmO+uUFOG 3QMAV0w58JWsUsLW80ifcx7T+0O7QeAMASqWqKva7d1Y2PgqNCJfDJDHOX/KuEy3 TUi8o5WkIUUtyPaMwnYXW9VkaEKIHBXxfjYBwg0llfGU9HKJmTj+yCrMMHB2t0m0 OlZUFx9E7U11mhWzGM64sICHuob8VjwsLgLPMJc1+ocDobo0HrJr1ZtWmMZScp60 SpK35EwU8jKZJTSXtI/SKtDdHGhGmxm4NvLy26TWSqHbEzlcelK+yqkifnLHr3tb we61NdV2ZA7XCrp+o3Q7NprMjRGtaP1aze2bQTjJfkLDdrShkZFw3/hYk75cRpvk tkf7Tl4oLtoa5lnNhB/S =sP5G -----END PGP SIGNATURE-----

1 0

Feature Request: please consider ship default Tor bridges
by iry 19 Aug '17

19 Aug '17

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello Tor people! A set of Tor bridges are shipped with Tor browser bundle[0], helping users in Tor-censored area to connection to the Tor network. Since system Tor users may also face the censorship problem, shall we ship some Tor bridges along with the tor package? The request is firstly reported[0] to Debian BTS and I got the following reply by Peter: > If upstream starts shipping bridges with their Tor releases, that > would naturally result in the Tor package shipping bridges as > well. > > I do not know whether that's a good idea or not, but I don't think > deviating from upstream would be particularly worthwhile. The following is some related information which may help the future discussion: The possible formats to hold those bridges can be: 1. JSON which is also the way tor-connection-wizard used so far[1]; 2. plain text which is the same formatt given by the BridgeDB[2] by Tor Project; 3. "Bridge" + plain text which is ready to be appended to a torrc file or to be one of the torrc files in /etc/torrc.d/ (or whatever torrc.d path Debain decides to use) The default bridge shipped with tor package should be exactly the same bridges contained in bridge_prefs.js[0] shipped with the latest stable TBB. This is because: 1. The servers hosting default bridges are set up for huge amount of traffic; 2. The servers hosting default bridges are probably audited by TPO for better security; 3. Using a different set of bridges will distinguish the anon-connection-wizard bridge users from the TBB bridge users, which compromises their anonymity. What do you think? Looking forward to hearing your insights! Best, iry [0]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=872456 [1]: https://gitweb.torproject.org/builders/tor-browser-bundle.git/tree/Bundl e-Data/PTConfigs/bridge_prefs.js?h=7.5a3-linux [2]: https://github.com/irykoon/anon-connection-wizard/blob/master/usr/share/ anon-connection-wizard/bridges_default [3]: https://bridges.torproject.org/options Best, iry -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJZldAaAAoJEKFLTbxtzdU8QHEP/0DyAtD95JOKEkDulsyuuVfx uYT+5WGaRSFntqRq91RcNkHLHDy61JtLXhr5VIcz/tYIIe3TVZhI9idqbPgJMZc+ xxS/4r5qhkkcJ5X99xo7Jerz/0Y/4CKboREAkSstz15RL3FNLF6mwFZgWsiZ4rMa SkruE8qchz1KIUuWKZyx3HioloZgIHQkvqQ6fE4asGIs8gnaKeofpSwRGq85/Vcq T8D0WTqCFweLFaYzCWMtO7bVKXrfqC8rGLesLPJhxZbl0MJ3H/5TdvbPHn6VwRH0 AZCT5q7A+0fC/+HHwsn9SFhMo0TaIOtZBonOH58X3OEamKrmJOwqESvCPqILtMC3 pU2PtoOSDQEd684b2hxoR+0uRMOew+CJ+U7lzyh7yYU9x3jv//9CsFGcKcD+FoFG zrkDPJ75uzYGJjHZUFpnk8opwVy49TghYiVvjwm9/PXXQVvEiCGNEt7W1wTHX3Ja DygMsGN8GXg6AqWRESg4NcI8N/4U2EUEt+Li45u0qsTJ/uYmfamsC/WoacfjznaD JQVKjJQlhuk7F3qUPuxtxaGCLopLJd/uAUyYaI/HPrFeR3uIawSzCW9prTkk/E7n wAop3mErdp6JYnTacUb4pcYINIQf1c7FymbngrAmJzljxH4apZpBPugitAYvtJ2X 2OBJpUV0CtEJH3poicdq =oct9 -----END PGP SIGNATURE-----

3 3

[release] CollecTor 1.2.1
by iwakeh 18 Aug '17

18 Aug '17

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi there! A bugfix release for CollecTor is available: https://dist.torproject.org/collector/1.2.1/ The bug fixed by this release affects CollecTors sanitizing bridge descriptors and was discovered due to the recent bridge authority outage. Please direct comments and questions to the metrics-team mailing list [2]. And, of course, bug reports [3] or feature requests [4] can be filed in trac. Cheers, iwakeh [1] https://gitweb.torproject.org/collector.git/plain/CHANGELOG.md?id=collector… [2] https://lists.torproject.org/cgi-bin/mailman/listinfo/metrics-team [3] https://trac.torproject.org/projects/tor/newticket?component=Metrics/Collec… [4] https://trac.torproject.org/projects/tor/newticket?component=Metrics/Collec… -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJZlvIvAAoJEPeEx9Sa/gviAEUP/iSAAW5uaQNpMKtNze9x87M/ jluCBRzvIN61xyxjib7Caswz5uBdUew2qYM1+fswBr7odng5sFlUuP6/oJZJBqr5 /C/68WYeYncXUj1vKi5mNjktJ7CJQE29anqG8EYtbVAKIqiQJmot/Hb8JI/V+RFU 1HueB78zPXbJBb8A0NBDvvhO5tFcTeQKEMKqZngkv4eojuhQu8pgT9Y5YGxMsSU9 al/kzpJIG78MnuKHZBjkSc8vn9YivZnxIyLgl8zaxKT5SOx11U3T8PN2rV5gJs3o qzstD75S71g7K9w4RZqg2bljp2xM4z0ui9lgfWWAKkodhm0aGZZFs9CIZeVhtN/s FiOVm+ZTJfpiudEqF9amv1uZxW9d5KQzpKKEjGKGOa9kk2idWZieLFbj2NLjDtv1 GJxYgW+pxliJYH/sQqSjJ4icxcQD75k4+Z725ENd8vVBVGDS7jqmjDr9tUKbctad ftD4Fjeg0CE8CTOneY2tTJ6w8dpbiPxXP1otzGltDGpOX0D1cMCSXtNX10/n4GRv ndnat57JBTLwKnRQ3SL/eDTXCwRpXzT66bUbWAhNeY6tl5aGni7/vItn4Hd9qf8v zp8T2X0tp2+02FYnidITPIxLmLfCcDh3b87qIFC+3DStD/GOuUVz0P/i/sfuCN6A onSYAUgAIqx7Uced2auo =9wXW -----END PGP SIGNATURE-----

1 0

Re: [tor-dev] Doesn't hidden services break RFC 3986?
by Ryan Carboni 14 Aug '17

14 Aug '17

Also: just because it's HTTP/S running over a different network stack, doesn't make it a new scheme. Just because your dinner arrives on a different plate doesn't mean the recipe has changed. :-) --- https://bugzilla.mozilla.org/show_bug.cgi?id=1228457 Tor is a strange sort of sacred cow highly revered leaks much methane But RFC 7686 literally bent over backwards to rewrite multiple standards because Tor was long existing. ".onion" shouldn't be resolved or sent over the internet. Sure, IP multicast had to be implemented, but its relevance to people not replacing analog technologies isn't particularly great, and those are corporations who make billions combined per year. But uh yes. Only the plate changed. But internet standards are very clear on plate specifications. Or rather, "authority" lookup. The dinnerware request protocol is pretty clear on this, with other protocols providing for saran-wrap or foil-wrap encapsulation, with their own provisions for exterior labeling. (or if there was a new way to link to torrent hashes, do you think it should be "torrent://hash/" or "hash.torrent"?) Although, if you guys really want to risk your government funding, I suggest $10,000 bug bounties out of a fund sized large enough to hire a single programmer (assuming there's a risk that you'll have more than a dozen severe bugs). To make things more difficult for the NSA, make it clear that there is no requirement for a cyber arms seller to stay bought by one person. Or propagate a meme that a cyber arms seller could sell the idea of an exploit to another cyber arms seller to write a new exploit for the same bug. Force folks like zerodium to pay twice. or uh "Make the enemy live up to its own book of rules." But who is your enemy?

1 0

Getting started coding on Tor [Re: tor-dev Digest, Vol 79, Issue 4]
by Nick Mathewson 14 Aug '17

14 Aug '17

On Sat, Aug 12, 2017 at 3:02 PM, John kongtcheu <johnkongtcheu(a)gmail.com> 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. > > Thank you, > Hi! We have some introductory material over here, including a list of subprojects and what they're implemented in: https://www.torproject.org/getinvolved/volunteer If you're interested in Tor itself, have a look at the doc/HACKING/GettingStarted.md file in the Tor git repository. It's got a bunch of other useful links. cheers, -- Nick

1 0

Doesn't hidden services break RFC 3986?
by Ryan Carboni 14 Aug '17

14 Aug '17

https://tools.ietf.org/html/rfc3986#section-3 By placing the scheme within the authority as a tld while using the same authority as the HTTP specification, this probably breaks RFC 3986 and maybe others. I might be a bit late in saying this.

3 2

Help us build Tails reproducibly
by u 09 Aug '17

09 Aug '17

Dear Tails and Tor contributors, dear Reproducible Builds community, As you might know, Tails [1] has received the Mozilla Open Source Software award (MOSS) to make Tails ISO images build reproducibly. Since this project has started, less than a year ago, we've made huge progress and we've finally seen some ISO images build reproducibly on the build environments of our core developers as well as on our isobuilder machines. (See our previous reports [2]). However, there are still some remaining issues which we'd like to know more about in order to fix them. That's why we are asking for your help: Please try and build the Tails 3.1 ISO image and report your findings back to us. You will find all instructions for doing so hereafter. Please don't hesitate to contact us if you get stuck at some point in the process, for example by connecting to our chatroom [3]. You can also send us email to tails-dev(a)boum.org (public) or tails(a)boum.org (private). # How? For your convenience all instructions needed to attempt to reproduce Tails 3.1 are included hereafter. However all commands are adapted for Debian Stretch (and Buster/Sid), so your results may vary if you run another Linux distribution. Our full build instructions [4] might help if you are having problems. ## Setup the build environment Building Tails requires the KVM virtual machine hypervisor to be available, a minimum of 1 GiB of free RAM and a maximum of 20 GB of free storage. ### Install dependencies sudo apt-get install \ git \ rake \ libvirt-daemon-system \ dnsmasq-base \ ebtables \ qemu-system-x86 \ qemu-utils \ vagrant \ vagrant-libvirt \ vmdebootstrap && \ sudo systemctl restart libvirtd ### If building as a non-root user (Skip this section if you intend to build Tails as the root user!) Make sure that the user that is supposed to initiate the build is part of the relevant groups: for group in kvm libvirt libvirt-qemu; do sudo adduser $user $group; done Then run `newgrp` (or just reboot) to apply the new group memberships to the session. ## Build Tails 3.1 git clone https://git-tails.immerda.ch/tails cd tails git checkout 3.1 git submodule update --init rake build # Send us feedback! No matter how your build attempt turned out we are interested in you sending us feedback. For that we'll first need some information of the system you used -- please run these commands in the exact same terminal session that you ran `rake build` in (e.g. run them right after `rake build`)! sudo apt install apt-show-versions || : ( for f in /etc/issue /proc/cpuinfo do echo "--- File: ${f} ---" cat "${f}" echo done for c in free locale env 'uname -a' '/usr/sbin/libvirtd --version' \ 'qemu-system-x86_64 --version' 'vagrant --version' do echo "--- Command: ${c} ---" eval "${c}" echo done if which apt-show-versions >/dev/null then echo '--- APT package versions ---' apt-show-versions qemu:amd64 linux-image-amd64:amd64 vagrant \ libvirt0:amd64 fi ) | bzip2 > system-info.txt.bz2 Please have a look at the generated file with bzless system-info.txt.bz2 to make sure it doesn't contain any sensitive information you do not want to leak in case you send this file to us or make it public! Next, please follow the instructions below that match your situation! ## If the build failed. Please open a ticket on our bug tracker [5] with "Category" set to "Build system" and `system-info.txt.bz2` attached (note that this makes this file public). ## If the build succeeded ... Please compute the SHA-512 checksum of the resulting ISO image: sha512sum tails-amd64-3.1.iso and compare it to: 843427fa13446c4b7134a10d3269b693317bbb898759e9d4e5dd8a25583372bed767e575974f5ca0229f1b44a99d4c7b64872c3dc433c0caf8965961cac9fb30 ### Use the SHA256sum from our signed upgrade files instead This is optional, but if you want to use an authenticated checksum, you can find the sha256 checksum in our upgrade files: https://tails.boum.org/upgrade/v1/Tails/3.0.1/amd64/stable/upgrades.yml .. which are signed by the Tails signing key [7]: https://tails.boum.org/upgrade/v1/Tails/3.0.1/amd64/stable/upgrades.yml.pgp The SHA256 checksum should be: 0ef1c7d880308ee9f98c255b2658b75445cc84622eae2944a342dcc50cea71c7 ### ... and the checksums match (i.e. reproduction succeeded). Congrats for successfully reproducing Tails 3.1! Please send an email to tails-dev(a)boum.org (public) or tails(a)boum.org (private) with the subject "Reproduction of Tails 3.1 successful" and attach `system-info.txt.bz2` to it. ### ... and the checksums differ (i.e. reproduction failed). Now you are in a great position to help Tails improve its reproducibility! Please install `diffoscope` [8] version 83 or higher. If you run Debian Stretch, that is: echo 'deb http://ftp.debian.org/debian stretch-backports main' \ | sudo tee /etc/apt/sources.list.d/stretch-backports.list && \ sudo apt update && \ sudo apt -o APT::Install-Suggests="true" \ -o APT::Install-Recommends="true" \ install diffoscope Then download the official Tails 3.1 ISO image [6] and compare it to yours: diffoscope \ --text diffoscope.txt \ --html diffoscope.html \ --max-report-size 262144000 \ --max-diff-block-lines 10000 \ --max-diff-input-lines 10000000 \ path/to/official/tails-amd64-3.1.iso \ path/to/your/tails-amd64-3.1.iso && \ bzip2 diffoscope.* Please send an email to tails-dev(a)boum.org (public) or tails(a)boum.org (private) with the subject "Reproduction of Tails 3.1 failed" and attach `system-info.txt.bz2` to it. We also want you attach one (the smallest!) of diffoscope.txt.bz2 and diffoscope.html.bz2 to the email, but if they are "big" (say >100 KiB) then please don't bomb our mail inboxes! Instead upload the file to some web-based file-sharing service (we'd recommend RiseUp [9]) and include the link(s) in the email. Thank you very much for your interest and help! Cheers! The Tails project [1] http://tails.boum.org [2] https://tails.boum.org/news/report_2017_06/, https://tails.boum.org/news/report_2017_05/, https://mailman.boum.org/pipermail/tails-dev/2017-March/011297.html [3] https://tails.boum.org/support/#talk [4] https://tails.boum.org/contribute/build [5] https://labs.riseup.net/code/projects/tails/issues/new [6] http://dl.amnesia.boum.org/tails/stable/tails-amd64-3.1/tails-amd64-3.1.iso [7] https://tails.boum.org/news/signing_key_transition/ [8] https://diffoscope.org/ [9] https://share.riseup.net/

1 0

[release] Onionoo 4.0-1.3.0
by iwakeh 08 Aug '17

08 Aug '17

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi there! Another release of Onionoo is available: https://dist.torproject.org/onionoo/4.0-1.3.0/ This release is a maintenance release: * It adapts to use the improvements of metrics-lib 2.0.0 and * Debian Stretch dependencies and * steps up to Jetty9. (See the changelog [0] and git repo for details.) Please direct comments and questions to the metrics-team mailing list [1]. Cheers, iwakeh [0] https://gitweb.torproject.org/onionoo.git/tree/CHANGELOG.md?h=onionoo-4.0-1… [1] https://lists.torproject.org/cgi-bin/mailman/listinfo/metrics-team -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJZiYO/AAoJEPeEx9Sa/gviYUQP/jTj8Tp5AtHacrW1zu9GqUry SlOSmwx0EgldVZDc96RD2rz0sef5OR0WBA/kQz8QUL3m6LpjdCmsOz9HyOZNtpqO gEY9RWEm0dfXLMai2BZVApp52X45MwRh+LBP/PTI/Sl5RJ4drmaDr+DZGHAzPJUz uXV9f45LNy/fZgtrR+Cjkr3pr+sb5IB/uGdjJYYC4hXXIhFHe6eRW0mqLGkjl733 sy5Z02ldTKntjeBfu+iVDgtObrYrDkDvbJYyQHPHwPLiVqtKiGZixeK8ojjPimIz 5O/GHH/2m00Jst+u4uyIeUQiUexzv/uMRLKYi0lPshbId1icGpAhs2VHy0pI7CXJ vr6rXkFv07tw86F36kOg2Vvy1/8oy0JEbZPA8hpl1F5tELp5Go0tf8Eq3PahMKh9 DfjOatQdj/BCi6G3dvtCiKyWnwd3chF1Gaqe1GmrAuDnrGGtbAWWv0ofStMOO+7X 2aI4y5Q2QTT7v9UJjks/rw4GOhEq+vlQHUFTVc4vSBm6bxSrowRyIy0/jUzeGs7A XT0CnTWyO5xtuNhGYsZPSx7fENGko1tPOnzjxurHCYcZNM7oBIJKwn2yol+xpEwr 2DE5lyp/8bmb4Ya6/m3li34ku++Y7peXQ3wVagB5aPq1oROZ5ttabi9gA+xPRCqk keSUDKXP9PBz+EtGvMoQ =ELXu -----END PGP SIGNATURE-----

1 0

Various Tor keys, their formats, and usages [was: Bridge Bandwidth Scanner Internship]
by isis agora lovecruft 08 Aug '17

08 Aug '17

Hello! The following was my attempt last week to summarise all of our various keys in server descriptors, how they are formatted, and what they are used for, in the hopes that this is useful in alleviating possible future confusions for others. Let me know (and, more importantly! let Jake know since he's writing a Rust parser for bridge descriptors as part of the Bridge Bandwidth Scanner project) if I got anything wrong. :) ----- Forwarded message from isis agora lovecruft <isis(a)torproject.org> ----- > From: isis agora lovecruft <isis(a)torproject.org> > Subject: Re: Bridge Bandwidth Scanner Internship > Date: Thu, 27 Jul 2017 19:52:47 +0000 > Message-ID: <20170727195247.GI24882(a)patternsinthevoid.net> > To: jnz(a)riseup.net > Reply-To: isis(a)torproject.org > Delivered-To: <isis+torproject(a)patternsinthevoid.net> > > jnz(a)riseup.net transcribed 1.4K bytes: > > Hey Isis, > > > > I have started the sanitization spec and the parser. A lot of the stuff > > I had to learn for the two overlaps, so I am working on them > > simultaneously. Conceptually, I understand the sanitization process, but > > I am a little bit confused about what some of the fields are in the > > descriptors. > > > > Q1. What exactly is the difference between "master-key", "identity-key", > > and "signing-key"? > > > > After reading through the descriptor spec, cert spec, and other docs, I > > am pretty confused on what each of the above means.I'm using the Nom > > crate for the parser, I've never used it before but so far I'm really > > liking it. Have you ever used it? > > This is specified (not all that well, imho) in dir-spec.txt… it's really > confusing. > > For versions of tor new enough to have prop#220 and prop#228 (>0.2.7.2-alpha): > > - "identity-ed25519" is a certificate containing a base64-encoded ed25519 > key. The bridge uses this to authenticate to clients. > > - "master-key-ed25519" is the ed25519 key which is in the > "identity-ed25519" certificate. > > - "onion-key" is an RSA-1024 key, encoded as a PKCS#1 RSAPublicKey > structure, encoded in base64, and wrapped in "-----BEGIN RSA PUBLIC > KEY-----" and "-----END RSA PUBLIC KEY-----". This key is used to > encrypt CREATE cells to in the older TAP handshake protocol. (TAP is > almost entirely unused on the network, last I checked. We'll likely be > removing "onion-key"s in the next year or so, after we EOL some old tor > versions.) > > - "ntor-onion-key" is a public curve25519 key, base64-encoded. This is used > in the newer NTor handshake protocol, which replaced TAP. It is still > quite common to see routers which have both an "onion-key" and an > "ntor-onion-key". > > - "signing-key" is the same type and format as "onion-key" above, but it's > used as a long-term identity key, for authenticating the bridge to > clients. (Similar to "identity-ed25519" just with RSA signatures.) > > - "router-sig-ed255519" is a only present iff "identity-ed25519" is > present, and it's an ed25519 signature of a SHA-256 digest of the > "entire" descriptor (Minus the "@purpose bridge" header since the Bridge > Authority is the one who adds that. So from "router " on the first line > up to and including the first space after "router-sig-ed25519".) This > "entire" descriptor is first prefixed with the string "Tor router > descriptor signature v1" before hashing and signing. After the signature > is produced, it is encoded in base64 and the trailing "="s are removed. > > - "router-signature" contains a signature of the PKCS#1-padded SHA-1 digest > of the "entire" server descriptor, taken from the beginning of the > "router" line (skipping "@purpose bridge" again), through (and > including) the newline after the "router-signature" line. The signature > is made with the router's "signing-key" (a.k.a. identity key). > > For older tor versions (without prop220 and/or prop228): > > - They will have "onion-key", "ntor-onion-key", "signing-key", and > "router-signature", as above. > > I've attached a tarball of today's descriptors for this bridge from the > public/default bridges in Tor Browser: > > https://atlas.torproject.org/#details/FEC8FB380DABA9D3C80790B634E4540BF5D09… > > Let me know if you want some more examples! I only grabbed one because they > are pretty annoying to pull out of the giant, unordered, undeduplicated > files the BridgeAuth produces (at least without writing a full parser). > > Also lmk if you have more questions, the entangled ball of crypto junk we > shove into descriptors is pretty confusing. […snip…] ----- End forwarded message ----- Best regards, -- ♥Ⓐ isis agora lovecruft _________________________________________________________ OpenPGP: 4096R/0A6A58A14B5946ABDE18E207A3ADB67A2CDB8B35 Current Keys: https://fyb.patternsinthevoid.net/isis.txt

1 0

X25519 ←→ Ed25519 key conversions and specs [was: Bridge Bandwidth Scanner Internship]
by isis agora lovecruft 08 Aug '17

08 Aug '17

jnz(a)riseup.net transcribed 2.0K bytes: > Hey Isis, > > I have a few crypto questions for you. The bonus question is purely out > of interest (I searched for the answer, but didn't get a > good/understandable answer, if you are busy don't worry about it). Hey Jake! I'm CCing the conversation to tor-dev, since these are all really good questions. (Also you found another problem in our specs!) > Q1. What does the bit argument in the the ntor-onion-key-crosscert field > do? > > The following is an example ntor-onion-key-crosscert field. The bit > argument is the "1" following ntor-onion-key-crosscert keyword. > > > ntor-onion-key-crosscert 1 > > -----BEGIN ED25519 CERT----- > > AQoABl2EAdjttTuvK9jQzdyi+Mh46ky1Jk9+Hw+FJ6eos5zUxcBDAJF+TGU6oZij > > DOToeg+/lIaEkv0RwIrl5aJta/jf2EdTgHRfCsMOLEWMfqjOA6pmkwc3jnWvWNms > > 7NVBzUcMWgA= > > -----END ED25519 CERT----- > > Q2. The following sentence is the bit argument's documentation from the > dir-spec. Could you possibly explain to me what this means? What is a > public key's "sign"? > > > Bit must be "0" or "1". It indicates the sign of the ed25519 public key corresponding to the ntor onion key. > > The following paragraph is also in the dir-spec, I know that it is > relevant, but I don't understand what it means. > > > C. Converting a curve25519 public key to an ed25519 public key > > > > Given a curve25519 x-coordinate (u), we can get the y coordinate > > of the ed25519 key using > > > > y = (u-1)/(u+1) > > > > and then we can apply the usual ed25519 point decompression > > algorithm to find the x coordinate of the ed25519 point to check > > signatures with. > > > > Note that we need the sign of the X coordinate to do this > > operation; otherwise, we'll have two possible X coordinates that > > might have correspond to the key. Therefore, we need the 'sign' > > of the X coordinate, as used by the ed25519 key expansion > > algorithm. > > > > To get the sign, the easiest way is to take the same private key, > > feed it to the ed25519 public key generation algorithm, and see > > what the sign is. > > BONUS. What is the difference between a curve25519 public key and an > ed25519 public key? Why would you want to convert back and forth between > the two? Okay, this is going to be a long answer. Let me know if parts don't make sense. So, as you noted, dir-spec.txt says [0]: > Bit must be "0" or "1". It indicates the sign of the ed25519 > public key corresponding to the ntor onion key. > > To compute the ed25519 public key corresponding to a > curve25519 key, see appendix C. There are a few different representations of the curve over the Galois field GF(2²⁵⁵ - 19) called curve25519. The (arguably) most useful is the twisted Edwards form of the curve (see our Rust documentation [1] for further details on point forms and more literature) defined for affine points P = (x,y) by the equation -x²+y² = 1 + dx²y² (1) where d = - 121665/121666 This is due to the fact that efficient, complete formulae (meaning that the same formulae, e.g. for point addition, can be used for all points, so you don't have messy if/then statements to deal with exceptional points) exist for Edwards curves. (Recently, complete formulae for Weierstrass curves and other prime-order curves have also been described. [2] However, they are still slightly less-efficient for most tasks.) There's a useful technique called a Montgomery ladder, which is an approach to constant-time (if implemented in a sane manner) point multiplication (i.e. computing nP by taking the point P and adding it to itself n times). This is particularly useful for elliptic curve Diffie-Hellman (ECDH) implementations, but it requires first converting a point from a certain representation (a.k.a. within a specific spatial coordinate system), usually "extended homogeneous twisted Edwards coordinates" (see Hişil's thesis [3], which is the explanation of all the different forms and group laws), into the affine point Q = (u,v) as it would lie on the Montgomery form of the curve: bv² = u³ + au² + u (2) where a = 486662 b = 1 The conversion is rather straighforward, as you can see from mine and Henry de Valence's code [4], but there's a problem in that the compressed form (i.e. "give me the serialised version that is just an array of 32 bytes") of points on the Montgomery curve are just the u-coordinate. You can use this u-coordinate to recover the v-coordinate, [5] and then use both u and v to recover the original Edwards x-coordinate, [6] but there's two possible x-coordinates, one positive and one negative. So, if you want to be able to use a key for both purposes, then, when using Montgomery form (e.g. an X25519 key a.k.a. a "curve25519 key") then you have to also pass around the sign of x. It's kind of icky. In this case, the "ntor-onion-key-crosscert" is an Ed25519 signature (so the public key is a point in twisted Edwards form) of the relay's public master identity key, computed using the "ntor-onion-key" (which is an X25519 key, so a point in Montgomery form). The verifier knows the "ntor-onion-key", but needs to know the sign of x in order to be able to convert it into the Edwards-form public key to check this signature. Following through the code tor is using, it appears that if "Bit" is "0", then x will be positive. If "Bit" is "1" then x will be negative. Tor's behaviour w.r.t. the sign bit (using either curve25519-donna [7] or ref10 [8]) appears to be identical to other implementations, namely Open Whispersystems' code [9] and curve25519-dalek. [10] It appears it isn't specified anywhere what the "Bit" is supposed to mean in terms of parsing the ntor-onion-cert into an Ed25519 key though. :( I made an attempt at specifying it better. [11] As for the question of why one would want to convert back and forth between the two… normally, you wouldn't want to do this. There's nothing concretely horribly wrong or insecure about it, but there are plenty of more theoretical concerns regarding any type of key reuse for different protocols, primarily because it removes any sense of domain separation, such that an attack on one protocol might be assisted by or contribute to attacking the other. With separate keys for separate purposes, you can breathe a lot easier knowing that if, e.g. your ECDH keys were compromised, that your signing key (being a totally different key) is (probably) unaffected. The only time where is does make sense to share a key between two protocols is what Nick's design for the cross-certifications, i.e.: a) Prove that you control the private part of an encryption key by converting it to a signing key, then signing the public master identity key, and b) Authenticate the signature by using the master identity key to sign the entire document (including the other signature). > Thanks for all the help, I hope that you are having a nice day and... > Happy Hacking. > > - Jake No worries! Thanks for the excellent questions and catching more bugs in our specs! [0]: https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt?id=ce09d266#n536 [1]: https://docs.rs/curve25519-dalek/0.10.0/curve25519_dalek/curve/index.html [2]: https://ellipticnews.wordpress.com/2016/05/30/complete-group-laws-for-prime… [3]: https://github.com/isislovecruft/library--/blob/master/cryptography%20%26%2… [4]: https://github.com/isislovecruft/curve25519-dalek/blob/f2883028d/src/curve.… [5]: https://github.com/isislovecruft/curve25519-dalek/blob/f2883028d/src/curve.… [6]: https://github.com/isislovecruft/curve25519-dalek/blob/f2883028d/src/curve.… [7]: https://gitweb.torproject.org/tor.git/tree/src/ext/ed25519/donna/ed25519_to… [8]: https://gitweb.torproject.org/tor.git/tree/src/ext/ed25519/ref10/keyconv.c?… [9]: https://github.com/WhisperSystems/curve25519-java/blob/master/android/jni/e… [10]: https://github.com/isislovecruft/curve25519-dalek/blob/f2883028d/src/curve.… [11]: https://gitweb.torproject.org/torspec.git/commit/?id=2395f34affbe97c19d7bb9… Best, -- ♥Ⓐ isis agora lovecruft _________________________________________________________ OpenPGP: 4096R/0A6A58A14B5946ABDE18E207A3ADB67A2CDB8B35 Current Keys: https://fyb.patternsinthevoid.net/isis.txt

1 0