- tor-dev - lists.torproject.org

Vanguard Plugin Options
by procmem＠riseup.net 29 Jan '20

29 Jan '20

Hi. We are rolling out the vanguard plugin for our users and wanted to understand some options we can enable. * In many parts of the Security README setting *circ_max_megabytes* is recommended. Though it is discouraged for usecases involving Onionshare and Securedrop which we support. What is a reasonable limit to set? What happens is the max ceiling gets hit? Does it permanently disrupt the upload/download? * "High load onion services may consider using 4 layer2 guards by changing the *num_layer2_guards* option in the configuration file <https://github.com/mikeperry-tor/vanguards/blob/master/vanguards-example.co…>, but going beyond that is not recommended." Does this benefit clients too? We would like to enable options that mimic the configuration used by actual high load onion services to provide them with more cover.

2 1

Snowflake server and traffic analysis questions
by procmem＠riseup.net 17 Jan '20

17 Jan '20

Thanks Cecylia for your great explanation.

1 0

Adding Tracing to little-t tor
by David Goulet 17 Jan '20

17 Jan '20

Greetings tor-dev! This email is a discussion on adding tracing to little-t tor. Tracing can be a very abstract notion sometimes so I'll start with a quick overview of what that is, what we can achieve and use cases within tor. Then I'll go over a last point which is safety. This email doesn't go into the technical details of userspace tracing on how and what will be done to add it to tor. That is for another discussion. 1. Overview Long story short, you can see tracing as a specific type of logging as in it records information of the application at runtime using tracepoints (similar to logging statement) so it can be used later. But the main differences from logging are in two parts: performance and API stability. Usually, tracing implies high performance as in adds very little overhead to the application in order to disrupt as little as possible the normal behavior of an application. This is extremely useful in cases where you want to catch race conditions or performance bottle necks. Tracers in userspace have usually an "inprocess library" which in short means that it records data (raw) from the application and move it to an outside buffer. Then, that buffer is emptied either on disk or network by the outside component of the tracer for which the data can be analyzed after collection. So all a tracer do is, within the application when a tracepoint is hit, copy some data into a buffer and yields back to the application. The other part is the API stability. Very often, logs (let say at DEBUG level) don't usually have strict stable requirements between released versions. But tracing events (tracepoints), are exposed to the outside for tracers to hook on, and for people to run analyzing tools on the recorded data. Thus, stability is usually strongly encouraged. In other words, what the tracepoint exposes, once released stable, should really not change that much over time. With a proper abstraction in the application, we can offer stable tracepoints for which a variety of tracers can hook themselves on at runtime. It is all about providing an interface to the outside world. 2. Why Tracing in Tor The tor software is a very complex beast. It has dozens of subsystems with various interactions between them. One of the big main job of tor is to relay data as fast as possible in order to keep the latency low. Which means, that there are code paths that are considered "fast path" implying that they must remain light and fast. One example is the crypto code that is hit at each cell. Tracing comes in extremely handy to hunt down race conditions, performance issues, or even multithreading problems. A fast relay, let say 25MB/s, if we wanted to record cell timing in order to hunt down such issues, it simply can _not_ be done with logging at debug level since it slows down considerably tor but also fills the disk in a matter of minutes. And using the control port is not a good solution for two main reasons: string formatting at each event and control port is part of the mainloop. So anything you ask to go on the control port will add an overhead to the overall behavior of tor which is not good when you hunt down races. One concrete example where tracing was used in the past in tor is with the rewrite of the cell scheduler (KIST). In order to measure cell timings within Tor so bottlenecks issues could be found, tracing had to be added so millions of events could be recorded within few minutes of using a fast relay in production. In pressure situation, this is where tracing comes handy. Tracing was also used recently to find onion service v3 reachability issues. In order to correlate connection, cell and circuit level problems with the higher level HS subsystem, we were able to record events in all those subsystems, match them with their precise timing (offered by tracing) and analyze the results later on after recording the data. 3. Safety Discussion Onto the last part I wanted to raise. Allowing anyone to record very low level data from tor, there is an obvious safety question that must be raised. Over the years, I've talked about tracing with many people in Tor and the consensus was always that it should never be enabled in production. As in, the packages shipped by Tor or by distros should _never_ build the tracepoints. In other words, it should be considered a development option only. Not only an option, but compiled _out_ in production and one has to explicitly build them into tor. For example (nothing final, just to show the idea): $ ./configure --enable-tracing I personally think that should be enough since the presence of the code upstream won't stop people from using it (bad or not) but we can prevent it to be in any legit Tor packages out there. See it a bit like the obsolete Tor2web option that was never enabled in any published packages by Tor Project or distros, one had to explicitly enable it at configure time. The ControlPort is allowed in production and if a malicious actor gets access to it, then game over. I do see tracing like that as well but at least we can control its availability as a feature where we can't for the ControlPort as of today. Any feedback is very welcome! Concerns, questions, thoughts. Cheers! David -- AOrq46damX3clZogjR9FlXTru90GV9IT5Rq/J0EzVSA=

