October 1992 - cypherpunks-legacy

TEMPEST, Eavesdropping
by Eric Hughes 22 Oct '92

22 Oct '92

>Their chief concern doesn't seem to be folks like us, but rather >concerns about vans parking outside high tech and defense contractors >and slurping up what they can [...] When banks start signing with private keys, then we get an even more interesting monitoring problem. >And someone asked about building Faraday cages. Don't even try! Sometimes it is cheaper to build a whole building to be tempest-spec than to buy all tempest-spec electronics. What I have heard about such stuff is solid copper walls and no windows. No exacly your classical Faraday cage; more like your classical Gaussian surface. :-> TEMPEST is an acronym. I don't remember for what. Eric

2 1

fast elliptical encryption
by Karl L. Barrus 22 Oct '92

22 Oct '92

In the winter NeXTWorld magazine, the article ("Tales from the Crypt") on page 94 mentions various topics of interest: public key encryption, export restrictions, the role of the NSA, etc. (It's just a one page article and doesn't go into much depth). Anyway, NeXTStep 3.0 is bundled with fast elliptical encryption for NeXTMail. As a result, 3.0 is export restricted. Does anybody know about the "fast elliptical encryption" public-key system? How different is it from good ol' RSA? Is it related to the elliptic-curve factoring algorithm (am I remembering this correctly - I don't know how elliptic curve factoring works, but I remember seeing a reference to it somewhere)? Just curious... /-----------------------------------\ | Karl L. Barrus | | barrus(a)tree.egr.uh.edu (NeXTMail) | | elee9sf(a)menudo.uh.edu | \-----------------------------------/

1 0

the acronym TEMPEST
by Karl L. Barrus 22 Oct '92

22 Oct '92

> TEMPEST is an acronym. I don't remember for what. > Eric TEMPEST = Transient ElectronMagnetic Pulse Emission STandard. Pretty cool sounding acronym :-) /-----------------------------------\ | Karl L. Barrus | | barrus(a)tree.egr.uh.edu (NeXTMail) | | elee9sf(a)menudo.uh.edu | \-----------------------------------/

1 0

another service
by Eric Hollander 22 Oct '92

22 Oct '92

I have thought of another service, like the depository, which might be useful to the user community: a time stamping notary service. This would have less security problems than the depository and would also be neccessary if RSA'ed documents are to replace contracts and other paper documents used in business. It would be easy to implement. A machine is set up with a hardware random number generator. This is used to generate a time-stamp key pair, perhaps every day or every hour. A user sends a document to this computer, which then signs it with the private half of the time-stamp key and then remails it to the user. Note that the document sent by the user is probably already encrypted and/or signed; sending it to the time-stamper does not compromise it in any way. The time stamper also keeps publishing the public half of its keys, to a wide enough audience that it would be impossible for any one person (or Agency) to modify all of them. Users could keep their own archives of them. After the time period has elapsed, the time-stamper should erase the private key corresponding to the time period. This is the only time that trust is involved and that the system might be compromised. If a private key were leaked, a time-stamp could be forged. This would allow users to keep dated, notarized documents in their files, so they could later prove that they had certain information at a certain time. Ideas? Thoughts? e

4 3

Re: Keystone
by fnordbox!loydb＠cs.utexas.edu 22 Oct '92

22 Oct '92

:I would be hesitant to implement a system that _only_ required a user :to generate a key pair. This, for the users, is too much provided :privacy. It will not teach the users how privacy really works, nor :will it give them any good idea how their privacy is being maintained. I take the opposite view -- I dare *not* supply such a system. Any user that is interested enough in 100% privacy will be encouraged -- both from the email prompt and through the message bases/file areas -- to d/l a copy of PGP. I'll probably write a tutorial on using it as well. But many users do not have the interest/time/ability to set up PGP on their home system. For them, I want to provide the best possible privacy given the ease with which anyone who can find their local LMOS can tap (voice or data) a line... :Defended privacy does not need to be difficult. I would spend effort, :instead of modifying BBS software, to make it easier for users to :handle encrypted email with their own terminal programs. I don't have my user's terminal program -- I *do* have the bbs software. :Again, trusted systems can turn into provided privacy. If there is a :distributed solution you can think up, use it. I don't know any way to maintain an up-to-date, central keyring without someone being in charge of regular updates. I'd make it available via Fido, FTP, BMS and regular d/l. Loyd *************************************************************************** * loydb(a)fnordbox.UUCP Once you pull the pin, * Loyd Blankenship * * GEnie: SJGAMES Mr. Grenade is no longer * PO Box 18957 * * Compu$erve: [73407,515] your friend! * Austin, TX 78760 * * cs.utexas.edu!dogface!fnordbox!loydb * 512/447-7866 * ***************************************************************************

