April 2017 - tor-dev - lists.torproject.org

Provisional Draft of Hyphae
by isis agora lovecruft 21 Apr '17

21 Apr '17

Hello! Henry and I have written up a provisional draft design for a social bridge distribution scheme, modelled after rBridge, which we're calling Hyphae. For those further interested, here is a draft PDF. [0] Included within is: - A technical history, with primary sources, of censorship of the Tor network, as well as remediations for those censorship attempts; - A description of the bridge distribution problem, including orthogonal problems and solutions, and prior proposals specific to the bridge distribution; - A description of an algebraic-MAC attribute-based credential scheme, requisite non-interactive zero-knowledge proofs, and sub-credentials and tokens, which we use to build our bridge distribution protocol; - A centralised, anonymous micropayments scheme, which we hope is of interest to other projects (such as Brave); - A description of our Hyphae protocol; - An high-level, cryptographic and protocol design comparison to the rBridge protocol; and - Draft notes on our implementation. Please note that this is a provisional draft paper, containing the design but not yet containing results specific to our implementation. We expect some things to change in minor ways during further refinement and implementation. That said, we welcome all feedback and appreciate review. [0]: https://patternsinthevoid.net/hyphae/hyphae.pdf Best regards, -- ♥Ⓐ isis agora lovecruft _________________________________________________________ OpenPGP: 4096R/0A6A58A14B5946ABDE18E207A3ADB67A2CDB8B35 Current Keys: https://fyb.patternsinthevoid.net/isis.txt

1 0

maatuska's bwscanner down since 2017-04-14 -> significant drop in relay traffic
by relayoperator＠openmailboxbeta.com 20 Apr '17

20 Apr '17

Hi Tom! since maatuska's bwscanner is down [1] I see a significant drop of traffic on many of my relays, and I believe this is related. Do you have any update to [2] on when maatuska will report bwscan results again? thanks, a concerned relayoperator [1] https://lists.torproject.org/pipermail/tor-consensus-health/2017-April/0078… https://consensus-health.torproject.org/graphs.html#bwauthgraphs [2] https://lists.torproject.org/pipermail/tor-consensus-health/2017-April/0078…

3 2

Re: [tor-dev] maatuska' s bwscanner down since 2017-04-14 -> significant drop in relay traffic
by relayoperator＠openmailboxbeta.com 20 Apr '17

20 Apr '17

> On Thu, Apr 20, 2017 at 10:54:21AM -0000, relayoperator(a)openmailboxbeta.com wrote: >> Hi Tom! >> since maatuska's bwscanner is down [1] I see a significant drop of traffic on many of my relays, and I believe this is related. >> Do you have any update to [2] on when maatuska will report bwscan results again? >> thanks, >> a concerned relayoperator > > I am also seeing a strange sudden drop in usage: > > https://atlas.torproject.org/#details/BCEDF6C193AA687AE471B8A22EBF6BC57C2D2… > > What's going on? In your case the traffic dropped but the consensus weight and exit probability is going way up. This is also strange but I guess unrelated to maatuska. Why is David Goulet's munin showing 8k measured lines for maatuska when there are 0?

2 1

Proposition: Applying an AONT to Prop224 addresses?
by Alec Muffett 15 Apr '17

15 Apr '17

Hi, So: a bunch of us were discussing Prop224 Onion addresses, and their UX-malleability. Specifically: that there are small bit fields in the current Prop224 Onion Address schema (eg: version, and other future structure?) which can be tweaked or amended without otherwise changing the functionality of the address, or without much changing what the user sees in the (say) browser address bar. This is a point of significant concern because of issues like phishing and passing-off - by analogy: t0rpr0ject.0rg versus torproject.org - and other games that can be played with a prop224 address now, or in future, to game user experience. We discussed the existing "hash the public key before base-32 encoding" approach, but hashing breaks the prop224 key blinding. Ian Goldberg - thank you Ian - offered this attractive solution: apply a *reversible* "All Or Nothing Transform" (AONT) to the entire Prop224 Onion Address, prior to Base32 Encoding. This way, even a single-bit mutation of (say) version number will have a "diffusion" effect, impacting ~ N/2 of the bits whilst having O(1) cost and being reversible so as not to impact the rest of Prop224. The result would be onion addresses which are less "tamperable" / more deterministic, that closer to one-and-only-one published onion address will correspond to an onion endpoint. What does the panel think? - alec -- http://dropsafe.crypticide.com/aboutalecm

7 27

Interest in collaborating on a standard Ed25519 key blinding scheme?
by Tony Arcieri 15 Apr '17

15 Apr '17