3 4

OK got mix vanguards from packages.debian.org with Tor from deb.torproject.org repository?
by Patrick Schleizer 17 Jan '20

17 Jan '20

I am considering to install vanguards by default in Whonix. Is it sane to mix the Debian 'tor' package deb.torproject.org (buster repository) with packages.debian.org buster version of 'vanguards' or do you foresee any issues? Cheers, Patrick

2 2

Snowflake server and traffic analysis questions
by procmem＠riseup.net 15 Jan '20

15 Jan '20

Goal: We (Whonix) are researching optional bridge hosting for our users to thwart web fingerprinting. Snowflake makes the most sense since no NAT hole-punching is needed. Correct me if I'm wrong here because if that was possible with obfs4 or meek it would save a lot of work. We now know acting as a bridge makes the user act as a guard node and not just a rendezvous to one.[1] [1] https://tor.stackexchange.com/questions/3636/what-is-the-relationship-betwe… Some questions to help with implementation: * Do the user's own data go through just two hops as well or are they sent to the guard node they chose before deciding to run as a bridge? How do configure Tor to do the former if it isn't? * Are there plans to create signed debs for snowflake client/server so we can use it with Debian's tor daemon? * Do Tor Browser bundles with the snowflake addon also include the server component? * Do Alpha bundles have this code yet? * When are these bundles expected to arrive to stable? * Is it possible to interact headlessly with the snowflake server component via commandline? How? * How can we run TBB headlessly so users don't mistakenly interact with it on the gateway?

2 1

Updates to Prop306: A Tor Implementation of IPv6 Happy Eyeballs
by Neel Chauhan 15 Jan '20

15 Jan '20

Hi tor-dev@ mailing list, Sorry for the many-months delay in updating Prop306. I have updated Prop306, which is the IPv6 Happy Eyeballs proposal. The GitHub PR is here: https://github.com/torproject/torspec/pull/98 The Trac ticket is here: https://trac.torproject.org/projects/tor/ticket/29801 Some of the older discussion on Prop306 can be seen on the thread here: https://lists.torproject.org/pipermail/tor-dev/2019-August/013959.html Could some of you please review this proposal? -Neel === https://www.neelc.org/

2 3

Tor Proposal 295
by Tomer Ashur 13 Jan '20

13 Jan '20

Dear all, Please find attached out final version for Proposal 295. This version has two changes compared to the previous one: 1. It fixes a vulnerability introduced in the previous iteration which was the result of making the authentication layer stateless. Since there is no freshness entering into the first layer, the same plaintext would have resulted in the same ciphertext thus allowing an adversary to distinguish. This is now fixed by restoring the running digest also for authentication layer thus making in stateful again. 2. It adds an option for forward secrecy. The approach here is similar to the one taken by Proposal 308 by replacing the encryption key of the first layer after successfully processing the message. If this approach is taken, there is no need to keep the authentication layer stateful anymore. I'll be leaving the mailing list to reduce noise in my mailbox. If you need anything from me regarding this proposal just make sure to CC me on the email and I'll be happy to answer. Wishes, Tomer

1 0

Changes to accessing and using MaxMind's databases
by Karsten Loesing 13 Jan '20

13 Jan '20

