Slashdot Mirror

I remember reading about TEMPEST standards from the government. The documents were (mostly) declassified recently and have standards for wiring sensitive (RED) data connections in different environments-- all the way to battlefield conditions.

Plus, you have some CYA protection here since it's a predefined standard!

http://www.eskimo.com/~joelm/tempest.html

http://www.fas.org/irp/program/security/tempest.ht m

... but I still like the chain link fence idea with guard dogs ...

for fast, cheap broadband is Bill Fogal's semiconductor. If I read those pages correctly, it will eliminate the need to rip out the thousands of miles of existing copper cable and replace them with optical fibres, while providing LOTS of bandwidth. And more...

According to Tom Bearden, it should become available early next year. I just hope it doesn't fall into the same black hole that comsumes so many of these weird inventions.

See http://www.eskimo.com/~scs/C-faq/q11.14.html for details

A sig would go here

"There is even a system called TEMPEST that detects electromagnetic emanations from a computer monitor." ?

Really ?! And here I thought it was a code word, perhaps even an acronymn, that that identifies a classified set of standards and endorsements for LIMITING electromagnetic emissions radiated from electronic equipment.

So for all you confused members of the press:

• The Complete, Unofficial TEMPEST Information Page
• TEMPEST in a teapot
• NSA/ISSO TEMPEST Endorsement Program

There are 2 (and only 2) reasons why one should own an SUV.
1) You do serious off-roading. This does not mean driving down a dirt road, or even a muddy road. It most certainly does not mean driving on ice or snow. This pertains to people who take their vehicles over combinations of large rocks, standing water, mud, loose dirt, etc.
2) You have a large family and you frequently tow a large payload (such as a boat).
In all other cases, an SUV is the wrong vehicle for the job, and if you are considering it you need to seriously analyze your choice of vehicle. SUVs are not safe. They are more dangerous in single car collisions (such as when you lose control of the vehicle and hit a guardrail, ditch, telephone pole, etc.), they are less able to handle emergency situations (such as swerving or hard braking to avoid road obstructions). Their Body-On-Frame construction means that in a collision with a smaller car, the brunt of the force will be transferred to the other vehicle, and in a collision with a larger vehicle (such as another SUV), the occupants will suffer the brunt of the force.
Please read the following sites for information regarding the myths of SUV "safety" and their ability to "handle" inclement weather.

Why SUVs are inferior on-road and off-road

Why technically advanced All-Wheel Drive systems are better than primitive part-time 4WD

On a side note, some have mentioned in defense that SUVs are taxed higher through the gasoline tax. Consider that many high-end sports cars (such as Porsche 911 Turbos, Ferarris, and such) are tacked with gas-guzzler taxes even though they get better mileage than the king of inefficency, the Ford Excursion V10 (8 city/10 HWY) and you will start to see the "fairness" of the fact that these vehicles don't have to stand up to the same crash standards, construction standards, or fuel standards that other vehicles do.

There are 2 (and only 2) reasons why one should own an SUV.
1) You do serious off-roading. This does not mean driving down a dirt road, or even a muddy road. It most certainly does not mean driving on ice or snow. This pertains to people who take their vehicles over combinations of large rocks, standing water, mud, loose dirt, etc.
2) You have a large family and you frequently tow a large payload (such as a boat).
In all other cases, an SUV is the wrong vehicle for the job, and if you are considering it you need to seriously analyze your choice of vehicle. SUVs are not safe. They are more dangerous in single car collisions (such as when you lose control of the vehicle and hit a guardrail, ditch, telephone pole, etc.), they are less able to handle emergency situations (such as swerving or hard braking to avoid road obstructions). Their Body-On-Frame construction means that in a collision with a smaller car, the brunt of the force will be transferred to the other vehicle, and in a collision with a larger vehicle (such as another SUV), the occupants will suffer the brunt of the force.
Please read the following sites for information regarding the myths of SUV "safety" and their ability to "handle" inclement weather.

