- tor-dev - lists.torproject.org

Tor 0.3.1 -> 0.3.2 coverage update
by Nick Mathewson 26 Sep '17

26 Sep '17

So, here's some good news about unit test coverage (as measured by 'make check') in 0.3.2: Our (line) test coverage rate is up, from 52.88% to 54.72%. But here is some bad news: The number of uncovered lines has still increased (from 30860 to 31608), even though covered lines have increased more rapidly. If you're interested in tracking down where we need coverage, I have used our "cov-diff" tool to generate a cleaned diff from the old coverage to the new coverage. You can download it (it's big!) from https://people.torproject.org/~nickm/volatile/coverage-diff.xz The format is: it is a diff between normalized gcov output files. To find new or modified un-covered lines, look for lines that begin with the regex /^\+ *\#/ ("starts with a plus, then some spaces, then a #"). Any lines like this are good candidates for additional testing IMO. peace, -- Nick

1 0

Does "ar: `u' modifier ignored since `D' is the default (see `U')" warning qualify as a bug?
by Patrick Durusau 25 Sep '17

25 Sep '17

Hello, Running Ubuntu 16.04, using: https://gitweb.torproject.org/tor.git/tag/?h=tor-0.3.2.1-alpha Following: https://lists.torproject.org/pipermail/tor-project/2017-September/001449.ht… and I get this warning 17 times from make: ar: `u' modifier ignored since `D' is the default (see `U') I traced this back to line 187 in Makefile.in ARFLAGS = cru Correcting to: ARFLAGS = cr src compiles sans the warnings. Is that a bug meriting a ticket? My primary strength is documentation and making mistakes in following it. ;-) Hope everyone is looking forward to a great weekend! Patrick -- Patrick Durusau patrick(a)durusau.net Technical Advisory Board, OASIS (TAB) Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300 Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps) Another Word For It (blog): http://tm.durusau.net Homepage: http://www.durusau.net Twitter: patrickDurusau

2 1

Anybody from Tor wants to participate at the pluggable transport meeting?
by vmon＠riseup.net 21 Sep '17

21 Sep '17

Hello Tor people, Dlshad (dothman(a)internews.org) from Internews has reached out to me to see if anybody from Tor is interested to participate in the next PT community meeting happening in Boston just after Tor-dev meeting. My understanding is that they'll book your ticket and arrange the accommodation for you. "I wanted to reach out to you and see if someone from Tor can join the Pluggable Transports community meeting which is going to be in Boston October 16-18. In this meeting, the community will discuss and go through the current draft of PT Spec https://www.pluggabletransports.info/spec/ and then release it. The rest of the meeting will be focusing on PT implementation." Cheers, vmon

1 0

Padding prop224 REND1 cells to blend them with legacy cells
by George Kadianakis 20 Sep '17

20 Sep '17

Hello Ian, (and other cryptographers on the list) here is a quick question which you might be able to answer super fast: Legacy RENDEZVOUS1 cells are bigger than the prop224 ones. The prop224 spec suggests we pad the new cells so that they look similar in size to the legacy ones. Here is how the legacy ones look like: RC Rendezvous cookie [20 octets] g^y Diffie-Hellman [128 octets] KH Handshake digest [20 octets] Here is how the prop224 ones look like: RENDEZVOUS_COOKIE [20 bytes] HANDSHAKE_INFO [64 bytes] The suggestion is to pad the prop224 cells to 168 bytes using random data. Would that work? My main question is whether the g^y part of the legacy cell has any distinguishers that could distinguish it from random data. It's encoded using OpenSSL's BN_bn2bin() and it's a 1024 bit DH public key. Are there any algebraic or openssl structure distinguishers we should be worrying about, or is random data sufficient to mask it out? Thanks!!! :)

2 2

Re: [tor-dev] Padding prop224 REND1 cells to blend them with legacy cells
by Ian Goldberg 20 Sep '17

20 Sep '17

Resending from a subscribed address. On Tue, Sep 19, 2017 at 05:44:46PM +0300, George Kadianakis wrote: > Hello Ian, (and other cryptographers on the list) > > here is a quick question which you might be able to answer super fast: > > Legacy RENDEZVOUS1 cells are bigger than the prop224 ones. The prop224 > spec suggests we pad the new cells so that they look similar in size to > the legacy ones. > > Here is how the legacy ones look like: > > RC Rendezvous cookie [20 octets] > g^y Diffie-Hellman [128 octets] > KH Handshake digest [20 octets] > > Here is how the prop224 ones look like: > > RENDEZVOUS_COOKIE [20 bytes] > HANDSHAKE_INFO [64 bytes] > > The suggestion is to pad the prop224 cells to 168 bytes using random data. > > Would that work? My main question is whether the g^y part of the legacy > cell has any distinguishers that could distinguish it from random data. > It's encoded using OpenSSL's BN_bn2bin() and it's a 1024 bit DH public > key. Are there any algebraic or openssl structure distinguishers we > should be worrying about, or is random data sufficient to mask it out? > > Thanks!!! :) Is your goal that someone who sees the *plaintext* of that cell won't be able to tell if it's a legacy RENDEZVOUS1 cell or a new one? If so, life is a bit complicated, since the g^y field will always be in the prime-order subgroup. (Note: I'm not actually 100% sure Tor uses a generator of the prime-order subgroup for g in this part of the spec. But it should have, and so hopefully did.) If HANDSHAKE_INFO || PADDING_64 (the latter being the first 64 bytes of the padding) is _not_ in the prime-order subgroup, the observer will be sure it's a prop224 cell. If it _is_, the observer can't tell. If that's undesirable, you could always insist that PADDING_64 be chosen such that HANDSHAKE_INFO || PADDING_64 _is_ in the prime-order subgroup. Raise it to the power of the prime order q to check; if the result is 1, you're good. You'll need to try on average (p-1)/q random values of PADDING_64 before you get a good one. (NOTE: *NOT* CONSTANT TIME.) If p = 2q+1, that's just 2, so not *terrible*, but 2 1024-bit modexps might still be annoying. If for some reason p is a DSA modululus or something bizarre like that, life is much more annoying. (I hope it's not.) This is all assuming p is of the form 2^1024 - (some number at most say 2^960), so that HANDSHAKE_INFO || PADDING_64 won't be larger than p itself, which would be another problem. To be sure, what are the g and p values used in this particular Diffie-Hellman?

2 2

Re: [tor-dev] tor-dev Digest, Vol 80, Issue 10
by flipchan 19 Sep '17

19 Sep '17

I emailed someone that runned an out of date version of tor yesterday and maybe it's more efficient to have an auto mailer to remind ppl to update On September 19, 2017 2:00:09 PM GMT+02:00, tor-dev-request(a)lists.torproject.org wrote: >Send tor-dev mailing list submissions to > tor-dev(a)lists.torproject.org > >To subscribe or unsubscribe via the World Wide Web, visit > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev >or, via email, send a message with subject or body 'help' to > tor-dev-request(a)lists.torproject.org > >You can reach the person managing the list at > tor-dev-owner(a)lists.torproject.org > >When replying, please edit your Subject line so it is more specific >than "Re: Contents of tor-dev digest..." > > >Today's Topics: > > 1. Re: Auto-senescence and/or CW penalty for a less outdated tor > network? (nusenu) > > >---------------------------------------------------------------------- > >Message: 1 >Date: Mon, 18 Sep 2017 17:30:00 +0000 >From: nusenu <nusenu-lists(a)riseup.net> >To: tor-dev(a)lists.torproject.org >Subject: Re: [tor-dev] Auto-senescence and/or CW penalty for a less > outdated tor network? >Message-ID: <6aaa7727-7013-2ff8-3eb1-ac9b752b5981(a)riseup.net> >Content-Type: text/plain; charset="windows-1252" > >>> 1) Auto-senescence >>> ------------------- >> >> I think automatic timed shutdown can be unhelpful or dangerous: > >Yes it reduces the number of options once such a feature would be >implemented and deployed. > >> * what if we need it earlier due to a severe bug or mandatory >feature? > >This should not be an issue since that auto-shutdown only mandates an >upper limit but does not stop you from removing a relay before that >limit has been reached. > >> * what if it isn't needed, and the relay version is fine? > >Yes this can be an issue, but if you say "every relay that runs >versions >past its eol date" [1] is "not fine" then the auto-shutdown date can be >specified with a very high likelihood to a date that is past the eol >date because you have an estimate of how long you plan to support it >(3y >for LTS). > >I'm less concerned about auto-shutdown for tor clients since most tor >users might be using TBB with auto updates and it would help you having >to do things like prop266. > >[1] >https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam/CoreTor… > >>> 2) consensus weight penalty for outdated relays >>> ----------------------------------------------- >> >> I can't see much point in this: if the relays are insecure, they >> should be eliminated. If not, they should be used. > >I'm happy with "insecure -> should be removed". >With "outdated" I meant "not running a recommended version" I'm not >sure >if that is the same as 'insecure'. > >A CW penalty would be a strong incentive for relay operators to keep >their relays up to date (to a recommended version). >This would likely reduce the number of relays running not-recommended >versions because currently the incentive is inverted (never >restart/update your tor instance - uptime!). >..but it would also affect testers running master. > > >>> 3) update tor dir auth code to reject old tor releases (not include >them >>> in consensus) >>> >------------------------------------------------------------------------- > >> In the past, we've excluded relay versions when they don't have a >> required feature. > >Does this step (excluding specific versions) require a code change or a >dir auth configuration change? (like it does for changing recommended >versions list) >If it does: Maybe it could be turned into a configurable option for dir >auths like recommended version. > >(3) will not stop old relays from contacting dir auths. > > >> We have a ticket to make a plan to kill off old client versions: >> https://trac.torproject.org/projects/tor/ticket/15940 >> But there's no equivalent ticket for relay versions. > > > >-- >https://mastodon.social/@nusenu >https://twitter.com/nusenu_ > >

