Computer's Heat May Unmask Anonymized PCs

Virtual_Raider writes "Wired is carrying a story about a method developed by security researchers to identify computers hiding behind anonymity services. From the article: 'His victim is the Onion Router, or "Tor" — a sophisticated privacy system that lets users surf the web anonymously. Tor encrypts a user's traffic, and bounces it through multiple servers, so the final destination doesn't know where it came from. Murdoch set up a Tor network at Cambridge to test his technique, which works like this: If an attacker wants to learn the IP address of a hidden server on the Tor network, he'll suddenly request something difficult or intensive from that server. The added load will cause it to warm up.'"

Comments

Hot enough to...

[Anonymous Coward]

http://knuttz.net/hosted_pages/USB-Cooking-2006082 2

Re:I didn't RTFA, but...

[KshGoddess]

the heat-up causes a shift in how much the clock drifts, and you can query time from different servers to pinpoint which one it is.

See what reading the article gets you? A tiny nugget of useless information.

Re:I didn't RTFA, but...

[Allicorn]

You really should've read TFA in this case. Apparently, heating up the box causes fluctuations in system time which this chap claims to be able to detect in a meaningful way. There's more to it - interesting read.

Alli

Re:I didn't RTFA, but...

[gslavik]

but what if the router happens to be an overclocked gaming system and the user happens to have fired up Prey/Doom3/others for an intence gaming session?

FTA: Clock Skew, not temp.

[Mr. Flibble]

The temp increase is the method to cause the clock to skew as the chip heats up due to added server load. The heat itself is not detected, so the summary is very misleading. The idea is to load the server enough so that the timestamps begin to change, and these changes can be detected.

Of course, the defense to this attack is probably something along the lines of:

$ man nice

Re:FTA: Clock Skew, not temp.

[jd]

There are several defenses.

• First, if the computer is sensibly cooled (ie: not by convection currents) then heating will be minimal.
  
• Second, if you use a high-precision clock-chip, the chip will be tens or hundreds of times more accurate than the system time, so the drift will be entirely absorbed through the loss of accuracy.
  
• Third, a defender worried about such an attack would use an oven-controlled oscillator for the clock, which means the temperature is whatever you want it to be. You can deliberately vary it to produce errors, or compensate for external temperature changes. Either way, you can be quite invisible to this method.
  
• Fourth, the TOR network should be using an external time source (eg: NTP) that is not included in the TOR tunnel - ie: it's out-of-band - which means that the computers can automagically correct drift. If the computers are REALLY good, they'd correct drift on a second-order or third-order basis, rather than as a constant, so that you adapt how you read the clock to the shift in drift.
  

The idea of using some sort of timing attack against such a network is interesting. There are probably better methods, though.

One idea that springs to mind is that such P2P systems use caches. If you could generate enough requests to flood the cache system, you can force any computer to query nearby computers, where the latency will be roughly equal to the number of hops along the critical path. It then becomes similar to the game of "Black Box", where you try to map particles by throwing rays in and seeing what happens. If you have a sufficiently large latency map from a sufficiently large number of entrance points, you should be able to derive the whole of the exposed topology of the P2P network and be able to identify which of those servers carry what data.

(Think about it. Those of us in Open Source have all done reverse engineering, we have all tried to wrest the secrets of some black box we can't see the inside of, and eventually we have all succeeded in doing so. Our interpretation may not 100% match the internals literally, but they WILL 100% match the internals logically. And in the end, that's all that matters.)

Re:FTA: Clock Skew, not temp.

[Anonymous Coward]

How is "nice" going to help? Nice only reduces the priority of a process. A CPU intensive process will still keep the CPU busy at 100%, whether it's spawned at normal priority or at a nice priority.

So nice has no impact on heat, it only improves responsiveness of other processes.

Re:FTA: Clock Skew, not temp.

[sjmurdoch]

First, if the computer is sensibly cooled (ie: not by convection currents) then heating will be minimal.

The computers I tested it with were normal desktop machines. They all had fans, and in some cases were thermostatically controlled. The differences in temperature were only 1–2 C, but that could be remotely detected.

Second, if you use a high-precision clock-chip, the chip will be tens or hundreds of times more accurate than the system time

An oven-controlled crystal might be accurate enough (<1ppm) but it still needs to be integrated at the hardware level. Plugging it into NTP is not enough since non-NTP synchronized clocks are exposed remotely. The same applies for using NTP normally. Moreover, NTP is explicitly designed to react slowly (to handle latency), so faster effects, like the ones I measure, will still be visible.

Re:FTA: Clock Skew, not temp.

[arevos]

One idea that springs to mind is that such P2P systems use caches. If you could generate enough requests to flood the cache system, you can force any computer to query nearby computers, where the latency will be roughly equal to the number of hops along the critical path. It then becomes similar to the game of "Black Box", where you try to map particles by throwing rays in and seeing what happens. If you have a sufficiently large latency map from a sufficiently large number of entrance points, you should be able to derive the whole of the exposed topology of the P2P network and be able to identify which of those servers carry what data.

Nice idea, but it wouldn't work on Tor. The topology of the router network depends on who is using it, as routing paths are decided by the machines using the Tor network to remain anonymous, not by the routers themselves. In the case of a hidden service on Tor, a directory server is used to associate a .onion TLD with several routing paths the clients can use to contact to the server. Little information can be derived from the routing paths themselves, as the address of each router in the sequence is encrypted with the public key of the previous router. Because there are only a finite set of routes published that can lead to the server, and because none of the routes can be dissected due to the encryption on them, testing their latency would tell you relatively little.

Your system would work fine on a decentralized P2P system not designed for anonymity, but none of the anonymous P2P systems I can think of would be caught out by your flooding attack.

(Think about it. Those of us in Open Source have all done reverse engineering, we have all tried to wrest the secrets of some black box we can't see the inside of, and eventually we have all succeeded in doing so. Our interpretation may not 100% match the internals literally, but they WILL 100% match the internals logically. And in the end, that's all that matters.)

In order to reverse engineer a black box, one needs to gather a sufficient amount of information. Tor limits what information you can gather. You can know that there are N routes that lead to a hidden service; you can know that M routers make up a particular route; you can know that the total latency of those M routers at any one time is L; and finally you can know that a particular route starts with the router R. This is the sum total of the information you have access to, and from this you have to work out what single server on the entire net is the one you're searching for. Good luck!

Re:FTA: Clock Skew, not temp.

[Gordonjcp]

Let me know if you want to try it with an oven-controlled clock. I'm sure I can sort out something that will hold a reasonably steady temperature (better than free-space at least).

Re:FTA: Clock Skew, not temp.

[Instine]

"(Think about it. Those of us in Open Source have all done reverse engineering, we have all tried to wrest the secrets of some black box we can't see the inside of, and eventually we have all succeeded in doing so. Our interpretation may not 100% match the internals literally, but they WILL 100% match the internals logically. And in the end, that's all that matters.)"