Why SUVs are inferior on-road and off-road

Why technically advanced All-Wheel Drive systems are better than primitive part-time 4WD

On a side note, some have mentioned in defense that SUVs are taxed higher through the gasoline tax. Consider that many high-end sports cars (such as Porsche 911 Turbos, Ferarris, and such) are tacked with gas-guzzler taxes even though they get better mileage than the king of inefficency, the Ford Excursion V10 (8 city/10 HWY) and you will start to see the "fairness" of the fact that these vehicles don't have to stand up to the same crash standards, construction standards, or fuel standards that other vehicles do.

good programming practices aside, it isn't required to.

Actually, you are required to. Compliers just don't enforce it well.

See the comp.lang.c FAQ 11.12 and 11.14

--Ty

good programming practices aside, it isn't required to.

Actually, you are required to. Compliers just don't enforce it well.

See the comp.lang.c FAQ 11.12 and 11.14

--Ty

good programming practices aside, it isn't required to.

Actually, you are required to. Compliers just don't enforce it well.

See the comp.lang.c FAQ 11.12 and 11.14

--Ty

Would you people please stop talking as if C/C++ were a language?

C and C++ are different languages. They obviously belong to the same family, and share a lot of syntax, but each has features the other does not. More importantly, they require different skills to use effectively. Much good C code would be bad style in C++, and vice versa.

Since the whole point of CS is to teach the underlying skills and not any one tool, this is kinda important. C and C++ are no more the same language than C++ and Java, or Java and C#. OK, forget the latter. ;-)

So, for goodness' sake, at least get the most basic information about these languages by reading some of the FAQs, before trying to comment. Pay particular attention to the last one, please; it was written by Bjarne Stroustrup, so it carries even more authority than the others.

You can safely assume that anyone posting about the "C/C++ language" here is neither an authority on C or C++, nor qualified to discuss the languages taught on a CS course.

TEMPEST is not a means to sniff your keyboard and mouse movements. TEMPEST is a standard explaining that it is possible to intercept and recreate electromagnetic emissions from a computer screen, computer chips and other aspects of the system. A TEMPESTed system is one that is hardened against spurious emissions.

Information on this can be found here: http://www.eskimo.com/~joelm/tempestintro.html#Wha t is

What about eavesdropping a la TEMPEST? (See this TEMPEST page.) This has been around and known for years and doesn't seem to be a big concern of the industry. It's all about acceptible risk. If you're data is not sensitive, use whatever hardware you like. If it's very sensitive, use shielded stuff. Where you fall in the spectrum should determine how much protection is warranted.

On one of the pages of William Beaty's Science Misconceptions site, there is a discussion of this issue with diagrams and further links.

Ok, I'll throw you a link:http://www.eskimo.com/~matth/hobby.html

A google search will pull up all kinds of analysis and commentary and historical perspective.

Some people have asked why we don't generate energy with one of those things. Well, we don't use a single parabolic mirror, because it is hard to build a very large one. Instead, we use multiple mirrors all angled toward a focal point, like this:

Solar Power Tower

While the website says that it is in use, the last few times I have driven by on (on my way to my parents house in Bako), it hasn't been exceptionally bright. I remember it in the late 80's, early 90's, the top of the tower looked like it was white hot (at the focus), and when they would move the mirrors away, above the tower, you could "see" a spot of "boiling" air - it looked like the wavyness you see rippling off a hot car, from the heat refraction, but hovering at a point in mid-air. Very impressive shit.

That's not all, though - want to build such a device yourself, for cooking perhaps? Check this...

Still not enough? Want to build a "real" solar furnace?

Go here!

Have fun, and don't burn yourself!

Worldcom - Generation Duh!

Why is this? As the majority of hobbyists must be aware, most of you steal your software. Hardware must be paid for, but software is something to share. Who cares if the people who worked on it get paid? Is this fair? ...

Companies are in three regions of the US and a South America country called 'Sereno' that was demographically somewhere between Mexico and Brazil. That way players only had to make one currency exchange and two GDP factors into account. Players have to mainly make production, advertising, pricing, and shipping decisions.

This made the learning curve was really light (compared to the Management Game by Center for Interactive Simulations) and only really took one class period with the prof clearing up detail questions from time to time. The game lasts for up to 6 game years with a decision/turn every quarter for a total of 24 turns.

We only played for 4 game years (two turns were due per week for the second half of the semester), and our grades depended on how well we did... my company came in third of eight; got a 'B'.

From an IT/game management point of view, it was pretty easy to set up. Students entered decisions at lab workstations to the server where the master console was installed and the profs sauntered by twice a week to run the master. Students then logged back on and got their own reports on what happened the last turn.

To sum up: the Business Policy Game was easy to learn, easy to play, and most students had fun with it.

For those of you that care, here is the real link:
http://cryptome.org/nacsim-5000.htm

also, here is a really neat site with an analysis on what this stuff really means:
http://eskimo.com/~joelm/tempest.html

and yet more great reading:
http://www.austinlinks.com/Crypto/tempest.html
http://www.thecodex.com/c_tempest.html
http://www.spyking.com/datascan.html

Hi again ;-)

Here is an article about a guy who build such a weapon, mostly out of commercially available tools.

*pretends that he is not into these things* ;-)

cheers
mike

Check it out. It's no joke.

www.eskimo.com

Although instant runoff may be better than the plurality scheme we have today, it has a number of flaws which can encourage people to "strategize," i.e. vote differently from their actual preferences. (In the U.S. election scheme, voting for a candidate you think has a chance of winning instead of the candidate you like best is a well-known form of strategizing.) Also, instant runoff can eliminate "compromise candidates" who would beat every other candidate in a two-way election despite not having received very many first place votes.

See this page for more information on voting schemes (particularly Condorcet's method) than you probably ever wanted to know.

(If there are a thousand or so election theorists living in exile on an island, and they need to elect a leader, and there are several strong candidates, and each theorist has a preference ranking of the candidates, and each theorist also has a preference ranking of the various possible voting schemes, what's the best way to choose the leader?)

void main{}

Ack! You must be an old school coder! For your information, you cannot have main not returning an integer in standard C or C++. It is invalid code.

The following links should help refine your coding style. I only mention this because a) I am pedantic, and b) because I happen to believe new programmers reading this list shouldn't have to read crappy, non-compliant code (especially when the C standard has been around more than 10 years):

http://www.eskimo.com/~scs /readings/voidmain.960823.html

http://www.delorie.com/djgpp/v2faq /faq22_25.html

And one of my favorite alt.lang.learnc-c++ contributors, Jack Klein:
http://home.att.net/~jackklein /ctips01.html#int_main

Stuart
*slashdot pedant*

I am backing up my post with information I found online from an elctrical engineer. Turns out I was right though (not that I had any doubt :) I thank the person who emailed me and made me back my comment up.

• and I quote: Re:The internet is the next generation of cockroac (Score:1) by fossa (pat7@gmx.net) on 9 514709 EST (#390) (User #212602 Info) http://www.crosswinds.net/~sideways/
  
  Actually, electrons themselves don't travel very fast. It's what they pass between themselves that travels at the speed of light. Nothing with mass can reach the speed of light according to the General Theory of Relativity.
  
  Okay, so what is it that they pass between each other??? Einstein was not entirely right...
  
  Damn, I'm not an electrical engineer... I do remember reading that somewhere however. Hang on while I search for some info... Searched Google for "electricity." I am now reading http://www.amasci.com/ele-edu.html... Aha! Click on "Barriers to Understanding Electricity," and then "ELECTONS FLOW AT THE SPEED OF LIGHT," to come to http://www.eskimo.com/~billb/miscon/eleca.html#lig ht. Read this paragraph, from that website:
  
  
  • THE "ELECTRICITY" INSIDE OF WIRES MOVES AT THE SPEED OF LIGHT? Wrong. In metals, electric current is a flow of electrons. Many books claim that these electrons flow at the speed of light. This is incorrect. Electrons actually flow quite slowly, at speeds on the order of centimeters per minute. It's the energy in the circuit which flows fast, not the electrons. When the electrons at one point in the circuit are pumped, electrons in the entire loop of the circuit are forced to flow, and energy spreads almost instantly throughout the entire circuit. This happens even though the electrons move very slowly.
  
  
  Thank you for calling my semi-bluff and making me actually prove what I said. I actually enjoyed looking this up and learned a couple things :)

