- cypherpunks-legacy@lists.ogf.org

Thanks a lot!!!!!
by vanam＠interceptor.ksu.ksu.edu 12 Apr '93

12 Apr '93

Thank for your answers and any other help for a beginer would be helpful... But to all that answered Thanks again... Stephen

1 0

Help, please.
by vanam＠shadow.ksu.ksu.edu 12 Apr '93

12 Apr '93

I am very new to the world of hacking... Could you all give me a hand understanding...(aka suggested reading and helpful tips for a newbie.) Thanx in advance Stephen

3 2

Re: REMAIL: cypherpunks strategy
by norm＠netcom.com 12 Apr '93

12 Apr '93

In-Reply-To: <26H11B1w164w(a)ideath.goldenbear.com> I just got around to Greg Broiles interesting note where he describes his practice of using several account names. He feels apologetic about it. Authors have used pen-names for a long time without opprobrium. The mathematician Eric Temple Bell wrote science fiction under the pen name "John Taine". Several authors have written different styles of works, one pen name per style. As I understand the law there is nothing illegal in using an alias as long as the purpose is not fraud, which is already illegal. One must protect the reputation of each alias. Where aliases are common negative reputations loose their bite but the benefits of positive reputations provide incentives for good behavior.

2 1

a new usenet group
by Eric Hughes 12 Apr '93

12 Apr '93

There is a new Usenet group that some on this list might be interested in. It's called alt.privacy.anon-server This group seems to have been created as a spillover for the debate on anonymity in news.admin.policy. My nntp server has seen less than 100 articles to date. I would encourage those in this group who have strong opinions to participate in this new forum, as it seems the advocates of strong privacy are not so numerous as they are here. Eric

1 0

Real-time BBS Encryption??
by Michael McMahon 12 Apr '93

12 Apr '93

I thought of this the other day, but don't know enough about programming and cryptography to do it, or if it actually could be done. Anyways, I figured I'd share it with all of you and see if anyone has any ideas. Here's the situation: We all know that some advanced computer systems have real-time encryption built into all modem connections. When a bank branch dials into the main office the entire transmission may be encrypted. This occurs even between terminal connections and the host. I'm wondering if there is a way to do this with PCs? Say I'm setting up a computer bulletin board for my company that is going to run off of a DOS PC. Is there a way to encrypt a remote users entire connection with the BBS, so that they would have to have a special term program to access the system? It would be best if the user only had to load a device driver or something so that they wouldn't all have to use the same comm program. Could this be done by loading a special device driver on both the host and remote so that all data going through com port 2 (or whatever) is encrypted? Anybody know if something like this is available? * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * Mike McMahon * * Internet: 585-7625(a)mcimail.com * * PGP Fingerprint: 95 F9 2A 1B 81 4F D8 31 56 ED BC A5 4F 64 A7 02 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

11 10

Distributed anonymous posting (was Re: Many Important Items...)
by Joe Thomas 12 Apr '93

12 Apr '93

