Re: [tor-dev] Prop279 and DNS

[Jesse V]

On 04/03/2017 05:01 PM, Jeremy Rand wrote:
> Maybe this topic has already been brought up, but in case it hasn't,
> I'll do so.  I notice that Prop279 (onion naming API) defines its own
> API rather than using DNS.  I guess that this is because of security
> concerns about the centralization of the DNS.

Hi Jeremy,

I believe that the general idea with prop279 is simply to introduce an
API for resolving pseudo-TLDs before they were sent through the Tor
network. How that is done is entirely dependent on the naming system.

For example, if a user typed in example.bit into a Namecoin-enabled Tor
browser, the software could then perform your proposed DNS lookup and
rewrite the request before turning it over to the tor binary. In my
case, my OnioNS software rewrites .tor to .onion, since the tor binary
knows how to handle .onion. At the moment, this is a bit hacky because
the software has connect with tor's control port, manually review and
process each lookup, rewrite the the request, and then tell tor to
connect it with a circuit. Prop 279 is designed to make this much easier
and avoid hacky solutions.

-- 
Jesse Victors
Developer of the Onion Name System



signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] The behavior of ClientRejectInternalAddresses

[Jesse V]

Hi everyone,

I would like some clarification on ClientRejectInternalAddresses. The
manual says:
> "If true, Tor does not try to fulfill requests to connect to an
internal address (like 127.0.0.1 or 192.168.0.1) unless a exit node is
specifically requested (for example, via a .exit hostname, or a
controller request). (Default: 1)

In other words, if I disable this flag and I open 127.0.0.1:8080 in the
Tor Browser, will the browser or the tor binary attempt to connect to
the client's 127.0.0.1:8080? This is essentially what I'm after, and I
just want to confirm that ClientRejectInternalAddresses is the best
approach, or if there is a better setting. Just to clarify, I want to
connect the client's localhost and not an exit's.

-- 
Jesse



signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] GSoC 17 | Name System API for Tor Onion Services

[Jesse V]

On 03/21/2017 10:54 AM, Pickfire wrote:
> I am Ivan Tham. Currently studying in Computer Science in APIIT Malaysia. I am
> interested particapate in Google Summer of Code 2017 under tor organization. I
> am interested to see Proposal 224 coming along but I would really like to see
> [Proposal 272][0] and hope that tor hidden services can be more user-friendly.
> 
> What do you think of the projects? Is the proposal too immature? I had looked
> into [OnioNS][1] as well and like the idea of having different types of DNS
> records for tor hidden services, how does it integrate with [Proposal 272][0]?
> 
> [0]: https://lists.torproject.org/pipermail/tor-dev/2016-October/011524.html
> [1]: https://lists.torproject.org/pipermail/tor-dev/2015-May/008826.html

Hi Ivan,

I am the author and the main developer behind the Onion Name System
(OnioNS) project, which I see you referenced above. You may be
interested in reading my paper here: [0]. Development is on Github and I
think that I have a very solid codebase, but I haven't commit anything
recently as I've been busy with a full-time job as a pen tester and
various other side projects that have occupied my time.

In my mind, there are a couple of issues that impact naming systems:
1) The SHAttered attack against SHA-1. This certainly affects current
onion services, and I'm personally a hesitant to enhance them with a
naming system, since a SHA-1 collision would undermine the security of
any naming system.
2) Prop224 is in the works and is still being finalized. Since the
addresses are much larger, we certainly want to have a good naming
system by the time it's ready to go, as this also encourages the
transition to the new system. The naming system API ties into this.

I would be very happy if you were to help implement the naming system
API. It's currently possible to redirect the streams by sending commands
to the tor control port, but an API would be much cleaner.

[0]:
https://www.degruyter.com/downloadpdf/j/popets.2017.2017.issue-1/popets-2017-0003/popets-2017-0003.pdf

-- 
Jesse



signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Remaining 4 bits in prop224 addresses

[Jesse V]

On 12/06/2016 11:27 AM, David Goulet wrote:
> We had little discussion but some of us agree for sure on having bits for the
> version number. That will tell a tor client to fetch the right descriptor
> instead of trying all version that have the same type of public key (.onion
> address). We currently have I believe 4 bit left which is only 16 values so we
> could extend to one more byte here so have more room.

I'm curious if we ever ran into this issue with the current HS protocol.
What type of changes would warrant a new address that that could not be
solved with a patch to the tor binary? We also need to consider the
difficulty of distributing a one-character-different address against the
difficulty of transitioning the network to the new descriptors. People
get very entrenched to their onion address, bookmark them, and some even
issue SSL certs for them.

Let's say we added another character, so that we have 9 bits free. Would
would be the consequence of using all 9 bits for a checksum? We could
solve the version/descriptor issue using a naming system and simply
point the name to a newer onion address. It's something to consider.

> Second thing that is possible, like you stated above, is a checksum.
> Unfortunately, I haven't thought much about this nor know the "state of the
> art of small-checksum" but definitely something to dig through! Jessie, if you
> feel like it, I welcome any analysis you can do on checksum here and some
> proposal about it. (Only if you want to :).

I'm not fluent in the arts of small checksums, but it seems to me that
we do have some benefit of using the first N bits of SHA2(version +
edDSA_address) as the checksum. I may not have time to write a full
proposal, but even with a small number of bits we do have a decent
chance of catching typos, which is the whole point. Obviously, this
chance will get better as you add more bytes, but prop224 addresses are
already fairly long and we should weigh the usability impact against the
probability of typos.

-- 
Jesse



signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] Remaining 4 bits in prop224 addresses

[Jesse V]

Hello all,

I've been closely following the other Proposal 224 threads regarding the
next-generation of onion services. I'm glad to see that we have a
timeline and plan for migrating the network. One unresolved point is
what to do with the remaining 4 bits in the longer addresses. Section
1.2 in the 224 document states "Note that since master keys are 32 bytes
long, and 52 bytes of base 32 encoding can hold 260 bits of information,
we have four unused bits in each of these names." It seems a waste for
these to be zeroed out. The four bits could also be used to hold
client-side flags, but I'm not aware of any applicable client settings
that could be used here. I suggest that we use them as a checksum.
(wasn't this proposed in Arlington?)

Since speed isn't a priority, aside from Adler-32 or some CRC function,
we could also hash the 32-byte key and use the first four bits of the
hash.  I think a checksum is best because it helps ensure data integrity
when the address is shared online, copy/pasted, or physically written
down. Bitcoin addresses contain a checksum as well for exactly this
reason. They use a combination of SHA-256 and RIPEMD-160 to compute the
checksum component.
Source:
1)
https://en.bitcoin.it/wiki/Technical_background_of_version_1_Bitcoin_addresses
2) https://bitcoin.stackexchange.com/questions/32353/

What do we think about a checksum, or do we have other plans here? I ask
because once we nail down the address format, I can add support for 224
into my Onion Name System.

-- 
Jesse



signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] prop224: What should we do with torrc options?

[Jesse V]

On 11/23/2016 07:04 PM, Yawning Angel wrote:
> Our fix: "Add another command, that does essentially the same thing,
> because people picked the wrong options, then later deal with the
> fallout from people getting used to the temporary command, and crying
> when it's deprecated."
> 
> I say "they should fix their code".

This issue with incorrect implementations reminds me of the
compatibility issues that cause issues with new SSL/TLS standards. These
implementations led to compatibility workarounds that introduced
security issues that had to be eventually fixed by TLS_FALLBACK_SCSV.

It's not our problem if their code breaks because they made incorrect
assumptions regarding the standard. The polite thing would be to submit
a patch so that Bitcoin nodes can update before we make the change.

--
Jesse



signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Distributed RNG Research

[Jesse V]

On 11/18/2016 10:30 AM, ban...@openmailbox.org wrote:
> New research on Distributed RNGs is published: "Scalable Bias-Resistant
> Distributed Randomness"
> 
> eprint.iacr.org/2016/1067

Nice! There's also https://eprint.iacr.org/2015/1015.pdf, which shows
that you can extract at least 32 bits of entropy from Bitcoin every 10
minutes. I chose this generator for my Onion Name System project.

-- 
Jesse



signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] prop224: What should we do with torrc options?

[Jesse V]

