[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