1 0

Auto-senescence and/or CW penalty for a less outdated tor network?
by nusenu 18 Sep '17

18 Sep '17

Hi, tl;dr: ideas to reduce the cw fraction that outdated relays make up of the tor network This email can be somewhat summarized by these three polls: https://twitter.com/nusenu_/status/909356846900801536 https://twitter.com/nusenu_/status/909359701908971520 https://twitter.com/nusenu_/status/909361044988071936 This email was sparked by a recent thread on twitter. As of 2017-09-16 more than 27% CW fraction of the tor network (>2500 relays) run a version of tor that is not recommended by tor's directory authorities [2]. More than 8% CW fraction (>1100 relays) even run tor branches that reached end-of-life and are no longer maintained. So if we agree that 27% CW fraction is to much, we could aim at reducing that fraction within the tor network. Here are a few ideas. 1) Auto-senescence ------------------- Alfie John suggested [1]: > automatic shutdown after its version is too old as used in zcash (the tor snap from Chad Miller does auto-shutdown already today), Moritz replied: > Tor already has this mechanism in the form of recommended/required versions in consensus I looked into that [3] but this is about tor _protocols_ (not versions) and is probably better suitable for avoiding compatibility issues within the tor network as multiple protocols coexist but you can not use that to remove specific tor versions because many versions share the same protocol set [4]. [1] https://twitter.com/alfiedotwtf/status/906310842672603136 [2] https://consensus-health.torproject.org/#recommendedversions [3] https://gitweb.torproject.org/torspec.git/tree/proposals/264-subprotocol-ve… [4] https://gist.github.com/nusenu/1302a04b26dac8e2ef838117f5f3fd2b So back to Alfie's suggestion. If tor should shutdown when 'too old' we have to know what 'too old' is. To come up with a timespan for 'too old' I looked into 61 currently used tor versions that are no longer recommended by dirauths. I measured the time between release date (as mentioned in the changelog) and the last consensus where the given version was listed as a recommended relay tor version [5], but these graphs show the "recommended" lifespan of releases before the new support policy [6] with shorter release cycles for "regular" releases has been introduced. [5] https://twitter.com/nusenu_/status/909355193434853376 [6] https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam/CoreTor… So instead of of using this historical data we could simply follow the support policy. regular release: Auto-shutdown 18 months (=9+grace period) after the branch became stable. LTS relase: Auto-shutdown 4 years (=3+grace period) after the branch became stable. Dates would be hardcoded and do not require relays to contact dirauths. So old relays will not but any load on dir auths and fallbackdirs everytime they start. Lets simulate these timespans for tor 0.2.4 and 0.2.5 (and lets assume they are LTS releases) - tor 0.2.4 relays - if they had such a logic - would shutdown on 2017-12-11 (eol date was 2017-08-01) - tor 0.2.5 relays whould shutdown on 2018-10-24 (eol date is 2018-05-01) (not mentioning 0.2.6/7 here) - tor 0.2.9 relays would shutdown on 2020-12-19 (eol date is 2020-01-01) You could add a torrc option to allow operators (and package maintainers) to opt-out of auto-shutdown. There is no doubt that any mechanism to disable old relays _automatically_ and by _default_ would shrink the tor network (compared to not having that), so having a good answer for "What is an acceptable CW fraction for outdated tor versions on the network?" would be important, but since the reasons for removing versions from the recommended list are very different the recommended datapoint might not be enough. 2) consensus weight penalty for outdated relays ----------------------------------------------- Instead of (or additionally to) telling relays to not upload descriptors (complete removal) you could _automatically_ reduce/cap their consensus weight on the dirauth side if they run - unsupported branches (harsher penalty) - run not-recommended tor releases over a long time (less harsh penalty) (The distinction between unsupported branches and not-recommended is currently not available as consensus information.) This approach makes the recommended version list a more critical consensus item and as you know this is not always managed ideally: - new releases not added to the list in a timely manner -> operators upgrading timely get warnings - old releases not removed timely or before deb.torproject.org provided new releases 3) update tor dir auth code to reject old tor releases (not include them in consensus) ------------------------------------------------------------------------- As soon as a tor directory operator updates to a new release the dirauth would no longer vote for specific tor versions (I guess this is the current mostly manual approach). Another important aspect is the practical reality in current package repositories, but I simply assume they will follow LTS releases and are fine with the 4 years (3+grace period) lifespan. regards, nusenu -- https://mastodon.social/@nusenu https://twitter.com/nusenu_