Hi! When trying to update tor's geoip databases the other day I found that MaxMind's GeoLite2 database is not available for download anymore. The reason is: https://blog.maxmind.com/2019/12/18/significant-changes-to-accessing-and-us… We do not have a MaxMind account (yet). As of now, we cannot update tor's geoip files nor the files used by Onionoo. Should we try to get somebody who knows more about licenses and legal stuff to review their GeoLite2 EULA and tell us if it's okay for us to sign up for a MaxMind account? A possible downside would be that whoever wants to verify that we didn't mess with their database when converting it to our format would have to sign up for an account, too. An alternative is to find another, truly open data source than MaxMind databases (#25542, #26585). However, this could eat up more time than we currently have available, and we should have something ready in a few weeks from now. I'm not sure how we would squeeze this into the metrics team schedule, so we might need help with this. Thoughts on the two alternatives? What else did I miss? All the best, Karsten

2 1

Should we remove the ClientAutoIPv6ORPort option?
by Neel Chauhan 12 Jan '20

12 Jan '20

Hi tor-dev@, Ticket: https://trac.torproject.org/projects/tor/ticket/32905 GitHub PR: https://github.com/torproject/tor/pull/1652 Considering that people had issues with the ClientAutoIPv6ORPort option, like when IPv6 was tried on IPv4-only connections in [1] and [2], I think we should just remove the ClientAutoIPv6ORPort option. Plus, we are going to do real Happy Eyeballs in Prop306, making ClientAutoIPv6ORPort redundant. Should we? -Neel Sources: [1] - https://blog.torproject.org/comment/281976#comment-281976 [2] - https://blog.torproject.org/comment/282102#comment-282102

1 0

Request info about how the Tor HS DoS works
by juanjo 07 Jan '20

07 Jan '20

Hello, since months ago we are debating proposals about how to stop HS being DDoSed. We have many open issues and even developed in a rush a fix "just for the network" (not HS availability). But, I have not seen yet a good explanation about what is really happening when HS is being DDoSed by this famous and effective attack. I mean, the only thing I know about it is that its goal is to send a ton of INTRODUCE2 cells to the HS, but, what is the cost for the attacker? Some questions need to be answered, at least If I want to understand it and make a proposal for fixing this issues. *Questions:* Is the attacker building a circuit to the Rendz point as expected by the protocol? How can we be sure of that? -Attacker (client) to Rendezvous point circuit: What is exactly happening on this circuit and how can the attacker improve the attack? Is the attacker using the same Rendz over and over for its INTRODUCE1? A new circuit to the Rendz? Can the first two hops of a circuit be reused (only changing the exit node) so it can build a new circuit to a new Rendz faster and make the attack better? -Attacker (client) to Intro point: what is exactly happening on this side of the equation? Sorry, but I could not find the answer to these questions and what is going on on any ticket or this mail lists.

1 0

Bridge benefits stackable?
by procmem＠riseup.net 02 Jan '20

02 Jan '20

Hi. We are considering allowing users to run their daemon (optionally) as a bridge in addition to client mode for increased traffic fingerprinting resistance [1]. Does running a bridge prevent you from using a bridge yourself? I've seen it mentioned that using bridges can protect users in event of a malicious guard node. Can the benefits of being a bridge and connecting to one be stacked? What is the best practice here? Happy New Year. [1] https://blog.torproject.org/new-low-cost-traffic-analysis-attacks-mitigatio…

1 0

Stem and Nyx bug tracking moved
by Damian Johnson 21 Dec '19

21 Dec '19

Hi all. Stem and Nyx's issue tracking has moved from Trac to GitHub. In the future please file tickets at... https://github.com/torproject/stem/issues/ https://github.com/torproject/nyx/issues/ Thanks! PS. All existing tickets have moved. These trac components will be disabled to cut down on confusion... https://trac.torproject.org/projects/tor/ticket/32832

1 0

(No Subject)
by techniquea2z＠protonmail.com 14 Dec '19

14 Dec '19

I am working on nibirumrx3wruiqf and have some questions: How to setup DDOS protection on the VPS & nginx levels? Any guidelines on nginx configurations for scale? How does mirroring work? I imagine you'd open many ports on the torrc, and have nginx listen to different instances of the same app on different http ports. If this project interests you and you want to collaborate, contact me

1 0

Probability of Guessing a v3 Onion Address
by procmem＠riseup.net 11 Dec '19

11 Dec '19

