On Aug 1, 2014, at 7:39 AM, tor-dev-requ...@lists.torproject.org wrote: > Send tor-dev mailing list submissions to > tor-dev@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-requ...@lists.torproject.org > > You can reach the person managing the list at > tor-dev-ow...@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 (bomer...@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 <tyran...@yahoo.co.nz> > To: "tor-dev@lists.torproject.org" <tor-dev@lists.torproject.org> > Cc: Ming Li <ming...@usu.edu> > Subject: Re: [tor-dev] DNS proposal for Tor hidden services > Message-ID: > <1406864446.92726.yahoomail...@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 <jvict...@jessevictors.com> > To: tor-dev@lists.torproject.org > Cc: Ming Li <ming...@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@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: bomer...@tiscali.it > To: <tor-dev@lists.torproject.org> > Subject: [tor-dev] New project idea > Message-ID: <d892658bbb76b60380e7a663faced...@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 <desnac...@riseup.net> > To: Nicholas Hopper <hop...@cs.umn.edu> > Cc: tor-dev@lists.torproject.org > Subject: Re: [tor-dev] Proposal 236 and the guardiness of a guard > Message-ID: <87egx0a175....@riseup.net> > Content-Type: text/plain > > Nicholas Hopper <hop...@cs.umn.edu> writes: > >> On Thu, Jul 31, 2014 at 11:24 AM, George Kadianakis >> <desnac...@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@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev > > > ------------------------------ > > End of tor-dev Digest, Vol 43, Issue 2 > **************************************
_______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev