Re: [tor-talk] test
answering the test :) 2012/3/29 James Brown jbrownfi...@gmail.com test ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk -- Miguel García Lafuente - Rock Neurotiko Vocal de la Junta Directiva Nacional del Partido Pirata. Coordinador de Jóvenes Piratas en Madrid. Libertad en lugar de miedo. - Información libre, sociedad libre. El contenido de este e-mail es privado, no se permite la revelacion del contenido de este e-mail a gente ajena a él. ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
[tor-talk] test
test ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] test
On 29.03.2012 07:56, Rock Neurotiko wrote: answering the test :) thanks ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
[tor-talk] Status/progress of TorRouter?
What is the status of TorRouter? Any progress on the project? I've been monitoring the active trac tickets and wiki sites. There are no changes since a long time. Is the progress behind closed doors? What is up with that project? Became it to big, unmaintainable, time-consuming? Or what are the issues, that no one is talking about it anymore? __ powered by Secure-Mail.biz - anonymous and secure e-mail accounts. ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Status/progress of TorRouter?
On Thu, 29 Mar 2012 15:29:50 +0200 pro...@secure-mail.biz wrote: What is the status of TorRouter? Any progress on the project? I've been monitoring the active trac tickets and wiki sites. There are no changes since a long time. Is the progress behind closed doors? What is up with that project? Became it to big, unmaintainable, time-consuming? Or what are the issues, that no one is talking about it anymore? Torouter is still a work in progress. There are really two projects here, the one we want to build and ship in scale and the one the community is building already. The goal of the torouter is to increase the number of relays and bridges globally. The secondary goal is to make it easy to use tor through a dedicated device. Both projects are still so young I don't have a preference for one over the other. My goal is to get more tor relays and bridges globally. Whichever project manages to accomplish that first, wins. There are benefits and costs to both ideas. # Tor's ideas The current state is we're working on plans to build our own hardware to handle the torouter needs. The excito b3 and dreamplug hardware is great, but costs too much and includes too many other features not needed in a torouter. Features like audio/spdif, hdmi, 1080p HD video, bluetooth, etc are not needed and just increase the price of the base circuit board. We are experimenting with the Freescale iMX53 board [0] to see if the current ARMv7 chips can handle being a tor bridge or relay. It also works well as a ARM-arch build system for debs and rpms. We're working with Bunnie of Bunnie Studios[1], and he thinks the next-generation Freescale chipset and board are far better options, because of the ARMv9 architecture and crypto offload build into the chipsets. We think this is roughly a $500k project to get the hardware designed, manufactured, and to create a highly usable, point and click web interface for the system based on Debian's armhf distribution. We want to be able to offer hardware torouters, fully packaged and ready to go for under $75, while still covering ongoing support, maintenance, and future improvements. We're currently doing a beta-test of a web interface to Tor with the excito b3 hardware and around 20 people. I'll let Runa talk more about how it's going and summarize the feedback from the testers. There are lots of people excited about this project, but finding funding to get started has been a challenge. The base hardware we create can be re-purposed for other 'plug computing' projects beyond the torouter. We're pondering kickstarter as well as a for-profit subsidiary to get some funding to turn this into a reality. And finally, torouter is a poor name. Onionbox is the leading candidate for a public launch. # Community ideas The Access Labs team[2] and others continue to work on their original idea of a torouter based on openwrt with a luci/lua web interface for tor. They've made great progress and have their system working on current hardware on the market today. They are running into the challenges of running tor in tight environments with limited cpu and ram capacities. It's a fine challenge to solve, and they are making progress. Having an actual embeddable tor, which is fully functional, would be fantastic. It could open Tor up to many more devices. It's probably at the point where they could start a larger beta test to ship devices pre-configured with everything. The largest barrier to adoption is integrating their tor into an existing device. The vast majority of the world, including the technical community, wants something that just works. Buying a Buffalo device, installing openwrt, installing tor, configuring it all for transparent proxying, is more work than many are willing to do. However, buying a device that is pre-configured with all of this appeals to many more people. The future is bright and waiting. [0] https://media.torproject.org/image/community-images/imx53porn/ [1] http://www.bunniestudios.com/ [2] https://accesslabs.org/ -- Andrew http://tpo.is/contact pgp 0x6B4D6475 ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] TorRouter - kickstarter
Thanks Andrew for the detailed answer! We're pondering kickstarter as well as a for-profit I didn't know that page. Looks very well.. http://www.kickstarter.com That sounds like very reasonable plan. FreedomBox had a lot success using kickstarter. In a very short time they got loads of money. http://www.kickstarter.com/projects/721744279/push-the-freedombox-foundation-from-0-to-60-in-30 Torproject is much older and famous. Describe the idea very well and then make a big media splash out of it. I think it would work. Are there any constraints/risks trying it? __ powered by Secure-Mail.biz - anonymous and secure e-mail accounts. ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
[tor-talk] Unable To Start Vidalia
I haven't been able to find a fix for this problem. If it has been addressed anywhere please direct me there. I downloaded Tor and it worked fine for about 5 min. Then I restarted the computer because other things updated. After it came back on I tried to start Tor and it just says unable to start vidalia. I've tried restarting multiple times, googling the problem, searching the archives and tried to uninstall and reinstall Tor. I wasn't able to figure out how to uninstall it though. Any advice on how to fix the problem or where to look to find the answer would be greatly appreciated. Thanks ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Unable To Start Vidalia
Make sure you have all other proxy services turned off. If TOR wont start after that, go to the settings. Look for a high anonymous proxy server and manually input the address and port number. If that doesn't work, then send TOR support an email. From: Bla Bla spamdumpster...@yahoo.com To: tor-talk@lists.torproject.org tor-talk@lists.torproject.org Sent: Thursday, March 29, 2012 12:48 PM Subject: [tor-talk] Unable To Start Vidalia I haven't been able to find a fix for this problem. If it has been addressed anywhere please direct me there. I downloaded Tor and it worked fine for about 5 min. Then I restarted the computer because other things updated. After it came back on I tried to start Tor and it just says unable to start vidalia. I've tried restarting multiple times, googling the problem, searching the archives and tried to uninstall and reinstall Tor. I wasn't able to figure out how to uninstall it though. Any advice on how to fix the problem or where to look to find the answer would be greatly appreciated. Thanks ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
[tor-talk] obfsproxy
Hi, is there any deb package or Ubuntu PPA repository for obfsproxy? If not - are there any plans for that? Regards, Matej ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] obfsproxy
Hi, is there any deb package or Ubuntu PPA repository for obfsproxy? If not - are there any plans for that? Regards, Matej Although compiling obfsproxy is as easy as it could be, I asked that questions myself. https://trac.torproject.org/projects/tor/query?status=acceptedstatus=assignedstatus=closedstatus=needs_informationstatus=needs_reviewstatus=needs_revisionstatus=newstatus=reopenedcomponent=Obfsproxyorder=priority https://trac.torproject.org/projects/tor/ticket/4926 asn says Next task is to fix all the bugs that weasel found (...) and make a 0.1.1 release that can actually be packaged by Linux distributions,. I don't think it's a good idea to wait for the distros. It can take quite some time. And torproject.org has it's own repository because they stated at some points somewhere (I don't find it anymore.), that the distributions repository have not been reliably updated. I haven't seen any ticket for creating a .deb package. Perhaps obfsproxy should also be added to the torproject.org repository? __ powered by Secure-Mail.biz - anonymous and secure e-mail accounts. ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
[tor-talk] Choosing a name for a .onon
Hi all, I was under the impression that the .onion names for Tor Hidden Services were pseudo-random based on the public key. How was someone able to choose one/choose some character in one? As an example: http://silkroadvb5piz3r.onion (hope it is not against policy to post that link, only example I know. ) How did they choose the first 8 characters? Thanks, Adrian -- The ability to quote is a serviceable substitute for wit. ~ W. Somerset Maugham The ability to Google can be a serviceable substitute for technical knowledge. ~ Adrian D. Crenshaw ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Choosing a name for a .onon
On Thu, Mar 29, 2012 at 6:47 PM, Adrian Crenshaw irong...@irongeek.com wrote: Hi all, I was under the impression that the .onion names for Tor Hidden Services were pseudo-random based on the public key. How was someone able to choose one/choose some character in one? As an example: http://silkroadvb5piz3r.onion (hope it is not against policy to post that link, only example I know. ) How did they choose the first 8 characters? Using a brute force search tool like http://gitorious.org/shallot/shallot/ I'd advise against it— while I don't have a study to back me up I expect 'readable' names like that discourage good security practices— that they cause people to use addresses (spread in that look like yours, perhaps) without verifying the source— and when people do compare they are probably more likely to just compare the readable parts. sure, the computation is a bit of a barrier— but it's easier for the attacker (who may generate fake onions for many sites at once) then it is for the defender. ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Choosing a name for a .onon
Adrian Crenshaw writes: Hi all, I was under the impression that the .onion names for Tor Hidden Services were pseudo-random based on the public key. How was someone able to choose one/choose some character in one? As an example: http://silkroadvb5piz3r.onion (hope it is not against policy to post that link, only example I know. ) How did they choose the first 8 characters? The basic answer is try a lot of possibilities on a computer until the one you want comes up! According to https://gitweb.torproject.org/torspec.git?a=blob_plain;hb=HEAD;f=rend-spec.txt the .onion name is a base32-encoded version of the first 80 bits of the SHA1 of the hidden service public key. base32 is 5 bits per character, so the prefix silkroad in the .onion address above is 5×8=40 bits (indeed, exactly half of the 80 bits in the entire .onion name). Choosing the first 40 bits of a hash generally requires trying an average of 2⁴⁰ possibilities; my laptop does about 3-4 million SHA1 operations per second (per CPU core) so it would take me 3-4 days (per CPU core) of computation to try that many possibilities on my laptop. Since hash value searches are completely parallelizable, you can make this arbitrarily faster by adding more computers to the search. Of course this requires being able to change something trivial about the public key when generating the .onion address. (Generating a new public key from scratch would be very time-consuming; making a 1024-bit keypair from scratch on my machine takes around 0.1 second, depending on how lucky the key-generation process gets, which is considerably longer than the 0.003 seconds that trying a SHA1 operation requires.) I'm not sure exactly what you would change because I'm not sure what data is (or can be) included in a hidden service public key, but there's probably something you can change without actually needing to make a new keypair. There's a nice description of the possibility of creating a public key with a chosen set of bits at the beginning or end at http://www.asheesh.org/note/debian/short-key-ids-are-bad-news.html although note that the Tor hidden service identifiers are 80 bits, while PGP short key IDs are only 32 bits, so it's 2⁴⁸ times as hard to fake a hidden service as it is to make a colliding PGP short key ID. (Full PGP fingerprints are 160 bits.) I first got interested in this when I used to develop a live-CD called LNX-BBC (for bootable business card). At that time we were using MD5 checksums on our web site, and I wrote a program to try lots of possibilities so that all of our MD5 values started with bbcbbc in hexadecimal (on average only 2²⁴ MD5 attempts). For more on the base32 encoding, see https://en.wikipedia.org/wiki/Base32 -- Seth Schoen sch...@eff.org Senior Staff Technologist https://www.eff.org/ Electronic Frontier Foundation https://www.eff.org/join 454 Shotwell Street, San Francisco, CA 94110 +1 415 436 9333 x107 ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Choosing a name for a .onon
On Fri, Mar 30, 2012 at 01:54, Seth David Schoen sch...@eff.org wrote: Choosing the first 40 bits of a hash generally requires trying an average of 2⁴⁰ possibilities; my laptop does about 3-4 million SHA1 operations per second (per CPU core) so it would take me 3-4 days (per CPU core) of computation to try that many possibilities on my laptop. Due to proliferation of Bitcoin, there are now very efficient SHA-256 generators for off-the-shelf GPUs. The numbers at [1] suggest performance that's at least two orders of magnitude faster than your laptop — and for double-SHA-256 instead of a single SHA-1 (which I assume can be done by the same software after some simple adaptation). [1] https://en.bitcoin.it/wiki/Mining_hardware_comparison Of course this requires being able to change something trivial about the public key when generating the .onion address. Not necessarily — you can generate the hash first, and then check whether the public key is legal. I.e., generate a 512-bit prime p, and then go on with producing a completely random 512-bit e, and checking whether SHA-1(ASN.1-RSAPublicKey(modulus=p*e, exponent=65537)) (which is how Tor computes the .onion address) produces the desired result. If it does, check whether e is prime. Density of primes in the range of e is ~1/512, so that's just 9 bits more of search space, and primality checking efficiency doesn't matter much. -- Maxim Kammerer Liberté Linux (discussion / support: http://dee.su/liberte-contribute) ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Choosing a name for a .onon
On 2012-03-30, Maxim Kammerer m...@dee.su wrote: On Fri, Mar 30, 2012 at 01:54, Seth David Schoen sch...@eff.org wrote: Choosing the first 40 bits of a hash generally requires trying an average of 2⁴⁰ possibilities; my laptop does about 3-4 million SHA1 operations per second (per CPU core) so it would take me 3-4 days (per CPU core) of computation to try that many possibilities on my laptop. Due to proliferation of Bitcoin, there are now very efficient SHA-256 generators for off-the-shelf GPUs. The numbers at [1] suggest performance that's at least two orders of magnitude faster than your laptop — and for double-SHA-256 instead of a single SHA-1 (which I assume can be done by the same software after some simple adaptation). [1] https://en.bitcoin.it/wiki/Mining_hardware_comparison Of course this requires being able to change something trivial about the public key when generating the .onion address. Not necessarily — you can generate the hash first, and then check whether the public key is legal. I.e., generate a 512-bit prime p, and then go on with producing a completely random 512-bit e, and checking whether SHA-1(ASN.1-RSAPublicKey(modulus=p*e, exponent=65537)) (which is how Tor computes the .onion address) produces the desired result. If it does, check whether e is prime. Density of primes in the range of e is ~1/512, so that's just 9 bits more of search space, and primality checking efficiency doesn't matter much. Shallot computes a single public modulus p*q and searches for a public exponent e which produces a SHA-1 hash with the desired properties. That's much faster than doing a 512-bit-by-512-bit bignum multiply for each hash, *and* the search for a suitable exponent could (in theory) be performed in parallel across many (untrusted) computers. Robert Ransom ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Choosing a name for a .onon
On 2012-03-30, Maxim Kammerer m...@dee.su wrote:
On Fri, Mar 30, 2012 at 06:06, Robert Ransom rransom.8...@gmail.com wrote:
Shallot computes a single public modulus p*q and searches for a public
exponent e which produces a SHA-1 hash with the desired properties.
For some reason I thought that that would produce non-standard RSA
keys, perhaps because the old ssl-genrsa only supported e={3,65537}
(whereas the new ssl-genpkey doesn't have this limitation). Isn't the
point of e like 3 or 65537 (with few bits set) to make encryption
fast?
Yes. (Note that hidden service identity public keys are only used for
signature verification, which is not the same as encryption with any
modern padding scheme.)
But Tor didn't enforce that requirement for hidden service identity
keys soon enough, and I don't think OpenSSL's RSA implementation
benefits much from those particular choices of e (other than from the
fact that they're short).
Do you know whether Shallot-produced RSA keys have any
noticeable detrimental effect on relays load because of the
unrestricted exponent?
Maybe a little. No one will let Shallot run long enough to produce a
really big public exponent, though. (Relays raise 1024-bit numbers to
320-bit powers all the time for forward secrecy. Shallot won't
generate 320-bit public exponents.)
Maliciously generated hidden service identity keys could have much
larger public exponents, but hopefully no one will bother implementing
that DoS attack.
That's much faster than doing a 512-bit-by-512-bit bignum multiply for
each hash, *and* the search for a suitable exponent could (in theory)
be performed in parallel across many (untrusted) computers.
Sure, but you don't have to do it in the most straightforward way. You
can multiply once, and then add 2p for each hash. The overhead for a
GPU / FPGA implementation should be negligible, and the search can be
parallelized as well.
Maybe. But note that the public exponent is stored at the end of the
public key blob, so updating the exponent (or a piece of it) also
makes generating each hash easier.
If adding large multiples of p, the nodes can be
untrusted, too, I guess.
No -- the Euclidean algorithm would break that *very* quickly.
Robert Ransom
___
tor-talk mailing list
tor-talk@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