Hi I was wondering what the mathematical probability of guessing an onion v3 address that is kept secret. Or asked differently: what is the entropy of v3 addresses if an adversary decides to bruteforce the entire keyspace? I am struggling to come up with a usecase for authenticated v3 services when keeping an address secret has the same effect and one can generate multiple addresses for the same server and share them with different entities. The degraded usability of v3 auth services compared to v2 is the reason I'm asking.

3 2

Onion DoS: Killing rendezvous circuits over the application layer
by George Kadianakis 10 Dec '19

10 Dec '19

Greetings! This is another thread [0] about onion service denial-of-service attacks. It has long been suggested that onion service operators should be given the option to kill spammy rendezvous circuits at will if they feel they are causing too much damage. Right now this is possible using the HiddenServiceExportCircuitID torrc option (introduced in #4700) and then using the CLOSECIRCUIT control port command to close circuits. Unfortunately, we have recently got reports that this technique is not viable for busy onion services under DoS because their control port gets overwhelmed by (useful for them) events, and it's basically rendered useless to the point that any CLOSECIRCUIT command takes several seconds to become effective. For this reason, multiple onion operators [1] have resorted to using the actual HTTP protocol as a direct channel of communication to the Tor daemon to request circuit shutdowns. This works by embedding a special string (or HTTP error code) to the HTTP responses from nginx to the Tor daemon and adding special custom code to the Tor daemon to close circuits that carry this string. This seems to work well enough for people so far. This is a thread to discuss this approach and other alternatives since it seems a useful tool against application-layer onion service denial of service attacks. Let me go through the positives and negatives of actuallym erging this defence upstream to little-t-tor: --- Positives: 1) This is a solid defense that actually helps people and has been reported as a positive countermeasure in an area that has been hard to find concrete defences (also see [0]). 2) Seems like more and more people are doing this already in a custom ad-hoc fashion, so merging this upstream will at least give them a secure way of doing it (instead of writing custom C code). 3) It's actually a pretty simple patch in terms of tech-debt and maintaining it. 4) The more we address DoS vectors like this one, the less incentive will exist for DoS actors to exist. Effectively improving the long-term health of the network. Negatives: a) It's a dirty hotfix that blends the networking layers and might be annoying to maintain in the long-term. b) It only works for HTTP (and without SSL?). --- For me, point (1) is extremely important, since we've been struggling with helping onion services that are getting DoSsed and this feature offers a solid defense against practical attacks. However, IMO the right way to do this feature, would be to improve the control port code and design so that it doesn't get so overwhelmed by multiple events. That said, I'm not sure exactly what kind of changes we would have to do to the control port to actually make it a viable option, and it seems to me like a pretty big project that serves as a medium-term to long-term solution (which we have no resources to pursue right now), whereas the hack of this thread is more of a short-term solution. I'm looking forward to constructive feedback here, since this seems like a controversial feature that users really need. Thanks! :) [0]: serving as a continuation of previous classics such as: https://lists.torproject.org/pipermail/tor-dev/2019-June/013875.html https://lists.torproject.org/pipermail/tor-dev/2019-July/013923.html etc. [1]: http://www.hackerfactor.com/blog/index.php?/archives/804-A-New-Tor-Attack.h… https://trac.torproject.org/projects/tor/ticket/32511

4 3

Trip Report: Reproducible Builds Summit
by Hans-Christoph Steiner 09 Dec '19

09 Dec '19

I was at the 5th Reproducible Builds Summit this past week, representing mostly Android topics. I attended the first two, so it was nice to see that there has been some real progress in the past few years of work. My main focus was working with an Apache/Maven developer on implementing the "buildinfo" spec for publishing reproducible Java JAR builds to Maven Central and other Maven repositories. Maven repositories are central to the whole Android and Java ecosystems as the primary means of getting libraries. We used the jtorctl library to prototype how this system will look when using the Maven, Gradle, and Bazel buildsystems. Given the results of our brief work, we should have something working and deployed this year. And there is already a Maven plugin for publishing the "buildinfo" files. So it should be easy to start getting libraries to publish these to Maven Central and other Maven repositories. Then the Apache/Maven Developer plans to push Apache Software Foundation to require reproducible builds for all its official Java releases. If you want to help with this effort, you can start publishing buildinfo files with your library, or try rebuilding libraries based on published buildinfo files to test whether there is enough information to reproduce the builds. .hc -- PGP fingerprint: EE66 20C7 136B 0D2C 456C 0A4D E9E2 8DEA 00AA 5556 https://pgp.mit.edu/pks/lookup?op=vindex&search=0xE9E28DEA00AA5556

1 0

Open Source Design Workshop, Brussels, January 31
by sajolida 04 Dec '19

04 Dec '19

The fine folks at Open Source Design are organizing on January 31 a practical workshop on usability testing: https://hsbxl.be/events/byteweek/2020/opensourcedesign/ It will happen in Brussels, 1 day before FOSDEM. >From the author and the description of the workshop I expect it to imply invaluable knowledge for free. Everybody interested in developing or designing usable software but without academic training on usability testing should attend a workshop like this. I'm not sending this email to UX mailing lists on purpose :) -- sajolida Tails — https://tails.boum.org/ UX · Fundraising · Technical

1 0

HSv3 descriptor work in stem
by George Kadianakis 04 Dec '19

04 Dec '19

Hello atagar, I'm starting this thread to ask you questions about stem and the HSv3 work we've been doing over email so that we don't do it over IRC. Here is an initial question: I'm working on HSv3 descriptor encoding, and I'm trying to understand how `_descriptor_content()` works. In particular, I want to compute the signature of a descriptor, but I see that `descriptor_content()` fills it with random bytes in all the `content()` methods I managed to find: ('signature', _random_crypto_blob('SIGNATURE')), What's the right way to compute the signature for such objects? In particular, I would need a method that first generates the whole descriptor body, and then computes the signature of that with a given private key. Can I use `_descriptor_content()` to do that? Or should I call `_descriptor_content()` to generate the whole thing _without_ the sig, and then do the signature computation on its result and concatenate it after? Thanks! :)