On 11/23/2016 09:39 AM, David Goulet wrote:
> I agree with you on the fact that ADD_ONION is nice and also crucial to hidden
> service as well. That will be addressed with the control port implementation
> of next generation. It's still an undecided part of the engineering work which
> is how we are going to proceed with it. Do we change the current
> events/commands to support both v2 and v3? Do we make new events/commands for
> v3? ... (#20699)

I suggest that we create new commands for v3. This will allow us to
officially deprecate the old APIs and its more intuitive for developers
since the distinction is clearer. This is also a golden opportunity to
change "HiddenServiceX" to "OnionServiceX" if we want to officially
transition the lingo.

-- 
Jesse



signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Joining Tor Project's software infrastructure

[Jesse V]

On 11/14/2016 07:58 AM, Iain R. Learmonth wrote:
> If the software is stable, and reproducibly built, I would aim for placing
> it into the Debian archives. I maintain ooniprobe on deb.torproject.org, but
> primarily for Ubuntu users and I would prefer that Debian users are using
> the version from the Debian archive.
> 
> One issue we run into is that in trying to support older distributions, we
> often then have to take on maintaining backports for various packages and in
> some cases this is a lot of overhead and careful version number management.
> 
> If you wanted to set up your own Debian repository, that would also be an
> alternative solution for the short-term.

This is a really good point, thank you for your suggestion. I will
change my approach and set up a Debian repository that Debian and Ubuntu
users can use. I looked also into adding into Debian. How do you suggest
that I get started with this? It would be great if I could get it into
Debian 8 if possible.

-- 
Jesse



signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Proposal 274: A Name System API for Tor Onion Services

[Jesse V]

On 10/11/2016 12:53 AM, Jeremy Rand wrote:
> It's also worth noting that it's been hard enough to get IETF to accept
> .bit (that effort stalled) -- adding a bunch of other TLD's would
> probably annoy IETF significantly (and destroy whatever good will exists
> at IETF right now), and I fully understand why this would annoy them.
> 
> I'm not really sure what the right mechanism is for a user to specify "I
> want this request to either use TLS or be resolved to a .onion record"
> (which seems to be the primary use case here).  Does anyone have
> suggestions?

As I understand it, the spirit of the naming system API is to resolve
$meaningfulName to $randomAddress.onion. It seems pretty clear its
focused on A records, but the naming system can support subdomains and
CNAME records if it likes. My approach with OnioNS is to simply use a
none-ICANN TLD, which is currently ".tor". There's a Trac ticket on
which TLD I should use, but it seems most intuitive to use something
obvious. Someone suggested that we continue to use .onion, but anything
that isn't 16 chars of base32 should be resolving using the naming
system. That seems like it would be more confusing. A new TLD seems more
intuitive.

-- 
Jesse



signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Proposal 274: A Name System API for Tor Onion Services

[Jesse V]

On 10/08/2016 08:50 AM, 61wxg...@vfemail.net wrote:
> How about specifying whether the Namecoin domain should point to .onion
> or clearnet in the domain?  We can require that TLDs for such service
> must end in either:
> 
> o o: The name points to a .onion name.
> 
> o i: The name points to an IP address.
> 
> o a: The name points to a clearnet domain name.
> 
> So example.zkeyo points to 66tluooeeyni5x6y.onion.  example.zkeyi
> points to 192.0.2.1 or (and?) 2001:db8::1.  example.zkeya points to
> example.com.

I don't think this is in scope of a naming system API. The naming system
probably has its own rules and users should be aware of those rules when
they use the naming system. For example, the Onion Name System (OnioNS)
will likely use ".tor" and I enforce that names must point to either
".tor" or ".onion", thus keeping it all internal. During my trial tests
today, the client code followed a chain until ".onion".

This is an API for onion services, so it doesn't make sense to handle
clearnet TLDs. There are other and easier ways of doing that, such as
alternative DNS roots.

-- 
Jesse



signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Joining Tor Project's software infrastructure

[Jesse V]

On 10/04/2016 03:54 PM, George Kadianakis wrote:
> Hello Jesse,
> 
> glad to hear you are still working on the OnioNS project, and happy to
> hear that the paper got accepted in PoPETS. We have great plans for
> hidden service naming layers, and it's great to see more people working
> on this topic. Thanks for updating the wiki as well.

My pleasure. I'm looking forward to see what you guys have in store.

> FWIW, I feel that using Github (or any other third-party git) for code
> hosting and ticket tracking is fine for now. If you still want a
> personal repository on gitweb, check out these docs:
> https://help.torproject.org/tsa/

Thanks, I'll look into it.

> I'm also not sure what's the exact policy on gitian and
> deb.torproject.org, and whether third-party applications (like OnioNS)
> can be placed there.

That's fine. It's not a big deal, but I would eventually like to have
reproducible builds on the official system. For now I have a few ideas
for reproducibility, so it's not a priority at present.

> Personally, I'm hesitant of giving the impression that Tor officially
> supports any of the proposed naming systems so early. I'd feel more
> confident about them after they get deployed and used by the wider
> community.

I can understand that. How did other software, such as obfs4, get
supported? I'm sure an early version of it was buggy and vulnerable, but
at some point it was integrated in to the system. I'm just wondering
what the requirements are and what the timeline looks like. I was hoping
to get started with the process.

> On this topic, what's your deployment strategy? If you really really
> need Tor project infrastructure to achieve it, let's talk about it.

I don't need Tor's build system, no. I can probably deploy just fine on
third-party systems (Github, Launchpad, etc) but it seems very
disjointed. I was hoping to get started on the process in moving towards
*.torproject.org so that it's easier to deploy. Everyone is already
familiar with the process and they have deb.torproject.org in their sources.

At present, I am envisioning a deployment strategy like this:
1) I will finish all the primary components and ensure that they all
mesh together nicely. This involves a lot of testing and changes on my
end. This is currently where I am.
2) I will deploy an alpha build to the approximately dozen volunteers
that have expressed interest so far. I will distribute RPMs, DEBs, and a
build of the Tor Browser that includes my libraries. I will help run the
servers and they can test out the components, particularly the onion
service and client software.
3) Fix bugs and deploy into beta.
4) I'll post on tor-dev or tor-relays asking for volunteers to help test
the server end. This is part where the system starts to become
decentralized.
5) Fix bugs, grow based on interest, add more documentation, expand the
project page, etc.
6) When everything seems stable and feature-complete, announce it so
that everyone can test out the stable builds.

> BTW, monitor this list, there will soon be a proposal specifying a Tor
> API for naming systems like OnioNS, similar to the one we have for
> pluggable transports.

That will be neat. At present the "intercept circuit requests,
auto-attach or rewrite based on TLD" approach seems pretty reliable, but
I will look forward to seeing what you guys come up with.

-- 
Jesse



signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Thesis using QUIC in Tor

[Jesse V]

On 09/30/2016 07:02 AM, Ali Clark wrote:
> For my master's thesis this summer I looked into the performance impact from
> using QUIC instead of TCP/TLS as the relay transport. Results from the
> experiments look quite promising.
> 
> For more details and the thesis, please see my blog post:
> https://www.benthamsgaze.org/2016/09/29/quux-a-quic-un-multiplexing-of-the-tor-relay-transport/

Hi Ali,

Well done, this looks really neat! A couple of questions:
1) Are you looking into publishing your work in a peer-reviewed journal
such as CSS, NDSS, PoPETS, or elsewhere?
2) Did you examine the performance improvements for 6-hop onion/hidden
service circuits?
3) Tor currently multiplexes circuits over the same TLS connection. This
is by design to avoid leaking circuit-level metadata, including the
observation of construction and tear-down. The first paragraph on page
21 seems to suggest that QUUX leaks this information. Is this correct,
or did you take steps to address this? For that matter, does QUUX leak
any additional metadata that could assist with de-anonymization attacks?

-- 
Jesse



signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] prop224: Ditching key blinding for shorter onion addresses

[Jesse V]

On 09/27/2016 11:15 AM, Jeff Burdges wrote:
> There were a couple reasons I stopped the work on integrating
> GNS with Tor, which Christian asked me to do :  First, I did not like
> that users could confirm that a particular subdomain exists if they know
> the base domain's public key.  Second, I disliked the absence of the
> collaborative random number generator protections you guys added to Tor.

I am curious, what is your issue with the subdomains? Are you referring
to enumerating all subdomains, or simply being able to confirm that a
particular subdomain exists? If I know that google.com exists and I am
looking for Google Maps, it seems reasonable that I might try to look up
maps.google.com. I wasn't able to find a practical solution against
enumeration for OnioNS, but I am curious what your exact concerns are here.

-- 
Jesse



signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Paper on how DNS affects Tor's anonymity

[Jesse V]

On 09/28/2016 11:35 AM, Philipp Winter wrote:
> My colleagues and I published a (not yet peer-reviewed) research paper
> on how DNS affects Tor's anonymity.  The key parts of our work are:
> 
> - We measure the DNS setup of exit relays over time, showing that at
>   times Google got to see almost 40% of DNS requests coming out of Tor.
> 
> - We show how website fingerprinting attacks can be augmented with
>   observed DNS requests, resulting in precise attacks for unpopular
>   websites.
> 
> - Similar to the "Users Get Routed" work, we simulate the impact of our
>   attack at Internet-scale using the TorPS simulator.
> 
> The PDF is available online:
> 
> 
> Our project page has code, data, and replication instructions:
> 
> ___