I'm trying to gauge interest on the IRTF's CFRG mailing list regarding collaborating on a draft for a standard Ed25519 hierarchical derivation / key blinding scheme: https://mailarchive.ietf.org/arch/msg/cfrg/lM1ix9R-0tVzhZorQhQlKvi4wpA The post makes several mentions of Tor's work in the space in regard to the next-generation hidden services design. I think it'd be great if Tor were to collaborate on the design of such a scheme and adopt it for the new hidden services design. I see a lot of convergent evolution in this space and think it would be great if there were a single standard everyone could implement. Even if you don't, I think there are some ideas from similar schemes Tor should fold back into its own design, particularly in regard to how certain bits of the private scalar are "clamped". Some discussion of that here: https://moderncrypto.org/mail-archive/curves/2017/000862.html tl;dr: clamp the third highest bit of the root scalar to zero (in addition to the bits normally clamped in the non-canonical Ed25519 private scalar), and use 224-bit child scalars. -- Tony Arcieri

5 5

Re: [tor-dev] Interest in collaborating on a standard Ed25519 key blinding scheme?
by Oleg Andreev 15 Apr '17

15 Apr '17

> From: George Kadianakis > Date: Wed, Apr 12, 2017 at 7:57 AM > > An update: > > After lots of discussions in the Amsterdam Tor meeting, the following > approach was suggested for cleansing keys of their torsion components > that is more friendly towards hierarchical key-derivation schemes: > https://moderncrypto.org/mail-archive/curves/2017/000866.html > > However, my current intuition is to just not do this for hidden service > ed25519 blinded keys. Those keys are only used for signing descriptors > which should be safe to do, and we don't plan to use them for D-H any > time soon. If we or some crazy app EVER decides to use those ephemeral > keys for key exchange, we would need to use a special DH function that > kills the tensor component of keys before using them, as suggested by > Trevor here: https://moderncrypto.org/mail-archive/curves/2017/000874.html > > Please let me know if you think this is not a good idea! Thanks for the update, George. TL;DR: your scheme seems to be just fine for signatures, and even torsion-safety issues are not huge issues IMHO. For wide applicability reasons, I am trying to make our scheme ChainKD [1] to fit as many use cases as possible and therefore very interested in Tor's requirements and rationale regarding Tor's key blinding proposal. L;R: After studying the situation with key derivation schemes for Ed25519, my impression is that the central issue is not even safety, but compatibility with existing Ed25519 implementations. People who have to integrate a key derivation scheme in their protocol are often not the same people who write the underlying primitives such as scalar multiplication. This means, that it's safer to be conservative and keep the derivation scheme as compatible with EdDSA as possible so that assumptions that implementors may take by just reading the EdDSA spec without knowing about key derivation schemes, do not cause compatibility problems. Since it's not a trivial task to even learn the landscape of problems around Ed25519 compatibility- and safety-wise, it'd help if we can figure all of that once, implement and reuse the result w/o having to go through this again and again. Hence, our interest in standardizing the scheme that satisfies as many requirements as possible. <comic relief> https://xkcd.com/927/ </comic relief> Following the feedback in BIP32-Ed25519 paper [2], I've updated our ChainKD [1] scheme to make it safely "compatible" with DH use cases (among those is asymmetric encryption such as ECIES). In the Design Rationale section [3] I try to describe the issues with low/high bits and torsion-safe representative and why we choose to keep those bits as defined in Curve25519 instead of "torsion-safe representative" and why we use BIP32-style blinding-by-addition instead of blinding-by-multiplication. One piece of feedback affecting our proposal is missing, though: I'd like to ask Tor developers what is the rationale and requirements for their key blinding proposal. Specifically, why do you choose to blind via multiplication instead of addition: s' = b*s; P' = b*P (Tor's proposal) vs s' = s + b; P' = P + b*G (BIP32, ChainKD) (G -- base point, P -- pubkey, s -- secret scalar, P = s*G, b -- blinding scalar) I know of a few reasons to use addition over multiplication (e.g. performance and bit-compatibility with EdDSA), but would love to learn if that hurts some protocols. PS. I've just joined the list and replying to a forwarded message. I apologize if I break the thread. [1] ChainKD, revised: https://github.com/chain/chain/blob/chainkd-dh/docs/protocol/specifications… [2] BIP32-Ed25519: https://drive.google.com/open?id=0ByMtMw2hul0EMFJuNnZORDR2NDA [3] ChainKD rationale: https://github.com/chain/chain/blob/chainkd-dh/docs/protocol/specifications…

2 1

Re: [tor-dev] [Twisted-Python] txtorcon versioning
by meejah 13 Apr '17

13 Apr '17

