Hi everyone tor devel!
I would like to know more information about last_restarted information.
- It's possibile to forge this kind of data or is somehow certified by the tor network?
Sometime, while sampling hourly some data by onionoo i've noticed some difference in the uptime by + or - a few seconds in this value.
- Any idea of how this is possible?!
- In which file do i find the code that handle this value?
Thank you!
Invita i tuoi amici e Tiscali ti premia! Il consiglio di un amico …
[View More]vale più di uno spot in TV. Per ogni nuovo abbonato 30 € di premio per te e per lui! Un amico al mese e parli e navighi sempre gratis: http://freelosophy.tiscali.it/
[View Less]
I have made a design and written some code for an email-based
registration system for flash proxy clients. Registration is the process
by which a censored client sends its IP address to request service from
an external proxy.
In summary, a censored client sends its address in encrypted email over
SMTP over TLS to a distinguished email address. A program running on the
flash proxy facilitator makes an IMAP connection over TLS, polls for
messages, then decrypts them and registers the addresses …
[View More]withing. The
email messages are sent by a registration helper program, not the
client's own email account, and they appear to come from a dummy
address. More information is in the ticket:
https://trac.torproject.org/projects/tor/ticket/6383#comment:5
I would appreciate a second look at the design, especially the use of
crypto. The ticket's comment number 5 calls out some particular
features.
This is our first registration system with a claim to being hard to
block. This is step 1 that goes through the firewall in the diagram at
http://crypto.stanford.edu/flashproxy/#how-it-works. The censor sees a
TLS session with a Gmail MX server, followed later by an incoming
connection from a flash proxy at a previously unseen IP address. What
makes this different than other circumvention ideas is that nothing is
sent directly to any published or unpublished Tor relay.
David Fifield
[View Less]
Note that this scheme is not quite safe to implement with Ed25519 or
other DSA-like signature schemes as described; the base point needs to
be multiplied by the same number as the public-key group element.
---------- Forwarded message ----------
From: Robert Ransom <rransom.8774(a)gmail.com>
Date: Wed, 19 Jan 2011 08:42:40 -0800
Subject: New HS protocol
To: Kadianakis George <desnacked(a)gmail.com>
Cc: [redacted], [redacted], tor-assistants(a)torproject.org
I wrote up the …
[View More]following new HS protocol on 2011-01-13, but haven't
sent it out anywhere publicly visible yet.
The only system I have come up with to hide a hidserv's identity key
from the directory servers requires that the hidserv use a discrete-log
cryptosystem for its identity key, and that the HS address contain
enough of the identity key that a client can compute a scalar multiple
of the identity key. (For example, the identity key can be a point on
an elliptic curve in Weierstrass form, and the HS address can be the
point's x coordinate.)
The system designer chooses a group, an element P of prime order p in
that group, and a publicly computable one-way function h mapping
bitstrings to integers in the interval [1, p-1].
The HS chooses a secret key n and computes its public key nP; its
descriptor index in time period t can be computed by any party which
knows its public key as h(t | nP)*nP, but only the HS will know the
discrete logarithm h(t | nP)*n of the descriptor index with base P.
The HS can therefore compute an ECDSA signature, for example, which the
directory server can verify using the descriptor index as a public key.
Robert Ransom
[View Less]
Somehow in August, Italy got a few thousand additional Tor users and
became third as far as usage of Tor:
> https://metrics.torproject.org/users.html?graph=direct-users&country=it#dir…
> Country Mean daily users
> United States 60769 (14.30 %)
> Iran 43709 (10.28 %)
> Italy 37306 (8.78 %)
> Germany 36672 (8.63 %)
Any insight?
--SiNA
Hi, all!
>From https://trac.torproject.org/projects/tor/wiki/org/roadmaps/Tor/024 :
"October 10, 2012: Big feature proposal checkpoint. Any large
complicated feature which requires a design proposal must have its
first design proposal draft by this date."
There are only 23 days till October 10. If there's something you want
in 0.2.4.x, and it is the kind of thing that needs a design proposal,
and there is no proposal yet, it could be time to start writing!
What needs a design proposal? …
[View More]Generally: anything that involves a
change to the Tor protocol; anything whose security implications are
nontrivial and need discussion; and anything that will change any Tor
specification. Err on the side of "it needs a proposal."
What is a "large complicated feature"? Please assume I'm going to be
extremely grumpy here, and err on the side of "it is big". If the
writeup of the proposal that explains how it works, or why to do it
this way is going to take more than a few paragraphs, it is probably
'big' or 'complex'.
(Note to would-be system-gamers: Please don't send a sketchy
incomplete draft as a placeholder to get your foot in the door. That's
not cool. If you don't have a draft ready, the feature can wait till
0.2.5.)
(Note also: a feature proposal by this deadline is a necessary
condition for getting your big/tricky/complicated feature into 0.2.4,
but not a sufficient condition. It also needs to have a working
implementation on schedule.)
(Note finally: This is not a promise to not merge stuff that violates
this deadline, but I sure will be trying not to merge such stuff.)
yrs,
--
Nick
[View Less]
Hi Nick,
I've revised the DNS draft, attaching it. In section 4 there are some options
for integration with libunbound, but each of them requires some work with the
stock libunbound code.
Ondrej
> Damian,
>
> I saw on the tor-dev mailing list you would be happy to have help with
> Python related Tor work. I'm game. I'd love to help the Tor Project.
Hi Scott. Glad you want to help! These are great questions so I'm
looping in Ravi (another developer who's actively hacking on stem) and
tor-dev in case other people are interested.
> I looked through the Easy bugs for Arm but it seems that Stem is where the
> effort is going now.
Yup. Arm was experiencing really bad …
[View More]feature creep so I swapped my
focus to stem around a year back. Here's the relevant links for
stem...
* Development Wiki
https://trac.torproject.org/projects/tor/wiki/doc/stem
* Gitweb
https://gitweb.torproject.org/stem.git
* Bug Tracker
http://tinyurl.com/stem-bugs
> Should I focus on Stem?
> Do you have a list of easier tasks to get my feet wet with?
Sure! We're currently working to make it feature complete and prepare
for its initial release. Development tasks tend to fall into a few
general categories...
===================
Controller Functionality
===================
Stem is primarily a replacement for TorCtl, a controller library used
by several of our other projects (arm, SoaT, TorBEL, etc). Ravi's been
focusing on making the Controller class feature complete. This is
mostly located in...
https://gitweb.torproject.org/stem.git/blob/HEAD:/stem/control.py
Some nice introductory tasks here would be...
* Add methods for querying relay descriptors
The first bits of this is very easy, while the later parts get a bit
more interesting...
- Add a get_relay() method that calls
get_info("desc/id/[fingerprint]") then return a ServerDescriptor for
it.
- Write unit and integ tests for the addition.
- [tricky part] Add a get_all_relays() method that provides an
iterator for all of the descriptors. The tricky bit is that the
BaseController provides discrete controller messages, but in this case
the "GETINFO desc/all" output is so large that we want to process it
while it comes in. This means changing stem's underlying message
processing system.
* Split low and high level controller methods
The Controller class is growing to be pretty bulky, and its methods
can generally be split into two categories...
- Low level methods that simply mirror what the control-spec provides.
- Higher level methods (like the get_relay() and get_all_relays()
above) which are more user friendly and build on what the control spec
provides.
Ravi: Do you have any thoughts on this? Do you think this would be a
good way to break up the controller, or would this just make it more
confusing? Alternatively we could wait until we try using stem in arm
to see if this makes sense or not...
===============
Descriptor Parsing
===============
This is where my focus has been for the last couple weeks. A
controller needs to be able to parse Tor's descriptor content
(GETINFO's desc, ns, and md responses). This has expanded to include
file descriptors and other descriptor content, so stem can be used as
a python replacement for MetricsLib. This is useful for projects like
Onionoo's python counterpart.
This is a somewhat dry part of stem to work on, so unless you like
reading specs and writing a parser for them this might not be a great
section to work on. That said, if detail oriented parsing and
validation sounds interesting then there's lots 'o tasks here.
======
Clients
======
Stem doesn't yet have any clients, and will certainly need some before
we make a release in order to work out the kinks. Our plan for this
is...
* Port arm's interpretor
Arm's control interpretor is actually a standalone script that can,
with a little work, be used independently from the rest of arm. It
would be interesting to see what an stem based control interpretor
would look like...
* Port arm's torTools module
Arm makes very heavy use of the controller, and abstracts all of its
TorCtl usage behind a wrapper module...
https://gitweb.torproject.org/arm.git/blob/HEAD:/src/util/torTools.py
This abstraction should make arm reasonably easy to move to stem.
Also, stem's getting many of that wrapper's features so arm's codebase
could be greatly simplified after we move.
* Port TorBEL
TorBEL would be a great candidate after we work out most of stem's
rough edges by moving arm. It'll likely provide some interesting use
cases, though this is still a ways out.
=======
Usability
=======
Stem doesn't yet have a site, nor have I posted its sphinx
documentation anywhere. A few things that we should do here is...
* Make a pretty site
Ideally I'd like to write the site itself with sphinx so we have a
consistent look between the front page and the documentation.
* Site with auto-updating documentation
This would involve setting up a site with a cron process that fetches
stem and, if changed, serves up the new documentation.
* Tidy up sphinx docs
Stem has a lot of documentation, but we haven't really looked much at
the sphinx output with an eye for making it developer friendly. It
would be nice to have people try to use stem, and improve the
documentation for the confusing bits.
* Examples
We should ask tor-dev@ for a list of bite sized Tor tasks that people
commonly want (like "print my relay's bandwidth" or "list all of the
relays with the BadExit flag"). Then write example scripts that do
this, and provide them on stem's site to give example usage.
> If so, how hard is it to set up a dev environment?
Very, very easy. Assuming that you have python, git, and tor installed
simply do the following.
* Get a copy of stem
git clone git://git.torproject.org/stem.git
* To run its unit tests
cd stem
./run_tests.py --unit
* To run its integ tests
./run_tests.py --integ
> Does the Tor Project have a formal mentorship program? How does that work?
I'm not sure what you mean by a 'formal mentorship program'. I've
mentored students through GSoC and Wesleyan's open source program if
that answers your question.
Cheers! -Damian
[View Less]
Hello tor-dev!
I would like to contribute to the torouter (aka TorRouter, aka OnionBox?)
project, with the intention of getting a "functional" development image
for the DreamPlug hardware released in the next few weeks.
The goals of the torouter project seem a bit vague (especially w/r/t a
transparent torified WiFi access point), perhaps this is why development
slowed down previously. I will attempt a design document and
specification, but mostly focus on making the core components (…
[View More]debian,
tor, web interface) functional and configurable, such that they could be
leveraged by others as solutions to specific use cases. Will this be
useful to others?
It seems like the preferred collaboration tool is the trac wiki and
tickets. Many of the torouter tickets seem stale and incomplete, and the
roadmap on the trac wiki is very out of date. Unless there is advice i'll
ignore those but continue discussion on tickets like #3854 (Summary of
outstanding things with Torouter) and #3453 (Torouter desires and
features).
cheers!
[View Less]
Following my email to this list, dated 29/07/2012, I direct your
attention to the IACR eprint document http://eprint.iacr.org/2012/494,
"Format-Transforming Encryption: More than Meets the DPI". In it, we
present our framework for steganographic encoding of messages using
regular languages, along with initial findings for a Python/C++ based
implementation.
To briefly highlight some of the main things we deliver:
* A record-layer, powered by format-transforming encryption, that can
tunnel …
[View More]arbitrary SOCKS streams.
* Algorithms that allow efficient and invertible mapping between bit
strings and elements of a regular language L. These allow us to encode
traditional encryptions of plaintexts into strings from L in a way
that maximizes the number of bits that are encoded.
* A framework for the creation of good regular languages, "good" with
respect to performance and security. In particular, our
language-learning framework produces sets of regular expressions
(compact representations of the languages) that are learned from real
traffic. Our system also allows you to use off-the-shelf regular
expressions, like those from appid [1] and l7-filter [2] that are
designed to detect HTTP traffic.
We consider this preliminary technical report on a work-in-progress.
In fact, we can already do more than what is reported (e.g. greater
variety of languages, better system performance), but we will save
these advances for a future release.
Cheers,
Kevin P Dyer (and his co-authors)
[1] http://code.google.com/p/appid/
[2] http://l7-filter.sourceforge.net/
[View Less]
Hello,
the current integration has a lot open issues and feature requests. [2]
Because there might come a proposal [1] to solve this cleanly, I created
an overview of all related open issues. [2] There are just so many
issues I though it makes sense to create an overview so nothing gets
forgotten. Feel free to edit/correct/expand the wiki site. Add your wishes.
I cc'ed all effected people, if someone has been forgotten, feel free to
forward this mail.
Can we have this discussion on tor-dev?
…
[View More]
Cheers,
adrelanos
[1] https://trac.torproject.org/projects/tor/ticket/5611#comment:43
[2] https://trac.torproject.org/projects/tor/wiki/doc/TB
[View Less]