- tor-dev - lists.torproject.org

Tor 0.3.1 ticket triage: please do this today if you hack on Tor.
by Nick Mathewson 26 Apr '17

26 Apr '17

Hi! We've got 3 weeks left in the 0.3.1 merge window (which closes on May 15) so let's try to triage the tickets. Here's what to do if you are going to develop anything for Tor 0.3.1: - Make sure that everything you are going to do for 031 is assigned to you, in the 0.3.1 milestone, and has a points estimate. ("Points" is a rough "how many days will this take me?" guess.) - If there is anything assigned to you for 031 that you _won't_ be doing for May 15, or that you won't be doing at all, please unassign it and/or defer it from the 031-milestone. - If your total points estimate is over 12 or so (or whatever number of programming days you think you will have, please defer the less important things, or tag them with 031-stretch. Then, in 24 hours or so, for all the tickets that don't get an owner, I will either defer them or mark them "too important to defer" and look for somebody else to do them. Let's see how this works! -- Nick

2 1

Action items wrt ed25519 onion address verification in prop224 (was Re: [tor-project] Network team meetings notes from 17 April 2017)
by George Kadianakis 25 Apr '17

25 Apr '17

Ian Goldberg <tor(a)cypherpunks.ca> writes: > On Thu, Apr 20, 2017 at 03:40:58PM +0300, George Kadianakis wrote: >> Hey Ian, >> >> so the current problem with ed25519-donna is that when I'm doing the >> above, I'm getting the following 32-byte key after ge25519_pack(). Here >> it is hexed up: >> >> 0x0100000000000000000000000000000000000000000000000000000000000000 >> >> I don't see any methods in ed25519-donna for checking a point or a >> packed point to see if it's the point at infinity (identity element). > > There actually is such a function, but it's buried in a weird place. > ge25519_is_neutral_vartime in ed25519-donna-batchverify.h does what you > want, but it's static, so you would need to copy it (and remove the line > involving batch_point_buffer). Probably not worthwhile. > > I can easily believe the representation of the identity (neutral) > element in ed25519 is the hex value above. (And it is; see below.) > >> I've been assuming that the point at infinity would be an all-zeroes >> 32-byte array, because that's what we are doing in curve25519, but I >> actually have no idea how the array representation of ge25519_pack() >> works. Here is our process for curve25519: >> https://gitweb.torproject.org/tor.git/tree/src/common/crypto_curve25519.c#n… > > Curve25519 only outputs the x coordinate, which is indeed 0, so you get > the all-zero value. ed25519 outputs the y coordinate (which is the > 255-bit value 0x000...0001 in little-endian format) and the single-bit > parity of the x coordinate (which is 0), so you do get the hex you give > above. (The identity element is the point (0,1) in Edwards curves, not > actually the point at infinity.) > >> The above packed point is an all zeroes 32-byte string, apart from the >> very first bit which is set. Could it be that the first bit is the >> compressed sign of the 'x' coordinate or something, and that's actually >> the point at infinity? >> >> But then what's the right way to check for the point at infinity? Check >> that everything is 0 apart from the first sign bit? > > Yes, pack the point, and compare it to the above 32-byte value. > >> And after I figure this out, I need to do the same for the reference >> implementation of ed25519, because as it seems Tor uses two simultaneous >> implementations of ed25519: >> https://gitweb.torproject.org/tor.git/tree/src/ext/ed25519 > > Yes, hopefully that implementation packs points in the same way! > >> Thanks for the help Ian :) Very much appreciated! > > No worries. > [CCing tor-dev since people might find it interesting] Thanks for the advice Ian :) With your help, I have now implemented the validation check. Check out the ticket #22006 and the branch `bug22006` here: https://gitweb.torproject.org/user/asn/tor.git/commit/?h=bug22006&id=628dd1… One last thing I'd like to do here is test our validation function against a pubkey with torsion component to make sure that it gets rejected. How would you go about generating such a pubkey? I was thinking of using the CRT to find an integer a \in Z, s.t a == 0 (mod l) && a == 1 (mod 8) but then I didn't know how to go from that scalar with a torsion component to an ed25519 point... Cheers!

2 4

Experimental Namecoin naming for Tor
by Jeremy Rand 23 Apr '17

23 Apr '17

Hi, I've pushed some experimental code for using Namecoin naming in Tor. The code is at https://github.com/JeremyRand/OnioNS-client , you want the "namecoin" branch. Rough instructions: 1. Install Namecoin Core and let it fully download the blockchain. (SPV support is in the works.) 2. Enable JSON-RPC with user/password authentication in Namecoin Core. (The procedure is identical as in Bitcoin Core.) 3. Set your Namecoin Core JSON-RPC login info in the init_namecoind function of src/assets/onions-stem.py. 4. Start Tor Browser Bundle. 5. Run src/assets/onions-stem.py. 6. The first time you run it, it will instruct you to add a line to one of the Tor config files; do this. Specifically, it will ask you to add the line "__LeaveStreamsUnattached 1" to torrc-defaults. 7. Start Tor Browser Bundle again. 8. Run src/assets/onions-stem.py again. 9. Try opening a Namecoin website in Tor Browser. Example websites that I've verified to work include: http://duckduckgo-onion.bit.onion http://bitcoinpl.bit http://federalistpapers.bit.onion http://botball.bit (gives a Dreamhost error) The .bit.onion sites should also work as plain .bit. Semantically, .bit.onion means that it will always resolve to a .onion address (meaning that .bit.onion names are encrypted and authenticated regardless of whether TLS is used); .bit means that it will resolve to any of .onion, IPv6, IPv4, or CNAME (prioritized in that order), meaning that .bit names are only encrypted and authenticated if TLS is used. These semantics are open to revision later, as the Tor community evolves its canonical naming semantics. This is all proof of concept for now; some or all of this code will be rewritten later (hopefully to use the pluggable naming API instead of the control port). It will probably not work with Whonix/Tails/Subgraph due to the control port filter. It will definitely make your Tor Browser instance stand out, since most users can't resolve Namecoin domain names. And since it accesses the control port, it could presumably do lots of horrible things to your Tor instance (and I make no guarantees that it's properly sanitizing the input that's passed to Tor's control port). Huge thanks to Jesse for OnioNS (on which this code is based), and also thanks to Nick for sharing helpful info on this mailing list. Let me know how it works for you. Cheers, -- -Jeremy Rand Lead Application Engineer at Namecoin Mobile email: jeremyrandmobile(a)airmail.cc Mobile OpenPGP: 2158 0643 C13B B40F B0FD 5854 B007 A32D AB44 3D9C Send non-security-critical things to my Mobile with OpenPGP. Please don't send me unencrypted messages. My business email jeremy(a)veclabs.net is having technical issues at the moment.

2 1

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