Excellent work, this is really neat!

It reminds me a bit of
https://www.cse.buffalo.edu/~mohaisen/doc/14-wpes.pdf, which describes
the prevalence accidental .onion lookups on DNS root servers.

The issue with 8.8.8.8 is significant. It's easy to point
/etc/resolv.conf at Google's DNS because it just works, without
realizing the implications. https://xkcd.com/1361/

-- 
Jesse



signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Naming Systems wiki page

[Jesse V]

On 09/27/2016 10:05 AM, Jeremy Rand wrote:
> Namecoin also can be used for name-level load balancing, although I
> haven't really carefully considered the anonymity effects of the load
> balancing (e.g. does it open the risk of fingerprinting?), so that
> feature is lower priority until I can think about that more carefully.
> I'm curious how OnioNS is handling that -- maybe there's some thinking
> in OnioNS's design that's adaptable to Namecoin?

Really? Now I'm curious how Namecoin does it!

OnioNS currently achieves load balancing by allowing the onion service
operator to specify a list of secondary addresses. In this case, the
name record contains the following:
+ RSA-1024 onion service public key
+ RSA-1024 signature
+ memorable name
+ secondary addresses
+ + "address1.onion"
+ + "address2.onion"
+ (other data)

The client will then randomly select address1.onion or address2.onion
and will round-robin until one of them connects. It's a very simple
scheme. Right now it looks like this:
https://github.com/Jesse-V/OnioNS-common/blob/8217c47bce76d87d056f1bab671c44e13f1e9d69/src/records/Record.cpp#L58

OnioNS also checks that the main public key is in the root directory of
each of the secondary addresses to ensure that they are all maintained
by the same entity. I am still mulling over possible attacks, defenses,
and implications, but in general it seems to work.

-- 
Jesse



signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Naming Systems wiki page

[Jesse V]

On 09/27/2016 02:39 AM, Jeremy Rand wrote:
> Relatedly -- I had some trouble summarizing some of the items in the
> Namecoin section because the security, privacy, and scalability
> properties of Namecoin are somewhat different depending on whether the
> user is using a full node (downloads the entire blockchain), a FBR-C
> node (receives full blocks that can contain current name transactions),
> or a headers-only node (receives only block headers).
> 
> I didn't want to change the layout of the page much without asking, but
> would it make sense to split the Namecoin section into multiple sections
> (a section for each of those node types)?  Or is it preferred to keep
> them in 1 section and say which of the security properties / drawbacks
> apply to which node types (which is what I've done for the moment)?

This is a fair point. I agree that we should split it up accordingly to
"Namecoin (full blockchain)" and "Namecoin (thin/SPV client)". Both have
different descriptions, security properties, and drawbacks so it would
probably be more organized this way.

-- 
Jesse



signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] Joining Tor Project's software infrastructure

[Jesse V]

Hey everyone,

Although it hasn't been obvious, I actually have been making some
serious progress on my Onion Name System (OnioNS) project. The paper was
accepted into PoPETS, the design is finally stable, and the software is
looking really promising, although not yet ready for use. I've focused
on improving the maturity of the software and set up the following:

* PGP-signed commits using my torproject identity
* Continuous integration via Travis CI
* Use clang-analyzer and cppcheck static analysis scanners
* Automated enforcement of code styling via clang-format
* Inclusion of a manpage and command-line help menu
* Packaging for Debian (Wheezy+) on my own machine
* Automated building for Ubuntu (14.04+) on Launchpad
* Protection against memory leaks and buffer overflows
* Software is split to minimize installation footprint
* Use of CMake, which should help the port to Windows
* No RPATH hacks
* Support for release and debug builds
* Support for Clang and GCC; all warnings enabled for debug
* No reliance on OpenSSL (CVE-2016-6309, are you serious?!)
* Use of well-maintained libraries for networking and parsing
* Minimal dependencies: Botan, JsonCpp, libcurl, libmicrohttpd
* Non-native dependencies included as git submodules

At this point, I am interested in taking the next step and try to
integrate with the Tor Project infrastructure. I am looking for
information on the following:

1) How do I upload packages to deb.torproject.org?
2) How do I join Gitian to generate reproducible builds?
3) How do I set up an Onion Name System component in Trac so that I can
migrate bug tracking from Github to Trac?
4) How do I set up a repository on gitweb.torproject.org? I'm more
comfortable using Github, but there's no need to centralize git.

I have a LDAP account, which should help with some of these. I wasn't
able to find much useful documentation on these topics, so I would
appreciate some help. Also, if anyone has any experience with RPM
packaging, I would like to figure that out. I haven't had too much luck
with Alien.

As I approach a proper release, my overall goal is to improve the
maturity, trust, usability of the OnioNS software. Please let me know
how I can accomplish the above tasks.

Recent commits:
https://github.com/Jesse-V/OnioNS-common/tree/json-rpc
https://github.com/Jesse-V/OnioNS-server/tree/json-rpc
https://github.com/Jesse-V/OnioNS-client/tree/json-rpc

I've also updated
https://trac.torproject.org/projects/tor/wiki/doc/OnionServiceNamingSystems

-- 
Jesse



signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] How to query HS hostname from control port

[Jesse V]

On 09/09/2016 10:15 PM, dawuud wrote:
> right. it shouldn't be necessary at all to modify the torrc... for most 
> features.

You need to modify the torrc in order to enable the ControlPort.
https://github.com/Jesse-V/OnioNS-server/tree/json-rpc#setup

>> > and an authentication, but it's just one less requirement using ADD_ONION.
> nah... you could use a unix domain socket instead of a TCP port and then
> just use filesystem permissions to limit access to the socket file.
> i much prefer this to authentication.
> 

Good suggestion, I'll look into it.

-- 
Jesse V



signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Hmac

[Jesse V]

On 09/09/2016 07:28 PM, Flipchan wrote:
> Hi all, so i spook with a friend of mine yesterday and we where chating
> about encryption and i told him that i use scrypt for password hashing.
> He told that hmac was alot better.
> 
> Does anyone know any Good whitepapers on hmac? Any Good python lib? Does
> anyone use it ?

The important thing here is that in this context, both scrypt and HMAC
receive two values: a password and a salt. This provides a defense
against rainbow tables if your database is compromised. It also avoid
leaking whether two users have the same password. The idea is to store
the username, salt, and hashed password in the database.

Scrypt is useful because it's memory-hard, which means that it better
resists hardware attacks since the scrypt operation requires precious
RAM. HMAC is useful because it isn't safe to compute SHA2(salt +
password) due to the Length Extension Attack against MD5, SHA1, and
SHA2, but this doesn't necessarily apply in this context. When you say
"HMAC", I assume that your friend means HMAC_SHA256.

HMAC_SHA256 is very common for storing passwords and there are many
papers, libraries, and other resources on it. I would start with the
Wikipedia article on HMAC and go from there. If you really want to dig
into the topic, look into Argon2.

-- 
Jesse V



signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] How to query HS hostname from control port

[Jesse V]

On 09/09/2016 04:23 AM, dawuud wrote:
> How does ADD_ONION help with tor vs app data isolation?  Why do you
> have to modify any torrc at all? Can't you do everything through the
> control port? I suppose there are many options not available via control port.
> 

Under the old method I required the user to set up the hidden/onion
service by adding a line to their torrc. That's not necessary if I used
ADD_ONION. In both methods I still need them to enable the control port
and an authentication, but it's just one less requirement using ADD_ONION.

Data isolation is improved because it separates responsibility. In
Linux, the tor binary runs under a separate user and sets up permissions
to protect sensitive data. My OnioNS software can run as a separate user
as well. This way, data is isolated to its respective software and I'm
not mixing everything.

-- 
Jesse V



signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] Dirauth setting for PathsNeededToBuildCircuits

[Jesse V]

Tor clients can only build circuits once they know enough about the
network. This "know enough" threshold is determined by the
PathsNeededToBuildCircuits setting. From reading Tor's manual, it seems
that a setting of X tells Tor clients to wait until they have enough
descriptors/microdescriptors such that they have X percentage of
consensus weight. By default PathsNeededToBuildCircuits is determined by
the directory authorities.

I'm curious, how is PathsNeededToBuildCircuits set? I don't see that
value in the microdescriptor documents, it doesn't seem to be documented
in tor-spec, and I don't see much about it online, but maybe I missed
something. What is the typical value? I see that 0.95 is the cutoff, but
how high will prevent a client from bootstrapping?

-- 
Jesse V



signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] How to query HS hostname from control port

[Jesse V]

Well, this certainly triggered more conversation than I was expecting. I
was simply wondering if there was such a method call, and apparently
there isn't. That's okay.

