tor-dev

tor-dev@lists.torproject.org

3589 discussions

Start a nNew thread

(no subject)
by vignesh kannan 26 Sep '19

26 Sep '19

Please sent me a video that how to get dark web please

3 3

(no subject)
by vignesh kannan 26 Sep '19

26 Sep '19

What should I do

1 0

(no subject)
by vignesh kannan 26 Sep '19

26 Sep '19

Okay

1 0

Counter Galois Onion: A New Proposal for Forward-Secure Relay Cryptography
by Jean Paul Degabriele 23 Sep '19

23 Sep '19

Hello tor-devs, Martijn Stam and myself have previously worked on analysing the security of proposal 261. Together with Martijn's PhD student, Alessandro Melloni, we have now written a proposal for an onion encryption scheme as an alternative to Proposals 261 and 295. It builds on the GCM-RUP construction from [ADL17] but it offers a number of improvements over proposal 295. In addition to addressing the issues described below we expect it to offer better performance. We are currently working on a security proof and potential efficiency optimisations for this scheme. In the meantime, we would be very happy to hear what you think and any feedback you may have. If something is unclear, please let us know. Best, Martijn, Alessandro, and Jean Paul --------------------- In our assessment of proposal 295 we identified the following issues: a) Improper use of the universal hash function. The proposal suggested using GHASH, a universal hash function, to compute the digest. Universal hash functions require their input to be independent of the hash key for security to hold. This is also a basic requirement in the tweakable block cipher construction, underlying the PIV and RUP constructions. However, the construction requires feeding back the digest (which is key-dependent) back into the input of the hash. Note that such feedback was not present in [ADL17] and the security proof breaks down with this modification. b) Lack of Forward Security for any type of hash function that is used. If instantiated with GHASH, proposal 295 does not provide forward security (as it is easy to invert given the hash key). The designers suggested (on the Tor dev mailing list) that forward security could be achieved by instantiating the hash function with SHA2 or SHAKE instead. Clearly this degrades the efficiency of the scheme but, as we argue below, it still does not suffice to achieve forward security Specifically, even if the hash function is instantiated with an ideal hash function (a random oracle), the construction succumbs to the following attack. Assume that the last OR in a circuit of length n has already processed some cells and that its current state is (Kf_n, Kb_n, Ktf_n, Ktb_n, Khf_n, Khb_n, Tf'_n, Tf'_{n+1}, Tb'_n, Tb'_{n+1}). An adversary, who has collected previous ciphertexts and nonces (C, N), then corrupts it. The adversary has enough information to recover the last message received by OR_n, which it computes as follows: N_{n+1} = Tf'_n ^ D(Ktf_n, Tf'_n ^ N_n) M = Decrypt(Kf_n, N_{n+1}, C_n). Clearly this breaks forward security, and it is enabled by the fact that the current digest needs to be saved for computing the next digest for when another ciphertext is received. [ADL17] Tomer Ashur, Orr Dunkelman, Atul Luykx, "Boosting Authenticated Encryption Robustness with Minimal Modifications", CRYPTO 2017.

3 3

Timing of opening pre-emptive circuits?
by Jeremy Rand 20 Sep '19

20 Sep '19

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi Tor-Dev, I'm curious what the timing is of Tor's opening of preemptive circuits. Specifically, consider the following attack: 1. A new stream is assigned to a clean circuit. 2. Because of the above, that clean circuit is now a dirty circuit. 3. Because of the above, the number of clean circuits is now decreased by 1. 4. Because of the above, the number of clean circuits is now lower than the number that Tor wants to have open. 5. Because of the above, Tor opens a new preemptive circuit. 6. An attacker who can observe the circuit in (1) and the circuit in (5) can deduce by temporal proximity that those 2 circuits belong to the same client. This attack seemed obvious enough to me that I assumed that Tor must have some kind of countermeasure to it, e.g. random delays in opening preemptive circuits. However, the tor-path specification doesn't mention any such countermeasure, and based on a brief search through the Tor source code, all I can find is that Tor opens preemptive circuits using a function that always gets called once per second (with no mention of any delay beyond that one-second interval, random or otherwise). So, does Tor make any effort to mitigate the above attack? If so, what mitigations are present, and where would I find them (in both the spec and the source code)? If not, is there any documented reason (e.g. "the attack is too hard to pull off" or "we want to mitigate it but haven't gotten to it yet") for the lack of mitigation? 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. -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEVB3fdzAraEcoBtkSs/LRZXhtZXAFAl2CoycACgkQs/LRZXht ZXDyjhAAk3F6fJUvNl4FHws6IIBHWXby/zC7MLzr9zR3sIC3RY4f/I7XBDTKKfMg iOehJlBEksm5sRz6nlybUBivsJ0WRL8VCT3rEK3+LQM7JrYNvGajolEw2apBUeB3 +Vg+Quo5JzTZrjCtXljxdps/hhC1YwEyN6pxxn2137q4XAsRPQgSCcWpsBuDTffb LFRwyGrNxk6chbpQc0GIWQRoeElxFwaLbUrZdGtaaEjBXY2oWoan1TUB34MAVNzF 1o6DlaO2JQ7weHVHoXlTlXS7gt84/WyY0xaHUY9ONHwrhgDPGv3N5+Fa2Em+PvGx ik+4iSCzPf6aKY0iUv1AsWKiaq8rRsMToyNzNZ048uYHk2IK2Zrbqh4Nm44RTzKD 84tJU71calRdNhbwuvmgsYKh26Ad9ALf9BzDeiweA3c5ZP0JP0OlLcAN9c056WT3 FQbChA1edZkWkPvBjGtl4l7ROIx6wkNpWgaQsYUCMveszB2Rm38BQw5sYLh8i6ha AlT3UVs/GJscSSsfmHGrTisao444Etp4J/+SFe1aNJwfOogbEfgJ1jRf8V5dlYEb rcicgkwmnBf01vnVaUO9C6/lToUa9i7r3BD3s6OQW24qz2ixieS3K6NxxxqMrVQ1 vFArleJIYA/FsDM2NPbeaUQA9z5GJj5X3FcPUPLLF+y5G/0HE14= =aBRL -----END PGP SIGNATURE-----

2 2

reproducible builds for Android tor daemon
by Hans-Christoph Steiner 17 Sep '19

17 Sep '19

Hey all, I'm currently working on tor for Android as part of a Guardian Project project. One key goal is making a shareable, reproducible build process for the tor daemon for Android. Then this would be published to MavenCentral as an Android AAR package to be used in all the apps that include tor (Tor Browser, Orbot, Briar, Thali, etc). I have cleaned up the existing build process a lot, so now I'm down to troubleshooting reproducible issues. First off, can anyone see any objections to switching Tor Browser, Orbot, Briar, etc. to use GPG-signed reproducible binaries via MavenCentral for the tor dameon? Second, I'd welcome pointers to the integration points in Tor Browser, Briar, etc. And third, and tips on getting a Linux shared library to build reproducibly. E.g. is faketime a hard requirement? And for those interested, the here's an overview of the whole project I'm tasked with: The basic idea is to make an Android-native TorService, which is a subclass of android.app.Service and loads tor daemon as a shared library, and starts it via JNI methods. This should be pretty close to how iOS apps use tor. Then that TorService should then plug into Orbot, Tor Browser, Briar, etc. Then based on that, I'll make a standalone, dead simple "TorServices" app that only provides Tor. No PTs, HSs, etc., just a tor daemon linked in as a shared library, providing a SOCKS and HTTP CONNECT proxy via tor. I hope to switch the ControlPort to use a UNIX domain socket. This then can also be embedded into Android OS ROMs that want to have Tor built-in as a system service, like CalyxOS. Then I'll be working on the apps choosing which tor provider to use, since we'll have a new TorServices, so apps that don't include Tor will have to figure out how to use Orbot and/or TorServices. Then that work will hopefully be extended into sharing tor between apps, e.g. letting Briar, Tor Browser, etc share the tor SOCKS proxy to other apps that want to use it. That would happen via Android mechanisms like Intents to manage the discovery of SOCKS ports. .hc -- PGP fingerprint: EE66 20C7 136B 0D2C 456C 0A4D E9E2 8DEA 00AA 5556 https://pgp.mit.edu/pks/lookup?op=vindex&search=0xE9E28DEA00AA5556

8 11

New Orbot, tor-android and AndroidPluggableTransport updates
by Nathan Freitas 17 Sep '19

17 Sep '19

A new Orbot is out, with a bug fix related to obfs4proxy installation, and a new tor! We've also updated the tor-android library, with the latest 0.4.1.5 release, and all is working well. https://github.com/guardianproject/tor-android/releases/tag/tor-android-bin… and we updated our AndroidPluggableTransports library, which was at the root of our "Orbot Bridge" bug, not properly installing the binary from the APK bundle. https://github.com/guardianproject/AndroidPluggableTransports/releases/tag/… These libraries and versions are available via our Guardian Project gradle/maven repo hosted on Github: maven { url "https://raw.githubusercontent.com/guardianproject/gpmaven/master" } implementation 'org.torproject:tor-android-binary:0.4.1.5-rc' implementation 'info.pluggabletransports.aptds:apt-dispatch-library:1.0.7' implementation 'info.pluggabletransports.aptds:apt-meek-obfs4-legacy:1.0.7' Everything is building again in our CI pipeline here: https://gitlab.com/guardianproject/orbot/pipelines and we nearly have automated on-device testing working via the cloud services Bitbar and/or Browserstack. Life is good, again. +n -------- Forwarded Message -------- Subject: Orbot 16.1.2 RC-2 with tor-0.4.1.5-rc Date: Tue, 10 Sep 2019 00:42:56 -0400 From: Nathan of Guardian <nathan(a)guardianproject.info> Organisation: Guardian Project To: Guardian Dev <guardian-dev(a)lists.mayfirst.org> Orbot 16.1.2-RC-2-tor-0.4.1.5-rc https://github.com/guardianproject/orbot/releases/tag/16.1.2-RC-2-tor-0.4.1… * Found and fixed bug related to bridges not working (https://github.com/guardianproject/orbot/issues/242) * Updated tor to 0.4.1.5 ARM64 APK: https://github.com/guardianproject/orbot/releases/download/16.1.2-RC-2-tor-… ARMEABI APK: https://github.com/guardianproject/orbot/releases/download/16.1.2-RC-2-tor-… @n8fr8 n8fr8 released this 5 minutes ago · 0 commits to master since this release c2e679d (HEAD -> master, tag: 16.1.2-RC-2-tor-0.4.1.5-rc) update to 16.1.2-RC-2-tor-0.4.1.5-rc 1d45a3d update APT Pluggable Transport library to 1.0.7 - this should fix one issue with installing the correct ofbs4proxy binary - also small changes to ensure no lock states and reduce log noise efec61d (tag: 16.1.2-RC-1-tor-0.4.0.4-rc, newport/master) update to 16.1.2-RC-1-tor-0.4.0.4-rc 237b388 yet another attempt at fixing the phantom zulu locale bug! a9efc3c disable tests for now in CI build 918bcca (origin/master, origin/HEAD) remove unused layouts for app-mini 08b670f update paths for app-mini code cefac58 putting classes back into main app package, and not "mini" 97d2aac improvements for bridge handling for #242 0e40c07 update badvpn tun2socks library 034844a remove fileprovider from app-mini since it is used just for HS d95f197 make keystore props reading not fail if not present d0640c6 remove output from repo e8f3158 remove binaries from repo 5845a4c update build tools to 29 003d9ea update build tools to 29 9c6de06 update build tools to 29 a266c65 add new functionality to allow for checking connections against app blacklist d98e5fb update changelog for 16.1.1-BETA-2-tor-0.4.0.4-rc-orbotservice Assets 6 Orbot-16.1.2-RC-2-tor-0.4.1.5-rc-fullperm-arm64-v8a-release.apk 10.3 MB Orbot-16.1.2-RC-2-tor-0.4.1.5-rc-fullperm-arm64-v8a-release.apk.asc 833 Bytes Orbot-16.1.2-RC-2-tor-0.4.1.5-rc-fullperm-armeabi-v7a-release.apk 9.94 MB Orbot-16.1.2-RC-2-tor-0.4.1.5-rc-fullperm-armeabi-v7a-release.apk.asc 833 Bytes

2 2

Network team: New status page for 0.4.2; feature freeze; want to work on any tickets?
by Nick Mathewson 16 Sep '19

16 Sep '19

Hi! This mail is mainly for the network-team folks, but I'm sending it to tor-dev anyway in case it's helpful to anybody else. I've made a new page for our 0.4.2 status, based on Teor's original 040 status page. Here it is: https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam/CoreTor… Note that as with 0.4.1, I'm using two different keywords: 042-must and 042-should. The difference here is that 042-must stuff should be things that would really block a release candidate, whereas 042-should stuff is stuff that we might in theory release without fixing. (It might annoy our users or violate our best practices, so we _should_ try to fix it, at least.) At the bottom of the page are all the tickets in the milestone that are *not* marked 042-must or 042-should. Some of these are things we could still fix anyway in 042; many will be removed. Please label them soon if you think they are things we should fix in 0.4.2! We are now in feature-freeze for 0.4.2.x. Let's try to solve our open 0.4.2.x issues soon, so that we can move on to 0.4.3.x. Most of the 042-must and 042-should issues are currently unassigned, so if there are any you would like to work on, please either assign them to yourself, or bring them up at the next team meeting? cheers, -- Nick

1 0

Preferred compression type?
by Steve Snyder 13 Sep '19

13 Sep '19

Given the multiple compression types supported (none, lzma, zlib, zstd), what is the order of preference for runtime use? Put another way, which compression method(s) should be supported to get optimal runtime performance from a Tor node? Thanks.

2 2

Compile warns
by grarpamp 12 Sep '19

12 Sep '19

freebsd 12 x64 gcc 8.3.0 src/core/or/connection_edge.c:2563:5: warning: potential null pointer dereference [-Wnull-dereference] src/lib/math/fp.c:106:16: warning: conversion from 'double' to 'float' may change value [-Wfloat-conversion] src/lib/math/fp.c:111:18: warning: conversion from 'double' to 'float' may change value [-Wfloat-conversion] src/lib/math/fp.c:136:16: warning: conversion from 'double' to 'float' may change value [-Wfloat-conversion] src/lib/math/fp.c:88:13: warning: conversion from 'double' to 'float' may change value [-Wfloat-conversion]

3 5

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-dev