April 1993 - cypherpunks-legacy

PGP 2.2 for mac
by trump＠pluto.ee.cua.edu 04 Apr '93

04 Apr '93

yes i am looking for pgp 2.2 for mac so if anyone knows where i can find it or if anyone can tell me if they can uuencode it and mail it to me (please contact me before mailing) i would be most greatful... i do not have a mac but i have a friend at the university of wisconsin that i feel sould have pgp... so as i plea for help into the black hole of the internet cypherpunk remailer i hope to hear some feed back.... also do the people in dc want to get a cypher punk meeting together??? i am wi willing to organize... Clovis

1 0

Keys on public machines
by szabo＠techbook.com 04 Apr '93

04 Apr '93

[lost attributions, sorry] >> I could do an ascii upload of my secret key and never expose my >> key to disk-storage. >> > This is even more dangerous than storing it on the disks of a multi-user > machine. Unless you are running in a kerberos environment it is trivial to > snoop your upload off the network... I don't find the risk of a real-time snoop to be as bad as the risk of a future snoop finding my private key alongside encrypted files that have been stored forever (backups). To mitigate either problem, how about having two layers of encryption: a private key to decrypt files for reading on a public machine, and a second public/private pair to reencrypt the files for storage and transmission to the home machine. The public machine knows the first private key (if snooped) and the second public key; only the home machine knows the second private key. Snooping the first private key compromises only unread and future messages until the key is changed. Messages archived in the reencrypted state are secure, but messages archived in the unread state with the first private key are still compromised forever. Is backing up mail directories a common practice? Are there (probably system-dependent) ways to avoid backups, such as anticipating or detecting when backups are about to occur, hidden directories, file permissions, etc? Also, this system introduces some user hostility, in that reencrypted files cannot be read again until moved to the home machine. Another idea is to implement the relevant features of Kerberos in a high-level client/server package that can be used to secure personal network communications of this kind. The package could be distributed with PGP. Nick Szabo szabo(a)techbook.com

1 0

Looking for PGP porting help
by zane＠genesis.mcs.com 04 Apr '93

04 Apr '93

I'm busy (actually, I'm procrastinating doing my schoolwork ;-) porting PGP 2.2 to the Apple IIGS. I have two problems and one question-- The question: Who should I contact with the fact that I'm doing this port so that once a new version of PGP comes out all my porting work isn't lost? The problems: I'm not a very experienced C programmer/porter. I seem to be one of two people in the Apple IIGS community who's interested in porting PGP. (The other is even LESS experienced at C-- he just learned C recently.) Any ideas? Thanks, -- | Sameer Parekh-zane(a)genesis.MCS.COM-PFA related mail to pfa(a)genesis.MCS.COM | | Apprentice Philosopher, Writer, Physicist, Healer, Programmer, Lover, more | | "Be God" - Me __ "Specialization is for Insects" - Robert A. Heinlein ____/ \_____________/ \____________________________________________________/

1 0

Second posting (emucs)
by treason＠gnu.ai.mit.edu 04 Apr '93

04 Apr '93

This is the second posting I have posted about emucs (encrypted multi-user chat system) on the list. I am hoping to get a little more involvement from stable coders to help develop this product. Most of you are knowledgable of irc and how flawed it is, the ease of logging, and the fascism of the operators therof. I want to alleviate this problem by producing a multi-user chat system involving 1 server and up to 50 clients which is counterproductive to promoting logging and such. My design is easy: All messages sent from a user will be encrypted(pgp) by the pc(msdos machine initially) before its sent over the phone line, to the server. The server will then determine if the message is public or private (very easy to do) and if private, will decrypt it using the servers public key. It will then pass the message to all users on the server in unencrypted format. If it is private the server will pass it directly to the recieving party, who's client will decrypt it (if its private the sender must have the receiver's public key) and display it to their view screen. I was considering encrypting and handling everything in a private manner, but have decided that this would be more than too much load on the recieving pc's so have decided to keep only private messages completely secure. When the person wanting to engage in the chat decides to run the client, he would supply his pass phrase as a command line parameter, and it would be stored in memory until the chat is terminated. Any time a private message comes to him the client would automatically decrypt it with his key and pass phrase. There will be key handling and exchanging utilities built into the server. The client will allow for vt100 emulation and will work as a terminal program until the chat is entered, at which time, the client wwill be prompted by the server to start its new function(ie. encryption). If anyone has any ideas or wishes to help me with this, please respond to treason(a)gnu.ai.mit.edu and explain what you can do, or what ideas you have. On the last posting of this sort, there was very little response, which frightens me because of the serious need for this kind of software. Treason(a)gnu.ai.mit.edu