I thought about this and decided to go with Yawning's suggestion to just
use ADD_ONION and then record the returned RSA private key. It's easy
enough to add that same key back into Tor whenever I want. There are
several main advantages with this route, including isolating my
software's data from Tor's and requiring fewer modifications to torrc.
It just seems cleaner in general.

-- 
Jesse V



signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] HTTPS Everywhere

[Jesse V]

On 09/05/2016 01:19 PM, AKASH DAS wrote:
> If I have to make any patch in the code, do I have to submit it in this
> mailing list or https-everywhere's mailing list? Just a doubt

What are you trying to patch? If you are trying to add a URL to their
whitelist, you don't need to submit a patch as they have a tool for
that. Otherwise, I am not certain how they accept git patches.

Per convention, please reply below the original message instead of above it.

-- 
Jesse V



signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] HTTPS Everywhere

[Jesse V]

On 09/05/2016 12:58 PM, AKASH DAS wrote:
> Can I know the issues that are currently in https everywhere.

This is the mailing list for Tor development, so you may want to
redirect your question to the EFF or some different channel.

HTTPS Everywhere has been really smooth for me and I've actually never
had an issue with it across many devices and several years. I know that
some websites don't handle HTTPS correctly, but that's why the EFF built
the tool based on a carefull-managed whitelist. If almost all of your
common websites are using HTTPS, then you might even consider enabling
the "Block all unencrypted requests" option, but then don't be surprised
when your favorite news site no longer loads. The situation is really
improving thanks to Let's Encrypt. :)

-- 
Jesse V



signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] How to query HS hostname from control port

[Jesse V]

On 09/05/2016 12:43 AM, meejah wrote:
> Could you use ADD_ONION instead? Why are you using the on-disk API if
> you don't want to give your thing permission to read those directories?

I'll consider it, but I want the onion service to be relatively
permanent. It would best if the hostname didn't change every time tor
restarted.

> I also don't see why you'd give something permission to use the
> control-port, but *not* permission to read hostname/private_key
> files...?

I'd just rather not risk unnecessary exposure of private keys. The
software doesn't need the key, so I'm risking compromise just to do
private -> public -> hostname, I'd rather query the hostname directly.
I'm using cookie authentication and both tor and onions-server have a
copy of the cookie file. This way I can set up IPC between them in a
more secure manner and they can each run as a separate user.

> (p.s. I can't reach http://onions55e7yam27n.onion/)

Nothing is online at the moment. I'll make a separate post once
everything is ready.

-- 
Jesse V



signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] How to query HS hostname from control port

[Jesse V]

On 09/04/2016 09:31 PM, meejah wrote:
> There are two types of onion services: "on disk" ones configured via
> torrc/SETCONF and the HiddenServiceDir and related options **or**
> "ephemeral" onions, created via the recently added ADD_ONION command.
> 
> In the latter case, you can list them with GETINFOs on "onions/current"
> or "onions/detached" depending on the options when you created them.
> 
> For the "HiddenServiceDir" onions, the only way to get the onion address
> that I know of is by reading the "hostname" file.
> 
> Can you describe what you're trying to do?
> 

I'm interested in the ones on disk. I wish that "onions/current" would
give me the list of HSs that were set up via torrc, but this doesn't
appear to be the case. I'm basically looking for the raw command.

This is part of my overhaul of the Onion Name System (OnioNS) project,
which has actually been silently active. I wasn't able to finish some
components until the design was stable. Now that the paper is finalized
and has been accepted, I have been finishing the codebase. The server
software needs to know the HS address so that it can distribute it to
other nodes in the OnioNS network. My to-do list is quickly diminishing
but I did run into this snag and I wasn't able to fix it.

-- 
Jesse V



signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] How to query HS hostname from control port

[Jesse V]

Hi everyone,

TL;DR: Please let me know how to fetch the hostname of my hidden service
from Tor's control port.

Say I have configured torrc to set up a hidden/onion service. By
default, it's set up in /var/lib/tor/hidden_service, a directory which
isn't world-readable. My software can authenticate into Tor's control
port, but it needs to know the hostname/address of the service. It can't
read the hidden_service/hostname file directly, and so far I haven't
figured out how to query Tor for that information. As a last resort, I
suppose I could copy /var/lib/tor/hidden_service/hostname to a directory
that the software can read, but I'd like to avoid that if possible.

I have hunted through
https://gitweb.torproject.org/torspec.git/tree/control-spec.txt without
too much success. The closest I have come is "GETCONF
HiddenServiceOptions" but I suspect that the option is under GETINFO
instead. However, the documentation mostly describes how to query
information about other onion services. I need to know about my service
though, if that's possible. Please advise.

-- 
Jesse V

I look forward to seeing everyone again in July at Minneapolis. :)



signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] How to integrate an external name resolver into Tor

[Jesse V]

On 08/02/2016 09:45 AM, teor wrote:
> 
> Has someone put together an example resolver that just does simple extension 
> substitution?
> It would amuse me to be able to visit 3g2upl4pq6kufc4m.chive, or 
> 3g2upl4pq6kufc4m.allium.
> 
> Tim
> 
> Tim Wilson-Brown (teor)

Thanks Nick for the helpful tips. I will certainly keep that in mind for
my implementation. I didn't realize that it was so easy to close streams
like that if the lookup failed, that's extremely helpful to know.

I've picked up a full-time job now and I haven't posted here for some
time. I have been (mostly silently) working on the Onion Name System
(OnioNS) project, which as you may remember maps ".tor"
to ".onion". It has been undergoing some major and
much-needed redesigns thanks to excellent comments from the reviewers of
the whitepaper. I've also switched dependencies; instead of raw sockets,
my own application protocol, and the massive Boost Asio library, I'm now
using libmicrohttpd and RPC-JSON, so the code is very versatile, clean,
and has a small footprint. It can still resolve "example.tor" to
3g2upl4pq6kufc4m.onion (DDG) or whatever else the resolver says.

Tim, to answer your question, here is my Python script that does the
circuit interception and lookup rewrite:
https://github.com/Jesse-V/OnioNS-client/blob/master/src/assets/onions-stem.py
The network is down so the code won't fully run, but I'm posting this
here so everyone can see what Nick's instructions look like in practice.
Like I said, I haven't implemented the failure case properly, but the
code is mostly there. Cut out the network code to the localhost resolver
and you could easily do trivial resolves of .onion addresses.

-- 
Jesse V



signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Quantum-safe Hybrid handshake for Tor

[Jesse V]

On 04/03/2016 10:37 AM, Jeff Burdges wrote:
> I should read up on this compression business since I'd no idea they
> were so small.  At first blush, these SIDH schemes must communicate
> curve parameters of the curve the isogeny maps to and two curve points
> to help the other party compute the isogeny on their prime's subgroup,
> so maybe 3-4 times the size of a curve point, but the curve is far
> larger than any used with normal ECDH too.  

"Key Compression for Isogeny-Based Cryptosystems". Here's just the
abstract: https://eprint.iacr.org/2016/229 and the full paper can be
found here: https://eprint.iacr.org/2016/229.pdf

-- 
Jesse V



signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Quantum-safe Hybrid handshake for Tor

[Jesse V]

On 04/03/2016 02:52 AM, Yawning Angel wrote:
> Your definition of "reasonably fast" doesn't match mine.  The number
> for SIDH (key exchange, when the thread was going off on a tangent
> about signatures) is ~200ms.
> 
> A portable newhope (Ring-LWE) implementation[0] on my laptop can do one
> side of the exchange in ~190 usec.  Saving a few cells is not a good
> reason to use a key exchange mechanism that is 1000x slower
> (NTRUEncrypt is also fast enough to be competitive).

I have yet to see any SIDH benchmarks either. I checked the citation but
I wasn't able to confirm where the ~200ms number came from. Thanks for
throwing out specific numbers on Ring-LWE, I wasn't aware that it was so
fast.

-- 
Jesse V



signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Quantum-safe Hybrid handshake for Tor

[Jesse V]

On 02/03/2016 12:12 PM, Jeff Burdges wrote:
> I donno that you'll ever beat that 1kb key size with a post-quantum
> system.  There is a lattice based signature scheme and an isogeny based
> scheme that'll both beat SPHINCS on signature sizes, but I think not so
> much on key size. 

I just wanted to resurrect this old thread to point out that
supersingular isogeny key exchange (SIDH) is the isogeny scheme that
you're referring to. Using a clever compression algorithm, SIDH only
needs to exchange 3072 bits (384 bytes) at a 128-bit quantum security
level. This beats SPHINCS by a mile and unlike NTRUEncrypt, fits nicely
into Tor's current cell size. I don't know about key sizes, though. If I
recall correctly, SIDH's paper also references the "A quantum-safe
circuit-extension handshake for Tor" paper that lead to this proposal.