-----BEGIN PGP SIGNED MESSAGE----- Tim May writes: > Phil Karn comments on my proposal: > > >>(Cypherpunks remailers may want to change the "Nobody" and "Anonymous" tags > >>to names that are less screenable, less susceptible to censorship by > >>ARMM-type programs... > >I'm not sure I like this idea. In my own discussions with people on > >this issue, I've found that "filterability" (for lack of a better > >term) overcomes *many* (if not all) of the standard objections to > >anonymous email. > A very good point. I was thinking more about the "ARMM"-style attacks and > not so much about the normal filters people might write to keep from seeing > anonymous posts. We may be getting ahead of ourselves here. Because of design decisions in the cypherpunk remailers, I think they'd be a poor infrastructure for anonymous Usenet posting. Anonymous posting has been around as long as Usenet, in the form of forged messages. The most important service Julf's remailer provided was a _return_path_ for replies, something cypherpunk remailers take deliberate steps to destroy. If one of the cypherpunk remailers suddenly decided to implement anonymous Usenet posting as-is, I think ARMM II would be the least of its problems. I have been working through a few ideas for the design of a _distributed_ anonymous posting service, in which the loss of one machine would not destroy all return addresses at that machine, nor compromise the return- path database. A handful of penet-style servers who share their return- address databases (kept updated through an encrypted e-mail protocol, perhaps) act as a Usenet "front-end" for posting. But their databases contain encrypted SASE paths through several cypherpunk remailers, instead of normal return addresses. Messages posted through any of the front ends could be sent to the same user-name at any of the other front-end machines, since they keep the same databases. In order to assure that SASE return path is robust, despite an environment in which remailers may be shut down at any time, secret sharing might be used for remailer private keys. When a remailer went down, a quorum of the remaining remailer operators would nominate a site to replace it, and send the "pieces" of the lost remailer's secret key to the replacement site's administrator. The remaining remailers would adjust their "routing tables" so mail whose next hop should be to the lost remailer is sent to its replacement instead. The best part is that all of this would be transparent to the Usenet user, who would just see a penet-style return address, along with a note in the automatically appended signature that said that "if mail to an1234(a)foo.com bounces, just try an1234(a)bar.uk or baz.fi," or whatever. No doubt there are some problems with this scheme (traffic analysis attacks on the SASE paths if the front-end database is compromised, etc.) that need to be addresssed, but I offer it as a preliminary idea for a replacement service whose stability would not be subject to the whims of any one site or network connection. > I guess the solution is to discourage global, ARMM-style filters (and > perhaps even look again, as a community, at digital sigs for postings, so that only the author can cancel them). Agreed. This could even be implemented into today's news structure. Old servers would continue to blindly heed all cancel messages, while the new software would verify PEM-style signatures, possibly as a header field. And if a cabal of prudish newsadmins wanted to let each other cancel those offensive anonymous articles at their sites, they could simply tell their software to accept cancels signed by cabal-members' keys. I don't see how anyone could oppose this. -----BEGIN PGP SIGNATURE----- Version: 2.2 iQCVAgUBK7Hk7Iwu6QoBw6rbAQF5owQAlfXjo8G+cKiSVEbfIBAXIAsmTJkBLcAH OhCzyXZXyCKeH5J8yB9cgTgpCsxQCdBgQLsW2aqvyWaVgMX4rXvjx6vqYbm4BW5p 9OQ6YhLI17zArrqPPsyzbYYHwUXXY2vYEWAmFXNhYBv9r4vbbT3IqPJgCTKltShA 5ho53DEkIRA= =6q8R -----END PGP SIGNATURE----- -- Joe Thomas <jthomas(a)access.digex.com> PGP key available by request or by finger. PGP key fingerprint: 1E E1 B8 6E 49 67 C4 19 8B F1 E4 9D F0 6D 68 4B

3 2

Trusting PGP
by norm＠netcom.com 12 Apr '93

12 Apr '93

At last I have read the operating instructions for PGP 2.2. I am impressed. I raised the issue of trusting PGP. John Draper correctly suggested that it was possible to trust PGP because the code was available for inspection. I agree that this places PGP far ahead of various competition regarding trust. I propose, however, that if there were a single specification that covered various file formats and perhaps program logic, that PGP would eventually gain substantially more trust. Here is why. As it is now, someone who reads the code to establish his trust in PGP must be familiar with C, in which PGP is written, number theory and various crypto threats and weaknesses. There are certainly such people. If, however, there were one operating specification then many more people would be attracted to the effort, ultimately yielding greater trust in PGP. Cryptographers without the skill or tenacity to read the code could contribute, as could programmers without the crypto theory. Each class would consult the specs, the programmers to verify that the code implemented the specs and the cryptographers to ponder whether programs with such specs were appropriate for their market. Such specifications are required for government rated secure software for just this reason.

1 0

PGP: Re: PGP Error
by edgar＠spectrx.Saigon.COM 12 Apr '93

12 Apr '93

-----BEGIN PGP SIGNED MESSAGE----- Michael Diehl wrote on April 6: When I use the following command line in a batch file, I get a Compression/ decompression error. No files are created. The contents of the batch file is: pgp -es %1 %2 Diehl Where %1 is the name of the file to send, and %2 is the other person's name. What am I doing wrong, or is ther a problem with my pgp? I think there's a problem with PGP. A net-friend of mine in Poland first brought this to my attention. He says he's already notified PGP author Branko Lankester. The problem's occurance seems to depend on the file being compressed/encrypted. Files which are already compressed, but are not ZIP files (e.g. ARJ files) seem to cause the problem. I was able to reproduce a similar problem by trying to compress ARJ.EXE (ARJ 2.30). In my case, the system crashed shortly - -after- PGP exited, and some of the armored files produced (I used - -eas) were obviously messed up. The obvious temporary bypass is to turn off compression for files which cause problems; not much of a penalty, since the file is already compressed. This can be done by a (temporary) change to the CONFIG.TXT file. I think there may also be an (undocumented) way to do this from the command line. Try: +compress=off -----BEGIN PGP SIGNATURE----- Version: 2.2 iQCVAgUBK8YEFN4nNf3ah8DHAQH1IgP9E0gvLSF2DQ5dkVcyXGGLZa4+bCcZ0kOM TefqfqFZLjU4MvOPMzXzkB01aDpg1IUyfExJazNjADCrbJKqFoZymyhuB+X6KMmy faTyFGsCeNcpA5x897qwsD/M7zM3j7EVauctAjNBTM9t/34eTuaYuesPPBmEaUcS yp7J1VOvbWM= =8+bK -----END PGP SIGNATURE----- -- edgar(a)spectrx.saigon.com (Edgar W. Swank) SPECTROX SYSTEMS +1.408.252.1005 Silicon Valley, Ca

1 0

FWEE!: kiosks
by internaut＠aol.com 12 Apr '93

12 Apr '93

Yo Dewds, I guess it's time for me to throw in my two bits on the Public WB Kiosk idea... I guess I appreciate the intent of implementing such a system, but there are some BIG strikes against it: [1] Strike One: Installation and maintenance costs (economics again). Can you IMAGINE what it would cost to build and maintain a network (and it would have to be a big one!) of public kiosks? Better to piggyback on existing infrastructure for purely practical reasons. I have an account on the aforementioned SF Net (little tables in coffeehouses all over the San Francisco Bay Area) and I have come to the conclusion that it would be prohibitive to just maintain such a system. Wayne Gregori would back me up on this. If you think it's a pain to keep your baby-powdered PC at home in decent working order, imagine one with beer spilt on it daily, bozos who type like Paul Bunyan on Steroids and the occasional chairleg-yanking-the-plug-out-of-the-wall incident. Most of the time, I log in to SF Net from home anyway. [2] Strike Two: Lack of Privacy while using the kiosks. I think Eric Hughes' argument (with due respects to Eric) about the expensive economics of monitoring the kiosks falls down just a tad when you consider that these would not even be _moving targets_! (In both the literal and figurative senses.) Sure, it's expensive to "tail" someone and find out where they go and who they meet, but it's less than trivial to set up a discreet camera that just watches a stationary kiosk all day long or maybe photographically or electromagnetically (with a moderately sophisticated bug) monitor the keystrokes. Maybe you _could_ make them portable and move them around; maybe you _could_ come up with a clever physical design that would preclude keystroke photography (but bugs?), but any such defenses would pale in comparison with the Privacy inherent in the WB input from a single user's personal system. "Public Privacy:" now _there's_ an oxymoron for the 90's! All jocularity aside, it would be pretty difficult to convince anyone with serious information on Govt abuses to stroll into a Mall and spill their guts on a PC Junior in a plywood box - I sure as hell wouldn't, would you? Hell, you could put touchscreens on it and I STILL wouldn't take the chance. Anyone ever seen the "Human Jukebox" in SF? A guy dresses up in a huge cardboard refrigerator shipping box and when you drop a quarter in, he plays (on trumpet) some selection from a list on the outside. Very funny stuff: I suggest you ask for "Strangers in the Night." [3] Strike Three (yer OUT!): those ugly little plastic-encased keyboards get all that icky finger dirt on 'em. Sure you laugh NOW, but just IMAGINE where people put their fingers before typing on them little keyboards. Yuck! Think of the diseases! The nose pickings! The leftover popcorn-butter residue! The Jeri-Curl! Yeesh... makes me wanna HURL. But Serially, Folks: If a group COULD surmount these difficulties, it would then have to begin to focus on the TYPE of whistleblowing that would take place on such systems. I have the feeling that they would be a PRIMARY contributor to the overall bullshit noise that would clutter up a decent WB systems and exponentially increase the difficulty of filtering out the "good" stuff for proper use. Sure, you could rely on OTP's to provide relatively secure transmissions, but the big question is: do we really want a bunch of Valley Girls at the local Mall logging in and complaining that they "can't get the proper shade of eyeliner and, like, why doesn't the Federal Govurnmint toe-tully reform the Health In-fersure-ance System" so they could, like, get the bunyons burned off their right foot in time for the Prom. I think you get my point. We have a ot more to work on before I consider this to be a desirable, much less viable, idea. dave ------------------------------------------------ | | | no fancy-dan sig-stamps, just li'l ol' me. | | | ------------------------------------------------

2 1

Speed of RSA
by Aviel David Rubin 09 Apr '93

09 Apr '93

Does anyone have anything on the speed of RSA encryption for various key lengths on various machines? In particular, I am interested in how long it takes to decrypt mail headers on an IBM rt or RS6000, for various key lengths. I'm sure this has been measured. Any help would be appreicated. Thanks. Avi Rubin

1 0