[tor-dev] unsubscribe

Patrick Reed patrick.j.reed2 at gmail.com
Fri Aug 1 11:51:47 UTC 2014


On Aug 1, 2014, at 7:39 AM, tor-dev-request at lists.torproject.org wrote:

> Send tor-dev mailing list submissions to
> 	tor-dev at lists.torproject.org
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> 	https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
> or, via email, send a message with subject or body 'help' to
> 	tor-dev-request at lists.torproject.org
> 
> You can reach the person managing the list at
> 	tor-dev-owner at lists.torproject.org
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of tor-dev digest..."
> 
> 
> Today's Topics:
> 
>   1. Re: DNS proposal for Tor hidden services (Tyrano Sauro)
>   2. New project idea (bomerino at tiscali.it)
>   3. Re: Proposal 236 and the guardiness of a guard (George Kadianakis)
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Thu, 31 Jul 2014 20:40:46 -0700
> From: Tyrano Sauro <tyranosu at yahoo.co.nz>
> To: "tor-dev at lists.torproject.org" <tor-dev at lists.torproject.org>
> Cc: Ming Li <ming.li at usu.edu>
> Subject: Re: [tor-dev] DNS proposal for Tor hidden services
> Message-ID:
> 	<1406864446.92726.YahooMailNeo at web163106.mail.bf1.yahoo.com>
> Content-Type: text/plain; charset="utf-8"
> 
> Can we know a DNS for the normal HTTP of a hidden service?
> If the onion hidden name cannot reach from outside of Tor then maybe use that?
> 
> 
> 
> ________________________________
> From: Jesse Victors <jvictors at jessevictors.com>
> To: tor-dev at lists.torproject.org 
> Cc: Ming Li <ming.li at usu.edu> 
> Sent: Tuesday, 29 July 2014 6:03 PM
> Subject: [tor-dev] DNS proposal for Tor hidden services
> 
> 
> 
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
> 
> 
> Hello everyone,
> 
> I have a proposal for Tor hidden services, which if it's a good idea
>    and workable I may be writing my Master's thesis on. My description
>    here is very early, and I would like to run it by you guys before I
>    continue further. I have already run it past Tor developers, but
>    have seen limited response, so I'm opening it up to a wider
>    audience. Basically, I propose integrating Namecoin into supporting
>    Tor relays, so as to provide a secure DNS service for .onion sites
>    within Tor itself. The result is that a human-readable address can
>    be translated into its .onion counterpart, analogous to a domain
>    name resolving into an IP address on the regular Internet, a square
>    of Zooko's Triangle conjecture.
> 
> Namecoin has a nearly identical codebase to Bitcoin, but instead of
>    currency its primary focus is holding information, with a focus in
>    DNS. Domains in Namecoin have the .bit extension, and registrations
>    are secured with hashes in a blockchain. Anyone with the Namecoin
>    blockchain can look up information in it, and indeed there are
>    already Namecoin-supporting DNS servers that use the Namecoin
>    blockchain to look up registrations in it. These basic premises are
>    at the heart of my idea. Now, 3g2upl4pq6kufc4m.onion is the address
>    for the DuckDuckGo hidden service, but it's hard to remember: even
>    worse than a traditional IP address. Under my idea, a user could
>    type in duckduckgo.tor, would see a secure translation to
>    3g2upl4pq6kufc4m.onion transparently and with masking, increasing
>    the usability and popularity of hidden services significantly.
> 
> My plan is in the context of Tor, to use the .tor domain, so as to
>    not conflict with existing Namecoin registrations. The .onion
>    address is a hash of the hidden service's public key, so if I own
>    the private keys to 3g2upl4pq6kufc4m.onion, I should be able to sign
>    something (perhaps the Namecoin public DSA key) to prove my
>    ownership and set duckduckgo.tor.bit to point to
>    3g2upl4pq6kufc4m.onion. I then upload this to the Namecoin network
>    as usual, (this costs 0.01 Namecoin) so that it becomes integrated
>    into the blockchain. So now duckduckgo.tor.bit points to
>    3g2upl4pq6kufc4m.onion, and everyone with the blockchain knows it.
>    Global DNS propagation may take less than 15 minutes. Namecoin
>    domain registrations expire after 36,000 blocks (about 200 days) so
>    a registration would have to be renewed occasionally for it to still
>    remain. This is free to do, but ensures that domains don't endure
>    indefinitely.
> 
> It's impractical for Tor users to download the Namecoin blockchain
>    in order to use this system, (even with Merkle trees) so instead
>    supporting Tor relays can hold a copy and the Tor client can send
>    out queries to them. At startup, Tor clients build several circuits
>    through the network in preparation for use. Now let's say the user
>    wants to look up duckduckgo.tor. To avoid spoofing attacks from a
>    malicious relay, Tor clients will query multiple relays and gain a
>    consensus. To do this, the Tor client generates three nonces, N1,
>    N2, and N3. It then picks three random relays, possible trusted
>    relays like guards, R1, R2, and R3. These relays have public RSA
>    keys K1, K2, and K3, respectively. For each of the three relays, the
>    Tor client takes the request for duckduckgo.tor, nonce Nj, and
>    encrypts the pair with the relay's public key Kj. Along with a
>    special new Tor flag specifying the use of this protocol, it then
>    sends the trio through the circuit to the middle relay. The middle
>    relay then queries the three relays. Each relay decrypts the request
>    using its private key, checks the blockchain for duckduckgo.tor.bit,
>    finds 3g2upl4pq6kufc4m.onion, and encrypts this answer with the
>    nonce, and sends it back, signing the result. The client receives
>    the answers, checks the signatures, decrypts the responses from the
>    three relays using the nonces, and compares the response. If all
>    three match, it then looks up 3g2upl4pq6kufc4m.onion in the
>    traditional way. If two or less match, it restarts with a different
>    set of three relays. If all three relays return that duckduckgo.tor
>    can't be found, it throws the standard DNS error message.
> 
> So I am simply building on top of the existing Tor hidden service
>    infrastructure, not modifying it. I can write up a proposal for
>    torspec.git once I have more details. I've already taken Tor
>    0.2.5.6-alpha code, installed Tor from source, and used Chutney to
>    set up a mini Tor network on localhost of 5 authorities, 10 relays,
>    and 1 client. That seems a good platform for development on this.
> 
> What do you guys think about my proposal? Is this a good idea, and
>    feasible? Anything I should watch out for as I go forward? What
>    security threats exist that I should specifically defend against?
> 
> Thank you for your time.
> 
> - -- 
> Jesse V.
> /CS, Network Security/
> /Utah State University/
> 
> 
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.14 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
> 
> iQF8BAEBCgBmBQJT2BouXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
> ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQxMjgyMjhENjEyODQ1OTU1NzBCMjgwRkFB
> RDk3MzY0RkMyMEJFQzgwAAoJEK2XNk/CC+yA98MH/ih8VMQ8ZaKInYDDe3HBiU/s
> 9XBoGUT7ouXqnmtjSLjeTJjDfaNmLYBIRsAJTk8n/mJ7Zz9ld/5FW/QNKd1hAelE
> wtL4hKyVhS70fWVkFqZTLLyeVHVbegJx5sF2YdkDD6cJDU//KNbXTCO7A1Bx9vOu
> vPFoA+3ytlKcpx8HZn//k0mD7cB/dcS2GwSQmG2C+X0pWooJIsAJCgKyetbAaiHL
> ub/sd6Sr0bgkItGOi9vlAdPo+p7nNMWVxQQPfNqzz1zQJzE3WRXpXKmIYAOtngWp
> VT6SyrSkOmir/1+LN/s9d22VMaQKAzUVz21gbugBr64moeQW/IWbWBOQSbFA0J0=
> =8zWV
> -----END PGP SIGNATURE-----
> 
> 
> _______________________________________________
> tor-dev mailing list
> tor-dev at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20140731/697e6781/attachment-0001.html>
> 
> ------------------------------
> 
> Message: 2
> Date: Fri, 01 Aug 2014 13:37:52 +0200
> From: bomerino at tiscali.it
> To: <tor-dev at lists.torproject.org>
> Subject: [tor-dev] New project idea
> Message-ID: <d892658bbb76b60380e7a663faced81e at tiscali.it>
> Content-Type: text/plain; charset="utf-8"
> 
> 
> 
> Hi all, 
> 
> my name is Omar, I am 33 years old and I am an Italian IT
> Engineer, I have worked for more than 10 years in coding and now I am a
> Portfolio Manager. I am quite interesting in TOR and in the application
> related. I have these two following idea for new TOR related project
> (obviously if you think can be useful I would like to be the owner, to
> have the property right or I do not how work this...please give me more
> information regarding that): 
> 
> 1. the first idea is more related to
> OnionCoffee, due to the fact that I would like use this library to
> provide another kind of anonyms for android, and if possible why not for
> apple. What I mean is to create a "ping pong" signal with several
> different Base Station so that your current location is unknown or
> appear like if you are in several place in the same time if someone
> trying to follow your mobile and your physical movement, or through GPS
> or through the signal you exchange with your nearer base station where
> you smart phone is connected. this is help you to stay safe and located
> in several place and not in only one, so if people looking for you and
> map your physical movement they do not know where you are really located
> 
> 
> 2. the second idea is TOR related, because I know TOR manage the
> header of the package send by TCP protocol so that no one can trace your
> connection and I would like to create an encryption library that encode
> and decode all the content of the data exchanged in the payload with a
> quantum cryptography algorithm, that give you the chance to exchange
> data and if something happen during the connection (like someone try to
> attack your data) the data content change, like in the Heisenberg
> principle. Create a client java library that encode and decode all
> content that you want to encrypt, for example a private chat. This I
> dare say add a new level of anonymity in addition to the fact to hide
> you location and who you are: you hide the content of what you are
> doing. 
> 
> I would like to create this two kind of project having the
> copyright of the idea and becoming the owner of this two projects. Of
> course I need technical knowledge support to build this. In which way
> TOR organize these things or I have to think to everything? 
> 
> What do
> you think about that? 
> 
> Thanks for your advises on my idea. 
> 
> Regards 
> 
> 
> 
> Scopri istella, il nuovo motore per il web italiano.
> Istella garantisce risultati di qualit? e la possibilit? di condividere, in modo semplice e veloce, documenti, immagini, audio e video.
> Usa istella, vai su http://www.istella.it?wtk=amc138614816829636
> 
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20140801/8bde1fa1/attachment-0001.html>
> 
> ------------------------------
> 
> Message: 3
> Date: Fri, 01 Aug 2014 14:39:26 +0300
> From: George Kadianakis <desnacked at riseup.net>
> To: Nicholas Hopper <hopper at cs.umn.edu>
> Cc: tor-dev at lists.torproject.org
> Subject: Re: [tor-dev] Proposal 236 and the guardiness of a guard
> Message-ID: <87egx0a175.fsf at riseup.net>
> Content-Type: text/plain
> 
> Nicholas Hopper <hopper at cs.umn.edu> writes:
> 
>> On Thu, Jul 31, 2014 at 11:24 AM, George Kadianakis
>> <desnacked at riseup.net> wrote:
>>> - You can see that old guards (like RichardFeynman) see a shrinkage
>>>  both on their guard and on their middle probabilities. This happens
>>>  because both the total guard weight and the total middle weight get
>>>  bigger [5], so their weight percentage gets smaller.
>> 
>> This doesn't sound right - total guard weight shouldn't change.  All
>> the proposal does is re-allocate some fraction of the weight of a
>> guard back to the middle (M) category.
> 
> Oops, you are right!
> 
> On my previous post, please disregard anything that had to do with
> guards probabilities then.
> 
> In this light, the behavior with Guard+Exit is good. That is, even for
> young guards (that are also exits), their middle probability is
> decreased, hence prioritizing exit traffic.
> 
> Also thanks for the comments on the #9321 questions.
> 
> Moving forward!
> 
> 
> 
> ------------------------------
> 
> Subject: Digest Footer
> 
> _______________________________________________
> tor-dev mailing list
> tor-dev at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
> 
> 
> ------------------------------
> 
> End of tor-dev Digest, Vol 43, Issue 2
> **************************************



More information about the tor-dev mailing list