Again, I have very little understanding of post-quantum crypto and I'm
just starting to understand ECC, but after looking over
https://en.wikipedia.org/wiki/Supersingular_isogeny_key_exchange and
skimming the SIDH paper, I'm rather impressed. SIDH doesn't seem to be
patented, it's reasonably fast, it uses the smallest bandwidth, and it
offers perfect forward secrecy. It seems to me that SIDH actually has
more potential for making it into Tor than any other post-quantum
cryptosystem.

-- 
Jesse V



signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Summary of meek's costs, December 2015

[Jesse V]

On 01/11/2016 02:42 PM, David Fifield wrote:
> We still have support from
> Google, so that $561.29 actually costs about $61.29.

Oh, I was not aware of this. When does the support expire, and how much
would it cost (in terms of Tor's budget) to double the bandwidth to 16
Mbits, for instance? I'm just thinking about the implications if there
were donations for meek.

-- 
Jesse V



signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Summary of meek's costs, December 2015

[Jesse V]

On 01/11/2016 12:47 PM, David Fifield wrote:
> December 2015  $561.29 +  $603.27 +  $172.60 =  $1337.16
> ...
> The number of users increased by about 1,000 in December 2015.

Thanks for the report, David.

There are now ~1800 users on meek-google sharing 8 Mbits. Of course,
it's also possible that many are lurking. I wonder if we should think of
a way to load-balance the CDNs a bit more, assuming Azure is accessible
from China. Perhaps we could re-order or at least clarify the bridge
options in the Tor Browser. Since it's logistically challenging to get
bridges from inside a censored country, it's possible that users try the
various bridge options using the built-in bridges (which are likely
blocked) before discovering that meek works, so they use that. I wonder
how we could encourage users to use other transports that are likely
faster, then use meek as a last resort.

-- 
Jesse V



signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Summary of meek's costs, December 2015

[Jesse V]

On 01/11/2016 12:47 PM, David Fifield wrote:
> December 2015  $561.29 +  $603.27 +  $172.60 =  $1337.16
> ...
> The number of users increased by about 1,000 in December 2015.

Thanks for the report, David.

There are now ~1800 users on meek-google sharing 8 Mbits. Of course,
it's also possible that many are lurking. I wonder if we should think of
a way to load-balance the CDNs a bit more, assuming Azure is accessible
from China. Perhaps we could re-order or at least clarify the bridge
options in the Tor Browser. Since it's logistically challenging to get
bridges from inside a censored country, it's possible that users try the
various bridge options using the built-in bridges (which are likely
blocked) before discovering that meek works, so they use that. I wonder
how we could encourage users to use other transports that are likely
faster, then use meek as a last resort.

-- 
Jesse V



signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Quantum-safe Hybrid handshake for Tor

[Jesse V]

On 01/02/2016 01:49 PM, Flipchan wrote:
> How would u add quantum-safe
> crypto? I havent seen anyone puttin a pub lib that anyone can import

Here's a webpage, a paper, and software from djb:
http://sphincs.cr.yp.to/ This is of course one example, there are other
works on post-quantum cryptography, and I'm sure most of the authors
like to provide a reference implementation of their idea.

For next time, please bottom-post and be sure to replace the subject
line to reflect the thread's name. You only have to replace the subject
line if you receive posts in a digest form.

-- 
Jesse V



signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Quantum-safe Hybrid handshake for Tor

[Jesse V]

On 01/02/2016 05:42 PM, Tim Wilson-Brown - teor wrote:
> And if we can't use the reference implementation, we have some decent
> programmers…
> (On the other hand, if there's no reference implementation, then that
> makes it hard to recommend that particular crypto scheme.)

That sounds pretty close to a "roll your own crypto" idea, which as I'm
sure you know is almost always a poor idea. Classical algorithms like
RSA and Diffie-Hellman are ~40 years old but they have many
side-channels and are still hard to implement correctly. There are so
many subtleties with ECDHE and ECDSA, with the notable exception of the
safer *25519 cryptosystems from djb. Post-quantum cryptography is over
my head, but considering the pattern and the newness of the field I
wouldn't trust any implementation unless it was written or at least
vetted by the authors of the respective post-quantum cryptosystem.

That being said, I'd like to thank Schanck, Whyte, and Zhang for their
work, their paper, and their reference implementation.

-- 
Jesse V



signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] IDE for Tor?

[Jesse V]

Lain,

IDEs do exist in Linux and some people like them, but you'll find that
most people use a text editor and the command-line. The terminal is
almost exclusively Bash, but the choice of text editor is a very
personal choice and is the frequent source of debate and contention
amount Linux enthusiasts. The debate is about 35 years old with no clear
winner, so I doubt that it can be resolved here and few people like a
flamewar.

That said, I have enjoyed Sublime Text, but lately I've switched to
Kate, which is FOSS and works just as well, and I prefer it over vim and
Emacs. Of course, real programmers use a magnetized needle and a steady
hand, but to each their own. :)

On 12/10/2015 02:48 PM, Nick Mathewson wrote:
> On Thu, Dec 10, 2015 at 1:10 PM, Lain Iwakura <lainiwak...@riseup.net> wrote:
>> Hello guys;
>>
>> Sorry such silly questions novice.
>> But what IDE you use, and why? In Linux, of course.
>> ... For C and python.
>> I see Eclipse (Mars), but it seems more to own java.
>> Codeblocks, perhaps?
>>
>> Excuse me still could not find me in the documentation.
> 
> I use emacs and a terminal. :)
> ___
> tor-dev mailing list
> tor-dev@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
> 

-- 
Jesse V



signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] running a BWauth

[Jesse V]

Yep, I've run Mike Perry's code before. It's all in torflow. I was also on a 1 
gbits link, but as I recall it wasn't that saturated so you might be able to 
get away with a 500 mbits.

I last ran his scripts back in July, and the logs and other saved data consumed 
all remaining disk space. I don't know if I missed a cleanup step somewhere or 
if the issue was fixed since then, but it's something to be aware of.

-- Jesse V.

On 11/03/2015 07:29 PM, Tom Ritter wrote:
> A 10GB network connection is not a requirement, 1GB would be fine,
> 500MB would also be fine. Mine is 4 core,  Intel(R) Xeon(R) CPU E5606
> @ 2.13GHz w/ 8GB of RAM.
>
> Everything is in torflow, I'm not aware of any other code.
>
> -tom
>
> On 2 November 2015 at 17:26,  <starlight.201...@binnacle.cx> wrote:
>> I am considering starting up a passive
>> BWauth in order to understand how they
>> work and fix bugs.
>>
>> What is the minimum and ideal hardware
>> configuration for a BWauth?
>>
>> Have my eye on an OVH config with
>> unmetered 1G, a fuzzy promise
>> of 500mbps minimum bandwidth and
>> a 3.4GHz 4core/8thread AES-NI CPU:
>>   http://ark.intel.com/products/80910
>>
>> The server could be turned up in any of
>> their facilities:
>>   https://www.ovh.com/us/about-us/datacenters.xml
>>
>> Or is 10G a requirement?  (out of my league)
>>
>> Is all code here
>>
>>https://gitweb.torproject.org/torflow.git/tree/NetworkScanners/BwAuthority
>>
>> or is there more?  Are uncommitted
>> fixes lying around anywhere?
>>
>> Thanks
>>
>> ___
>> tor-dev mailing list
>> tor-dev@lists.torproject.org
>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
> ___
> tor-dev mailing list
> tor-dev@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
>




signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Update of prop#250: Random Number Generation During Tor Voting

[Jesse V]

David,

I'm in the midst of reworking my OnioNS design around prop250 (and the security 
analysis therein) and as far as I can tell these changes make sense. I like the 
00:00 -> 24:00 change as it's more intuitive as you said. I was at first very 
concerned that you removed the majority requirement as that is the assumption 
made during consensus generation, but I think your argument for the new 
conflict resolution make sense. I'm excited that the implementation is nearly 
complete and I look forward to seeing it in Tor infrastructure!

Jesse V.

On 10/28/2015 10:26 AM, David Goulet wrote:
> First, period have been changed from 12:00 -> 12:00 (24 hour) to 00:00
> -> 24:00 so the protocol run is not over two days. Seemed more logical
> and less confusing :).
>
> Second, we've removed the need of having majority for a commit to be
> considered for the shared random computation. Yes this sounds intense!!
> so it needs your attention.




signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Second release of OnioNS beta

[Jesse V]

Heads-up everyone,

After some debugging with s7r, it appears that sometimes the programs 
(onions-server, onions-hs, or onions-client) fail to start because they cannot 
load the common library. So if you run any of the programs in the terminal, you 
will see an error that libonions-common.so cannot be found, or they simply 
won't run if you start them without an active terminal. This is because that 
library is installed to /usr/lib/onions-common, but the loader is looking for 
it in /usr/lib/, among other locations. I do set the RPATH in CMake in an 
attempt to fix this, but in some cases (at least in my build for Debian Wheezy) 
it may not be set or installed correctly. I'm investigating and looking through 
https://cmake.org/Wiki/CMake_RPATH_handling