In many ways I agree, but literal != logical. If I spoof the behaviour you look for, I could 'frame' another server for my processes. Logically, it would be they that served it, but literaly, it would be me. If I can detect and filter the flood from the attact, in order to avoid the timeing offset, but imediately start a similar attac on another server in the system, ....

Unlike most webservers, most servers on Tor are desktops. They're not their to serve, but to browse. So unlike a web server, you can afford to deflect flood attacts, and effectively do without service for a while, dureing an attack.

So if you REALY want anon, this is not the end of Tor (an similar) as a solution.

Re:FTA: Clock Skew, not temp.

[pla]

There are several defenses.

You forgot the simplest one that will defeat all attempts at timestamp fingerprinting...

Lie about the time. As long as it monotonically increases between packets, and stays within a few seconds of accurate, everything goes smoothly (for most general-purpose data traffic - Obviously this would completely screw up something like an NTP query).

Re:FTA: Clock Skew, not temp.

[Anonymous Coward]

so the summary is very misleading. This is Slashdot. Mod parent -1, Redundant.

Re:FTA: Clock Skew, not temp.

[jd]

Probing a theoretically ideal anonymous P2P network can be done if certain conditions are met. Step through the following and see what you think.

1. If you connect to each and every R in the set of R' (the total number of edge-connected nodes in the network) and cache-flood prior to making your standard test query, and repeat the process R'/3 times, then the mean value of M over all these tests will be the maximum possible radius of the topology. It doesn't matter what test query you use or where in the topology the query is located.
2. The minimum possible radius of the network is the square root of R'.
3. The total latency from the edge to any server can not be less than the strict sum of the latencies of all intermediate hops. We therefore have one inequality for each of our R'/3 queries from our R' starting points with two terms for each of the transitions (Mx to My) in the list of M we have for that query. (One term for the actual latency generated, one term for whatever delay is introduced to conceal the path.)
4. We do not (yet) know how this table matches up. What we do is we start with the smallest radius and work our way up. The maximum area occurs with a circle, so area = pi * r^2, round up to the nearest whole node. The entire matrix above will fit if and only if the radius we are estimating is equal to or greater to the actual radius.
5. The additional concealment latency cannot be too great or the network is useless, so the concealment latency for a path has to be significantly smaller than the total latency of that same path.
6. There will be exactly one minimal fit for these conditions and this will be the topology of the network.

Re:FTA: Clock Skew, not temp.

[arevos]

There will be exactly one minimal fit for these conditions and this will be the topology of the network.

This won't work on Tor, for three reasons. First, there is no overall network topology. The routers merely act on routing instructions passed onto them via the client; they don't make connections autonomously, like, for instance, the nodes in a Gnutella network would do. Second, the hidden servers are not actually part of the Tor network; the routers merely act as middle men, stopping direct communication between the server and the client. Thirdly, I'm not aware of any caching that goes on between router nodes, nor can I see anything that would actually need caching.

One could try all possible routing permutations, but this would mean trying out R'!/(R'-R)! different routing paths, which would be difficult to conceal and would be infeasible for large values of R'. Also, if the ratio between R' and R is sufficiently large, then there will likely be a great number of permutations that generate similar latencies. One could take each permutation and perform timing attacks on the routers, but this would require access to the network traffic of the routers, and since the Tor routers are numerous and spread across many different countries, this would likely prove very difficult even for large government agencies. In short, this isn't a feasible attack.

Re:FTA: Clock Skew, not temp.

[jd]

Lying about the time works to a degree, but you can only lie in a positive direction. Eventually, with enough tries, it may be possible to figure out that there is a value you NEVER go below. That is the maximum the real time can be. If it's too much below that, however, anything that is time-order dependent risks getting screwed up.

Now, this isn't to say you can't seriously screw with the network's perception of time. For example, you could channel bond multiple VPN connections into a single super-VPN connection, fragment the packet, and use load-balancing to have each fragment sent by a different path. You need something a little fancier on the receiving end, as the fragments may come in out of order, but it's very doable. The delay for that link then appears to be the time taken to deliver the slowest fragment plus the time for fragmenting and rebuilding. As the MTUs for each channel can be randomly varied with every fragment, it would be impossible to infer the speed of any link as it would be impossible to know how much data had been sent by it.