No one has mentioned the possibility that consumers may on average benefit by better data collection and price discrimination. Game theoretic analysis shows this can actually happen. Check out this page if you know some game theory:

http://www.eskimo.com/~weidai/monopoly-memory.txt

> I'm not sure how one could possibly
> tap information from the weak signals
> coming from the microprocessor, that
> sounds nearly impossible, ...

Actually, I have read somewhere that it is not only possible to do this, but it is possible to write a virus which, when run on the target machine, could use emanations from the cpu to transmit a message (say, a file on the hard drive) to a listening antenna by making the cpu perform certain instructions. The victim, of course, would have absolutely no way of knowing that any information had actually left the machine (i.e. a network monitor wouldn't even blink at this, because the data isn't going out over any conventional network connection). Incredibly interesting concept, I'd love to know if anyone has ever actually pulled this off. The closest I've seen in real life is one web site (I don't have the exact url but I'm pretty sure it was one of the links on this page) where this guy had written a program to demonstrate this, and had hooked up an antenna to a microphone, recorded the morse-code style sounds coming from the cpu, and put the sound files up for people to download and listen to. The transmission rate was obviously pretty crappy (we're talking a few bits per second at most), but given enough time and effort, it would be very interesting to see what might come out of that kind of research.

--

Long answer: no, unless there are tools for converting TeX/METAFONT fonts to Adobe Type 1 (not merely PostScript; Type 1 is a specially structured subset of PS) or TrueType. I haven't heard of any. It's more likely that there exist tools to make a set of bitmap (BDF/PCF) fonts from a METAFONT font, but that's not quite the same.

I think you're missing the point. For X screen fonts, you don't want Type 1 PostScript or TrueType fonts, you want well-crafted bitmaps that have been designed for screen display. I don't know about your machine, but on my system, Type 1 and TrueType fonts (other than Microsoft's Web fonts, which were specifically designed for screen display) look awful. Only the bitmap fonts (and Microsoft Web fonts) are readable and acceptable for everyday use. I leave PostScript fonts to gv.

The mf program translates METAFONT format (MF) source files into GF (font raster) and TFM (TeX Font Metrics) files; GF files must be processed by gftopk to produce PK (packed font raster) files. xmbdfed, however, can import PK or GF font files and produce BDF files.

