Invalid uptime warning messages
At 10:00 p.m. my tor server began issuing a warning message about a negative uptime: Feb 16 16:30:26.059 [notice] Your IP address seems to have changed to 66.225.36.43. Updating. Feb 16 16:30:31.007 [notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor. Feb 16 16:30:49.556 [notice] Performing bandwidth self-test...done. Feb 16 16:33:46.139 [notice] Self-testing indicates your DirPort is reachable from the outside. Excellent. Feb 16 22:08:02.031 [warn] Invalid uptime -19907 Feb 16 22:09:01.581 [warn] Invalid uptime -19907 Feb 16 22:10:02.879 [warn] Invalid uptime -19907 Feb 16 22:11:04.153 [warn] Invalid uptime -19907 Feb 16 22:12:04.540 [warn] Invalid uptime -19907 Feb 16 22:13:05.834 [warn] Invalid uptime -19907 Feb 16 22:14:07.146 [warn] Invalid uptime -19907 Feb 16 22:15:07.441 [warn] Invalid uptime -19907 Feb 16 22:16:10.859 [warn] Invalid uptime -19907 Feb 16 22:17:09.581 [warn] Invalid uptime -19907 It has continued to issue these messages about every minute all through the night so far. What exactly is it complaining about? An error in its own uptime? The system uptime looks valid to me. What causes this to happen? Is there a way to fix it while it's running? Or does it just have to be restarted? Scott Bennett, Comm. ASMELG, CFIAG ** * Internet: bennett at cs.niu.edu * ** * A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army. * *-- Gov. John Hancock, New York Journal, 28 January 1790 * **
Re: Invalid uptime warning messages
I wrote: At 10:00 p.m. my tor server began issuing a warning message about a Apparently, my contact lens blurred and I misread the time. Obviously, I should have typed 10:08 p.m. negative uptime: Feb 16 16:30:26.059 [notice] Your IP address seems to have changed to 66.225.36.43. Updating. Feb 16 16:30:31.007 [notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor. Feb 16 16:30:49.556 [notice] Performing bandwidth self-test...done. Feb 16 16:33:46.139 [notice] Self-testing indicates your DirPort is reachable from the outside. Excellent. Feb 16 22:08:02.031 [warn] Invalid uptime -19907 Feb 16 22:09:01.581 [warn] Invalid uptime -19907 Feb 16 22:10:02.879 [warn] Invalid uptime -19907 Feb 16 22:11:04.153 [warn] Invalid uptime -19907 Feb 16 22:12:04.540 [warn] Invalid uptime -19907 Feb 16 22:13:05.834 [warn] Invalid uptime -19907 Feb 16 22:14:07.146 [warn] Invalid uptime -19907 Feb 16 22:15:07.441 [warn] Invalid uptime -19907 Feb 16 22:16:10.859 [warn] Invalid uptime -19907 Feb 16 22:17:09.581 [warn] Invalid uptime -19907 It has continued to issue these messages about every minute all through the night so far. What exactly is it complaining about? An error in its own uptime? The system uptime looks valid to me. What causes this to happen? Is there a way to fix it while it's running? Or does it just have to be restarted? Scott Bennett, Comm. ASMELG, CFIAG ** * Internet: bennett at cs.niu.edu * ** * A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army. * *-- Gov. John Hancock, New York Journal, 28 January 1790 * **
Re: Invalid uptime warning messages
Scott Bennett wrote: At 10:00 p.m. my tor server began issuing a warning message about a negative uptime: yep, the same here on blutmagie. TZ is UTC+1 Feb 17 04:40:45.116 [warn] Invalid uptime -19907 btw: I just found that even with MAX_FILEDESCRIPTORS=32768 tor regularly complains about too many open files. On my box the number of file descriptors tends to be about 10.000. Feb 17 11:49:36.374 [warn] Error creating network socket: Too many open files regards Olaf signature.asc Description: OpenPGP digital signature
Re: Invalid uptime warning messages
On Sunday 17 February 2008 10:56:28 Olaf Selke wrote: Scott Bennett wrote: At 10:00 p.m. my tor server began issuing a warning message about a negative uptime: yep, the same here on blutmagie. TZ is UTC+1 Feb 17 04:40:45.116 [warn] Invalid uptime -19907 The affected router appears to be 'crobertp'. It has the invalid uptime value in it's router descriptor: signature.asc Description: This is a digitally signed message part.
Re: Invalid uptime warning messages
On Sunday 17 February 2008 12:10:40 Robert Hogan wrote: On Sunday 17 February 2008 10:56:28 Olaf Selke wrote: Scott Bennett wrote: At 10:00 p.m. my tor server began issuing a warning message about a negative uptime: yep, the same here on blutmagie. TZ is UTC+1 Feb 17 04:40:45.116 [warn] Invalid uptime -19907 The affected router appears to be 'crobertp'. It has the invalid uptime value in it's router descriptor: 250+desc/name/crobertp= router crobertp 201.51.22.53 563 0 9030 platform Tor 0.1.1.24 on Linux i686 published 2008-02-17 09:03:34 opt fingerprint 3D18 77CA 3BBD 97A5 9D38 0640 6696 E692 420B EF67 uptime -19907 bandwidth 20480 51200 0 I've bcc'd the owner of the router so he can upgrade his Tor (0.1.1.24 must be deprecated by now). signature.asc Description: This is a digitally signed message part.
Re: Invalid uptime warning messages
Scott Bennett schrieb: At 10:00 p.m. my tor server began issuing a warning message about a negative uptime: Yes, the same here on 2 nodes, one starting this night between 3 and 4 UTC, the other on startup this morning. I had a quick look at debug messages here, I think there is some router with a weird descriptor and Tor discards it upon download and tries to download it again at some later time (on non-directory-caches every 10min). After the last warning about the invalid uptime (2 hours ago) I got Feb 17 11:33:21.408 [debug] download_status_increment_failure(): 3AE4C8E5C4CA589CF51861F9294BC9B8020D3308 failed 5 time(s); Giving up for a while. So I assume this router to be the one with the invalid uptime in the descriptor. Dominik
Re: Invalid uptime warning messages
Scott Bennett schrieb: At 10:00 p.m. my tor server began issuing a warning message about a negative uptime: the same here on arachne TZ is UTC+1 Feb 17 04:26:58.192 [warn] Invalid uptime -19907 Feb 17 13:58:23.510 [debug] router_new_address_suggestion(): Got X-Your-Address-Is: 84.165.114.73. Feb 17 13:58:24.222 [debug] resolve_my_address(): Resolved Address to '84.165.114.73'. Feb 17 13:58:24.222 [debug] connection_dir_client_reached_eof(): Time on received directory is within tolerance; we are 0 seconds skewed. (That's okay.) Feb 17 13:58:24.222 [info] connection_dir_client_reached_eof(): Received server info (size 2425) from server '194.109.206.212:80' Feb 17 13:58:24.222 [warn] Invalid uptime -19907 Feb 17 13:58:24.222 [info] router_load_routers_from_string(): 0 elements to add Feb 17 13:58:24.258 [info] entry_guards_compute_status(): Summary: Entry 'elc2' is reachable, usable, and live. regards Ruediger
Re: Compromised entry guards rejecting safe circuits (was Re: OSI 1-3 attack on Tor? in it.wikipedia)
Ben Wilhelm wrote: 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 Ben, I think you are using the purely theoretical numbers and applying them to the problem as if they were reality. As I remember the problem with the selection of primes for PKE is, 1. the seeding of the pseudo-random number generator e.g. with a 16bit seed then only 65,000 or so entry points into the number generation which leads that number of keys. Even for an 8byte random seed the number of keys generated would be about 10^19 keys and obviously, following your example, this represents less than a milligram of your hydrogen memory, about a breath of air in the lungs of the average human being. 2. the pseudo-random numbers generators, themselves have not been proven to be numerically complete. Indeed their very form suggests not. Bearing these things in mind, it may be possible to pick off machines where their key is only generated from a small sub-set of the total possible keys. I am sorry I included the example of the prime numbers tail off as it only served to confuse the issue and probably got you involved in your calculation in the first place. Hopefully, this brings a breath of fresh air to this subject and ends the scoffing of some detractors. Of course, the scenario for this attack, as originally outlined ( Re: OSI 1-3 attack on Tor? in it.wikipedia), is still intact, fully correct and easily provable. Thank you for your interest. -K- Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs
Re: .onion sites fail to load with: (waiting for rendezvous desc)
On Sat, Feb 16, 2008 at 12:03:02PM -0800, [EMAIL PROTECTED] wrote: 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. FWIW, it looks like Karsten maybe just fixed this issue with a patch that went into the Subversion repository as r13540. If anybody who's been seeing this problem is able to try running svn trunk, it would be great to see whether this fixes the problem. Thanks! Yrs, -- Nick
Re: Compromised entry guards rejecting safe circuits (was Re: OSI 1-3 attack on Tor? in it.wikipedia)
Anon Mus wrote: Ben, I think you are using the purely theoretical numbers and applying them to the problem as if they were reality. As I remember the problem with the selection of primes for PKE is, 1. the seeding of the pseudo-random number generator e.g. with a 16bit seed then only 65,000 or so entry points into the number generation which leads that number of keys. Even for an 8byte random seed the number of keys generated would be about 10^19 keys and obviously, following your example, this represents less than a milligram of your hydrogen memory, about a breath of air in the lungs of the average human being. Yes, this is correct - if you use a horrifically insecure random-number generator, you'll end up with a horrifically insecure public key. Any serious application of crypto will use a random-number generator with far more than 16 bits of entropy. I don't actually know what the current standard for pseudo-random crypto generators are, but I give as a simple example Boost's Mersenne Twister generator, which, as I understand it, can be given something on the order of 20,000 bits of entropy as a seed. (Obviously, this is far more than is strictly needed to generate all 256-bit primes.) 2. the pseudo-random numbers generators, themselves have not been proven to be numerically complete. Indeed their very form suggests not. This is untrue in several ways. There's nothing in the structure of a psuedorandom generator which makes it impossible to analyse, and many pseudorandom generators are understood extremely well. Again, this isn't something I'm particularly expert in, but it's a solved problem to roughly the same extent that the entire public-key cryptography issue is a solved problem (i.e. solved, barring spectacular and unexpected advances.) Note that you could simply use a source of truly secure entropy to bypass these issues entirely, and most non-embedded operating systems include such a thing built-in. Of course, the scenario for this attack, as originally outlined ( Re: OSI 1-3 attack on Tor? in it.wikipedia), is still intact, fully correct and easily provable. We've described logically why your original attack would not work (at least, why it would not allow any kind of security breaches - obviously you can bring the Tor network down using such an attack, but that's not exactly avoidable.) It is neither intact nor correct, and, assuming no security bugs in the Tor implementation, I believe it is provably so. -Ben
max number of file descriptors hard coded
Narf! debugging the [warn] Error creating network socket: Too many open files messages I just found the max number of file descriptors apparently being hard coded in or.h to a value of 15.000. Raising the number using ulimit -n thus shows no effect. Olaf
Re: .onion sites fail to load with: (waiting for rendezvous desc)
On Feb 17, 2008, at 6:03 PM, [EMAIL PROTECTED] wrote: On Sat, Feb 16, 2008 at 12:03:02PM -0800, [EMAIL PROTECTED] wrote: 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. FWIW, it looks like Karsten maybe just fixed this issue with a patch that went into the Subversion repository as r13540. If anybody who's been seeing this problem is able to try running svn trunk, it would be great to see whether this fixes the problem. Thanks! Yrs, -- Nick Hi, I just compiled and testet the new version. Using this, I was able to contact core.onion, the v2 descriptor testpage and the example hidden service. On core.onion, I clicked a few random links. Most were not working, but in the logs, the error message is different - I get [Notice] Closing stream for '[scrubbed].onion': hidden service is unavailable (try again later). which I guess means that the service is down. Also, I got a few [Notice] Tried for 120 seconds to get a connection to [scrubbed]:80. Giving up. (waiting for circuit) and [Notice] Rend stream is 120 seconds late. Giving up on address '[scrubbed].onion'. in my logs. I hope this can help you Best Sebastian PGP.sig Description: This is a digitally signed message part
Re: Compromised entry guards rejecting safe circuits (was Re: OSI 1-3 attack on Tor? in it.wikipedia)
Ben Wilhelm wrote: Anon Mus wrote: Ben, I think you are using the purely theoretical numbers and applying them to the problem as if they were reality. As I remember the problem with the selection of primes for PKE is, 1. the seeding of the pseudo-random number generator e.g. with a 16bit seed then only 65,000 or so entry points into the number generation which leads that number of keys. Even for an 8byte random seed the number of keys generated would be about 10^19 keys and obviously, following your example, this represents less than a milligram of your hydrogen memory, about a breath of air in the lungs of the average human being. Yes, this is correct - if you use a horrifically insecure random-number generator, you'll end up with a horrifically insecure public key. Any serious application of crypto will use a random-number generator with far more than 16 bits of entropy. I don't actually know what the current standard for pseudo-random crypto generators are, but I give as a simple example Boost's Mersenne Twister generator, which, as I understand it, can be given something on the order of 20,000 bits of entropy as a seed. (Obviously, this is far more than is strictly needed to generate all 256-bit primes.) Hands up those tor nodes using Boost's Mersenne Twister generator. 2. the pseudo-random numbers generators, themselves have not been proven to be numerically complete. Indeed their very form suggests not. This is untrue in several ways. There's nothing in the structure of a psuedorandom generator which makes it impossible to analyse, and many pseudorandom generators are understood extremely well. Again, this isn't something I'm particularly expert in, but it's a solved problem to roughly the same extent that the entire public-key cryptography issue is a solved problem (i.e. solved, barring spectacular and unexpected advances.) Note that you could simply use a source of truly secure entropy to bypass these issues entirely, and most non-embedded operating systems include such a thing built-in. Hands up those tor nodes using a true entropy dongle. FYI - I empirically tested a common pseudo-random number generator in the 90's and found it seriously wanting. So you and I will have to agree to disagree over this. Of course, the scenario for this attack, as originally outlined ( Re: OSI 1-3 attack on Tor? in it.wikipedia), is still intact, fully correct and easily provable. We've described logically why your original attack would not work (at least, why it would not allow any kind of security breaches - obviously you can bring the Tor network down using such an attack, but that's not exactly avoidable.) It is neither intact nor correct, and, assuming no security bugs in the Tor implementation, I believe it is provably so. -Ben We've ?? - whose the we?? (rhetorical) Lets see whats been admitted so far shall we, Roger Dingledine wrote: Mike Perry also brought up an attack like this when he was working on SoaT. Alas (or perhaps fortunately), he's been working on Torbutton-dev lately instead. The number of competent anonymity programmers and designers in the world is still woefully small. OK - so the basic attack works - Mr Dingledine says so.. Ben Wilhelm wrote: 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. OK - so you yourself accept that spyware could steal private keys. (And there's lots of spyware out there) I myself wrote: 1. Attacker sets up a number of genuine tor servers, could be tor nodes right up to guard level - attacker therefore has these keys. OK - NO ONE has challenged this, it would be silly to do so, so I guess it stands as accepted. Ben, all thats left is you (and your we) disagreeing with the storage of public/private key pairs (A.3.). For my part I am 100% certain this is so!! I know it for a fact. Therefore, please be good enough to lay this matter to rest and accept that most is proven, if not totally accepted by all. There will always be die-hards and face savers but we try not to encourage them to dis-inform or-talk tor USers (thats the US not the WE). -K- Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping
exit policy
I would like to set an exit policy, but at the same time, I would like to be safe. I want my cake and eat it too. Is there a suggested safe exit policy? As far as websites go, what is preferred is the ability to read websites, but not write, such as would be done on hotmail. Secured protocols are preferred also, so there is end to end encryption. Any suggestions?
Re: OSI 1-3 attack on Tor? in it.wikipedia
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Anon Mus wrote: F. Fox wrote: (snip) 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. (snip) The contents of any file may be stolen by spyware. Thank you for backing me up. Here's another copy of my previous statement: unless you're talking about lists of *compromised* keys (I.E., STOLEN, LIKE VIA MALWARE.) Notice the portion in all caps. Of course you may not really be than dumb. (snip) Looks more like you can't read. - -- F. Fox AAS, CompTIA A+/Network+/Security+ Owner of Tor node kitsune http://fenrisfox.livejournal.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQIVAwUBR7jIM+j8TXmm2ggwAQiQFQ/+LuuR74vN/COMbf0xOnFzxehTyMckzCM8 iFnVCJ/5ZLS8fSZhaLgvmK2TwcVm56xBVxkFM+ZEgR41U1b1PUzo37FiaUMHMXGY urHbtrIAjYg6ju143o+055o7pZ6HvSqRhERJj5JMbO9NaWt34+NM6ctSNoaak3/d EE6+/DdIJXNr1lKMX2vEML87od6hhzg3X5uykCeyXub1QUq6CJac0Abk/AqA5kX9 373kEGfG61ra/KlGy+ooG7pn9XCLFKCMvIfw1JbRLzk0LeFgecfyT3jkdxwqVru4 dayzy9JVNTiGU7i+XGonuKM2C2VhFPS9kDW7H9zjJxaCibq6jvhbXAA99GynuZky o3sCjzl779SMTZM+KQrkrx9U3QhKhgJW2YTt2US2loU5oEAQvP5Xy/Q5ItBE/CcR 3yg2W+XGlJPJeq7SscjE2eGLer8jzsD7q9HRz3q5bbZRyVGDgB2ftYQycEkEwnvr BW6vpl/RcHzkYVnjMEHb81wv0DptiYrlu+7lAbVoTk2pCyO954W9tHC2ZQL3FUV3 Lc9MY94CLxb+yhmHYh6E4V7gJB977Uefl31CoqgqgVIzBGHXfwBPbFUIBCsqNiiR Uv9Dvx5MGqztTEIHs5oLgLv15Sw8sh7oEPt/my+SB7Bzp3bDEJtr0SKB7M2SETSG jyzEvIxgnOg= =3/QF -END PGP SIGNATURE-
[OT] On recent events
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 myMentalTrollFood /dev/null - -- F. Fox AAS, CompTIA A+/Network+/Security+ Owner of Tor node kitsune http://fenrisfox.livejournal.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQIVAwUBR7jOGej8TXmm2ggwAQgOBA//ciLsP3dHG/IOrHbf1dYKJZT1ZKJ4oLl2 h6bxx9KnLQgCJDbvMH9MK4rhMOWrW0iCMAGprdKOoAVo7DSnjWcEI4QA5uEUvEVm EoiRpbXs1RJOVGFga9foh7IStVYHCaYHK09LUS2x73jgtixy5Gh+cjgxid4EA9dF fdYI1Ep+y85mbz6qXGFcQ+KkFYMOPTuqM16DJ/C3QUXaULR2oJYC2KfEwcWpewwV rRyCCGYjc6hoCvk8raF+tkDDEop2qfMZ8Bx/wfuFAvCwLmTlPFzVEo1r/nPsN/2t 2A8t/XLjZpOWjTvpa+p5w44ImdylPXVZ8m3wcca4AwvIAg5c2QknDFwOOqowb4Tp GfY2FDv7+Kdf+V3bbcQArZu5aRtAqhgKn9h+6LOcF+WQWIKrezsQ/kUuKTG9qcCO 6YVjEZQu4vQxhQsYjt9wEW8zY1nHQ3SfO380YP8yPYEyYhy3HqKwTBRXwhVwnK4e a/Fvi9Q/3Ur/tA2trnoG594ymIuF4jMSKJPhrPl47Bmhw6r2OpUavnk7mOCbubGc v2aTLh0VbxY8E+pcSJ3V7ZrxQLEV8Yab1CbaR1ehwRhPM0RI0/12NW537+bijV0Z 7Iq3f8k3B18UZ/4eXLdUNsquR66Sxp4Heq2LhFG3iIPNzZ9L9tqLqvoSMTYzseNI S2IEw+YfQRE= =ssgX -END PGP SIGNATURE-