If this occurs, there are two workarounds. The first is to run
export LD_LIBRARY_PATH="/usr/lib/onions-common"
before running any of the software. The second is to add 
"/usr/lib/onions-common/" (without quotes) to /etc/ld.so.conf
Both should tell the loader to look for the library in the correct path.

This issue might also occur on Fedora under the for the experimental .rpm, but 
I'm not sure. The issue doesn't occur on my computer, but if it also applies to 
Ubuntu or Mint, please let me know. It's always possible to compile from source 
and run the software from the build directory, but I would really like to 
identify the scope of this issue and then properly fix it.

Thanks,
Jesse V.



signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] Second release of OnioNS beta

[Jesse V]

Hello everyone,

I am pleased to announce the second release of the Onion Name System (OnioNS) 
for beta testing. This release represents about 180 commits and is a major 
update from my last release. The two servers should be up long-term, so feel 
free to play around with it. "Example.tor" is live and new registrations should 
be available client-side about 20 seconds after upload.

As usual, the code, pre-built binaries, and instructions are available in the 
four OnioNS repositories at https://github.com/Jesse-V?tab=repositories
Please star them if they work well for you. Most people will probably just want 
OnioNS-client, which integrates into the Tor Browser.

The big changes include:
* Servers are now powered by hidden services. This means that they utilize 
existing Tor connections (circuits and TLS links) which is a major improvement 
over the direct communication in the last release. In the process, I switched 
all communications from SOCKS4 to SOCKS5 and it seems to work well. The OnioNS 
servers would be excellent candidates for single-onion services (Tor-embedded 
servers with only client-side anonymity) so I will switch to that when they 
becomes available.
* Servers now manage Ed25519 keys and I'm using floodberry's ed25519-donna 
implementation. All responses from a server are signed, so communication is 
automatically authenticated. The private key is held in the main working 
directory, which is ~/.OnioNS/ for the time being. Due to this, it's not 
currently possible to run two distinct servers as the same user.
* The trusted Quorum server now generates a Merkle tree and signs the root, 
which the client uses to authenticate Records (registrations) and to provide 
authenticated denial-of-existence. In effect, this prevents the client's name 
server from falsely returning a 404 or from forging a Record.
* I overhauled most of the networking code. It's significantly more stable, 
closely follows a request-response pattern, and I don't anticipate needing to 
change the networking format in the near future.
* The hidden service software now saves the generated Record to disk, so that 
it can try again if the upload fails.
* I introduced two static analysis tools: cppcheck and Clang's scan-build and 
created the scanBuild.sh script to facilitate analysis. They found one small 
memory leak, which I fixed, so now all of the repositories pass inspection.
* I'm now using the Travis continual integration system, which watches for 
commits in Github and then rebuilds the project. I get notifications in 
#tor-bots if the repo fails to build into a .deb, which is handy. Any pull 
requests are also checked in the same way.
* Many bugs were identified and fixed.

I need some help with:
* Testing a linking bug that is sometimes encountered when compiling from 
source. The ticket is https://github.com/Jesse-V/OnioNS-server/issues/79 I 
don't know whether the issue is dependent on Debian Wheezy, Ubuntu Trusty, or 
my CMakeLists. I'm not sure how to fix it, either.
* Testing an experimental .rpm format. I used the "alien" program to convert 
Wheezy and Trusty .deb files to .rpm, so as to better cater to Fedora. The 
rpm's are available in the Releases page on Github. I don't know if the 
packages work correctly, so if you are on Fedora, please try them out and let 
me know. If they don't work, I would appreciate instructions on how to build 
them properly.
* General testing: does the HS-side and client-side code work well and perform 
reliable for you?

Related notes:
* Earlier this month someone in Egypt created the ".tor" article on Wikipedia, 
which has a few details about this project. Thanks for that!
* S7r, I couldn't contact you on IRC, but if you're still up for running a name 
server to handle client connections, please let me know. I'll need your HS 
address and your server's Ed25519 public key, which is shown when the server 
starts. Then I'll push out an update that should transition clients over to 
you. It'll be nice to spread out ownership of the infrastructure.

Next on the list:
* I'm planning to focus the next release on stability, security, unit tests 
(I'm looking into coveralls.io), and doxygen documentation. The code is 
currently a bit fragile, so I'd like the next release to improve error 
handling. I'll be maintaining this version until the next one comes out, so I 
made a "stable" branch which will be for bug fixes and the like. I recommend 
that Ubuntu/Mint users use the PPA so that it's easy to deploy updates.
* I need to let servers update themselves if they are out-of-date. Once I fix 
this, it should be straightforward to add more servers to this system.

Thanks for the support everyone, and enjoy testing!

Jesse V.





signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] 7th and last status report for OnioNS

[Jesse V]

Happy Friday everyone,


This is my last status report for the Summer of Privacy program, but I think I 
can end my reports on a good note.

* At the suggestion of several people, I rewrote the networking infrastructure. 
Before, OnioNS-client and OnioNS-HS contacted the servers over Tor circuits, 
and OnioNS-server sent messages to each other over unencrypted TCP/IP links 
P2P-style. Now, the servers bind to localhost and are powered by hidden 
services, so all server-server communication occurs Ricochet-style. This is 
superior because it provides a significant increase to network attacks, works 
around the problem of distributing another TCP port in the consensus, and 
allows Tor relay administrators to run OnioNS servers without having to punch 
yet another hole in their firewall. I don't need anonymity for server P2P 
communication, so I will certainly be using the single onion service 
infrastructure when it becomes available.

* All OnioNS servers now manage Ed25519 keypairs. In my design, authoritative 
Quorum servers will use their key for authenticated denial-of-existence and to 
prevent regular name servers from forging responses, but this infrastructure is 
not fully in place yet. When OnioNS merges into Tor, this keypair would be each 
router's signing key or at least a keypair signed by the signing key.

* Servers now save newly-received Records to disk to prevent them. The cache 
file is loaded when the server starts up.

* OnioNS-HS now saves newly-validated Records to disk before attempting to 
upload them. This is incredibly handy to prevent having to re-preform all the 
proof-of-work if the upload fails.

* OnioNS-HS no longer has a dependency on little-t-tor. As s7r wisely points 
out, some people may have installed tor from git. I also added a flag to 
specify the number of worker threads, which can help reduce the system 
requirements if the HS is hosted on a VM with minimal system resources.

* OnioNS-client no longer logs all Tor Browser activity. I used this for 
debugging, but it's no longer worth compromising user privacy. The software 
also correctly shuts down when the Tor Browser closes; in the process of fixing 
this I also discovered that it's not a good idea to misinterpret the 
documentation and run an application containing kill(0, SIGTERM);. The result 
was quite unexpected.

* In addition to intercepting all *.tor domains, OnioNS-client now rewrites 
check.torproject.org to another domain that shows that OnioNS is enabled in 
the browser. Before, users had to visit example.tor to confirm that the 
OnioNS software is running, but this was problematic because if OnioNS wasn't 
running, they get an error message because their exit node cannot resolve 
example.tor on the Internet DNS. Now these failures no longer leak.

* I've stopped packaging my own build of jsoncpp, so I added a dependency for a 
system installation. Fortunately, Ubuntu/Mint, Debian, and Fedora all have that 
library in their repositories.

* Logs now include the date and time, which is quite handy.

* Numerous bugfixes, most notably I fixed the bug where the recipient would 
fail to understand a message longer than 500 bytes.



To summarize the state of the project at the end of the SoP program:

* All of the infrastructure for OnioNS is in place. There are still a few 
protocols left to finish off, but all big tasks are complete. The client-side 
and HS-side software is pretty reliable and stable at this point.
* Although the software lacks in-line documentation, I have gone to great 
lengths to increase its readability and overall organization.
* OnioNS runs just fine on Debian, Ubuntu, Mint, and Fedora, although I do not 
have any support for Windows or OS X. I'm asking for help from any Windows 
developer to help port the client software over there, please talk to me about 
that.
* I have full intentions of continuing to maintain the OnioNS project. Please 
keep an eye on https://github.com/Jesse-V?tab=repositories and I will post here 
when I push out releases. I'm very close to the next beta test.
* Once the OnioNS software is fully ready, no modifications to Tor should be 
necessary to merge OnioNS into the Tor network.

Thanks everyone for the help, it's been a great summer project!

Jesse V.




signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Hash Visualizations to Protect Against Onion Phishing