3 10

Practracker regen in #30381
by teor 28 Nov '19

28 Nov '19

Hi George, David, It looks like you regenerated the whole practracker file in #30381: https://trac.torproject.org/projects/tor/ticket/30381 https://github.com/torproject/tor/commit/53ac9a9a91a8f2ab45c755504567160749… But we usually just add exceptions for the files that we modified. When we do a full regeneration, we lose a whole lot of warnings that tell us where our code quality is getting worse. Do you mind if I revert the unrelated changes? T -- teor ----------------------------------------------------------------------

3 4

Proposal 271 - improvements
by Florentin Rochet 26 Nov '19

26 Nov '19

Hello, I'm doing research on improving Tor security via path selection. This work is with Ryan Wails, Aaron Johnson, Prateek Mittal, and Olivier Pereira. In our work, we ran into load-balancing problems that affected our experiments. We identified the problem to originate in the specification and implementation of Proposal 271, "Another algorithm for guard selection", which was implemented in tor-0.3.0.1-alpha ~2 years ago and is thus now in tor stable. In short, Prop 271 causes guards to be selected with probabilities different than their weights due to the way it samples many guards and then chooses primary guards from that sample. We are suggesting a straightforward fix to the problem, which is, roughly speaking, to choose primary guards in the order in which they were sampled. We have created a patch implementing this fix for the case affecting our experiments, which would improve the current situation. We are further suggesting that Tor apply the technique throughout the guard-selection logic. In more detail, Prop 271 chooses guards via a multi-step process: 1. It chooses 20 distinct guards (and sometimes more) by sampling without replacement with probability proportional to consensus weight. 2. It produces two subsets of the sample: (1) "filtered" guards, which are guards that satisfy various torrc constraints, and (2) "confirmed" guards, which are guards through which a circuit has been constructed. 3. The "primary" guards (i.e. the actual guards used for circuits) are chosen from the confirmed and filtered subsets. I'm ignoring the additional "usable" subsets for clarity. This description is based on Section 4.6 of the specification (https://gitweb.torproject.org/torspec.git/tree/guard-spec.txt) The primary guards are selected uniformly at random from the filtered guards when no confirmed guards exist. No confirmed guards appear to exist until some primary guards have been selected, and so when Tor is started the first time the primary guards always come only from the filtered set. The uniformly-random selection causes a bias in primary-guard selection away from consensus weights and towards a more uniform selection of guards. As just an example of the problem, if there were only 20 guards in the network, the sampled set would be all guards and primary guard selection would be entirely uniformly random, ignoring weights entirely. This bias is worse the larger the sampled set is relative to the entire set of guards, and it has a significant effect on Tor simulations, which are typically on smaller networks. We believe that this issue has only a limited effect on Tor currently due to the relatively large number of guards. However, the issue is potentially worse when there exist confirmed guards. In this case, primary guards are chosen from the intersection of confirmed and filtered guards in the order they were added to the confirmed set. That order seems to be the order in which circuits were successfully created through the guards, which would thus be both somewhat non-deterministic (because it depends on when a circuit successfully finishes) and random (because circuits are only attempted through primary guards, which are initially uniformly-random filtered guards). The non-determinism especially could yield guard selection probabilities that deviate quite a bit from the consensus weights. This design has both performance and security implications. It potentially reduces the performance of the Tor network by making the load unbalanced. It also affects the correctness of performance analyses done with Shadow simulations, and the error is likely much larger due to the smaller size of simulation networks, which commonly include 100 or fewer guards. The design also reduces Tor's security by increasing the number of clients that an adversary running small relays can observe. In addition, an adversary has to wait less time than it should after it starts a malicious guard to be chosen by a client. This weakness occurs because the malicious guard only needs to enter the sampled list to have a chance to be chosen as primary, rather than having to wait until all previously-sampled guards have already expired. We propose a solution that fits well within the existing guard-selection algorithm. Our solution is to select primary guards in the order they were sampled. This ordering should be applied after the filtering and/or confirmed guard sets are constructed as normal. That is, primary guards should be selected from the filtered guards (if no guards are both confirmed and filtered) or from the set of confirmed and filtered guards (if such guards exist) in the order they were initially sampled. This solution guarantees that each primary guard is selected (without replacement) from all guards with a probability that is proportional to its consensus weight. We include a patch that applies this ordering only when primary guards are selected from filtered guards. This fixes the problem in Shadow simulations because confirmed guards never exist when primary guards are being selected. However, to solve all issues in the real Tor network, we recommend that you apply similar logic to the case that primary guards are selected from confirmed guards. Note that the issue of sampling skewing guard selection seems to have been raised in proposal discussions, which is documented in the proposal (although the proposed solution is less practical): > [Paul Syverson in a conversation at the Wilmington Meeting 2017 says that > we should look into how we're doing this sampling. Essentially, his > concern is that, since we are sampling by bandwidth at first (when we > choose the `sampled` set), then later there is another bias—when trying to > build circuits (and hence marking guards as confirmed) we select those > which completed a usable circuit first (and hence have the lowest > latency)—that this sort of "doubly skewed" selection may "snub" some > low-consensus-weight guards and leave them unused completely. Thus the > issue is primarily that we're not allocating network resources > efficiently. Mine and Nick's guard algorithm simulation code never > checked what percentage of possible guards the algorithm reasonably > allowed clients to use; this would be an interesting thing to check in > simulation at some point. If it does turn out to be a problem, Paul's > intuition for a fix is to select uniformly at random to obtain the > `sampled` set, then weight by bandwidth when trying to build circuits and > marking guards as confirmed. —isis] Best, Florentin

3 3

introduce some customization on the tbb
by sarpedon montecarlo 21 Nov '19

21 Nov '19

Hello to the community! my first question is that is there a solution for rapid development of tbb? i was wondering that each time a contributor wants to change something in the tbb or add extra functionality, they have to go through the build process which i just guess would be very time consuming. i was wondering that is there any containerized environment for this? any docker ecosystem available or other solutions that might help? my second question is about the changes that i want to implement. i am interested into the graphical settings page about bridges and tor process that currently tbb is exposing to the end users. if we want to add more functionality into this settings page, where should we start to change? and is there any possibility that we may have some control over the underlying tor process as well, for instance controlling it's launching or it's torrc configuration; because as i see, there must be a link between the graphical interface of tbb and the underlying tor process so that is the way we can control bridges for instance. similar to this i was planning to add more graphical options to the interface for controlling other configuration aspects of the tor process through it's torrc or other workarounds. in the past i have achieved this by writing a browser extension that benefits from native messaging for communication to the tor process; but this is not really performance friendly and an intuitive experience for the end users.i am not satisfied with the result. so i was interested on mirroring these functionalities inside tbb. i really appreciate your insights and thoughts on the matter, have a great day, Sarpedon.

3 5

转发： Which elliptic curve Tor use & use safe curve only
by Tom255 21 Nov '19

21 Nov '19

Please use Ed448-Goldilocks or named Curve448 (suggest) and Curve25519 only. Curve448 potentially offering 224 bits of security, even safer than NIST P-384. Curve25519 potentially offering 128 bits of security and safer and faster than NIST P-256. More important, they're both ECC Security, not only ECDLP Security. ECC Security doesn't equal to ECDLP Security. " Unfortunately, there is a gap between ECDLP difficulty and ECC security. None of these standards do a good job of ensuring ECC security. There are many attacks that break real-world ECC without solving ECDLP. The core problem is that if you implement the standard curves, chances are you're doing it wrong: -Your implementation produces incorrect results for some rare curve points. -Your implementation leaks secret data when the input isn't a curve point. -Your implementation leaks secret data through branch timing. -Your implementation leaks secret data through cache timing. " (https://safecurves.cr.yp.to/) And those curves are recommended by RFC 7748: https://tools.ietf.org/html/rfc7748 If possible, use Curve448 only. It's even safer than NIST P-384 and it's new.

1 0

torsocks configure bug (uClibc, maybe other nonstandard libcs)
by akater 14 Nov '19

14 Nov '19

In torsocks' configure.ac, libc_name is determined by means of ldd /usr/bin/yes which is then grepped for libc. On a uClibc system I use, ldd /usr/bin/yes yields two entries, namely libc.so.0 => ... ld64-uClibc.so.0 => ... The resulting string begins with quotation mark, ends with quotation mark and contains newline character. At some point during the configuration process (I have not figured out when exactly), the aforementioned string is trimmed erroneously. In my case, the first line is left out and the second one is discarded. The remaining chunk, with the opening quotation mark but without the closing one, ends up in another configuration file, producing a line like SOME_VARIABLE="libc.so.0 without the closing quotation mark. Build cannot proceed from there. The libc determination process thus needs to be fixed. My hotfix was to change grep 'libc\.' to grep '\slibc\.' but I can't suggest the proper solution as I'm not experienced with shell scripts. I will perform a test if provided with (a link to) a relevant standalone patch for torsocks-2.2.0 or torsocks-2.3.0.

2 1

Acceptable clock skew in tor 0.4.1
by intrigeri 14 Nov '19

14 Nov '19

Hi, recently, tor has become more tolerant to skewed system clocks; great, thanks! At Tails, we would like to take advantage of these improvements in order to remove as much as we can of our not-quite-safe clock fixing code. Our testing suggests that: - A ±24h clock skew is now acceptable in most cases¹: tor bootstraps successfully. - While with a ±48h clock skew, tor fails to bootstrap. Could someone on the network team please confirm that these empirical results match what the code is currently supposed to do? Thanks in advance! [1] In some corner cases I see weird behavior (#32438). And obfs4proxy is stricter than that, which I should report on Trac. Cheers, -- intrigeri

3 2

[paper] Breaking and (Partially) Fixing Provably Secure Onion Routing
by Eugen Leitl 05 Nov '19

05 Nov '19

https://arxiv.org/abs/1910.13772 Breaking and (Partially) Fixing Provably Secure Onion Routing Christiane Kuhn, Martin Beck, Thorsten Strufe (Submitted on 30 Oct 2019) After several years of research on onion routing, Camenisch and Lysyanskaya, in an attempt at rigorous analysis, defined an ideal functionality in the universal composability model, together with properties that protocols have to meet to achieve provable security. A whole family of systems based their security proofs on this work. However, analyzing HORNET and Sphinx, two instances from this family, we show that this proof strategy is broken. We discover a previously unknown vulnerability that breaks anonymity completely, and explain a known one. Both should not exist if privacy is proven correctly. In this work, we analyze and fix the proof strategy used for this family of systems. After proving the efficacy of the ideal functionality, we show how the original properties are flawed and suggest improved, effective properties in their place. Finally, we discover another common mistake in the proofs. We demonstrate how to avoid it by showing our improved properties for one protocol, thus partially fixing the family of provably secure onion routing protocols. Subjects: Cryptography and Security (cs.CR) Cite as: arXiv:1910.13772 [cs.CR] (or arXiv:1910.13772v1 [cs.CR] for this version)

1 0