1 0

Mailing LIst
by x62727g2＠usma8.USMA.EDU 04 Apr '93

04 Apr '93

I am very very interested in getting on your mailing list. PLease include me. Thank you. Anthony GAtlin ------------------------------------------------------------------------------ Notice: In accordance with Title 18 USC 2511 and 18 USC 2703, any monitoring of this communication without a Federal warrant or consent of sender or receiver is in violation of Federal Law. Consent for monitoring is not given.

1 0

MEET: Boston area Cypherpunks Meeting
by Derek Atkins 04 Apr '93

04 Apr '93

-----BEGIN PGP SIGNED MESSAGE----- The FIRST Boston-area cypherpunks meeting: Date: Saturday, April 10, 1993 Time: 12 noon - ~5 pm Where: MIT Room 1-115 If you need better directions, please feel free to send me e-mail, or you can call me at 617 868-4469. Hope to see people there! - -derek PGP 2 key available upon request on the key-server: pgp-public-keys(a)toxicwaste.mit.edu - -- Derek Atkins, MIT '93, Electrical Engineering and Computer Science Secretary, MIT Student Information Processing Board (SIPB) MIT Media Laboratory, Speech Research Group warlord(a)MIT.EDU PP-ASEL N1NWH -----BEGIN PGP SIGNATURE----- Version: 2.2 iQBuAgUBK76hsTh0K1zBsGrxAQHD7ALFExaf+JQ3l21P1c5Tuxx2RdKy/AsLLZo1 D6Y0LsaPe7YEW9bofbQr0HKdW08KvZgDHowUomjCFgLRVJPtwyTJkqWuL4424/XU cuSe+LWeNJ+llrbosFgsk/o= =wZJR -----END PGP SIGNATURE-----

1 0

PGP help and comments.
by J. Michael Diehl 04 Apr '93

04 Apr '93

I am really learning to love PGP, and I haven't even used it much yet! I'm insisting that all my friends get keys. But.... I would like to set up two secret keys for myself. One 512 bits long and another 1024 bits long. I'll distribute the short one. I'll give the long one to trusted and close friends. I'm having difficulty setting it up so that pgp defaults to using the short key to encrypt stuff. Note that I want the same user id for both, but perhapse with a "secure" flag in the user id of the large key. How can I do this? Can we get someone to compile and distribute pgp for the amoeba, er, I mean Amiga? ;^) My friend has one, but no C compiler. Some suggestions for future versions... Is there any chance of pgp cloaking it's ascii armoured output to look like uuencoded data? I would like to use pgp on the mainframes, but don't want to store my secret key on their disks. Would it be possible to have pgp accept it's secret key via stdin. I could do an ascii upload of my secret key and never expose my key to disk-storage. How about password protecting pgp itself. No one could use my copy of pgp unless they knew my password. And only my copy of pgp could decrypt my secret key. Just a thought. How about a -wn option that would wipe the original file 'n' times. Like pgp -wen10 very_secret_stuff cohort. That should keep even Big Brother from prying. Is it possible to have pgp develope a third key that looks just like a regular key except that when it is used in place of your secret key, it produces an alternate plaintext. This way, if Big Brother "requested" you'r key, and you needed to dissavow all of you'r messages, you could exchange the third key for you'r secret key. When someone used this key, they'd get some insulting message that may or may not have been the original message...and there'd be no way of knowing. I kinda doubt it on this one, but wouldn't it be nice! Geez, have I really gone on for 40 lines? Sorry about that, but any comments? Hope to hear from you. -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.2 mQBNAiu21SIAAAECAMKkKKP4JIxSPR7rOUZ7mbi6yDPfFa7T6zOtOBX8iI939tIU 9JFTxdyvTejK3qmYDGozNaqySQ/0++nGqZgikcsABRG0LUouIE1pY2hhZWwgRGll aGwsIG1lLCA8bWRpZWhsQHRyaXRvbi51bW4uZWR1Pg== =YquS -----END PGP PUBLIC KEY BLOCK-----

3 3

jarthur remailer has PGP
by Eli Brandt 04 Apr '93

04 Apr '93

