October 1992 - cypherpunks-legacy

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

Re: one time pads.
by George A. Gleason 20 Oct '92

20 Oct '92

Re use fo CD ROMs for OTPs. That would seem to be a variation on the old theme of the book cipher, which is *not* random and therefore *not* secure. Also, agreeing on key procedures over the *phone* in *clear voice* is kind of like sex without a condom. Not secure. Not safe. Potentially deadly. While we're on the subject of link encryption, the same response pertains to the suggestion made by someone from SJG here (whose name I ought to know but my memory for names has more holes than Bush's economic plan) about key distribution and transmission of cleartext over phone lines. It *doesn't matter* if it's encrypted at the BBS server, if it goes in clear over the phone. Keyword in context recognition is no problem when dealing with ASCII. Various agencies (you know who) have raised this to a fine art. The telephone line is precisely the link in the chain which is weakest and needs most to be protected. If the nasty-wasties break down your door and go for your hard drive, it's already too late. Like worrying about a condom after the fact. Now as a matter of record, it's been demonstrated that a processor emits electromagnetic radiation back over the phone lines as well as electrical power lines, which can be picked up at a distance. So consider for a moment that there is a BBS serving dissidents, who Big Brother wants to monitor. Seeing all the encrypted traffic, they install a device on the phone line and the AC to pick up what the mircoprocessor is doing. And they see it doing crypto, and they see the cleartext which is recovered, and get the keys, and the whole damn thing may as well be transparent. So for BBSs and such, I would argue that it's necessary to have electromechanical relays to isolate the computer from the phone lines when encrypting or decrypting; ideally isolate it from the AC as well (using an uninterruptable power supply, which will run the computer on batteries for some period of time, say 45 minutes). So you have a great big red toggle switch next to the computer, and for some period during the day when doing all the crypto processing, throw the switch to the Safe position to get it off the phones and AC lines. This might make BBS use a little less convenient (in that email becomes available the day after it was posted), but at least it's not literally leaking everyone's secrets into the airwaves. This general area is part of a larger topic called TEMPEST. Anyone else interested in pursuing this angle...? -gg

2 1

Re: More private PGP...?
by George A. Gleason 20 Oct '92

20 Oct '92

Hal, I think those would be vry useful. Now of course, we don't want to advocate that radio users in the United States do anything like sending ciphertext over the airwaves, but we might want to develop something that we can ship to the Gusanos who want to take Cuba back for the Mafia, or maybe in a better vein, something that the Tien-an-men kids can use when overthrowing the Commies in China. Good ideas about message headers. Since the source code for PGP is widely available, it would seem a straightforward matter to alter the program to include the new features. What I'd really like also is a Mac version.... -gg

1 0

one time pads.
by hkhenson＠cup.portal.com 20 Oct '92

20 Oct '92

I can suggest a way to "distribute" a one time pad, even though the people never meet. Just agree over the phone on which CD ROM to use, and some forumula for an offset into the CD ROM. You might want to throw away some of the data to make the bit stream less regular, but with 600 meg, who cares? Keith Henson

3 3

Re: one time pads
by George A. Gleason 18 Oct '92

18 Oct '92

Sigh... well, I guess I can see if the people I know who are interested, would do it as a freebie... Funny thing is, when I first looked into crypto for dissident purposes, back in 1981 or so, I was interested in a PKS implementation, but someone else in my circle persuaded me that OTPs would be preferable in some cases. Now here we are with a PKS and I'm still making noises about OTPs. Guess the debate is closed for the moment... congratulations, y'all, for good arguements in a good tone. Now the well is about to close for the night, so I gotta scoot. Be back soon... -gg

1 0

Intro & Keystone
by fnordbox!loydb＠cs.utexas.edu 17 Oct '92

17 Oct '92

First, as a newcomer, and introduction. My name is Loyd Blankenship. I am the Product Development Manager at Steve Jackson Games, and was the employee raided by the Secret Service that set off the formation of the EFF, our lawsuit against them, and much angst within the government. I also use the nome de' plume "The Mentor" when traversing the computer underground. On to stuff relevant to the list: A group of us here in Austin have spent a great deal of time discussing the advantages of RSA-encrypted e-mail. I'm putting a BBS back up later in the year, and would like to offer secure communications to my users. Since the threat of seizure is very real (the feds still have over $10,000 (1989 street price) of computer equipment of mine since I'm "still under investigation"), this needs to be implemented before the message is ever written to hard disk. To implement this, I'm currently trying to get PGP up on my Amiga, then write the necessary C & AREXX functions to link it in with my BBS's (DLG Pro) email function. The outgrowth of this was the Keystone project. We're going to attempt to get everyone in Austin cyberspace public-key capable, and get a master keyring that will be regularly distributed via a trusted system to other nodes in town. Ideally, you would be able to send RSA-encrypted email from any bbs on any of the local nets to any other bbs -- even if all you know is the destination address. We're going to do this by attempting to make the bbs PGP-friendly. All the user has to do is generate a key pair. The two potential weak links in this chain are line security and key validation. The first is almost insurmountable -- unless the user takes the time to d/l a complete copy of PGP and the Austin Keystone Keyring and encrypt the mail on their home system. But if not, then they have to live with the chance that someone is data-tapping. The second will rely on face-to-face identification -- this is why we're making this a local effort. It will probably be Christmas (when I have a 3-week vacation) before serious strides are made in this, but I'm interested in any comments people may have. Loyd p.s. What is this "game" you are talking about? *************************************************************************** * 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: one time pads
by George A. Gleason 17 Oct '92

17 Oct '92

Re. your point about security and burglary. An intruder could copy a one-time pad, but of course an intruder can also copy the private key to an RSA system as well. I'll admit that physical key control is easier with public key systems: one just keeps one's key disc in one's personal possession at all times, and keeps a couple of backup copies in the hands of close trusted friends or family who understand and will take equal precautions. One could also design physical storage media which are intrusion resistant in the sense of self-destructing if tampered with or fed the wrong password; these would work as well for OTP keys as for RSA keys. In some conceivable applications, physical security can be insured as a matter of the vital interests of the participants. Again, I'm by no means trying to suggest that OTPs be considered for particularly wide application. Rather, that OTPs and a range of other systems be designed, implemented, and made available so that potential users can make their own informed choices. -gg

4 4