2 1

Re: Home security...
by George A. Gleason 21 Oct '92

21 Oct '92

Tempest: there are companies which make cages for Macs and PCs, I don't have addresses but they can probably be found with some searching of ads. The main application it would seem, is not the individual home user (unless s/he's a notorious digital dissident) but rather the encrypted BBS, particularly one which decrypts and re-encrypts or retransmits messages. Consider the labor cost of monitoring a computer, and you can see it would be reserved for the ones that are "significant." Keeping your computer off the phones and AC while doing crypto processing, can be fairly easy. Unplug the darn modem from the phone socket. (Gee that was simple, wasn't it?) Use a laptop and run it entirely on the batteries while doing crypto processing. You can go buy an old laptop pretty cheaply these days... Or get an uninterruptable power supply for your main computer; cost will vary from $600 to $1500 depending on how much time you need to be running on the large batteries which are converted into AC to run the computer. -gg

1 0

Re: Mac Version PGP
by Fen Labalme 21 Oct '92

21 Oct '92

Subject: RE>Mac Version PGP > No one has been able to get me the source-code to PGP, and when > I ftp'd it from wherever, it came ZIP'd in a format that my > unzipper doesn't recognize. There are several mac un-zip programs available for anonymous ftp from sumex.stanford.edu (cd info-mac/util; mget unzip-11.hqx mac-zip-10.hqx). > But, it should be fairly straight forward to throw it into > THINK C. A person here has put a short amount of effort into "macifying" PGP. He's gotten it to compile in Think and MPW, but it won't run yet. According to him, the technical reason is that some sort of "goofy bus-error bullshit" is occuring, and so, if you figure it out, please let this list know (as well as possible posting it to alt.crypt.sources, if such exists). We will do the same. Good luck! Fen

1 0

Depository Proposal (revised)
by tom.jennings＠f111.n125.z1.FIDONET.ORG 21 Oct '92

21 Oct '92

Just thought I'd forward on something that's cooking in Fidoland. This guy has code running already. I haven't even looked at it yet myself If it's a crock, please be kind and forward suggestions to the author... tomj(a)fidosw.fidonet.org -------------------- begin forwarded message (Please note that examples still have not been included with this text) Public Keys Depository Proposal By Marcos R. Della (1:125/180 or marcos(a)zippy.sonoma.edu) Def: De.pos.i.to.ry (di-POZ-i-tohr-ee) n. a storehouse, a place for safekeeping of things -+---------------------------------------------------------------------+- With the latest release of the PGP20 program, public key availability has fallen into the hands of the individual. This provides a relative degree of security over messages that are sent from user to user in various formats (text, binary, etc) over different transportation mechanisms. I will not go into the system that allows public keys to work nor public key history. Instead I'll point you to the rather complete documentation that comes with the PGP program. Unfortunately, there is a major drawback to this system (also pointed out in the PGP documentation). Public key distribution has few security elements involved to insure the validity of a particular key. PGP attempts to address this problem by providing a "signature" system to each public key to give reasonable validity to its origin. Unfortunately, this depends upon trust of the individual who signs the key to begin with. Who polices the policemen? Unfortunatly, the issue of key validity is yet another topic that cannot be easily addressed since authenticity lies in one persons trust of another. Yet there still needs to be a system in which keys can be distributed or held for later use. This system should be multiply redundant and have some degree of immediate access in order to make the information stored useful. One such system would be a depository, a place to store public keys for later retrieval. This proposal will attempt to describe a system whereby you can get around the validation of public keys problem without requiring someone to police the Depository itself! -------- Problems Involved: - How do you know the key depositor isn't faking his/her keys? - How do you verify (at the depository) that a key being deposited is from the key originator or is even valid? - What is to prevent the depository from faking keys that is "signs"? - How can this system be resonably redundant and easy to access? First off, the depository is NOT a validation center. The system never will verify the users as existing or if they are even honest users. The depository key signature only verifies that the key has been deposited and is available for access at any time. Again, the depository DOES NOT verify users, only the fact that a deposit has been made. (A better form of deposit slip) If a user wants to deposit his/her key, what is to prevent the sysop from intercepting this public key, making a substitution replacement, and then forwarding the new public key? Unfortunately, there are sysops out there that have already done this in some respects. Thereby the system has to place the responsibility upon the user for key deposit verification. To prevent the sysop from changing the deposit, the user should use the Depository Public Key (hereafter referred to as DepoKey) to send his/her key for deposit. Again, what prevents the "bad" sysop from just throwing this message away (obviously he can't read it) and sending a fake message (also encrypted with the DepoKey)? Although this eventually thwarts the entire system (the sysop cannot fake the users public key unless the user uploads it in plain text to the sysop), it still causes problems. To prevent this, the user should include some sort of text in the deposit that the depository will mail back to the user, ENCRYPTED along with the user's public key. When the user receives a valid message back that contains his original text, things are fine. If the user does not receive a response in a few days or gets an incorrect return message, then the user should send a cancel message to the depository and re-deposit his or her key. The complete the handshake, the user should send an authentication back to the depository stating that the key was recieved correctly (instructions on how to do this should be returned with the key). If a return reciept isn't back in a resonable period of time, the depository will remove the key from its deposit keyring. NOTE: This will never invalidate a public key, it will only prevent it from being distributed via the depository system. What is to prevent the depository from faking keys that it "signs"? Well, in order to be effective with fake keys, you need to be in the transport path of the messages that you are planning on "stealing". Since the depository is not a major hub or node (except possibly to a few people) this negates any effect of faking keys. Also, once a user has received verification that the depository has his public key, he can then also post it anywhere. The depository will return his public key with a depository signature on it. This allows the user to upload a verified key to anywhere. When keys are distributed with a depository signature on them, then they are on file with the depository in case someone wants to withdraw them later. As long as the public key for the depository is made worldwide public, this system will work. As for creating a multiply redundant system, there should be several sites that are listed as depositories. These systems will on a weekly basis, exchange acknowledged keys (ie, keys that have undergone the handshaking process) with one another. A user can then request a key from ANY of the depository sites and get the same information. For those that want certified keys (other than from the users) such as a BBS system needing the public key of another, there will be a withdrawal mechanism built into the depository to pull single or multiple keys. Also, the complete public keyring may optionally be pulled (FREQing). ----------- The actual mechanism: Below is the Depository Public Key. Any public key that has been signed with this depository key will be assumed to have undergone the handshake process to verify that the originator of the key pair has in fact issued a valid key. This signature only verifies the deposit (a reciept). *** THIS KEY DOES NOT VERIFY THE IDENTITY OF THE USER!!! ONLY THAT *** *** THE USER WAS IN FACT THE ORIGINATOR OF THE PUBLIC KEY *** *** AND HAS DEPOSITED IT INTO THE PUBLIC KEY DEPOSITORY!!! *** For user identification, there should be a second or third signature from a BBS or known friend. This will give the key a verification level. If the user wishes to deposit a key with another person's signature, there will be no problem since the handshake method still insures the source and destination of the message. (Note: This is preferred since depository keys will then be distributed with dual signatures) The depository allow four functions: Deposit, Withdrawal, Cancel, and Acknowledgement of Deposit. To use these function... DEPOSIT: Address a message to "Depository" at one of the listed depositories at the end of this document. The subject will be "Deposit" and the text body will contain your Public Key (in Ascii format) and some small body of text that will be reflected back to you. NOTE: The small body of text and your public key should be encoded WITH the Depository Key. WITHDRAWAL: Address a message to "Depository". The subject will be "Withdrawal" and the text body will contain what you are looking for on each line just as if you were polling your own PGP program. You will be sent back a list of keys with the depository signature verifying the message. Note that a * for the body text will give a LONG list back to you... For fidonet, this MIGHT require a poll to recieve your return list. See Appendix A CANCEL: Address a message to "Depository". The subject will be "Cancel" and the text body will contain the text "CANCEL PUBLIC KEY" with your signature on the message. The cancel will not take place without your signature! You will receive a cleartext response to this. All this does is to remove your public key from the depository keyring. If this comes with a "kill" signature for the key, then it will be moved from the deposit keyring to the invalid/killed keyring. ACKNOWLEDGE: Address a message to "Depository". The subject will be "Acknowledge" and the text body will contain the text "ACKNOWLEDGE" with your signature on the message. Without the signature, your public key will continue the daily countdown to keyring removal. A cleartext message will be returned upon any receipt of this message. Anything that doesn't fit one of these will be rejected and a return message will be bounced back. ------------------------------------------------------------------------- *** WARNING *** This proposal ONLY provides a method of storing keys for public distribution and withdrawl. This in NOW WAY verifies or even attempts to verify the authenticity of the issuer of the key. *** WARNING *** ----------------------------[ CUT HERE ]--------------------------------- Depository #1 (1:125/180) [KeyID:77854F] "Depository #1 [Public Keys]" -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.0 mQCNAirV7H4AAAEEAMgk39sU7OvZGr/Ig/g0Kaw2cY3FpQOFvRXp9OXmlAch3FBA Ow2/oD8dbKdiQamuIMFw6qpg0Bw2k8mhKXCfFhLIZjH3FJeqKQrV7UvELBJdCT4q b7wRg8jeLos2rR9a4jt+s0srNS/LznfLvquESEhMuzcxSTC27OyxS4Fbd4VPAAUT tBtEZXBvc2l0b3J5ICMxIFtQdWJsaWMgS2V5c10= =rC+3 -----END PGP PUBLIC KEY BLOCK----- --- GEcho 1.00/beta * Origin: The Babble Underground (Home of the Jabber QWK Reader) (1:125/180) SEEN-BY: 125/111 125 180 185 374/14 ;; -------------------- End forwarded message -- Tom Jennings / World Power Systems email: tomj(a)fidosw.fidonet.org FidoNet: 1:125/111, BBS +1-415-863-2739 postal: Box 77731, San Francisco CA 94107 USA -- tom jennings - via FidoNet node 1:125/555 UUCP: ...!uunet!hoptoad!kumr!fidogate!111!tom.jennings INTERNET: tom.jennings(a)f111.n125.z1.FIDONET.ORG

1 0

TEMPEST, Eavesdropping, and PDAs
by tcmay＠netcom.com 21 Oct '92

21 Oct '92

Eric Hughes posted a nice summary of the TEMPEST situation (interception of RF for eavesdropping on computers). I'll just add a few comments. > About Tempest. > > The ability to monitor is real; it's more powerful than you would first > imagine. And the NSA has reportedly restricted several papers on this, though they can't do much about the stuff coming from abroad. Their chief concern doesn't seem to be folks like us, but rather concerns about vans parking outside high tech and defense contractors and slurping up what they can from non-TEMPEST (all caps, for some reason) terminals and computers. And someone asked about building Faraday cages. Don't even try! In 1972-3 I worked inside a Faraday cage in the lab of Dr. Paul Hansma (who's now famous for his atomic force microscope work--small world), and it was real tough to shield against high frequencies (above 500 MHz). Modern computers run at 50MHz and faster and the signal edges are of course much faster. RF emissions are a major hassle, and even 30 dB of shielding will still mean enough emissions for a dedicated listener to pick up. > Hal mentions using flat panel displays to combat emissions. This > works, as evidenced by the continued existence of Grid Computer. > Remember Grid, who came out with these way-expensive gas plasma > laptops around 1985/6? The reason they sold so many of those and are > still around was that a large number of them were Tempest certified. > (Even larger revenues!) I understand that the Tempest spec Grids had > a thin layer of gold foil in front of the screen, even so. Yes, gold > thin enough to see through. BTW, I have one of the original magnesium-cased, bubble-memoried GRiD Compasses. Tres elegant (and even "way cool"....Not! It heats up something fierce, with the magnesium case acting as a heat sink). (I got this at Weird Stuff Warehouse, complete with a magnesium-cased disk drive, cables, etc., for $250. Fully functional, but not a lot of software written for "GRiD-OS." Maybe I'll bring it to the next Cypherpunks meeting.) > monitoring easier. It's safe to presume that there is some amazing > stuff going on. Read The Puzzle Palace for more hints. (Like the > valley in WV which is one big antenna.) Ditto on this book recommendation: all would-be cypherpunks should read James Bamford's "The Puzzle Palace." Though published in 1982, it revealed a lot about such "No Such Agency," so much so that the director of NSA, upon encountering Bamford at a dinner, refused to shake his hand and said "Sir, I consider you an unindicted felon!" > Emissions monitoring is also all economics. The price to monitor > increases with each more sophisticated attack. CRT's are easy, CPU's > are hard. I would like to see public research in this area, just like > there is public research in cryptography. Until the public has a > better idea of what various attacks cost, there can't be rational > decisions about emissions security. I think the longterm solution to this problem is the same as that for the key problem: small, highly portable, self-contained computers for doing the most sensitive work and for providing passwords to remote systems. Smartcards are one approach, though they obviously are highly constrained in what they can do other than act as ATM or VISA cards. (Laptops are one idea. Following Eric's suggestion that we look into TEMPEST issues, perhaps we could "rate" different laptops and PCs for emissions. Just a thought.) Apple's "Newton" PDA ("Personal Digital Assistant"), General Magic's whatever (talk to Fen L., who works there, but who won't say much), Eo's Hobbit-based PDA, and other systems (Sharp, Casio, etc.), offer a better platform, at least for the long term. With 100 MIPS performance, LCD screens, and no dangling keyboards and cables, these gizmos should be favorably positioned for security-conscious applications. RF emissions should be low to begin with (and can be characterized, of course); additional shielding should be easier to achieve than with full-sized units. PDAs also are small enough that people will carry them everywhere, thus both enhancing security against tampering, and also making them workhorses for security applications. With a good interface to desktop machines, the critical security functions can be done inside the PDA (e.g., accessing a terminal or remote system using zero knowledge protocols, where the PDA answers a challenge question without revealing the actual password or whatever secret key). The announced PDAs also have slots for "PCMCIA" cards, small credit-card-sized cards that can add functionality and memory. The lack of a keyboard in the smallest of these units will be a limit (though external keyboards are options...and with some care, these keyboards can even be made TEMPEST class, though leakage will still persist. A battery-operated keyboard with fiber-optic link to the PDA might be one approach.). The issue of hooking these PDAs to desktop machines and networks is an interestesting one. Wirless links would seem to be risky, except that if all critical computations are done _inside_ the PDA then what gets transmitted is not really "fragile" (in the eavesdropping sense). I suspect that someone will offer a small fiber optic link (like the one I have going between my CD player and my DAT machine). And it will be a couple of years before these become common. But it's about 2-3 years from now that our mission gets really interesting, anyway. Digital money, anonymous voting and conferences (imagine using wireless, encrypted links in meetings to negotiate without opponents knowing..just one of several small business product niches), and all kind of other crypto anarchy ideas. PGP 3.0 for PDAs! -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay(a)netcom.com | anonymous networks, digital pseudonyms, zero 408-688-5409 | knowledge, reputations, information markets, W.A.S.T.E.: Aptos, CA | black markets, collapse of governments. Higher Power: 2^756839 | PGP 2.0 and MailSafe keys by arrangement.

1 0

Fakemail
by shawnb 21 Oct '92

21 Oct '92

Cyperpunks.... Man you guys generate lots of stuff... Anyhow I noticed that some of you are using fakemail... Are you using a shell script for this? The only fakemail scripts I've seen have not really worked. Could someone forward a copy to me? Thanks. Shawn

1 0