Recently there has been a substantial amount of discussion concerning the use of accurate timing in an attempt to uncover encryption keys, by carefully noting the length of time that a decryption takes in a computer of a known cpu speed. I have noticed that most of the discussion focussed on the delay time of the overall operation done over a network, for example a LAN or perhaps the Internet, but it has been recognized that imprecision due to indeterminate network timings make such a tactic problematic at least. However, being a ham and occasionally listening to the various odd noises produced by a computer when you tune a VHF or UHF ham radio to a harmonic of the clock speed, it ccurred to me that the delay times WITHIN a particular encryption/decryption would be far more easily measured with local RF snooping. I would imagine that if you can determine even a fraction of a bit of key from a network "ping," you could do a lot better "listening" to the execution of a program within a few hundred feet with an ordinary radio receiver and a sophisiticated analysis program. Okay, I admit, this is certainly not a new idea. The military's TEMPEST program is to build electronic equipment which is so "quiet" that it is impossible (or, at least, arbitrarily difficult) to capture useful information by inadvertent radio transmission. Obviously, that is out of the league (not to mention the budget) of the vast majority of the users of personal computers. Nevertheless, it seems to me that if we as a community of computer users are interested in security, we should not merely focus on the mathematics and algorithms used and their reliability, but also secondary methods to break the systems involved. True, most of us are not sufficiently interesting "targets" to justify this kind of attack, but machines such as encrypted remailers are sufficiently "high value" that protecting them would be worth a little extra effort I'm not under any illusion that we can hope to make them "snoop-proof", but a little effort should substantial raise the difficulty level.. More than a year ago, it occurred to me that it might be worth it to build a CPU clock replacement module that took the place of the main CPU crystal oscillator, and replaced it with a oscillator module whose frequency was (very long period!) pseudorandomly varied, possibly with a resolution of 16-bit and over a range of perhaps 1%., with the frequency varying every few tens or hundreds of microseconds. The result, I presume, is that every operation synchronized to the microprocessor clock would vary in time and would be hard to "tune" with a normal radio receiver. It seems to me that this would make the resulting computer harder to "bug" using standard equipment. If this were do-able and were in fact done, it would probably be worth it to "tailor" the spectrum of variation in clock speed so that these variations do not tend to average out over "long" times, for example a few hundred milliseconds or even tens of seconds. This would at least help to disguise the decryption-time information that is commonly discussed. A complicating factor is the fact that modern motherboards often generate their microprocessor clocks using PLL synthesis from a master clock, probably the 14.318 MHz clock. On the one hand, that might make the process easier; only one clock to vary. On the other, it is at least conceivable that there are some devices in any given computer which depend on a precisely constant clock speed, and would not tolerate such variation. This was probably more true in the early days of the IBM PC; today you usually see separate crystals on any cards that need truly specific frequencies. (Hey, I didn't say this was a perfect solution, merely one that would raise the barrier a bit...) Other potential tactics. (Some of which are already happening; if anybody out there is more informed about such techniques, please tell me) 0. Copper-screen cages. Okay, maybe this appears to be a bit too obvious, but it really isn't too involved: A few years ago, I happened onto a roll of honest-to-goodness copper screen; sort of line window screen but made of pure copper. Sewn/soldered into a bag, it would make an excellent cover. (openings required for floppies and CDROMS, as well as cables are obviously a complication, but... 1. Use CPUs with Internal caches as well as external caches, both to reduce the amount of electronic noise transmitted to antenna-length wires outside the microprocessors, as well as make external memory accesses less predictable and less frequent. Fortunately, I suppose, the natural transition to 486's, DX2's and DX4/4s) and Pentiums has make this happen without any anti-snooping motivaition. 2. Eventually, CRT's will be replaced with some sort of matrix-type displays that emit far less useable information and will be easier to shield. 3. Filtering of every wire that comes out of the computer's case, primarily using a combination of ferrite beads and decoupling capacitors. This would be especially true of the telephone line, which would be accessible from outside a house or office. Also, use of multiple powerline filters/surge protectors in series. 4. I'd pay particular attention to the keyboard interface and its associated microcontroller: Years ago, I speculated that if a VFO (voltage to frequency converter) was placed on the data line between the keyboard and the computer, it would transmit the identity of every key pressed. (This would obviously include passwords, too) (Does the keyboard hardware of the typical PC allow echobacks, whcih would allow the CPU to fill the CPU/Keyboard channel with apparently meaningless random garbage, thwarting RF overhearing of this data?!?) And I wouldn't be surprised if the NSA has built replacement keyboard controllers to be used to surreptiously replace on garden-variety keyboards, controllers which deliberately "broadcast" such information in an even easier-to-discern pattern. Even a short access to such a keyboard and it might be telling your secrets. Even if a black-bag job wasn't possible, If it were possible to tune to its normal keyboard microprocessor operation rate, and given a known keyboard scan pattern a particular pressed key could be identified. Given how cheap keyboards are these days, a slightly paranoid person might buy one from a trustworthy source and glue the case shut to prevent tampering, and replace it monthly with cast-offs. 5. While this isn't my area of expertise, it occurs to me that softrware should be written to complete operations in an identical time frame, no matter the input data. While this has already been hashed over on the nets, the "solution" that is typically discussed involves adding a null loop at the end of the real operation, and contining only after the "wall clock" shows enough time has passed. This isn't an adequate solution, I think, if local RFmonitoring of the computer can be done. (It will know when the actual result ended) A better (and, sadly, more inefficient) method would involve executing BOTH branches of conditional jump, and only using the data generated from the desired half at the very end.. Another possibility might be (for certain large mathematical algorithms) is to split up the functions and to execute them in a "random" order, with enough "dummy" operations inserted to further disguise the facts. For example, if you're multiplying two 1024-bit values to get a 2048-bit result, program this to be done in a pseudrandom order and intersperse any operations with pseudorandom operations to disguise it. (A pseudorandom interrupt generator might help, here.) 6. Think like an NSA hack. If I were such a sneaky bastard, I'd try to figure out a way to module a visible LED on the computer's case with data, or modulate the video display's brightness to signal slow-speed data.. Well, that's just a few thoughts. There's a lot more material out there that ought to be discussed. Admittedly, these subjects can appear to be a bit more than a little paranoid, but without such discussion we're almost certain to be at risk.