(Well, OK, not truly "impossible", but the number of permutations skyrockets, as you now have every possible permutation of paths from a node multiplied by every possible state that path can be in for that fragment multiplied by the factorial of the number of differently-sized fragments. My saturation attack only works if each line has a well-defined characteristic with limited random noise - it doesn't work if you create an essentially infinite number of virtual lines with a non-deterministic characteristic.)

In the end, mathematical attacks of any kind rely on being able to expose some finite number of invariants (however trivial they may be) which can be correlated to some finite number of nodes (whether or not it is the number of actual nodes), where you can then minimize the map to produce the most likely arrangement.

When there are no invariants, it is impossible to do any further analysis. You can't isolate individual members, you can't isolate groups, you can't compare any two objects, you can't use induction to build associations, you can't do anything.

Re:FTA: Clock Skew, not temp.

[jd]

Ok, fairy nuff. In which case, I have to confess I'm out of ideas.

You don't need to know every complete path, so the number of possible permutations is something you can work around. Think of the tables used by the nudes for routing as one gigantic divided secret. It is possible to prove that for a divided secret, you need only know one part more than 1/3 of all the parts before the secret is weak enough to be considered compromised. The question, then, is purely one of how to gain access to these tables.

If you can guesstimate a range for the number of nodes, then only certain values for that range will produce a series of simultaneous equations which correspond 1:N with the terms in the simultaneous equations produced when attempting to cover the maximum number of routes possible in the system. Of those, one will be a minimum and the rest will be that minimum with terms that can only be reflections.

However, from all the replies I've received so far, I'm willing to accept that Tor is immune to attacks that rely on the Byzantine class of problems - that even if you actually have enough data, knowing that you do is an NP-complete problem. (To be totally secure, it must be possible to prove that even obtaining sufficient information is NP-complete, which may be the case here but that's a much much higher standard.)

Re:FTA: Clock Skew, not temp.

[arevos]

Think of the tables used by the nodes for routing as one gigantic divided secret. It is possible to prove that for a divided secret, you need only know one part more than 1/3 of all the parts before the secret is weak enough to be considered compromised. The question, then, is purely one of how to gain access to these tables. I don't think that's quite right. If there are 3 pieces of data encrypted with three different keys, then knowing what one of those pieces of information is doesn't necessarily help figure out what the other two pieces are.

Tor is pleasingly clever in the way it goes about ensuring anonymity. Each router in the Tor network publishes its IP address and public key on a directory server. The client picks a random sequence of router addresses, R1 to RN, and corresponding public keys, P1 to PN. It then encrypts each router address with the public key from the previous one in the sequence. You can think of this like an onion; each router decrypts its own layer with its private key, finds out what the next router in the sequence is, then discards that layer. This means that each router only knows the previous and next address, so unless all the routers are in collaboration, the complete sequence of routers is a secret distributed across N different routers.

Hidden services work by publishing a series of routes that lead to the hidden server. Because the routes are encrypted with the public keys of each router, one cannot tell where they lead just by looking at them. Communication between the hidden server and the client is also encrypted. Here's where my scant knowledge of Tor starts to break down, however I can make a series of educated guesses. Presumably the hidden server must be indistinguishable from a router, otherwise the routers on the end of the sequence could query the hidden server and get an idea of its content. If the hidden server cannot be distinguished from a router, then the routers at the end of the sequence have no way of telling whether they are at the end, or whether they're just another link in the chain. This would also mean that the published routes would have to be padded with random data to prevent the end server from gathering information from the size of the encrypted route.

Of course, this implies that either hidden services are published routers, or not all Tor routers are published publicly. I'm not sure how this works, or whether my reasoning leading up to this conclusion is incorrect. I'll endeavour to find out more, if only to sate my own curiousity.

Re:I didn't RTFA, but...

[dr.badass]

Um... doesn't that require him to have physical access to the server anyway?

According to TFA, no. Now maybe you want to R it.

Re:I didn't RTFA, but...

[Tweaker_Phreaker]

You left out the part about how his method only has 64 unique "fingerprints" and so this is utterly useless.

Run Distributed.net or SETI@Home etc.

[Lord_Breetai]

They'll peg the CPU, that way it'll be warm all the time. And since they can be set as an idle process they'll step aside as needed.

Re:I didn't RTFA, but...

[qbwiz]

You measure clock skew before, during, and after you hit the hidden service. If the change in clock skew happens at the same time you load the server, that indicates that it's probably the correct server.

Randomize the clock

[Mal Reynolds]

Randomizing the clock of systems serving Tor traffic would render this attack worthless.

Since this and other such attacks are based on analyzing very small changes in the target system clock, even a tiny amount of randomization or pseudo randomization would be effective.

Re:Randomize the clock

[Baricom]

Other potential solutions include preventing machines from reporting local time (through HTTP? - I'm not clear the attacker learns the time in the first place; neither TCP nor IP have time information in the headers, it seems) or preventing hidden servers from talking on the public Internet.

For most hidden services, either should be feasible. Timing doesn't seem that important anyway, given the inherent latency of the Tor network.

Re:Randomize the clock

[whoever57]

If I read this correctly, it requires the enclosure to heat up, since the clock oscillator is on the motherboard, not on the CPU. Thus, randomising fan speeds would have the same effect.

Even if the clock oscillator were part of the CPU package, adding some random variation to the CPU cooler fan speed would defeat this.

Re:Randomize the clock

[KermodeBear]

What about always using 100% of your CPU? I run the BOINC client for the Rosetta@HOME project and tell it to crunch as much data as it can with idle CPU time. It is ALWAYS up and running. So, if I have this running on a machine that also uses Tor then the "create extra CPU load" method would fail.

Re:Randomize the clock

[Psychotria]

It's probably easy for the "attacker" to note the time they "attack".

Re:Randomize the clock

[kasperd]

neither TCP nor IP have time information in the headers

I think they do. I don't know exactly how it works, but netcraft use it to report the uptime of servers. There is also a feature in nmap which does something similar, though it doesn't seem very reliable to me.

But this whole thing seems unrealistic anyway simply because you don't know which machine to be monitoring, and you can't be monitoring every machine on the internet.

Re:Randomize the clock

[Fweeky]

RFC1323:

This memo presents a set of TCP extensions to improve performance
  over large bandwidth*delay product paths and to provide reliable
  operation over very high-speed paths. It defines new TCP options for
  scaled windows and timestamps, which are designed to provide
  compatible interworking with TCP's that do not implement the
  extensions. The timestamps are used for two distinct mechanisms:
  RTTM (Round Trip Time Measurement) and PAWS (Protect Against Wrapped
  Sequences).

Section 4:

The timestamp value to be sent in TSval is to be obtained from a
      (virtual) clock that we call the "timestamp clock". Its values
      must be at least approximately proportional to real time, in order
      to measure actual RTT.

Re:Randomize the clock

[evilviper]

So, if I have this running on a machine that also uses Tor then the "create extra CPU load" method would fail.

Not necessarily.

If you have your CPU-intensive app running at a low priority, and TOR running at a higher priority, then your CPU will become slightly hotter when TOR is doing heavy processing.

It may make it much harder to detect than it already is, but there you go.

Re:Randomize the clock

[Anonymous Coward]

What has priority got to do with it?

Why would heavy processing by TOR make the CPU run hotter than heavy processing by $SOME_APP ? It's still just heavy processing, CPU at 100% usage.

Re:Randomize the clock

[sjmurdoch]

Have a look at this blog posting for why adding random noise will not prevent the attack. Essentially, random noise doesn't change the average skew, since the computer doesn't have an independent reference clock. By taking a moving average over time, the noise can be detected and removed.

Re:Randomize the clock

[Zogg]

Not necessarily. Not all CPU loads are equal, especially in terms of heat. For example, using the floating point unit as opposed to doing integer processing will produce different temperature changes.

This was my first thought as a defense while the researcher was presenting at the CCS conference this year, but he did a good job of tearing that idea apart during the question and answer session.

Re:Randomize the clock

[Anonymous Coward]

I`d think harddrive activity to be more of a load on the system, but maybe it won`t make the clock drift? I don`t know, but people tend to forget the harddrive as the slowest bottleneck in the system.

Re:Randomize the clock

[mysidia]

RFC1323 is not part of tcp/ip. It is an optional extension that some systems could choose to implement. A system does not have to implement these options. Leave RFC1323 options turned off at the operating system level, and you won't reveal information about the system time keeping in that manner.

However, there is a possibility the TOR and other applications themselves reveal the timestamp, say the applications ordinarily include it in messages passed from one peer to another (or from server to client), then it may also be possible for a probe to inquire with various network services running on the machine and thereby obtain the system time.

Re:Randomize the clock

[Dion]

How?

Please explain exactly how the CPU will know what priority the scheduler has assigned to a given process.

A system with speedstep might turn up the clock rate when it sees that there is a high priority process wanting CPU, but that's not the norm.

Re:Randomize the clock

[evilviper]

Please explain exactly how the CPU will know what priority the scheduler has assigned to a given process.

I don't specifically know "how". What I do know is that it's a fact, and quite easy to demonstrate.

Start a long-running CPU-intensive program (my preference is mencoder) at a low priority, and monitor the CPU tempurature. After you've given it plenty of time to cool down (a day or more if you like) start the program at the default or higher priority, and you'll see the tempurature is significantly higher.

Re:Randomize the clock

[John Hasler]

One can add systematic skew as well as noise.

Re:Randomize the clock

[instarx]

Randomizing the clock of systems serving Tor traffic would render this attack worthless.

Since this and other such attacks are based on analyzing very small changes in the target system clock, even a tiny amount of randomization or pseudo randomization would be effective.

Although it would certainly make it more difficult, it would not be an absolute defense against the identification of the PC. Identification of a PC that is using this defense may not occur in 30 seconds after a single challenge, but could still happen over long periods and many challenges. The defensive changes in clock speed employed by the anonymous PC would not be truly random since they would have to stay within certain narrow parameters. This means that there would be 1)a baseline average clock speed differing for each computer, and 2)an average rate of change of clock speed for each computer. It would likely be possible to statistically identify a change in the average clock speed by issuing it many challenges, and to detect a different rate of change based on the timing of the challenges. In other words, computer 87 has a slightly higher baseline speed when challenged and it has a higher ratio of increases to decreases in its clock speed when challenges are issued.

Re:Randomize the clock

[Dion]

Hmm, I wonder if that has something to do with the length of time slices for very nice processes?

Did you do that test on a laptop?

Re:Randomize the clock

[Watson Ladd]

It's not what you think the time is, it's what they think it is that you need to find out.

Re:Randomize the clock

[evilviper]

Did you do that test on a laptop?

Not a laptop, nor a desktop with CnQ/SpeedStep...

In fact it is a 4 year-old Athlon XP, in a motherboard that doesn't even support S2K.

Re:Trivial Solution

[jandrese]

What if your servers are busy with other tasks, like decoding other people's TOR traffic? It seems to me that busy servers are pretty chaotic and this attack would be pretty dicey in the real world.

Fix it with NTP?

[Kadin2048]

Not that I think this sort of thing is really going to become anything more than an interesting proof-of-concept anytime soon, but couldn't you combat this by having a local NTP server for your server farm, and then setting the servers to update from that server at frequent intervals (say every 5 sec or so)? It would waste cycles on the machines and generate some extra load on the network, but it would keep the clocks from ever drifting far, and it would narrow the window in which you'd be able to detect drift to something pretty small.

Re:Fix it with NTP?

[Anonymous Coward]

couldn't you combat this by having a local NTP server for your server farm, and then setting the servers to update from that server at frequent intervals (say every 5 sec or so)? It would waste cycles on the machines and generate some extra load on the network, but it would keep the clocks from ever drifting far, and it would narrow the window in which you'd be able to detect drift to something pretty small.

Or try a simple hardware upgrade

Re:Fix it with NTP?

[Cramer]

One word: MULTICAST

Every computer on my network (several dozen) are sync'd every 5 seconds by a single packet. (ok, 3... one from each NTP server.) That includes windows machines too. (forget w32time and install ntpd)

Re:Fix it with NTP?

[Splab]

The article is very low on information on how he proposes to locate a computer. Yes clock skew would help, but you need to locate the machine somehow. And on top of that he thinks that more traffic equals higher load on the cpu. This isn't necessarily true, in a closed environment you might be able to do it, but on a global scale I can't see how this would help you unless you got global knowledge of the network, and if you do, sybil attack is a lot easier to do.

One must remember TOR doesn't guarantee strong anonymity, for that you need something like Herbivore.

Re:Fix it with NTP?

[tlund]

The 1kHz clock driving the TCP timestamps in Linux is not NTP corrected. You should probably read his paper.

Re:Fix it with NTP?

[dgatwood]

Exactly. This is kind of like the whole NP-Complete space. It's hard to find the right answer, but once you've found the right answer, it can be verified in polynomial time. Same thing here. It's a verification exploit, not a location exploit. It can, with a sufficiently large number of tests, verify that the host you think is providing the information really is. However, unless you can simultaneously track the heat emissions from every computer in the world (and somehow process that much information in a useful way!!!) it isn't a tracking tool.

The most likely place where this could be used is to provide additional evidence when there is already some reason to suspect that a person is serving illegal material. It could thus make a difference when obtaining a search warrant for someone who is already suspected. However, the initial evidence gathering and location would likely have to be done using more traditional (word-of-mouth, email interception, domestic spying) ways.

Re:Fix it with NTP?

[sjmurdoch]

The article is very low on information on how he proposes to locate a computer.

This is explained in the associated paper.

Re:Fix it with NTP?

[lky]

While Herbivore sounds interesting, don't forget to mention its limitations as well.

In the Herbivore documentation, you will find this PDF: Eluding Carnivores: File Sharing with Strong Anonymity

From which we learn that: The system consists of approximately 27,000 lines of Java and C code, 2,000 of which comprise the GUI for anonymous filesharing and a helper application for k-anonymous chat while the rest form the core system. (Section 5: Performance)

So Herbivore provides anonymity for filesharing and chat. That is all it can do in its current implementation.

On the other hand, Tor works with any IP based protocol and can be integrated into the applications that a user currently uses.

The second weakness of Herbivore is that it is not ready for distribution yet. The only code available is if you request to be part of the initial rollout by non-anonymous email. Herbivore Download Page

Tor is not only available for download, it is in current use.

The third weakness of Herbivore is that it requires that a client application be run on the users system. If your system is ever confiscated and examined by the authorities, this can be judged to be evidence of potential wrong doing resulting in further examination (if you don't believe this is possible, just read: PGP Ruled as Relevant For Criminal Case). A secondary weakness of the client is that it will limit the operating systems that Herbivore will run on to those systems that support Java and that Herbivore has been developed for (I2P has the same problem).

On the other hand, Tor can be used by simply configuring the users application to use a known Tor entry point as a proxy server. This configuration can be removed when the user is done, leaving little or no tracks. In this way, Tor can be used by any system that supports TCP/IP and SSL.

And the fourth and last weakness I will mention is that since Herbivore has not been released yet, it has not undergone extensive peer review and testing. On the other hand, the reason we are aware of Tors weaknesses is because it has been released, tested and peer reviewed. As we've learned from many cryptographic systems, you should not trust them until this peer review is complete and any/all weaknesses are known (which is why Tor has the disclaimer that it should not be fully trusted yet).

While Herbivore may provide strong anonymity, in no way is it a replacement for a general anonymity tool like Tor. On the other hand the more tools we have, the better. So I look forward to testing Herbivore when it becomes available.

Re:Fix it with NTP?

[Splab]

Theres a few reasons why this is so. First of all, this was as far as I know a proof of concept. Secondly in order to send one bit, the you need to transmit 2k+1 bits (from memory, should be in same section as the one you mentioned), that is very expensive. And due to the protocol it's very easy to do some DoS attacks on a clique, granted you can try to switch to a new clique, but you can spend a lot of time trying to get your message sent.

Re:Fix it with NTP?

[shadowmas]

Wouldn't this create a possible vulnerability where a malicious host could forge a packet containing wrong time and having all other computers updating the clock to that time? or are the hosts somehow able to validate the packets?

I agree it wouldn't do much in terms of dammage but i would guess it would make it possible to bypass a few time restricted activities, logging, etc.

Re:Fix it with NTP?

[Cramer]

NTP supports authentication. It also allows admins to set the authoritative sources.

Here's my config:

# Prohibit general access to this service.
restrict default ignore

# Permit all access over the loopback interface. This could
# be tightened as well, but to do so would effect some of
# the administrative functions.
restrict 127.0.0.1

# --- OUR TIMESERVERS -----

# --- NTP MULTICASTCLIENT ---
multicastclient # listen on default 224.0.1.1
  restrict 224.0.1.1 mask 255.255.255.255 nomodify notrap
  restrict mask 255.255.255.255 nomodify notrap

# --- GENERAL CONFIGURATION ---

#
# Drift file. Put this in a directory which the daemon can write to.
# No symbolic links allowed, either, since the daemon updates the file
# by creating a temporary in the same directory and then rename()'ing
# it to the file.
#
driftfile /etc/ntp/drift
broadcastdelay 0.008

#
# Disable authentication
#
disable auth

Re:I didn't RTFA, but...

[Arethan]

According to TFA, no. Now maybe you want to R it. You must be new here...

Too easy to defeat

[Anonymous Coward]

So the next iteration of TOR will inject random +/- tick into the timestamps. Making it impossible to decorrelate.

Not to mention that anonymous browsing are not servers. They will not respond to load.

What is needed - better protocols for mail and other services making anonymous services moot.

WHA!?!

[illeism]

I'm changing my heatsink from copper to fiber...

Great heat source

[edwardpickman]

I miss read the title the first time, the joke being I do heat my office with computers. I have three of them in the room and the 4800 dual core puts out a fair amount of heat on it's own keeping it toasty compared to the rest of the house. I used to have a dual 300 that got so hot you couldn't touch the side of the case. I literally put a box fan on that one to keep it running.

Re:Great heat source

[Gordonjcp]

I have a PDP-11/73 that warms up the workshop quite nicely. I don't know why, but despite drawing around 400W (just the same as my PC) it throws out a lot more heat. Of course if you fire up the big RL02s it gets a lot noisier and the current draw goes up. Just the PDP-11 on its own is quieter than my PC, too, despite having four 5" fans.

Re:Great heat source

[Anonymous Coward]

a fair amount of heat on it's own

"its".

Re:Trivial Solution

[Bios_Hakr]

I picture this attack being used as part of an ongoing investigation. They have a target and they just need some pattern analysis to secure the warrant. Over a month-long investigation, they could glean a lot of info by throwing up very specific requests and seeing if your hard drive springs to life or your CPU spikes.

In most cases, the wouldn't even need to be near your house. A well-positioned amp-meter with remote sensing could tell you if the CPU suddenly needed more power.

April already?

[daveb]

It's amazing how fast the year flies. It seems like Christmas was just this week and we're already at April 1.

Re:I didn't RTFA, but...

[Barny]

Close, but no cigar.

His software lets you pinpoint servers in the anon TOR network, good trick, but ultimately useless (since its the users computer you are trying to find).

Of course the other problem is "giving it a heavy load" define heavy load? is it just a little more than usual? or does it mean you have to heat board (he goes off system clock, maintained by a frequency crystal on the MB), most data centres I would think would be fairly efficient at routing even high heat loads out of enclosures and away from the machine.

And then, whoever he does this to can sue him for DoSing their machine, if they can prove (and its not overly difficult) that heat damages computer parts, he can be nabbed for wilful destruction of property as well, since his whole exercise heats the machine for no other reason than locating it.

Then of course, the only way to "heat up" said computer is to do it through the TOR api, which i am guessing most anon servers are built to handle very well (since that would be their primary task).

Oh, and this of course neglects to take into account that your TOR requests may be handled by many many servers in a cluster, each one heating and skewing at different rates...

Ok, its late on a Saturday afternoon and I can poke that many holes in his trick (even if only one is at all real), gimme a good 2-3 hours with some energy drinks in me and I can find more I am sure ^_^

If he can prove it works (and successfully do something usefull with it) in the real world, then it would be a better story.

Re:I didn't RTFA, but...

[Hooya]

consider the parent posters ID: 25287
consider your id: 223197

then, consider the fact that you found "You must be new here" a novel response - at least novel enough for you to use it. let me just say, *You* must be new here. :P

P.S. i hope the recursive irony - including my ID and the parent posters ID - is self evident. no need for recursive "*You* must be new here" replies. please think of the children.

P.P.S. i don't really think recursion is the right word. but the fact that an 'older' user is declared 'new' by a newer user on each child post should lead to a division by zero, a black hole, or at least a bazzarro world somewhere... or it might just be my bed time.

Re:I didn't RTFA, but...

[Tweaker_Phreaker]

Read what you just said. Skew is a distortion of measurement. In normal operation there is no distortion, only when the crystal is heated. So by definition there is only one possible value for the skew and it's the change from before to after the crystal has been heated.

utterly useless?

[pavera]

Ok, so if I am using Tor, presumably I've got clients behind these servers.... so according to the article, he can detect a server? What good does that do him? That doesn't identify *MY* machine the client which is actually doing the browsing. So, he can see which server is running Tor... couldn't he just portscan to find that out?

Re:utterly useless?

[Anonymous Coward]

TFS mentioned "servers" and then jumped to "hidden servers".

Hidden services are something different than a Tor user. A hidden server is reachable via some hostname in the .onion TLD and provides services like HTTP, just like in the non-Tor network. It's basically an anonymous server instead of an anonymous client.

Re:I didn't RTFA, but...

[DaSilva_XiaoPuTao]

Sounds alot like the timing based attack on RSA. And it's very easily countered with adding some extra (random if you want) time padding.

Re:I didn't RTFA, but...

[qbwiz]

Sure there's clock skew normally. I know that my computer doesn't have a caesium-133 atom inside of it. As such, the clock is inaccurate and bound to vary relative to the correct time. I have noticed that it has been up to a couple of minutes off. Right now, as I updated it from an NTP server, it was 4 seconds off. It has to become inaccurate to have that problem.

More info on Murdochs talk

[tlund]

More info on Murdochs talk can be found at the congress website.

Re:I didn't RTFA, but...

[Short Circuit]

P.P.S. i don't really think recursion is the right word. but the fact that an 'older' user is declared 'new' by a newer user on each child post should lead to a division by zero, a black hole, or at least a bazzarro world somewhere... or it might just be my bed time.
 
  I'll take issue with your usage of the word "older"; I'll have you know that, at a measly 23 years old, I'm probably younger than /. users with a higher UID number.

And I'm too tired to really care that I really don't need to get involved in another log(UID)-based pissing match. (But hey, isn't that what posting on Slashdot at 2:30AM is all about? Besides, I already made a constructive comment over in the article about embedding DB authentication credentials on software.)

(And this ends my stupid and over-explained attempt at being funny May a future potential employer find this comment and giggle.)

Re:Trivial Solution

[Lehk228]

folding@home running at low priority will suck up the unused cycles on your machine giving a pretty much flat power draw in response to "extra" work since you are always doing extra work

Re:I didn't RTFA, but...

[Toba82]

You must be new here.

Everyone knows that no number of P.P.P.P.P.P.P.S.s that you can add will prevent SOMEONE from posting this very comment.

Re:I didn't RTFA, but...

[Tweaker_Phreaker]

Yes but that's not the skew he's measuring. He's only measuring the skew caused by heating the crystal.

Re:I didn't RTFA, but...

[Anonymous Coward]

The word you're looking for is induction.

Re:Trivial Solution

[MBHkewl]

There are CPU frequency-shifting programs (for Linux: cpufreq) that allow the computer's user to change the CPU's frequency to his/her liking...
One could easily set the frequency lower than the original maximum, so that spikes can't be detected.

Add to the above approach, keeping the clock in sync, as others have noted.

And if I suddenly load a video file

[bruce_the_loon]

My CPU temp would spike more than what he's doing to me. Or if I'm playing a game.

Packet-rewriting firewalls, here we come :)

Re:And if I suddenly load a video file

[Anonymous Coward]

My CPU temp would spike more than what he's doing to me. Or if I'm playing a game.

Mine will usually go at least from 114F to 135F just while loading acrobat reader. Meanwhile the fan goes from low to medium to high. I could hear the difference in the next room if I launched myself out of the chair immediatly after double-clicking the filename.

Re:And if I suddenly load a video file

[Sorthum]

Foxit reader has a crap-ton less overhead.

Re:And if I suddenly load a video file

[grub]

Packet-rewriting firewalls, here we come :)

Has been done for years.

Utter Bullshit

[imag0]

Apparently written by someone whom has never stepped in a well stocked data center before.

Re:Utter Bullshit

[dfoulger]

Obviously someone who is unaware of the millions of machines that are routinely overheated by overload ... most machines running graphics intensive applications and all machines running BOINC. Bad thinking, but wishful thinking often is. Davis

Nope.

[Anonymous Coward]

Never randomize what you can remove. They'll do a bunch of attacks, then average out the randomness.
Best to try to correct for the clock skew more often, instead.

Re:Trivial Solution

[MBHkewl]

Plus other distributed projects, like the ones from http://www.distributed.net/

Re:I didn't RTFA, but...

[johnw]

You must be new here...

Re:I didn't RTFA, but...

[ColaMan]

I really don't need to get involved in another log(UID)-based pissing match. (But hey, isn't that what posting on Slashdot at 2:30AM is all about?

STFU, noob. :-P

Waiting, waiting, waiting.....

Easy solution...

[AmiMoJo]

Just run Folding 24/7, max out your CPU. Also, monitoring heat requires physical access to the server. Oh well, nice try though.

FTA: Easier, faster, not temp.

[Anonymous Coward]

Gee, all this braintrust and everyone missed the part were he says that there are easier and faster ways to attack Tor. Maybe you all should be worrying about THAT, instead of how to keep your clocks from skewing?

Curiously

[Jacques Chester]

All the anonymised computers which heated up had Pentium 4s.

Sounds like a ...

[genmax]

lot of hot air to me ! *ducks*

Re:I didn't RTFA, but...

[Scarletdown]

Someone finally posted the Saddam execution video:

And here I thought he was executed via hanging. Instead...

Death by Boonga-Boonga!!!

Re:I didn't RTFA, but...

[kfg]

. . .the fact that an 'older' user is declared 'new' by a newer user on each child post should lead to a division by zero, a black hole, or at least a bazzarro world somewhere...

. . .in Japan!

KFG

LOL

[wickedsteve]

You need to query a list of suspects and there are only at best 64 unique fingerprints.
Should I be scared now?

Hold on

[fred911]

It looks to me like this can (somewhat) finger print a given machine but I sure don't see how it can discover an IP on TOR.

Re:I didn't RTFA, but...

[jesboat]

pwned

Re:Trivial Solution

[evilviper]

A well-positioned amp-meter with remote sensing could tell you if the CPU suddenly needed more power.

Somehow I don't think that would meet the standard for evidence...

You need to measure tiny variations in current caused by one device, mixed in with the haystack of all the other electric devices in your house... Most of which can vary significantly from moment to moment.

please read the other posts before posting

[name*censored*]

You are the lucky eighth person to post this very same idea (almost word for word) :)

Please read the other posts :)

Re:I didn't RTFA, but...

[steveoc]

You must be ....

awww .. forget it.

Re:I didn't RTFA, but...

[Anonymous Coward]

Close, but no cigar. His software lets you pinpoint servers in the anon TOR network, good trick, but ultimately useless (since its the users computer you are trying to find). A foolish statement. Tor offers the facility of hidden servers, or receiver anonymity. Some servers wish to remain anoymous. In other words it is _not_ the user we are interested in for this attack.

Of course the other problem is "giving it a heavy load" define heavy load? is it just a little more than usual? or does it mean you have to heat board (he goes off system clock, maintained by a frequency crystal on the MB), most data centres I would think would be fairly efficient at routing even high heat loads out of enclosures and away from the machine. Did you read the paper ? Again, obviously not. The clock skew is present even without the temperature affect, however minor changes in temperature do offer additional clock skew. The range of temperature causing skew is under 2 degrees.

And then, whoever he does this to can sue him for DoSing their machine, if they can prove (and its not overly difficult) that heat damages computer parts, he can be nabbed for wilful destruction of property as well, since his whole exercise heats the machine for no other reason than locating it. An fine point, outstanding. Except we don't know who the person is, they are using Tor. Sender anonymity, it's great.

Then of course, the only way to "heat up" said computer is to do it through the TOR api, which i am guessing most anon servers are built to handle very well (since that would be their primary task). No this is not the case, as in fact most 'anon servers' or tor onion routers are not built for Tor. Tor is an additional feature run on these machines, there are very few core tor routers, solely dedicated to tor. And of course by merely routing a number of streams, doing exactly what the application was designed to do, the temperature will build up.

Oh, and this of course neglects to take into account that your TOR requests may be handled by many many servers in a cluster, each one heating and skewing at different rates... There is no support in Tor at the moment for load balancing, if that is what you are implying.

Ok, its late on a Saturday afternoon and I can poke that many holes in his trick (even if only one is at all real), gimme a good 2-3 hours with some energy drinks in me and I can find more I am sure ^_^ If he can prove it works (and successfully do something usefull with it) in the real world, then it would be a better story. Read the paper and inform yourself. http://www.cl.cam.ac.uk/~sjm217/papers/ccs06hotorn ot.pdf

Far simpler method...

[Kjella]

1. Create a minor botnet
2. DDoS a server, not enough to kill it but slow it down a lot
3. Measure response times to hidden service
4. If all requests using different paths now are slow, you got it

Also, that attack scales to detect multiple hidden sites simultaniously - hit one server, request ten sites and see who answers quickly and not. It's just a consequence of depending on one machine. The only way you could totally avoid that is to not have services at all, only distributed datastore like e.g. Freenet. That would severely limit the possible applications though.

Simple Defense

[Cbs228]

Since date and time information isn't included in TCP/IP packets, this kind of attack won't work for all services. Assuming that the "hidden servers" in question are HTTP servers, there is a rather simple workaround: simply disable sending the "Date" header. This can probably be accomplished with mod_headers in Apache, but I've never tried using it myself. Oddly enough, the server would still be standards compliant. Obviously, servers that leak the current time by some other means would still be vulnerable.

A simpler, less precise attack of this nature would simply be to continuously ping the suspected server via both Tor and the public internet. If they (reproducibly) fail at the same time (and we could launch a denial-of-service attack to make it fail), they're probably the same machine. Attacks of this nature might even be able to confirm if a hidden server is on the same network as another computer.... But any of these attacks require someone to suspect you of running the server in the first place—and if they do, you probably have bigger problems to worry about.

The bottom line is, as Tor's manual clearly indicates, having a hidden server machine accessible from both Tor and the internet is a bad thing. Operators of hidden services should use a dedicated machine and block all incoming traffic (on all TCP and UDP ports) that is not via Tor.

Re:Simple Defense

[sjmurdoch]

Since date and time information isn't included in TCP/IP packets

Actually, it is, and this what I mainly use, but initial sequence numbers also incorporate a timer. If both are unavailable, the link between packet emission and timer interrupts will still show up the clock skew.

Anyone got a tin foil hat?

[Anonymous Coward]

That's it, I'm removing the NSA logo'd temprature monitor from my PC.

The answer is RC5, or SETI

[Bert64]

If you leave a process running in the background consuming 100% of your cpu all the time, like setiathome or distributed.net, then your system won't get hotter, rather it will just be processing something else to load the cpu and still generating the same amount of heat.

Re:The answer is RC5, or SETI

[Anonymous Coward]

Hey wow, never saw that idea before. Read much?

Re:Trivial Solution

[Anonymous Coward]

It shouldn't be too hard to isolate the power usage of your basement.

Time Sync Early And Often

[martyb]

What if there were a time sync server in the setup whose whole purpose in life is to keep track of the time?

Have no other apps running on it, so that it has negligible system load. All the other systems in the TOR could be set up to sync their time with it every few seconds, i.e. before clock drift becomes detectable. Might check each and every second so as to intentionally cause a collision on the time server and add some randomness. Or, do a time sync every random(1..10) seconds. Or, use multiple NICs going to different ports on the switch/router where one NIC has a short ethernet cable, and the other one is quite long, so as to introduce different delays in the comms with the time server. I'm sure there are other ways.

Re:Time Sync Early And Often

[Anonymous Coward]

You wouldnt even need to do it that fast... TFA states it would take a few hours of time drift to detect a server that also has a Known IP... seems like you could get away with syncing the clock every hour or so... Of course only getting 64 unique fingerprints on something like the TOR network which I would image has thousands, if not hundreds of thousands of computers connected wouldn't be very useful....

Run Seti@Home for your privacy

[Skylinux]

Here is a simple way of beating this attack, run Seti@Home to keep your computer cooking at all times.

Re:Run Seti@Home for your privacy

[slothman32]

Seti!
At least that has a point.
I haven't found anyone who didn't think Norton made programs which don't take all your resources.

Use NTP to defend against all clock skew attacks

[Terje Mathisen]

This theoretical attack is based on using (previously covered on /.) clock skew to identify systems.

The correct defense is the same as the last time:

a) Make sure that there is no system clock skew, by running Network Time Protocol (NTP) on all servers.

b) Make sure that all externally visible timestamps are based on the system clock.

Part (b) is the only difficult step, since many current IP stacks use a private counter/clock instead of the system clock, presumably to reduce the overhead of providing timestamps. I know that Linus T have discussed using user-level library code to provide microsecond resolution (or better) timestamps, with very low overhead:

The library code can just query the cpu/system timer, multiply by the current scale factor (which depends on things like dynamically variable cpu clock frequency), and add the base time which was stored by the OS on the last HW clock interrupt: Total runtime, including call/return overhead can be below 100 clock cycles, which is fast enough to use it everywhere timestamps are needed:

BTW, I wrote asm code to do exactly this inside Novell's NetWare OS a little over 10 years ago. In NetWare these timestamps were used by the Packet Burst algorithms which optimized packet transmission rates.

Terje

Re:I didn't RTFA, but...

[Anonymous Coward]

You really should've read TFA in this case. Not to mention that the story submitter and the goddamn "editors" should also have RTFA.

Re:I didn't RTFA, but...

[Sorthum]

And you must have missed the part that it's not the timestamp he measures, but the change in timestamp over a period of time that correlates to what he has the remote server do. That's a lot more telling.

Somewhat Major assumption here..

[FrostyCoolSlug]

Ok, I read the article, and it essentially says.. "Do something intensive, the clock slows down marginally, then use the differences potentially created to find which machine it was".

In his TOR network test, he apparently found the machine, but.. How many of them were receiving "Normal Day to Day" use? On how many of those machines were people playing first person shooter or real time strats? even once the TOR request is complete, if people are still gaming, in the time it takes to find the IP, that skew more than likely would have increased more.

In a real life situation, the time it would take to find a tor server, would be easily long enough for a different skew to have developed.

Apparently it's difficult to defend against it, but it's also difficult to actually PROVE it.

what if

[hurfy]

What i haven't seen mentioned yet is:

Won't this break down if more than one investigator is running this attack on a network? What if several people try this trick against a group of servers? How would they know the time skew was due to THEIR query? What if this is the best trick ever so everyone trying to track down a computer uses it ;)

Couldn't they detect whatever the popular trick is to increase temp and have the computer try and skew others on the network. I don't suppose you would want to do it randomly against your own network as it may slow everything down but it seems you certainly could.

Seems like a lot of variables in there along with the other ideas presented.

Sounds like a good theory that runs into real world speed bumps pretty quickly.

Having a flying car to get around traffic sounds great, until everyone else gets one too....

Watt goes around, comes around.

[Ungrounded Lightning]

I miss read the title the first time, the joke being I do heat my office with computers. I have three of them in the room and the 4800 dual core puts out a fair amount of heat on it's own keeping it toasty compared to the rest of the house. ...

I did the same "back in the day" when I got my first personal Unix box - an Altos 68000 - one of crowd of generic Motorols 60x0 unix boxes that came out before PCs squeezed them out. With a meg of RAM and an 8" hard drive it put out enough heat to keep the computer room and the adjacent living room toasty in a Michigan winter.

Of course this was an issue in a Michigan summer. Fortunately the 4" fan blew OUTWARD at the rear of the box. I modified a drier vent to mount over the fan and ran a 4" drier hose to a similar vent mounted in an insert in the window. Then the heat was exhuseted outdoors. B-)

Ops/watt were a lot fewer in those days. But the dissipation per room without cooling and power available per outlet is still the same. It's interesting that we now have enough uses for crunch that the old room-heat issue is still (or once again) with us.

This system requires 2 points of info

[Allnighterking]

Not one. You have to know a finite set of computers that are a Tor network. In my reading of the article it seems that without this finite set you fall victim to the 16 per 1000 that have the same skew, problem.

Without knowing as well that all systems are skewd differently you also have a problem. What if you grabbed a random set of 32, with 2 groups of 12 and one of 8 with identical skews.

Re:I didn't RTFA, but...

[Ferzerp]

is this the place for people with uid's under 100,000?

Heat seeking missives

[PopeRatzo]

I can see SWAT teams zeroing in on toaster ovens all over the World.

Any self-respecting admin is going to keep his servers in a temperature controlled environment, but the lunch room is another story entirely.

I want to know the size and source of the grant supporting this research. I'm looking for funding for my fusion-at-room-temperature device (pics on YouTube!).

Links

[Anonymous Coward]

This paper is actually a few months old. It was presented to the ACM in October and linked from Light Blue Touchpaper in September. Here is a link to the summary along with links to the actual paper and slides to Murdoch's talk:

http://www.lightbluetouchpaper.org/2006/09/04/hot- or-not-revealing-hidden-services-by-their-clock-sk ew/
http://www.cl.cam.ac.uk/~sjm217/#talk-ccc06hotorno t

I believe many of the mitigation techniques mentioned in previous comments have been discussed elsewhere and some of them do not work nearly as well as you would expect.

this is just a ploy to give them probable cause

[DragonTHC]

9 million different things could cause a cpu to heat up.

first of which is poor circulation.

bad software, a network attack, a defrag, a virus scan

and since when is TOR a bad thing? since when is anonymizing your computer a crime?

Re:this is just a ploy to give them probable cause

[John Hasler]

> ...and since when is TOR a bad thing? since when is anonymizing your computer
> a crime?

Who said it was? If you are using TOR you must be doing so for some reason and therefor should be interested in evidence that it is not as anonymous as you though it was.

Fix it with SETI at home

[p7]

An easier fix would be to keep the processor pegged at 100% with a low priority process. Any new process would just keep the maxed, so there shouldn't be any appreciable heat related skew.

Re:Fix it with SETI at home

[Em Adespoton]

Or, just have the Tor server toss a little random data between two ports from time to time, as is done to secure other hardware where this technique has been tried in the past (like smartcards). Or just run WoW in the foreground ;)

Re:Use NTP to defend against all clock skew attack

[Score Whore]

I thought you were dead....

Re:I didn't RTFA, but...

[Tweaker_Phreaker]

Not at all, people are making too many assumptions about what is not written. All it says is that he tests the skew caused by heating up the crystal which takes several hours to do. It says nothing about testing the skew while the system is "idle" because in reality there's no way for him to know if the system is actually idle or not. His system is all about making sure there is a load and then testing the skew while it's hot.

A cool fix...

[ted]

Simply lock up the CPU doing something busy all the time.... ie

nice -n +20 gzip < /dev/zero > /dev/null &

On any modern unix variant, you'll not notice any loss in performance, however, just about every available cpu cycle will be chewed. Your system load (cpu and interrupt) will be relatively constant, regardless of what else you might have the box doing.

Check and see, but I think all of us unix junkies have those commands installed by default. :) No recompile or rewrite of some RFC required.

I think it's a cool fix.

Wrong Target

[YetAnotherBob]

This technique will work to find where they are looking, but now who is doing the looking. It'd take a lot of traffic to make my computer at home heat up.

Sounds like what they have is more a way to tell which server you are using. not sure it would be useful to anyone else. Also, there must be some false positives here too.

Tor without software installation?

[Kadin2048]

On the other hand, Tor can be used by simply configuring the users application to use a known Tor entry point as a proxy server. This configuration can be removed when the user is done, leaving little or no tracks. In this way, Tor can be used by any system that supports TCP/IP and SSL.

This is slightly offtopic, but I didn't realize that you could use the TOR network in this way. Can you expand on this? I thought in order to use TOR, you had to install the TOR software package on the end-user's machine, and then point the web browser to use a SOCKS4a proxy on the localhost, running on some special port.

I always saw this as a weakness of TOR, because it meant that you couldn't use it from a public computer, or in an atmosphere that was hostile to the very idea of anonymity products in general.

Do you have to set up a special TOR node to accept external SOCKS connections, in order to use TOR without any software installed? Or can you just get a list of addresses somewhere that are known inputs into the TOR network, pop one into your proxy configuration, and surf away? (And in the latter case, where does a person get the addresses?)

Re:Tor without software installation?

[Splab]

That was the point of our project, to make it easier to use. With a linux router running iptables and our software all TCP/IP will be captured and transmitted on TOR (Or whatever subset of TCP/IP communication you want it to grab)

Seems like bs to me

[darrenadelaide]

Seems like a pile of steaming bs.

Even if the theory were true, you still would be going through multiple computers, so you would be unable to detect skew, let alone packet latency which would differ.

NEXT

Darren

Re:Seems like bs to me

[Anonymous Coward]

You didn't actually RTFA, did you? See this post and its response.

How can I work it into my next CSI:Renton script?

[jeblucas]

This is good science-y stuff. It sounds like something that could actually happen, so I want to jam it into my next script for CSI:Redmond. Here's what I need from you nerds:

1. Some dialogue explaining the process* in a step by step manner that can be spoken over stylized computer screenshots and typing noises.
2. Some Photoshopped computer screens with GIGANTIC FONTS that look like the process is happening. Progress bars please.
3. Some kind of hip crime that computer nerds are doing now. Pedophilia is old news--Dateline has that wrapped up. Something with barely concealed titties would be nice, but I may be asking too much.

Thanks for your help, please send said help with a waiver.

* Accuracy NOT required.

Re:I didn't RTFA, but...

[Anonymous Coward]

Fuck you. Anyone who still pretends they're a "phreaker" needs to have their nuts removed so they can't reproduce.

Re:I didn't RTFA, but...

[MyIS]

Skew this discussion.

...sorry about that. :)

Re:I didn't RTFA, but...

[Tweaker_Phreaker]

Rofl, sounds like I hit a nerve. I made a few accounts way way back and this is the only one I've been able to remember and don't give a rats ass about how bad a name it is.

Re:Trivial Solution

[bombshelter13]

Or possibly even have it randomly change frequency within a range of a couple hundred mhz at random every few seconds.

Re:I didn't RTFA, but...

[Anonymous Coward]

My name isn't Rofl.

Watch who you're calling "noob"...

[Svartalf]

...Noob

Re:I didn't RTFA, but...

[Anonymous Coward]

You definitely are new here.

Abandoned ID's can be reclaimed by new users.