Manish Tomar <manish.tomar(a)gmail.com> writes: > If you don't mind, could you describe your reasoning behind this > decision? I am always curious to learn any concrete reasons behind > this. If this seems spammy to the mailing list, please feel free to > respond only to me. Mostly because I don't want to ever have breaking changes, so then you're "not supposed" to upgdate the big version number. I haven't found that "semantic versioning" has been working very well for the release-style of txtorcon. Other, less important reasons: Twisted does this; it's easier to tell "how new" a release is; and big version numbers are cool (just kidding). -- meejah

1 0

Release: sandboxed-tor-browser-0.0.5
by Yawning Angel 13 Apr '17

13 Apr '17

Hello, I just tagged sandboxed-tor-browser 0.0.5. Binaries will be built when the next Tor Browser build happens (soon). Astute readers will notice that I skipped the release announcement for 0.0.4, which was tagged yesterday. This is due to changes related to e10s being enabled in the next alpha release, that were caught after the 0.0.4 tag was created. Changes in version 0.0.5 - 2017-04-13: * Bug 21764: Use bubblewrap's `--die-with-parent` when supported. * Fix e10s Web Content crash on systems with grsec kernels. * Add `prlimit64` to the firefox system call whitelist. Changes in version 0.0.4 - 2017-04-12: * Bug 21928: Force a reinstall if an existing hardened bundle is present. * Bug 21929: Remove hardened/ASAN related code. * Bug 21927: Remove the ability to install/update the hardened bundle. * Bug 21244: Update the MAR signing key for 7.0. * Bug 21536: Remove asn's scramblesuit bridge from Tor Browser. * Fix compilation with Go 1.8. * Use Config.Clone() to clone TLS configs when available. The main major change is the eradication of support for the `hardened` series, as the Tor Browser team will be dropping it starting from the next release (#20814). The impact on `sandboxed-tor-browser` + `hardened` users is thus: * (< 0.0.4) Will not correctly transition to the alpha channel. Sorry. The bundle may or may not be rendered non-functional by the transition update, I don't have a good way to test the Tor Browser auto update infrastructure with updates that haven't been released yet. * (>= 0.0.4) When `sandboxed-tor-browser` is launched, it will detect the `hardened` bundle and force a reinstall. This will eradicate the existing bundle directory obliterating user customization, bookmarks, and downloads (unless the download directory is overridden). A warning dialog box is displayed prior to booting the user back to the installation screen. Known issues: * Sending SIGINT to `sandboxed-tor-browser` (or likely otherwise killing the process) will leave the firefox process running on ESR52 + e10s builds, *unless* bubblewrap is version 0.1.8 or newer. Exiting firefox normally works as intended. Regards, -- Yawning Angel

1 0

txtorcon versioning
by meejah 13 Apr '17

13 Apr '17

I will soon release the next version of txtorcon with a ton of cool new features. This will be called 0.19.0. More details: http://timaq4ygg2iegci7.onion/releases.html Going forward, versioning will switch to a "CalVer.org" variant. At one point, I thought of breaking a few now-regrettable APIs. However, I will not do this. The next version after 0.19.0 will be 17.x.y Changes in any existing APIs will be done by first introducing the new thing, deprecating the old thing and eventually removing the old thing. The new documentation's "programming guide" includes some notes on API stability. I have not to date broken/changed any existing API. Also at this point nothing is deprecated (but there are "preferred" APIs). The onion services APIs *will* change for the 17.x release. New code should follow the recommendations in the programming guide. Existing code will continue to work for the forseeable future. thanks, meejah

2 2

GNU Guix and Tor Browser Packaging
by bancfc＠openmailbox.org 11 Apr '17

11 Apr '17

There is a serious Tor Browser packaging effort [3][4] being done by ng0 (GNUnet dev) for the GNU Guix [0] package manager. GNU Guix supports transactional upgrades and roll-backs, unprivileged package management, per-user profiles and most importantly reproducible builds. I have checked with Guix's upstream and they are working on making a binary mirror available over a Tor Hidden Service. [2] Also planned is resilience [2] to the attack outlined in the TUF threat model. [1] Back to the topic of Tor Browser packaging. While there are good reasons for Debian's pakaging policies they make packaging of fast evolving software (and especially with TBB's reliance on a opaque binary VM for builds) impractial. Both we and Micah have been doing a good effort to automate downloading and validating TBB but I still believe its a maintenance burden and Guix may be a way out of that for Linux distros in general. What are your thoughts on this? *** [0] https://www.gnu.org/software/guix/ [1] https://github.com/theupdateframework/tuf/blob/develop/SECURITY.md [2] https://lists.gnu.org/archive/html/guix-devel/2017-03/msg00192.html [3] https://lists.gnu.org/archive/html/guix-devel/2017-03/msg00189.html [4] https://lists.gnu.org/archive/html/guix-devel/2017-03/msg00149.html

2 2