For a neat example of PK fonts in use as screen fonts, check out TeXmacs, which gives you a really nice looking WYSIWYG display (better than anything else I've ever seen running under X). TeXmacs uses fairly large font sizes, however; I'm not sure if you can get legible PK fonts at smaller sizes (for, say, a terminal window).

(By the way, the Type 1 Utils are not GPLed, but are freely available for use or modification (provided you maintain the existing copyright notices), and can be found on Eddie Kohler's Web site. If you want Debian packages, an ancient (pre-Eddie) version is available from the main archives (t1utils), with the current version (t1utils-ek) available from this site (as source, unless you have a PowerPC machine).)

Microsoft has traditionally been one of the least anti-piracy companies.

Perhaps, but Bill Gates of Micro-Soft is the original anti-piracy zealot.

There are several issues here: peer review, architecture, algorithm and implementation.

Peer Review: At each step in the process (architecture, algorithm, and implementation), you should publish your ideas for criticism by experts. slashdot, Advogato, the Cypherpunks mailing list, sci.crypt, and the Crypto++ mailing list might (or might not) be good places to find such people.

Architecture: You should do a public key architecture where every participant has a public/private key pair and the public keys are used to sign and encrypt symmetric keys that are then used for encryption and authentication of messages. There are three feasible architectures for public key distribution. You have to choose one based upon your threat model. Almost all realistic threat models should be handled using the first option: "opportunistic public key distribution". If you don't have a threat model in mind at all then you might as well use the first option. If you do have a threat model which precludes using the first option then I'd like to hear about it -- you must be doing something very interesting indeed.

• Option one: "opportunistic public key distribution". The first time any pair of people talk to one another, they exchange public keys in an un-authenticated exchange. (Also: you could just do Diffie-Hellman key generation here.) After that, they remember each other's public keys for future use. This is susceptible to an active attack (a "Man In The Middle Attack"), during the first step (though not afterwards). However the cost to the attacker of executing a MITM attack is probably far more than the payoff. This depends on your threat model.
• Option two: make it the user's problem; Each user decides whether to use a given key to talk to another user or not. This is the user interface nightmare that single-handedly prevented strong crypto from becoming standard in e-mail, but for a few applications it might be the right thing.
• Option three: hardcoded; Generate key pairs yourself and include them in the application. For example if you are going to have a single central server in your system which you operate then you can generate a key pair for it, put the secret key on the server, and put a copy of the public key into each copy of the client (e.g. include the public key hardcoded into the client source code). This doesn't work as well if you want to distribute copies of your server for other people to operate, but refer to "Option one"...

Algorithm: You probably just want Triple-DES and RSA (after September of this year, when RSA becomes free of patents) or else Triple-DES and Diffie-Hellman. It should be easy to switch to a different symmetric cipher later after the new ones have been peer-reviewed and tried by fire, but for starters you want the old standbys that have already withstood the test of time. They will be fast enough for you at first and if you need more speed later you can switch.

Implementation: Your first choice should be to use an extant implementation. Don't try to implement it yourself no matter how simple it looks. Satan's Computer is deceptively subtle to people who are used to hacking Murphy's Computer.

I prefer Wei Dai's Crypto++ library, but that is because I'm doing complex non-standard crypto tricks. If you just want simple "encrypt/authenticate a stream" functionality then use a TLS implementation like OpenSSL. By the way, if anyone wants to make Python wrappers for Crypto++ (possibly with the aid of Swig) then I would love to hear about it!

Okay that's my advice. Specific pitfalls to avoid are: skipping peer-review, trying to design a generalized perfect public key architecture to handle all possible threat models, using a newfangled or non-standard algorithm ("In open source hackery, newfangled is good. In crypto, not."), and implementing it yourself instead of using a library.

Please direct all flames and accolades to: zooko@schowto.mad-scientist.com

There are several issues here: peer review, architecture, algorithm and implementation.

Peer Review: At each step in the process (architecture, algorithm, and implementation), you should publish your ideas for criticism by experts. slashdot, Advogato, the Cypherpunks mailing list, sci.crypt, and the Crypto++ mailing list might (or might not) be good places to find such people.

Architecture: You should do a public key architecture where every participant has a public/private key pair and the public keys are used to sign and encrypt symmetric keys that are then used for encryption and authentication of messages. There are three feasible architectures for public key distribution. You have to choose one based upon your threat model. Almost all realistic threat models should be handled using the first option: "opportunistic public key distribution". If you don't have a threat model in mind at all then you might as well use the first option. If you do have a threat model which precludes using the first option then I'd like to hear about it -- you must be doing something very interesting indeed.

• Option one: "opportunistic public key distribution". The first time any pair of people talk to one another, they exchange public keys in an un-authenticated exchange. (Also: you could just do Diffie-Hellman key generation here.) After that, they remember each other's public keys for future use. This is susceptible to an active attack (a "Man In The Middle Attack"), during the first step (though not afterwards). However the cost to the attacker of executing a MITM attack is probably far more than the payoff. This depends on your threat model.
• Option two: make it the user's problem; Each user decides whether to use a given key to talk to another user or not. This is the user interface nightmare that single-handedly prevented strong crypto from becoming standard in e-mail, but for a few applications it might be the right thing.
• Option three: hardcoded; Generate key pairs yourself and include them in the application. For example if you are going to have a single central server in your system which you operate then you can generate a key pair for it, put the secret key on the server, and put a copy of the public key into each copy of the client (e.g. include the public key hardcoded into the client source code). This doesn't work as well if you want to distribute copies of your server for other people to operate, but refer to "Option one"...

Algorithm: You probably just want Triple-DES and RSA (after September of this year, when RSA becomes free of patents) or else Triple-DES and Diffie-Hellman. It should be easy to switch to a different symmetric cipher later after the new ones have been peer-reviewed and tried by fire, but for starters you want the old standbys that have already withstood the test of time. They will be fast enough for you at first and if you need more speed later you can switch.

Implementation: Your first choice should be to use an extant implementation. Don't try to implement it yourself no matter how simple it looks. Satan's Computer is deceptively subtle to people who are used to hacking Murphy's Computer.

I prefer Wei Dai's Crypto++ library, but that is because I'm doing complex non-standard crypto tricks. If you just want simple "encrypt/authenticate a stream" functionality then use a TLS implementation like OpenSSL. By the way, if anyone wants to make Python wrappers for Crypto++ (possibly with the aid of Swig) then I would love to hear about it!

Okay that's my advice. Specific pitfalls to avoid are: skipping peer-review, trying to design a generalized perfect public key architecture to handle all possible threat models, using a newfangled or non-standard algorithm ("In open source hackery, newfangled is good. In crypto, not."), and implementing it yourself instead of using a library.

Please direct all flames and accolades to: zooko@schowto.mad-scientist.com

More on the traffic flow idea here.

With the help of his brother he has built a pretty cool system (beats either of my two) and has been using a device called an Adap2U Keyboard Emulator System which allows him to use Sip'n'Puff through a straw to "type" using Morse Code.

He also has a page on his site for disABILITY information and resources which seems to be an Ultimate collection of links.

And check out fun with Microwaves link that is on the Altoids page.

I think the neatest things from this were links off the Altoid tin page, including the match-head sized web server, and the Altoid tin radio.


--Phil (And who doesn't like Unwise Microwave Oven Experiments?)

It's based on the original Linux source release from Id, and is brought to you by the same wizard (wizards?) who produced the greatest entertainment app of all time on any PDA: PalmGB, the color Gameboy emulator for WinCE. More info available here, as long as you're willing to put up with the midis playing in the background. ;) (Actually, the one playing on the Doom screen is pretty cool, but I digress.)

Cheers,
ZicoKnows@hotmail.com

I think so. Have you heard of TEMPEST? Remote monitoring... Here is a great amount of info on it.

Can anyone elaborate if this encryption scheme could possibly prevent Tempest attacks? From what I can gather this is what they are trying to do. However, I am weary of Intel actually being concerned for user privacy (P3 Processor ID).

And why such weak cypher strength? This surely will be crackable, and i'm sure that companies aren't going to do a total recall on their monitors because a key was cracked. This seems fishy to me - if it's not creating a false sense of security it's gotta be something not to a person concerned about privacy. It has to please corporate giants in some way.

Yes. this has been widely demonstrated in academia and other experiments. Two good sources are The Complete, Unofficial TEMPEST Information Page by Joel McNamara, and Ross Anderson's Soft Tempest pages. The latter is particularly mindbending and everyone on /. should give it a read....
--

How does a Tesla Coil work

A short bio

The Tesla Coil webring

The Nikola Tesla Museum

Huge ftp archive with Tesla pcitures

Tesla's Autobiography

Very thorough plan on how to build your own Tesla Coil

This guy already made his own Tesla Coil

Enjoy,
Arno

-------------------------------------------------- -------------------------
"One World, one Web, one Program" - Microsoft promotional ad
"Ein Volk, ein Reich, ein Fuhrer" - Adolf Hitler

http://www.picturez.net/ - All the people all the pictures

I remember hearing about a contest to write the shortest self-duplicating C program (i.e. something that would spit out an exact copy of its own code). Someone submitted an empty file once, which is kind clever. But does anyone know of the next shortest?

Actually, the empty program is not a valid C program according to the ISO / ANSI definitions. For one thing, it doesn't define main() and so will produce a linker error.

The only other one I off hand know is the one mentioned in the comp.lang.c FAQ

I really doubt that the circuitry in his microwave poses any real threat to the rest of the technological world.

[humor]

Are you kidding me? Look at what horrors can be wrought with a mere household microwave .. click
here.

[/humor]

I believe that what you're talking about is Van Eck Phreaking (that is, interrupting the stray RF that the cathode ray tube in your monitor transmits, and recreating the image on another cathode.). This is quite old stuff, and is still in use today. The Tempest stuff that was recently released deals greatly with this. Basically, if you don't have a monitor shielded in metal, you're at risk, and that's that. For more information, you can check out this link for basic information, and Van Eck's original submission, or you can check out this one, and lastly, if you want some info on how to build a Van Eck Phreaking rig, then I would suggest the book at this site. Don't forget to type in Van Eck in the search box to find the box. Happy Van Eck'ing.

--Josh Adams

Uh, not precisely. The "legit" MST3K crew never did Trek-5. It was a fan production. You can find out all about it from this guy.

Schwab

Sorry to say it, but yeah, an LCD can be used to snoop on you too. So can your keyboard. So can your hard drive; processor; printer; scanner; etc. Pretty much any computer part that has electricity running through it is a security hazard when it comes to this kind of stuff.

Read some of the articles on the Complete TEMPEST Information Page if you want to really scare yourself. Convieniently, there are also links to companies there who produce TEMPEST-spec computer equipment and peripherals.

~GoRK

Already, a few people have posted expressing their misconceptions about what TEMPEST is. In a nutshell, it's the process by which radiation given off by electronic devices can be captured and analyzed in order to gather information about what that device is doing.

A good example of how it can be used was given during the October 1996 episode of Discovery Channel's "Cyberlife" show.

A couple other decent sites with more information about TEMPEST are:
The Complete, Unofficial TEMPEST Information Page
TEMPEST monitoring in the real world

Having read mosts of the posts on this article, I haven't been able to find any that directly address the issue of monitoring e-mail. Here's my address:

Echelon couldn't possibly be able to intercept and read everybody's e-mail. Keep in mind that this is a very large part of what Echelon is described as. Having been the Systems Administrator at an ISP, I can assure you that I was never approached by anyone who was probably a representative of the NSA and asked to transmit copies of all of our customer's e-mail over microwaves to their sattelite, or any other such thing. This sort of scenario seems ridiculous, and is probably not quite what most people are suggesting.

But, then again, how on earth would Echelon get copies of our customers' e-mail to each other? Really. Think about it. The mail travels from their computer to our mail server and then someone retrieves it from the mail server.

Assuming their aren't white TEMPEST vans outside all of our customers houses, how would they get this information?

"The phone company, obviously," you say. Nope. Previous to my experience as a Systems Administrator, I really wouldn't have any information that would leave me to believe that Ma Bell wasn't the NSA's puppet. However, when you really start to analyze this possibility, you again see that this just couldn't be the case, especially given the current evidence that exists. (Note that all I'm saying is that the phone company isn't used to intercept your e-mail, and will refrain from addressing voice phone calls as others have done this previously).

The first thing to look to is the existance of CLECs (Competitive Local Exchange Carriers). These are entirely private companies that decide they want to run their own phone network, either alongside Bell's or by building their own and interconnecting (yes, I know some CLECs just resell Bell's services). Here in Kansas City, these companies are Birch Telecom and MCI Worldcom (formerly Brookes Fiber Communications). In addition, the medium-sized ISP I ran also considered becoming a CLEC. This involves little more than paying twenty-give grand to a few lawyers.

Now, in the same way that I ran our e-mail servers and was confident that we weren't working with Echelon to give them all of our customer's e-mail (sent to each other over our mail servers), I am also confident that if I and my engineers ran copper between multiple suburban areas of the city, install SS7 switches, etc., that I would fail to setup the Echelon port (or somesuch other method of giving info to Echelon) on any of these switches. Any phone call that stayed within our phone network (our phone customer calling another one of our phone customers) would be known secure. Certainly, the FBI has the ability to tap individual phone lines and we're aware of that. You'd be a fool not to recognize the difference between access to a single phone line and access to every trunk in your network. It would be painfully obvious to myself and everyone involved in the construction of the phone network of an international ring of spies was going to be looking at the data.

So, I contend that because most any telecommunications company can start their own phone network in competition with Ma Bell and since all of these companies would become aware of the Echelon network if they were apart of it, that when one of our customers sent e-mail to our mail server and another one of our customers retrieved that e-mail, no one was intercepting that e-mail.

Futhermore, there would be way too many switch managers and other telco engineers that would have to be aware of such a massive network of spying for it to exist. It's absurd to think that one of these persons wouldn't have come forward with evidence showing the existence of Echelon before now.

"But what about e-mail sent all over the world that goes through large carriers?" you ask. It's true that I only addressed e-mail sent locally to a medium-sized ISP in Kansas City, but I think it's easy to see how the scenario scales to any large service provider. It is obvious that if Echelon wanted to read everybody's e-mail, they would be reading everybody's e-mail, not just some of it. When it comes down to it, Echelon would have to be working with a bunch of administrators working for AOL, CompuServe, Prodigy, etc., just like they would have to be working with me in a medium-sized ISP to get everyone's e-mail. Think about all the e-mail that only stays on AOL's network, or just Netcom's. Wouldn't criminals be flocking to signup for service from my ISP if they knew that none of it would intercepted by Echelon since it wasn't traveling over large carriers' networks?

Certainly, I haven't addressed every possibility or methodology of spying on e-mail, but I think I at least put some doubt in the minds of those assuming that it wouldn't be that hard for NSA to intercept every piece of data in the world. I think it all comes down to remembering that the Internet is just a bunch of companies, large and small, working together, and that there would have to be a lot of these companies in on the masterplan for Echelon to be what everyone thinks it is. Now, maybe just UUnet, Sprint, MCI, Savvis, and Qwest are all in on covertly redirecting packets to Echelon, and no one else. I have nothing to offer to show why this wouldn't ve happening. While that might be a large percentage of Internet traffic, I still think Echelon would be largely pointless if it could be averted by using a small service provider (voice, data, or otherwise).

So, if you're still convinced that the Echelon crew is reading your e-mail, switch your phone lines to the smallest CLEC in your area, signup for service from a smalltown ISP, and have all the people you communicate with do the same.

What sucks is that I might be entirely wrong; that might be able to detect everything traveling on copper wire from hundreds of miles above the earth.

Who knows? Not me. So reply!

It's scary stuff the first time you try it!

Well, there's a WinCE version of Doom available at http://www.eskimo.com/~hayes/doomce.html which can even be played in 4-color grayscale. You can even tap the screen in order to fire or open doors! Cool stuff IMO.

The cloning here regenerated a perfect being from the DNA found in the alien space craft wreckage...

We discuss the messy mathematical ins and outs of various single-winner and multi-winner systems, in an effort to fully understand the spectrum of systems available and their relative merits. Not for the faint of heart, but if you are interested in that sort of thing...

Bouncing a laser off of a window, and measuring the reflection allows very impressive eavesdropping.

Doesn't work so good if the building is tall (sway) or if it is a windy day.

I've never seen it done, but I'm quite convinced that the patternt on your screen and the state of your CPU can be monitored in real time, from a quarter mile away

The exploit is called TEMPEST.