Snarfed PGP 2.2 and found it more successful on a Symmetry than 2.1, which I couldn't get to stop dumping core on keygen. So the remailer on jarthur now supports encryption, I think. Bang on it and see if you agree. The jarthur remailer's key: (512 bits only, it's on an insecure box) -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.2 mQBNAiu+hVUAAAECAMVjEfl2IMNgSOJ+/fx1V6EbH50ofa6K4r1PBKMmkcHQextP ghwC4lXIgaAWUlLJ9x61+qf4jB5fpNUZLrF9FUsABRG0NWphcnRodXIgcmVtYWls ZXIgIGMvbyA8ZWJyYW5kdEBqYXJ0aHVyLmNsYXJlbW9udC5lZHU+ =Zxy7 -----END PGP PUBLIC KEY BLOCK----- The makefile paragraph: symmetry_gcc: $(MAKE) all CC=gcc LD=gcc OBJS_EXT=_80386.o \ CFLAGS="-O -I. -DNOTERMIO -D_BSD -DUNIX -DUSE_NBIO $(BYTEORDER) -Di386" Logging is turned back on until the glitches are out. Enjoy. PGP 2 key by finger or e-mail Eli ebrandt(a)jarthur.claremont.edu

1 0

MEET: I'm going West! (Bay Area)
by Marc Horowitz 04 Apr '93

04 Apr '93

I'm going to be at a meeting at the Westin hotel in Milbrae, CA. I'm taking an early-morning (ugh) flight out on Tuesday, and I'm red-eye'ing back Friday night/Saturday morning (to be back for the Boston Area Cypherpunks meeting :-) I should be free in the evenings, namely, Tuesday, Wednesday, and Thursday nights. I'd be interested in getting together with people to exchange signatures, talk about stuff, eat dinner, or whatever. I can be reached by email at <marc(a)mit.edu>, which I should be reading remotely, or you can leave a message for me at the hotel at 415-692-3500. Marc

1 0

Re: TEMPEST in a teapot
by karn＠qualcomm.com 04 Apr '93

04 Apr '93

A few minor comments on a pretty comprehensive and well written article. Although TEMPEST is closely related to EMI shielding, remember that TEMPEST is concerned only with *information bearing* radiations, not interference. In particular, the switching power supply, a potentially prodigious source of EMI, is not a significant TEMPEST issue because power supply emissions carry little if any information. (Varying loads might cause minor modulations of switching frequencies, etc, but this is probably something that only the paranoid "covert channel" types worry about. Maybe you coull tell when the floppy drive motor starts and stops, but I doubt you could do much else.) Who knows, cutting down on power supply radiation might make it easier to extract information from the emissions that remain, because of the jamming effect of power supply noise. But don't let that stop you. It's your duty to your neighbors to emit as little RF noise as possible. When I lived in New Jersey, I learned to my chagrin that my two PC clones made my next door neighbor's AM radio useless. Only 25 miles from New York, he was unable to listen to WABC, a 50KW clear channel AM station! The problem disappeared completely when I installed some inline AC RFI filters in the power supplies. Since we shared a pole transformer, I theorize that the noise was conducted from my computer to his radio directly over the power lines. Which brings me to my next point. I have not seen *any* clone-grade PC power supplies with adequate power line filtering. They have a minimal LC lowpass network on the power supply board itself, but this is usually inadequate. Whenever I buy a new power supply, the first thing I do when I get it home is to replace the IEC power connector with an integrated, shielded power connector/RFI line filter. These devices are widely available for several dollars from electronics surplus houses and amateur radio "hamfests". I also use power cords with built-in ferrite "lumps" but these are probably harder to find (one particular hamfest vendor had a lot of them a few years ago, but I haven't seen them since.) Modern monitors are *much* better shielded than the early PC monitors, especially those no-name Korean or Taiwanese copies of the original IBM PC monochrome monitor. If you have the misfortune of owning one of those old monitors, as I do on one of my systems, chances are the lion's share of its emissions are coming from the +70V power lead that runs from the main circuit board to the video output stage on the base of the CRT. (Note! Do NOT confuse this with the high voltage lead going to the anode of the CRT!) The +70V power line to the video output driver acts as an antenna for radiated video signals that can be *quite* strong. I suspect that the reports we've seen of successfully picking up the image on a computer display were taking advantage of this. To fix the problem, just replace the plain wire with a piece of shielded coax, bypass the ends with .01 or .1 uF capacitors of sufficient working voltage, and ground the shields to circuit board ground on both ends. Phil

1 0