Re: Is http://serifos.eecs.harvard.edu dead?
Thanks for the answers, i know most of the mentioned urls, but how can i access a text file with all tor servers? I never saw something like that on these pages, not even a link. I tried this: http://torstatus.kgprog.com/exit.pl?textonly=1 and the result was a FORBIDDEN (You don't have permission to access /exit.pl on this server.) message. -Dieter Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs
Re: Is http://serifos.eecs.harvard.edu dead?
Dieter Zinke schrieb: Thanks for the answers, i know most of the mentioned urls, but how can i access a text file with all tor servers? I never saw something like that on these pages, not even a link. The easiest may be to use the file your tor node has, as it contains all potentially usable routers: cached-descriptors (or cached-routers for older Tor versions). (Additionally you may need the consensus to find out which ones are running/valid (cached-consensus)). Dominik
Re: Compromised entry guards rejecting safe circuits (was Re: OSI 1-3 attack on Tor? in it.wikipedia)
Roger Dingledine wrote: (I changed the thread's Subject, since Anon Mus's attack is not the same as the attack described on it.wikipedia.) Here's the original quote text translation of the article in it.wikipedia from the starting thread to which I replied. quote: Tor works on assuming IP protocol's integrity. An ISP, however, can work on a lower OSI level to divert an user's Tor traffic to a separate, fake server. ATM switching or MPLS labeling can be used to selectively deviate an user's Tor traffic towards a third-party controlled Tor network. Therefore, IP address and key exchange with an unknown peer do not ensure that an user has not connected to a rogue node. I think this compares well with most of the aspects of the scenario I described in my reply, albeit I added the necessary pass through component out to the real tor network to make it work. [The ATM switching or MPLS labeling is just the lower-layer network protocol/method, many IP networks operate over these, its common place, so don't be confused by that.] On Fri, Feb 15, 2008 at 12:42:59PM -0800, Anon Mus wrote: F. Fox wrote: Anon Mus wrote: 3. Attacker has a list of known public/private key pairs. These are generated over the years by government security service supercomputers and their own secure network computers (around the world). Such lists are regularly swapped between 'friendly' countries and are fro sale on the black market. Given any tor nodes public key, the attacker looks up that key in the list and it returns the tor nodes genuine private key, where it has it in its list. (Interesting note: here you have to imagine that there is software of out there, like the tor network itself, which could be used for generating and acquiring billions of key pairs a year over millions of networked computers world wide. You only need to store the key pairs such networked software generates after they have finished with them.) Umm... unless you're talking about lists of *compromised* keys (i.e., stolen, like via malware), then this is pure FUD. Trying to figure out the private key by other means, is pretty infeasible. I agree with others here that this particular item from Anon Mus is bogus. The math simply doesn't work this way: 1024 bits is really big, and enumerating and storing products of 512ish-bit primes is going to fill up your disk way before you have a non-trivial fraction of them. Take a look at figure 1 in here... http://home.zonnet.nl/galien8/prime/prime.html now reframe the graph there in 512bit primes and extrapolate the graph. The US NSA has many floors of high density storage archives. Like a supermassive automated DVD changer. I must say, I feel that 3 very deliberate and clumbsy attempts have been to shoot down such a VERY obvious and sound scenario. Why so? Probably the reason they all misinterpreted your attack is the thread you posted it in (which describes a similar-sounding attack that *is* bogus), plus the above A.3 which sounds like it's straight out of some conspiracy theory. Theory??? Facts::: Connection machines: http://en.wikipedia.org/wiki/Connection_Machine CM5: http://en.wikipedia.org/wiki/FROSTBURG Also at connection machines at US edu's Univ. Penn http://www.ese.upenn.edu/facilities.html Univ. Maryland http://www.ece.umd.edu/Academic/Grad/Gen_info/ginfodoc.html Univ. Florida http://www.cise.ufl.edu/~jnw/IA/ia-software.html Univ. Florida AM http://www.oakridge.doe.gov/diversity/florida.html Now THIS is what I call a conspiracy theory ( :D )::: A fully global networked array of prime number testers, prime numbers being the underlying basis for your public key encryption technology. 1 million decimal digit long primes achieved, the search for 10 million digit primes underway. http://en.wikipedia.org/wiki/Great_Internet_Mersenne_Prime_Search http://mersenne.org/primenet/ The virtual machine's sustained throughput http://mersenne.org/ips/stats.html* is currently *29479 billion floating point operations per second* (gigaflops), or 2448.9 CPU years (Pentium 90Mhz) computing time per day. For the testing of Mersenne numbers, this is equivalent to 1052 Cray T916 supercomputers Take a look at just which org is offering the $100,000 prize !!! (In the para. headed by *v22.12 Mersenne Research Software Released)* http://mersenne.org/ips/index.html#contest This project went live in 1997 and the CM5 ( http://en.wikipedia.org/wiki/FROSTBURG ) was phased out in 1999 .. you decide. Makes 512 bit prime location and storage look like a walk in the park. Now that we've cleared that up (if we have), let me rephrase your attack and we can see if it makes sense to more people here. Imagine an adversary who can observe any connection attempt from Alice and fail any of them that he wants. Imagine this adversary also runs, say, 10% of the Tor network, including some guard nodes and some
Re: Compromised entry guards rejecting safe circuits (was Re: OSI 1-3 attack on Tor? in it.wikipedia)
Anon Mus wrote: A fully global networked array of prime number testers, prime numbers being the underlying basis for your public key encryption technology. 1 million decimal digit long primes achieved, the search for 10 million digit primes underway. http://en.wikipedia.org/wiki/Great_Internet_Mersenne_Prime_Search http://mersenne.org/primenet/ The virtual machine's sustained throughput http://mersenne.org/ips/stats.html* is currently *29479 billion floating point operations per second* (gigaflops), or 2448.9 CPU years (Pentium 90Mhz) computing time per day. For the testing of Mersenne numbers, this is equivalent to 1052 Cray T916 supercomputers Take a look at just which org is offering the $100,000 prize !!! (In the para. headed by *v22.12 Mersenne Research Software Released)* http://mersenne.org/ips/index.html#contest This project went live in 1997 and the CM5 ( http://en.wikipedia.org/wiki/FROSTBURG ) was phased out in 1999 .. you decide. Makes 512 bit prime location and storage look like a walk in the park. You're suffering from several very serious misconceptions. First off, the Mersenne primality testing network is designed to test prime numbers of a very specific type, namely 2^n-1. It turns out that you can test primality for those numbers in a much more efficient manner than for general primes. The Mersenne algorithm is useless for general primes, and virtually every prime used in modern cryptography is not going to be a Mersenne prime. Second, merely testing to see if something is prime is not isn't particularly helpful in breaking modern cryptography. You already know that the public key isn't a prime (since it's the product of two private keys) and you also already know that the private keys are prime (since that's necessary for the algorithm to function.) What you'd need to do in order to derive the private keys from a public key is to *factor* an extremely large number with no convenient properties. This is an entirely different issue from mere primality testing. Without major breakthroughs in number factoring, I seem to remember it's actually provable that modern public keys literally cannot be factored within the heat death of the universe. As in, if you turned every atom of the universe into energy, and used it to power a universe-sized supercomputer which reaches the theoretical limits of efficiency, you would not be done factoring a single public key by the time you ran out of energy. Unless you want to claim that the US government is actually *more powerful* than this, any number of supercomputers and databases they might have is completely irrelevant. Now, if you do want to keep on with the the government is all-powerful and can corrupt Tor installations easily, there's a few easy tactics you can use. First, you can claim that the US governmenet has come up with a factoring breakthrough that makes factoring - and thus far, far easier. There's certainly nothing we've discovered yet that proves this is impossible. Of course, there's no evidence for it being possible either. Second, private keys are only as secure as they system they are stored on. Much more plausibly, you could claim that the US government has backdoors into most (if not all) modern OSes, including the ones used to generate Tor's directory server private keys. If the government got the private keys that way there would be, of course, no barrier to them intercepting Tor communications in exactly the way you claim. But claiming that the government has huge datacenters that derive public keys from private keys is simply impossible. The math doesn't add up. Now for a bit of hard math, just to demonstrate that you need to think about your numbers a bit further: The density of prime numbers can be approximated as 1/log(N), as you've mentioned. This means, for 256-binary-digit primes, the density is approximately 1/log(2^256) or 0.012976. There are 2^255 (that's about 5.7896 * 10^76) 256-digit numbers, therefore we can assume that there are approximately 1/log(2^256) * 2^255 primes in that area. This is approximately 7.5127 * 10^74 primes. If we assume we can store each prime number on a single atom of hydrogen (this is obviously a hilarious overestimation of storage density, but bear with me) we can store 6.02214 * 10^23 prime numbers in one gram of hydrogen. Thus we will need 1.2475 * 10^51 grams in order to store our prime database. The Sun masses approximately 1.98892 * 10^33 grams, so we'll need the hydrogen of approximately 627 thousand million million suns merely to store a list of all the 256-digit prime numbers. If Tor uses 512-bit keys then we're approximately seventy orders of magnitude too small, however. (That was actually kind of fun to work out.) -Ben
Re: Is http://serifos.eecs.harvard.edu dead?
Dieter Zinke wrote: Thanks for the answers, i know most of the mentioned urls, but how can i access a text file with all tor servers? * CSV List of All Current Tor Server IP Addresses http://torstatus.kgprog.com/ip_list_all.php http://torstatus.blutmagie.de/ip_list_all.php * CSV List of All Current Tor Server Exit Node IP Addresses http://torstatus.kgprog.com/ip_list_exit.php http://torstatus.blutmagie.de/ip_list_exit.php https works as well Olaf
Re: Compromised entry guards rejecting safe circuits (was Re: OSI 1-3 attack on Tor? in it.wikipedia)
Ben Wilhelm wrote: Anon Mus wrote: A fully global networked array of prime number testers, prime numbers being the underlying basis for your public key encryption technology. 1 million decimal digit long primes achieved, the search for 10 million digit primes underway. http://en.wikipedia.org/wiki/Great_Internet_Mersenne_Prime_Search http://mersenne.org/primenet/ The virtual machine's sustained throughput http://mersenne.org/ips/stats.html* is currently *29479 billion floating point operations per second* (gigaflops), or 2448.9 CPU years (Pentium 90Mhz) computing time per day. For the testing of Mersenne numbers, this is equivalent to 1052 Cray T916 supercomputers Take a look at just which org is offering the $100,000 prize !!! (In the para. headed by *v22.12 Mersenne Research Software Released)* http://mersenne.org/ips/index.html#contest This project went live in 1997 and the CM5 ( http://en.wikipedia.org/wiki/FROSTBURG ) was phased out in 1999 .. you decide. Makes 512 bit prime location and storage look like a walk in the park. You're suffering from several very serious misconceptions. First off, the Mersenne primality testing network is designed to test prime numbers of a very specific type, namely 2^n-1. It turns out that you can test primality for those numbers in a much more efficient manner than for general primes. The Mersenne algorithm is useless for general primes, and virtually every prime used in modern cryptography is not going to be a Mersenne prime. Second, merely testing to see if something is prime is not isn't particularly helpful in breaking modern cryptography. You already know that the public key isn't a prime (since it's the product of two private keys) and you also already know that the private keys are prime (since that's necessary for the algorithm to function.) What you'd need to do in order to derive the private keys from a public key is to *factor* an extremely large number with no convenient properties. This is an entirely different issue from mere primality testing. Without major breakthroughs in number factoring, I seem to remember it's actually provable that modern public keys literally cannot be factored within the heat death of the universe. As in, if you turned every atom of the universe into energy, and used it to power a universe-sized supercomputer which reaches the theoretical limits of efficiency, you would not be done factoring a single public key by the time you ran out of energy. Unless you want to claim that the US government is actually *more powerful* than this, any number of supercomputers and databases they might have is completely irrelevant. Now, if you do want to keep on with the the government is all-powerful and can corrupt Tor installations easily, there's a few easy tactics you can use. First, you can claim that the US governmenet has come up with a factoring breakthrough that makes factoring - and thus far, far easier. There's certainly nothing we've discovered yet that proves this is impossible. Of course, there's no evidence for it being possible either. Second, private keys are only as secure as they system they are stored on. Much more plausibly, you could claim that the US government has backdoors into most (if not all) modern OSes, including the ones used to generate Tor's directory server private keys. If the government got the private keys that way there would be, of course, no barrier to them intercepting Tor communications in exactly the way you claim. But claiming that the government has huge datacenters that derive public keys from private keys is simply impossible. The math doesn't add up. Now for a bit of hard math, just to demonstrate that you need to think about your numbers a bit further: The density of prime numbers can be approximated as 1/log(N), as you've mentioned. This means, for 256-binary-digit primes, the density is approximately 1/log(2^256) or 0.012976. There are 2^255 (that's about 5.7896 * 10^76) 256-digit numbers, therefore we can assume that there are approximately 1/log(2^256) * 2^255 primes in that area. This is approximately 7.5127 * 10^74 primes. If we assume we can store each prime number on a single atom of hydrogen (this is obviously a hilarious overestimation of storage density, but bear with me) we can store 6.02214 * 10^23 prime numbers in one gram of hydrogen. Thus we will need 1.2475 * 10^51 grams in order to store our prime database. The Sun masses approximately 1.98892 * 10^33 grams, so we'll need the hydrogen of approximately 627 thousand million million suns merely to store a list of all the 256-digit prime numbers. If Tor uses 512-bit keys then we're approximately seventy orders of magnitude too small, however. (That was actually kind of fun to work out.) -Ben Ben, Yes you are right factorising this is hard, but thats not what I've been
.onion sites fail to load with: (waiting for rendezvous desc)
I'm seeing this message in terminal running Tor when trying to connect to any .onion sites: [notice] Tried for 120 seconds to get a connection to [scrubbed]:80. Giving up. (waiting for rendezvous desc), followed by a Privoxy 502 error. Where these pages once loaded for me, they now all fail after attempting to load with the reason given in Tor above. Others have verified the .onion sites I try to connect to as up and running, but I can almost never connect to them anymore. I'm running the latest Tor alpha. Every other use of Tor works fine, only this problem when trying .onion sites. Any clues on what may be wrong and how to fix plz? thx -- [EMAIL PROTECTED] -- http://www.fastmail.fm - Does exactly what it says on the tin
Re: Compromised entry guards rejecting safe circuits (was Re: OSI 1-3 attack on Tor? in it.wikipedia)
Anon Mus schrieb: Yes you are right factorising this is hard, but thats not what I've been suggesting. What if every time you generated a pair of keys you stored the result somewhere! Did you read Ben's comment about storage space for storing a huge number of primes? It is quite impossible to store a significant percentage of the keyspace of a key with 1024 bits. For even 1% you would have to store 2^1024/100 keys: 17976931348623159077293051907890247336179769789423065727343008115773\ 26758055009631327084773224075360211201138798713933576587897688144166\ 22492847430639474124377767893424865485276302219601246094119453082952\ 08500576883815068234246288147391311054082723716335051068458629823994\ 724593847971630483535632962422413721 And even if you could store that: there are much easier ways to compromise a Tor user. If breaking public/private key based encryption would be that easy, then nobody would use it but working on better encryption schemes. Dominik
Re: Compromised entry guards rejecting safe circuits (was Re: OSI 1-3 attack on Tor? in it.wikipedia)
Anon Mus wrote: Ben, Yes you are right factorising this is hard, but thats not what I've been suggesting. What if every time you generated a pair of keys you stored the result somewhere! Say you owned a huge network of say mil/gov computers which communicate securely using sefl generated rotating keys. As any client finishes with a key pair they send them off to a central storage location. If they are not there already they are added to the store. To find the private key(s) you only need to search through the list of public keys. If you only find 1% of the server communities private keys then you've got many extra nodes to add to your dummy network. Hopefully you understand this and I'll get some sleep tonite ( :D ). -K- You're continuing to drastically underestimate the numbers involved. Let's say that a computer is a cube, one half foot on each side. Now let's take the Earth, and *cover the Earth with solid computers* to a depth of one mile. This gives us approximately 232 billion billion computers. If you assume that each computer can generate a thousand private/public pairs per second (I believe this is an exaggeration for commodity hardware, though you could likely build a custom system to do so) then that means we get 2.32 * 10^23 keys every second. I'm going to go handwavy here and assume that one key is approximately equal to one prime. This isn't true, but we'll end up within an order of magnitude of the right answer, and honestly more precision than that isn't needed. With 7.5127 * 10^74 primes, attempting to cover 1% of the keyspace at 2.32 * 10^23 keys per second would take approximately one million million million million million million million *years*. Excuse me for not being particularly worried about this. And remember, this assumes the entire surface of the planet is covered, a mile thick, with computers. Last I checked this was not the case. (Again, this also ignores the issue of where you store all this data.) Seriously, sit down and think about the numbers some. The numbers are *gigantic* - so gigantic that brute force becomes implausible, even if you assume the adversary owns all the government and corporations of our world and has access to alien supercomputers. -Ben
Re: .onion sites fail to load with: (waiting for rendezvous desc)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, | [notice] Tried for 120 seconds to get a connection to [scrubbed]:80. | Giving up. (waiting for rendezvous desc), followed by a Privoxy 502 | error. Some days ago there was a guy on #tor with a similar problem. You? :) After trying out some things which did not appear to have any direct effect, it suddenly worked again for him. I just tried to access two hidden services. Worked fine. But obviously, there is a bug that we should track down. Maybe you can help us with that? | Others have verified the .onion sites I try to connect to as up and | running, but I can almost never connect to them anymore. I'm running | the latest Tor alpha. Every other use of Tor works fine, only this | problem when trying .onion sites. What does almost never mean? How often does it work? What happens when you restart Tor and try again? What if you wait for some minutes after starting Tor before trying? With latest Tor alpha you mean 0.2.0.19-alpha? Did you try to compile and run current trunk? Unfortunately one bug fix for 0.2.0.19-alpha turned out to be erroneous and was reverted in current trunk. But I doubt that it's the one causing the problem you describe. What versions are the people running who say that it's working for them? Can you tell the .onion address in public or in private mail to me? Or another service that you can tell? If not, do you know by any chance who is running such a service and whether they are running version 0.2.0.10-alpha or higher? Can you reach the example hidden service http://duskgytldkxiuqc6.onion/ or my v2 test service http://uulvbbixcufpmmg4.onion/ ? Thanks for your help! - --Karsten -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHt0u+0M+WPffBEmURAlZiAKCyKH9YJcyy9PQx2j5n54Z1lvWhVACfcGaw K1GuMu9rxNeUpIACfMVYzLM= =XXuE -END PGP SIGNATURE-
Re: Compromised entry guards rejecting safe circuits (was Re: OSI 1-3 attack on Tor? in it.wikipedia)
Ben Wilhelm wrote: (snipped cool stuff) thanks a lot for your shrewd and amusing explanations. I would not mind, if this discussion would go on like that for a while ;) cheers, florian
Re: .onion sites fail to load with: (waiting for rendezvous desc)
On Sat, 16 Feb 2008 21:46:54 +0100, Karsten Loesing [EMAIL PROTECTED] said: Some days ago there was a guy on #tor with a similar problem. You? :) No. #tor on OFTC has a ban on tor users right now, why? This does not help bug reporters very well. Why not a moderation mode instead of ban? After trying out some things which did not appear to have any direct effect, it suddenly worked again for him. I've tried everything I can think of, nothing works. Should I revert to stable until this is fixed? I don't know if I can offer much help. I just tried to access two hidden services. Worked fine. But obviously, there is a bug that we should track down. Maybe you can help us with that? I can connect to http://duskgytldkxiuqc6.onion/ without a problem, but others including core.onion, hidden wiki, Freenode's hidden IRC server, and a few others don't work as they used to. I attempt only known verified as working .onion sites from others. Non-fuctional (down) .onion sites show a different message in terminal unrelated to this bug. What does almost never mean? How often does it work? One day I managed to connect to one when I reloaded the site the moment following the failure message (with 0.2.0.17-alpha (or) 18-alpha), but I have been unable to reproduce this with the current 19-alpha). What happens when you restart Tor and try again? What if you wait for some minutes after starting Tor before trying? All tries fail. With latest Tor alpha you mean 0.2.0.19-alpha? Yes Did you try to compile and run current trunk? Unfortunately one bug fix for 0.2.0.19-alpha turned out to be erroneous and was reverted in current trunk. But I doubt that it's the one causing the problem you describe. I download only from download page @ torproject.org, I don't apply patches myself or use svn. What versions are the people running who say that it's working for them? This information I have not verified from them. Can you tell the .onion address in public or in private mail to me? I mentioned a few of them above. I personally have little use for .onion sites as most of them don't have content interesting to me, but I test anyway because it is alpha. -- [EMAIL PROTECTED] -- http://www.fastmail.fm - A no graphics, no pop-ups email service
I can upgrade a Debian HPPA tor node
Hi, i'm running a HPPA machine with Debian 4.0 It doesnt upgrade tor to newer version. What i have to do? Changing sources in apt-get? Compile from source? Please help me. Thanks
Re: .onion sites fail to load with: (waiting for rendezvous desc)
On Sat, Feb 16, 2008 at 02:02:23PM -0800, [EMAIL PROTECTED] wrote 2.3K bytes in 63 lines about: : No. #tor on OFTC has a ban on tor users right now, why? This does not : help bug reporters very well. Why not a moderation mode instead of ban? We were flooded with trolls. It was a temporary measure. -- Andrew
Re: I can upgrade a Debian HPPA tor node
What i have to do? Changing sources in apt-get? Compile from source? Take a look at deb packages at https://wiki.torproject.org/noreply/TheOnionRouter/TorOnDebian Compile from source (and roll your own deb, take a look at checkinstall) if there isn't a package suitable for your machine. M
Re: .onion sites fail to load with: (waiting for rendezvous desc)
Hi, after reading this I went ahead and with the help of Phobos compiled an installed trunk. On Feb 16, 2008, at 11:02 PM, [EMAIL PROTECTED] wrote: On Sat, 16 Feb 2008 21:46:54 +0100, Karsten Loesing [EMAIL PROTECTED] said: Some days ago there was a guy on #tor with a similar problem. You? :) Nope, that was me :) I just tried to access two hidden services. Worked fine. But obviously, there is a bug that we should track down. Maybe you can help us with that? I'd like to help I can connect to http://duskgytldkxiuqc6.onion/ without a problem, but others including core.onion, hidden wiki, Freenode's hidden IRC server, and a few others don't work as they used to. I attempt only known verified as working .onion sites from others. Non-fuctional (down) .onion sites show a different message in terminal unrelated to this bug. I had a somewhat strange behaviour. I was able to connect to the example hidden service, but not the v2 test service. trying to access the v2 test service, I got the message [Notice] Tried for 120 seconds to get a connection to [scrubbed]:80. Giving up. (waiting for rendezvous desc) a bit later, I could access the v2 test page without a problem, but core.onion still throws the above error message. The strange thing is that a made-up onion address gives a different error message in the log: Trying to access http://duskgytldkxi2qc6.onion/ (almost the same as a above, but changed one letter) I get a [Notice] Closing stream for '[scrubbed].onion': hidden service is unavailable (try again later). in the logs :) What happens when you restart Tor and try again? What if you wait for some minutes after starting Tor before trying? All tries fail. Same here, it does not matter how long Tor has been running Did you try to compile and run current trunk? Unfortunately one bug fix for 0.2.0.19-alpha turned out to be erroneous and was reverted in current trunk. But I doubt that it's the one causing the problem you describe. unfortunately, this doesn't seem to be the problem :( Best Sebastian PGP.sig Description: This is a digitally signed message part