[Jesse V]

 Jacek Wielemborek d33...@gmail.com writes:

 George Kadianakis pisze:
 Some real UX research needs to be done here, before we decide something 
 terrible.

 Just curious, has anybody seen any cognitive studies on the SSH
 randomart visualisation? I always found them impossible to remember.
 Perhaps adding a bit more color could help...
 Hm. Indeed.

 I can remember the general shape and edges of my SSH server's key, but not any
 details.

 I doubt I would remember the randomart of like 10 onion websites, especially 
 if
 I didn't visit them regularly. But maybe I would remember the randomart of my
 webmail better than my SSH server's.


The main issue is that there's always going to be a tradeoff between 
memorability and security. It's difficult to cram sufficient entropy into a 
visualization and expect people to remember it. I agree that coloring schemes 
or perhaps faces stand the best chance of memorability, but they are difficult 
to deploy. I wonder if a simpler scheme is sufficient.

I suggest using a word-bank to generate a series of words. First, take the 
.onion address or the hidden service public identity key (basically the same 
thing for 224) and run it through scrypt or similar algorithm. Then, based on 
the output, select a series of words from the dictionary. Present the series of 
words in George's mockup 
(https://people.torproject.org/~asn/tbb_randomart/randomart_mockup.png) in lieu 
of the art. It's not a new idea to use a word-list for this purpose: I recall 
reading a paper suggesting to use a word-list to encode .onion addresses rather 
than base32. The scheme has also been deployed by websites; Gfycat, for 
example, shows a series of words in its URL to provide an identifier to user 
images. It's also successful in practice: everyone in the /r/globaloffensive 
subreddit recognizes the DelayedAutisticGuppy reference before they even open 
the gif.

People remember random information best if it's grouped, but usually the 
maximum group size is about 4, which is why phone numbers are split with 
delimiters. To make it simple, I suggest showing one row of four words. Each 
character in a .onion address has 32 possible combinations. If you used a 
word-bank of 1,024 words, you cover two characters per word. If your dictionary 
consists of 32,768 words, you can capture three at a time. Assuming this latter 
case, if four words are used, you can cover 12 characters, or 60 bits. If you 
combine that with the number of characters in the address that users 
intrinsically check subconsciously, it's extremely difficult for an attacker to 
match all of them. The Shallot README indicates that it would take nearly 10 
millenia to find a 12-character match, and this of course does not take into 
account a round of scrypt before the word-list is used. Everyone remembers 
correct horse battery staple, right?






signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] 6th status report for OnioNS

[Jesse V]

This status report covers three main points of progress for the Onion Name 
System (OnioNS) project.

1) Since my last report, I opened up this project for beta testing. The server 
logs show that a number of people opened and ran servers for some time, and a 
number of individuals claimed names for their hidden services. S7r was 
extremely helpful in beta testing, we had a very productive private 
conversation on IRC. He helped me identify bugs and several areas of 
improvement. He also reproduced a few show-stopping issues that I had 
considered closed, so I'll be taking care of those as soon as I can. It was a 
thorough test and I very much appreciate the help.

2) I spent a significant amount of time over the last few weeks rewriting my 
design paper. I applied two suggestions that I heard during PETS and the 
Arlington HS meeting: a) to switch from using the consensus for a global source 
of entropy to the new commit-and-reveal proposal, and b) to select members of 
the Quorum (the authoritative set of OnioNS nodes) with selection weight 
proportional to their consensus weight, rather than with even probability. Both 
of these turned out to be excellent ideas. The dirauth commitment protocol is 
far more resistant to attacks than my original scheme and the new Quorum 
selection technique is highly resistant to Sybil attacks. In fact, even if all 
Fast and Stable routers in the lowest 70 percentile by consensus weight are 
malicious, it's still extremely unlikely that a random Quorum selection will 
result in a situation where the attacker wins.

3) There's an upstream change that I forgot to mention in my last report: the 
fact that Tor 0.2.7 now creates and manages Ed25519 keys brings OnioNS one step 
closer towards integration with Tor: my design documents call for OnioNS 
servers to manage Ed25519 signatures. It's a stronger and faster cryptosystem 
than RSA and has much smaller signatures, which reduces the overhead of my data 
structures. Down the road, I should be able to use the online signing key, so I 
won't need to touch the offline identity key.

As we come closer to the end of the Summer of Privacy timeline, I'm going to 
concentrate on addressing the bugs that s7r identified, finish implementing 
some security protocol, and try to move to a fully decentralized setup.

Jesse V.



signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] First release of OnioNS for beta testing

[Jesse V]

Thanks Dr. Fu, I look forward to your comments.

From the server log, apparently so far no one has tested the client, though 
someone has set up a server. I just want to highlight that I have servers up 
and running so the client and the HS functionality should work out of the box.

For the client, install the software then follow the instructions in the README 
to integrate it into the Tor Browser. My current approach is to rename the Tor 
binary from tor to torbin and then insert a symlink to the onions-tbb 
executable under the name tor. Then the onions-tbb software lauches torbin, 
onions-client, and the Stem script in that order, thus allowing all the 
necessary software to start with the Tor Browser. I have also added some 
functionality to wait until Tor is fully bootstrapped before launching 
onions-client and the Stem script, thus this approach is fully compatible with 
Tor bridges.

Jesse V.

 Subject:
 Re: [tor-dev] First release of OnioNS for beta testing
 From:
 Xinwen Fu
 Date:
 08/08/2015 04:25 AM

 To:
 tor-dev@lists.torproject.org tor-dev@lists.torproject.org


 Fantastic work. Will test it.

 Xinwen Fu





signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] First release of OnioNS for beta testing

[Jesse V]

Happy Saturday everyone,

At long last, 310 commits later, I am pleased to present a release of the Onion 
Name System (OnioNS), a DNS for Tor hidden services. This release is a 
usability test; it offers reliable behind-the-scenes integration with the Tor 
Browser, a friendly command-line dialog for claiming domain names and 
subdomains, and many options for hosting and configuring a server. The system 
utilizes two servers: a single Quorum node which hidden services upload their 
claims to and another server which clients query against. I am looking for 
feedback as to how usable the system is and areas where it could be improved. 
Most of the changes going forward will be behind-the-scenes.

The software is divided into three primary pieces, OnioNS-client, OnioNS-HS, 
and OnioNS-server. These all have OnioNS-common (a shared library) as a 
dependency. You can install whichever one you'd like, or all of them. This 
software is currently Linux-only, and Debian 7 and 8, Ubuntu 14.04 - 15.10, 
Mint 17 - 17.2, and Fedora 21 - 23 are supported. I provide packages for Debian 
7 and a software repository for currently-supported versions of Ubuntu and Mint 
on 32-bit, 62-bit, and ARM systems. If possible, please use the repository.

Please see the READMEs in the following repositories for more information, 
including installation, initialization, and configuration procedures. Manpages 
are also included for your convenience.
https://github.com/Jesse-V/OnioNS-common
https://github.com/Jesse-V/OnioNS-client
https://github.com/Jesse-V/OnioNS-HS
https://github.com/Jesse-V/OnioNS-server
Please star the repository if it works well for you.

I have claimed example.tor for my project's HS and claimed the 
arma.example.tor subdomain that points to Roger's site, so you can test this 
from the client. Please open a ticket if you find a new bug, or contact me if 
you don't have a Github account.

A brief FAQ:

Q: How does one pronounce OnioNS?
A: As one would pronounce the lowercase form: onions, the plural of onion.

Q: It only takes a couple of minutes to claim a domain name, isn't that too 
easy?
A: In this release, I have set a very small difficulty level. It will certainly 
be harder in the future and more counter-measures are being considered. Also, 
since the claims are not yet saved to disk, I offer no guarantee of their 
long-term survival.

Q: Should I use this on production hidden services?
A: No, this software is not ready. This release introduces _features_, not 
security. Tor circuits are used on both the client and HS side, but I can't 
guarantee that my SOCKS use is leak-proof, for example. I'm asking for help 
with finding bugs that may compromise anonymity.

Q: I'm running Windows/OSX/BSD/Arch/Gentoo/LFS/etc, can I test OnioNS?
A: Yes, but I'm not currently supporting that environment, so you're mostly on 
your own. However, if you can give me compilation instructions, I may be able 
to. I am also looking to coordinate with anyone familiar with RPM or Windows 
development.

Q: Is there security on your network communications?
A: Client and HS communication occurs over Tor circuits, and there are some 
integrity checks, but simply getting everything to work is the priority here. 
Most of the infrastructure is set up so adding signatures and such will be 
easy, but that is next on the list. Once that occurs, the name server (Mirror) 
the client uses can be malicious with no significant impact.

Q: Where can I learn more about this project?
A: The normal project page, onions55e7yam27n.onion, is currently being 
rewritten. A simple page is in its place, so example.tor is still there. 
Literature on this project may be found at 
https://github.com/Jesse-V/OnioNS-literature. Please see the PDFs under the 
respective folders. Note that the distributed design will be changing to use 
George's commit-and-reveal scheme.