2 2

PQ crypto updates
by bancfc＠openmailbox.org 18 Sep '17

18 Sep '17

If I understand correctly, DJB describes how NTRU-Prime is more robust against certain attack classes that Ring-LWE is more prone to: https://twitter.com/hashbreaker/status/880086983057526784 *** About two months later DJB releases a streamlined version of NTRU-Prime that is faster, safer and uses less resources than the latest version of New Hope while (wait for it...) completely eliminating decryption failures !: https://twitter.com/hashbreaker/status/898048057849380864 https://twitter.com/hashbreaker/status/898048506681860096 https://twitter.com/hashbreaker/status/898048760009420801 https://twitter.com/hashbreaker/status/898391210456489984 *** 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

5 8

Dir auths using 2x bandwidth in last week
by Roger Dingledine 18 Sep '17

18 Sep '17

https://atlas.torproject.org/#details/9695DFC35FFEB861329B9F1AB04C46397020C… https://atlas.torproject.org/#details/F2044413DAC2E02E3D6BCF4735A19BCA1DE97… https://atlas.torproject.org/#details/BD6A829255CB08E66FBE7D3748363586E46B3… https://atlas.torproject.org/#details/74A910646BCEEFBCD2E874FC1DC997430F968… https://atlas.torproject.org/#details/7EA6EAD6FD83083C538F44038BBFA077587DD… 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? --Roger

3 6

[release] CollecTor 1.3.0, metrics-lib 2.1.0, Onionoo 4.1-1.5.0
by iwakeh 15 Sep '17

15 Sep '17

Hi there! three new releases are available: https://dist.torproject.org/collector/1.3.0/ https://dist.torproject.org/metrics-lib/2.1.0/ https://dist.torproject.org/onionoo/4.1-1.5.0/ These releases upgrade all projects to use Java 8. A few issues and improvements come along and can be found in the change-logs [0], [1], [2]. Please direct comments and questions to the metrics-team mailing list [3]. Cheers, iwakeh [0] https://gitweb.torproject.org/collector.git/tree/CHANGELOG.md?h=collector-1… [1] https://gitweb.torproject.org/metrics-lib.git/tree/CHANGELOG.md?h=metrics-l… [2] https://gitweb.torproject.org/onionoo.git/tree/CHANGELOG.md?h=onionoo-4.1-1… [3] https://lists.torproject.org/cgi-bin/mailman/listinfo/metrics-team

1 0