- cypherpunks-legacy@lists.ogf.org

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

21 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 20 Oct '92

20 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 20 Oct '92

20 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 20 Oct '92

20 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

Tempest.
by nobody＠soda.berkeley.edu 20 Oct '92

20 Oct '92

Re TEMPEST technology: (Note that TEMPEST is the technology for _protection_ against electronic eavesdropping on your computer emissions. There is presumably a code word for performing such snooping, but it must be secret.) I've read that the worst emitter is your CRT screen. In fact, they say that you can sometimes put a TV-type monitor next to your computer monitor and get a faint, ghosty image of your CRT screen on the second monitor. If you get this much without any amplification, it's under- standable that high-quality equipment can pick up an image from a greater distance. The best way to avoid this, IMO, is to use a laptop. The LCD display of a laptop does not use the large electromagnetic fields that a CRT display does. Laptops also use lower power levels in general so they should emit less. I don't really know whether the "raw" CPU activity of your computer could be picked up and interpreted at a distance. With as many different signals as there are on the address and data busses, along with all the other wires you have, I can't really see how anything meaningful could be picked up with remote monitoring. It would seem that they'd be totally jumbled. So, for BBS use, where the system is operating automatically, I'd say that it would be OK as long as you don't display any cleartext or key/password information on the screen. You could just turn the monitor off when it's operating. For home use, a laptop has the advantage that it can have greater physical security (because it's smaller and more portable), you can carry your decryption keys with you, you can download to it at work or school and decrypt without trusting the multi-user systems they have there, and it should be relatively immune to electro- magnetic snooping. Hal 74076.1041(a)compuserve.com

3 2

Mac Version PGP
by No_Such_Address＠atdt.org 20 Oct '92

20 Oct '92

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. (Maybe I've been ZIP superceded). Anyway, it hasn't been very convenient to get a hold of it for me. But, it should be fairly straight forward to throw it into THINK C. THINK C supports a console with command-line. You would not necessarily have to Mac-ify it (although it would certainly make it more aesthetically pleasing); so porting to the Mac is not a dead-end port. THINK C should be able to compile and execute PGP as-is. As soon as I can get the source, I'll put my words into action. (re: Macifying it: It's simple enough to slap together an interface on top of something like PGP; that's one, maybe two dialog boxes with a bunch of radio buttons and check boxes and a routine to parse it all and hand the info over in a way PGP expects. BFD. So, criticisms I've heard about it being a hassle and a pointless exercise to port PGP to the Mac are without merit, as far as I'm concerned.)

1 0

Unsubscribe me from mailing list
by G5100035＠NICKEL.LAURENTIAN.CA 20 Oct '92

20 Oct '92

I can no longer handle the mail volume from your mailing list. Please unsubscribe me from the list. Thanks.

1 0

More private PGP...?
by nobody＠soda.berkeley.edu 20 Oct '92

20 Oct '92

One of the things I've noticed about PGP is that it makes it pretty obvious that you're sending an encrypted message. The big -----BEGIN PGP MESSAGE----- at the start pretty much gives that away. In most cases, this is fine, but sometimes it may not be desirable to make it this obvious. Sending encrypted messages may call unwelcome attention to yourself. Also, some people are experimenting with packet radio on the amateur bands, and it's not legal to send encrypted messages there. What I think would be nice would be an "innocent" mode for PGP in which it created files which looked like something else. For example, what if your encrypted output file looked like: begin 666 testpat.gif MI\44:#G4D>QQXR!-M,Z20O1K&5D<U"C;V<J#-I@:ANT,A+>0, 5-4F.X<%MT M2:V94,K;XE@B?]%IHF+_<VT=U! 3Q;;M-K<QT.N"?%IJTNU!%(KF7K]2^B6+ M;&TTGTULW(4%:F@\&MB^ ^Y5Y\#2A6^*86F-Y"^%J$>WGI%(]#=F]/[LV+&! M,NH0(!3B35CW#!-Z7"B_L'=-C 8DLB-(J R"3?EE9<.>QE4Y?T$66IA7B@W? end This will be recognizable, if you've seen many, as a uuencoded file, a common encoding for non-ascii files. The header line suggests that it is a graphics file. Tons of these types of files are sent across email networks every day. Sending your encrypted messages in this form would give you a lower profile. Still, if someone goes to the effort to uudecode your message, and examines the resulting file, it will be obvious that it's not a GIF file because it lacks the proper headers. Instead, with the current PGP implementation it will be obvious that it is in fact a PGP file, because the header format matches the PGP spec. Again, I think it would be better if PGP in this mode were able to produce a file without headers which will give away what it is. Even better would be the ability to mimic headers of some other types of files, such as the .ZIP, .ZOO, or Unix "compress" format which are often used in binary files people mail around. Another thing that I think is kind of bad about PGP in the context of avoiding traffic analysis is that it puts the key ID of the destination person in the header. There was some discussion during development of a mode in which no key ID information would be in the header; the only way you'd have of knowing if the message was for you was to try decrypting it. (There is a checksum which is used internally to tell if the decryption was done with the right key.) This way you could broadcast messages to some group, and no one could know which person in the group you were sending to. These "anonymous destination" messages could be encoded with a key ID of zeros, and the PGP software could easily be modified to let the user try a decryption on such a message, reporting success or failure. How useful do these kinds of features seem to people? Would they really be helpful or is this just paranoia? Hal 74076.1041(a)compuserve.com

2 1