Q: Are the servers reliable enough to run under Comcast?
A: I have not tested them in production or otherwise under 
https://github.com/tylertreat/comcast, but I may in the future. I welcome help 
in this area.

Enjoy,
Jesse V.






signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] 5th status report for OnioNS

[Jesse V]

Hi everyone,

As I stated in my last status report, I promised to work on server-to-server 
communication in preparation for a beta test. Quite a bit of work was done in 
this area, with the result that the server-server protocols are now working as 
intended and fairly reliably. The changes include:

* Ability to bind to a specific IPv4 address. This is useful not only in 
servers with multiple interfaces, but allows two instances of OnioNS-server to 
run simultaniously on localhost, which is great for testing and debugging.
* Improved server-side logging and diagnostic information. Each network session 
has it's own identification number, which makes it easy to keep track of events 
and conversations.
* Rewrote the networking code responsible for retransmitting information such 
as new Records. The servers now correctly sends Records to subscribers.
* A Mirror server now reestablishes the network connection with a Quorum server 
if the Quorum server drops from the network.
* Many bug fixes, addressing numerous issues with crashes, networking issues, 
and serialization faults.

With these changes, the OnioNS project is in a pretty good state. Here's an 
overview of the system's order of operations:

1) A single Quorum server starts up and listens on a specific IP and port. It's 
a TCP server and waits for JSON-encoded messages.
2) A Mirror server starts up, connects with and subscribes to the Quorum server.
3) A hidden service operator generates a claim on a domain name (say 
example.tor) and optionally some subdomains. This claim is represented in the 
Record data structure.
4) The operator sends the Record over a Tor circuit to the Quorum server, who 
inspects it, caches it, and sends it to all subscribers, which is the single 
Mirror node.
5) The Mirror inspects the Record, caches it, and sends it to all subscribers, 
but here it doesn't have any.
6) A client starts up the Tor Browser with the OnioNS software installed. This 
means that the starting of the Tor Browser also triggers the launching of the 
OnioNS software: a binary and a Python script.
7) The user types in example.tor. Their Python script detects the pseudo-TLD 
and performs a query lookup to the Mirror node, who replies with the Record.
8) The OnioNS-client software inspects the Record, extracts the hidden service 
address, and passes the address back to the Stem script.
9) The Stem script rewrites the original stream request from step 7 to this HS 
address and tells Tor to attach the stream to some circuit.
10) Tor attaches the stream with the effect that the hidden service loads in 
the Tor Browser.

All of these pieces are now in place and generally work as intended without 
requiring any user intervention. The step of separating the responsibility into 
two different servers is now behind me, which when coupled with the working 
subscriber-based server-server communication, gives me many options to move 
forward towards a distributed system. I have a couple of annoyance-level bugs 
to fix but a prototype is very near. I will be shortly resume building packages 
and will currently be supporting Ubuntu, Mint, Debian, and Fedora on i386, 
amd64, and armhf.

As a final note, a quick thanks to George for the well-written 
commit-reveal-consensus proposal. As he stated in his introduction, I certainly 
need that in order to integrate OnioNS with the Tor network.

Jesse V.




signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] 4th status report for OnioNS

[Jesse V]

Hello again everyone,

This report covers the period of time that I spent in Washington, DC at the 
hidden service meetings. I made excellent progress on this project. On the 
10th, for example, I pushed nearly 30 commits. I fixed many significant bugs 
and improved many areas that would make the software easier to understand and 
to configure.

* Created a separate and fully-fledged manpage for the hidden service, server, 
and client aspects of the software.
* Client-side and HS-side are now complete and working reliably. The hidden 
service can generate a Record (a claim on a domain name) and transmit it over a 
Tor circuit to a remote server. The client now has a binary that launches the 
Tor executable, the onions-client binary, and a Stem script when the Tor 
Browser opens, and can now shut them all down properly now.
* Fixed a show-stopping bug that prevented the Stem script from launching 
automatically with the Tor Browser. (George, this bug was why I had to launch 
Stem manually when I showed the software to you.) The error thrown for this bug 
was large and unhelpful, but the fix was amusingly simple: 
https://github.com/Jesse-V/OnioNS-client/commit/9e80691b02e2a843b26ac21b6b0b88daf6840667
* Many bug fixes and enhancement updates, including some points of confusion.
* Improved flexibility for hosting a server, including the capability to bind 
to a custom TCP port.
* Finalized event logging and a flag to specify where the log goes. Logs on the 
client-side now go in an OnioNS folder inside the Tor Browser directory.
* Migrated flag-parsing from the tclap library I found long ago on SourceForge 
to Unix popt.
* Added a system installation of Tor as a dependency for the hidden service 
code.
* Minor code cleanup.

Global sources of randomness were also discussed at the hidden service 
meetings. I need a source of timestamped archivable randomness that the whole 
network agrees on in order to securely build OnioNS into a distributed system. 
The global randomness also has implications for the next generation of hidden 
service protocols, so there was an overall need to get something together. We 
made good progress towards this goal.

I was able to show Roger and George a demonstration of OnioNS. I registered 
example.tor and arma.example.tor, pointed example.tor at a HS that I was 
hosting on my laptop and arma.example.tor at Roger's hidden service 
(duskgytldkxiuqc6.onion) and uploaded the Record over a Tor circuit to a remote 
machine, Server A. I then manually transfered the JSON-encoded data structures 
from Server A to Server B, another machine. Then I launched the Tor Browser 
(with my binary substitution in place) so that all of the client-side programs 
were running. I entered example.tor into the Tor Browser and as expected 
arrived at my hidden service, and then typed arma.example.tor into the browser 
and as expected loaded duskgytldkxiuqc6.onion. This was a great test. The 
server-to-server communication needs a few bug fixes, but most of that code is 
in place. As soon as that is complete, I should be about ready for a beta test.

Jesse V.




signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] 3rd status report for OnioNS

[Jesse V]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hello everyone,

I have been making significant progress on the Onion Name System project, and 
it's really coming down the home stretch here.

* I have been focusing on a four-party system: a hidden service operator, an 
authoritative server, a name server (mirror), and a client. Thus two servers 
are involved, so the responsibility is split.
* The mirror can now subscribe to the authoritative server for events, thus it 
receives new Records (claims on domain names) and new signatures on the data 
structures. The design now prevents the mirror from lying to the client.
* After some discussions with others at PETS, I have split my software into 
four separate repositories and four different packages: tor-onions-hs, 
tor-onions-client, tor-onions-server, and tor-onions-common. The first three 
now have a very focused responsibility and have dependencies on the -common 
package, a shared library that handles configuration parsing, talking to Tor, 
and other generic tasks. This also means that hidden service operators need 
only install the -hs package, which reduces the amount of code running on their 
protected server.
* I have organized all the tickets on Github into their respective repository 
and assigned most of them to milestones to indicate how soon I will be tackling 
them.
* I have also successfully integrated the software into the Tor Browser such 
that when the Tor Browser starts, Tor and the OnioNS software launch behind the 
scenes and in the correct order. My modification is a binary substitution 
rather than recompiling the Tor Launcher, but the result appears to be reliable 
and greatly simplifies the client end of things.
* In the last status report, I discussed work on logging. I have made 
significant progress on this task, which is now a critical item because the 
software now runs in the background when launched from the Tor Browser, so 
normal stdout is not seen. The software logs to Tor Browser 
dir/Browser/TorBrowser/Data/OnioNS/
* I saw DonnchaC's alpha release. I am really working on making a prototype 
that everyone can beta test. The packaging and integration into the Tor Browser 
should make this very straightforward, but I need to have all the 
configurations in place and a few more bugs worked out before then.

Jesse V.

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQEcBAEBCAAGBQJVnnvTAAoJEK2XNk/CC+yATgQH/RSG1rNzUIF9pkyPQFl0YYHP
fbor9zzdRXeHIADrnnn4trg4epGW43SCLJ2bpFiI7/keYTe6FFABE8j0W0mB8RbQ
cIERbDmfGFBgrPrx0sPxMHj99637sF2j3igIxdln5rtqbvOuXLrgI3F+a6fWdCmr
6GFgTaurGexrCI5ybvqcaMz6p2/eRDuTl+k51gz6cWPzV7mzdCzzU9Gl1miqpS6M
UB/RsjMwgGJDpcS/b0hlIXU6Zcsc1Kk3pP+czj99JsychHEUHZFSNB5qsVsDDCHq
h/BS44O/v+x2aJg1ZwL6hn02ghn0HE9hapIglERQFLxZ/pQvTsVJzUL2gaL5L8I=
=BC+c
-END PGP SIGNATURE-


___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev