January 1993 - cypherpunks-legacy

Re: Remail addresses...
by Hal 05 Jan '93

05 Jan '93

-----BEGIN PGP SIGNED MESSAGE----- From: edgar(a)spectrx.Saigon.COM (Edgar W. Swank) > > Anon-To: <next destination> > Encrypt-With: <some DES or IDEA key> > > I'd like to point out that the "-ca" function of PGP could be used > to perform this function if Encrypt-With: specified a PGP pass-phrase > rather than a direct key. This sounds like a good idea. The user would have to have some scripts to decrypt incoming anonymous-address messages using this pass phrase (or some sequence of pass phrases if more than one remailer was used for the anonymous address). > I'd also like to suggest that the message- > body to be encrypted require heading and trailing delimiters such as: > > -----BEGIN MESSAGE BODY----- > -----END MESSAGE BODY----- > > Note delimiters would not be part of message body and would not > be encrypted. These anonymous addresses do need a distinction between the "message address" (or "envelope") and the message body. The anonymous address gets decrypted at each step, and the message body gets encrypted at each step using the scheme above. But Eric Hughes pointed out that we already have such a distinction in the RFC822 message headers vs body. We should use that existing structure rather than try to create our own. That means that anonymous addresses should be designed to fit into mail headers. Unfortunately many mail agents make this difficult or inconvenient right now, but perhaps that is an area where we could make some improvements. In this model, we would not need message body delimiters, since mail already has its message body delimited distinct from its headers. If we do process the message body with encryption at each stage, I do have an idea which could be useful. If the body which is being encrypted is already in the format of an ASCII-encoded message using the standard RFC822 encryption used in PGP, RIPEM and PEM, then rather than just encrypting it it could be de-ASCII'd, then encrypted, then re-ASCII'd. This would keep it from increasing in size by a factor of 4/3 at each encryption step. Hal -----BEGIN PGP SIGNATURE----- Version: 2.1 iQCVAgUBK0kHvKgTA69YIUw3AQHBuwP/ekp1feh06tLHwxws49DE3wVxnu/36Yg7 oW2l43n3llgRJC+r/KYJ2+5LTG0/f1Ib/R8c4qxUJzZeCj7zABSdJ6KSwIlwmfP6 Djz0vOBnife6CvhQRi+T/8NuFqFIzlxO1vK+7tG9KWshxP+7AMayGOLuY0pOTREX 7brcJHnn7Mg= =9Uss -----END PGP SIGNATURE----- Distribution: CYPHERPUNKS >INTERNET:CYPHERPUNKS@TOAD.COM

1 0

Re: Return addresses
by edgar＠spectrx.Saigon.COM 05 Jan '93

05 Jan '93

Hal Finney wrote here on Dec 30: Chaum's idea was that the message contents would be encrypted at each step, as Eric suggests, but Chaum would have the encryption key be part of the anonymous address, created by the same person who made the anonymous address. The idea would be, after decrypting the incoming message, the remailer would see something like: Anon-To: <next destination> Encrypt-With: <some DES or IDEA key> It would then encrypt the message "contents" (but not the "envelope", as Eric points out) using the specified key. When the owner of the anonymous address received the message, he would decrypt it using the chain of "Encrypt-With" keys that he put into the anonymous address. I'd like to point out that the "-ca" function of PGP could be used to perform this function if Encrypt-With: specified a PGP pass-phrase rather than a direct key. I'd also like to suggest that the message- body to be encrypted require heading and trailing delimiters such as: -----BEGIN MESSAGE BODY----- -----END MESSAGE BODY----- Note delimiters would not be part of message body and would not be encrypted. -- edgar(a)spectrx.saigon.com (Edgar W. Swank) SPECTROX SYSTEMS +1.408.252.1005 Silicon Valley, Ca

1 0

Acceptance of Keys
by Matt Willis 04 Jan '93

04 Jan '93

<As excerpted from Julf (admin(a)anon.penet.fi) >Richard Childers writes: > >> It is the user's job to hide his or her identity, but it should not >> be the programmer's responsibility to anticipate the user's failure >> to think at all. Someone who uses these tools without understanding >> the principles upon which they are founded - such as people whom >> accept keys from individuals whom are only electronically known - >> will quickly founder upon their own, um, state of stupor, and one >> should not undertake to protect them from this, as what you are pro- >> -tecting them from, in reality, is the opportunity to learn from >> their mistakes. As wary as I am of expressing my ignorance, I'll give it a shot... I'm new to the Cypherpunks list and I'm just curious, is it going against the principles of PGP to "accept keys from individuals whom are only electronically known"? (if so, I guess I'm in a state of stupor) Most of my dealings on the internet are internet-exclusive, that is, I never meet the people with whom I communicate. With the exception of some locals, computer social life in FL, USA is pretty non-existant. I wish my communications to be secure and I believe that PGP is the best way and I will never have the opportunity to meet the people I talk to in Kansas or in New York (both places, I hope I never visit). If meat-relations are the only secure way I'm supposed to communicate, then I guess I'll have to use carrier pigeons. :) DISCLAIMER: Of course, I could be taking this TOTALLY out of context, and in that case this message should read: Hey, I really like this list... It's intellectually stimulating and a clearly positive influence on my life. How's the weather in Europe? I'm not trying to be argumentative, I just have serious questions about the keeping of public keys... here's another one... couldn't we assign one at birth... it'd be better than a social security number (dunno what you use in Europe), but a whole lot harder to remember... ALSO: We Mac users are wondering when MacPGP 2.1 will be out? Anyone have any contact info? thanks for reading my words. +-------Matt-Willis--------------------------------+ | Matt Willis ASTMWILL(a)STETSON.BITNET | elsewhere: | Matt Willis Head of the Underground | mwill(a)mindvox.phantom.com | Matt Willis Robotech PBM List | +-------Matt-Willis--------------------------------+ "Absolutely alone in awareness of the mechanism." -Agrippa by WG

2 1

Re: The Need for Positive Repuations
by hughes＠toad.com 04 Jan '93

04 Jan '93

--------------------------- Original Message --------------------------- You sent this to cypherpunks-request and not to cypherpunks. Eric ----------------------------------------------------------------------------- Return-Path: <@YaleVM.YCC.Yale.Edu:KL62@MARISTB.BITNET> Date: Fri, 18 Dec 92 15:18:35 EST From: "Ryan, Edmund J" <KL62%MARISTB.bitnet(a)YaleVM.YCC.Yale.Edu> To: <cypherpunks-request(a)toad.com> Subject: Re: The Need for Positive Repuations In-Reply-To: In reply to your message of FRI 18 DEC 1992 11:45:55 EST > Indeed, in the long run, when there are billions of people in the nets, > even UseNet newsgroups devoted to people who use musical instruments as > sex toys would have thousands of posts a day because given billions of > possible subscribers, finding a few tens of thousands with a particularly > obscure interest wouldn't be hard. Thus, in the long run, the nets will move > to "closed" newsgroups and mailing lists in which to be a subscriber one > will have to be explicitly subscribed to a list and will only be able to > read with one's private key and post by digitally signing messages. In such > an environment, anonymous abusers will simply be incapable of annoying people. Well there won't be a complete movement in that direction. The set up of the list may differ. Some lists may be open to all to read but open only to subscribers to post. Some lists may be the other way around. (Can't think of an example, but there may be one out there.) By the way, I've never really seen too many abusive postings on the Usenet groups I frequent.It doesn't seem to be a problem. Just my opinion. > A weak version of this exists already in the Extropians mailing list, which > considers itself to be a closed list. The list is governed by a privately > produced legal code (its in some ways a test of anarchocapitalist legal theory > and since the adoption of the code, we've had a reduction of flaming by > a large factor even though we've seen a three fold increase in list size. > The content is improving because people know that sanctions will be applied > for flaming and that they can actually be kicked off the list, and that being > kicked off is meaningful. In the long run, all serious discussion groups > will likely evolve in this direction, with the lists being closed to explicit > subscribers and with meaningful sanctions like ostracism being applied to > people that behave in an antisocial manner. Such lists have little reason > to fear people hiding behind cloaks of anonymity. With digital signatures, > even the anonymous can develop meaningful reputations and can be sanctioned > for failing to live up to those reputations. > > Perry Again, there will always be the fun of watching people flame. Virtually, Edmund J. Ryan ------------------------------------------------------------------------ - Edmund J. Ryan C.I.S. Major Extropian - - KL62@MARISTB C.S. Minor Libertarian - - "Insert your snappy quote of the day." - ------------------------------------------------------------------------ ------------------------------------------------------------------------ - Edmund J. Ryan Major: Computer Information Systems - - KL62@MARISTB Minor: Computer Science/Business - - Marist College Political philosophy: Libertarian - - Poughkeepsie, NY Extropian - - - - "Replace taxpayers with shareholders, - - regulators with customers: privatize!" - ------------------------------------------------------------------------

1 0

Re: A solution remailer signature suppression
by Richard Childers 04 Jan '93

04 Jan '93

"Hugh Daniels said here on Dec 28: There are very good reasons to build remailers (and all mail tools) to pass on all the bytes they can, trailing spaces and .sigs included." "Hugh doesn't say what these reasons are. They are not obvious to me, so I must disagree. I've already stated what I think are good reasons at least for remailers whose purpose is anonymity to remove automatic sigs which are likley to destroy anonymity." I can think of a few ... (1) it's a bad precedent to rewrite contents. one program's apparent signature could be another program's data or instruction. (2) it is unnecessary complexity and falls under KISS, IE, 'Keep It Simple, Simon'. (-: (3) It is less robust and portable as a result of having this additional complexity. ( I use 'portable' not in the conventional compiler- specific manner, but more to apply to a given application's usability for future, yet-to-be- known applications, IE, flexibility. ) In this respect it fails to conform to requirements for a good software 'tool'. It is the user's job to hide his or her identity, but it should not be the programmer's responsibility to anticipate the user's failure to think at all. Someone who uses these tools without understanding the principles upon which they are founded - such as people whom accept keys from individuals whom are only electronically known - will quickly founder upon their own, um, state of stupor, and one should not undertake to protect them from this, as what you are pro- -tecting them from, in reality, is the opportunity to learn from their mistakes. "I've said I would accept either a less ambiguous sig delimiter than "--" or a remailer option to remove the sig (default) or leave it in." Until there is a convention, IE, an RFC or ANSI standard for signatures, it would be unwise to build in any assumption. I just realized an excellent example. For years, I've been signing myself ... -- richard ... such that everything after my name - IE, contact data - would be trimmed off. Not well thought out ... I have actually seen this in the case of a few mail servers that rewrite contents ( such as the elec- -tric vehicles digest, EV-L ). -- richard ===== -- richard childers rchilder(a)us.oracle.com 1 415 506 2411 oracle data center -- unix systems & network administration "If Life is a drama, then, surely, the hardest parts go to the most skillful."

2 1

Anonymous discussion on Pax
by ghsvax!hal＠uunet.UU.NET 04 Jan '93

04 Jan '93

There has been some discussion on the Pax mailing list (mail to anon.subscribe(a)pax.tpa.com.au to subscribe) about anonymous posting and mail. Here is an excerpt from one posting that I thought was interesting. From: mjr(a)netcom.com (Matthew Rapaport) > >anonymous posting is just another noise source. Very little is riding > >on who "wins" arguments on Usenet. > > True, so I'll try something more serious. Suppose you were trying to > convince some small group of vulnerable people to commit some crime, or > aid in one directly or indirectly (perhaps for political reasons). > He/she/they might resist one provacateur, but all *10* of *you* assure > him/her/them that you've all done it (for which reason you must > naturally hide your identities), it must be done, etc. > > ******* > > >The idea of positive reputations is designed to help with the problem > >that anonymity could lower the quality of postings by reducing > >accountability. > > The WELL tried a completely anonymous conference once. It quickly became > a mire of flaming viciousness, lying, trickery and backstabbing. It was > unbelievable to see how fast it got nasty, and in an otherwise > reasonably well behaved user population. Does anyone here have information on this experiment on the WELL? That sounds like an interesting data point. Presumably they did not try to press on with some kind of rating or reputation system. Hal 74076.1041(a)compuserve.com

1 0

Re: Why mailers should not touch the body
by jordan＠imsi.com 03 Jan '93

03 Jan '93

I got lots of mail telling me that signing messages in the body of the message came about because "various mailers" munge header lines. Now it's true that for gateway processing, To: and From: lines need to get translated, but I've never seen a mailer change or remove a header that doesn't have to do with addressing before. Can someone provide an example? My claim is that a signature belongs on the envelope and not in the body. ----- To be clear, I'm talking about (e.g.) a PGP signature, not a .signature with a cute saying in it. /jordan

1 0

New remailers...
by Hal 03 Jan '93

03 Jan '93

-----BEGIN PGP SIGNED MESSAGE----- From: tribble(a)xanadu.com (E. Dean Tribble) > First a brief description of the new (read not-yet-available) remailer > architecture, then what's this means to signatures, etc. > [...] This is neat. It sounds like the plan is to provide a convenient mail filtering tool which provides remailer capability as a SIDE EFFECT! What a great way to spread remailers! Not to mention, the same tools can provide automatic encryption and decryption - the long-sought integration of PGP (or RIPEM, etc.) with mail in an easy-to-use way. I'm really looking forward to seeing more about this idea. Speaking of integrating encryption into email, does anybody here have access to the announced beta-test of PEM from TIS? It would be interesting to see the documentation about how they've handled the user-interface issue. I gather that it only works with the MH package but presumably they've had to face some of the problems we're talking about here. Hal 74076.1041(a)compuserve.com -----BEGIN PGP SIGNATURE----- Version: 2.1 iQCVAgUBK0ZOFqgTA69YIUw3AQHQkwP/VjXxDvQWqpx+owL4re1YVtMTobydqcD4 myGTAyT9VVmB5R/DEQdatwyc+mXuvGAx7YTEX+o3MPuZE/5VXFG+FgZZb21PZqWS UFae9YFY1AY6RHJi0APM5G5S8x6LHJJXtKo1wFgeKd8BjUeHS1l73qFpKeNzdN3g SCzCS/BGslE= =xw7Q -----END PGP SIGNATURE----- Distribution: CYPHERPUNKS >INTERNET:CYPHERPUNKS@TOAD.COM

1 0

remailer architecture (and signatures)
by tribble＠xanadu.com 03 Jan '93

03 Jan '93

First a brief description of the new (read not-yet-available) remailer architecture, then what's this means to signatures, etc. The new remailer design comes from the realization that mail systems are missing configurability on both sides of message delivery: when you receive mail, and when you send it. Most of the 'remailer' is just the infrastructure to allow programmatic modification to messages in those two phases of delivery. With this infrastructure, remailers are trivial to construct. There will be an Incoming Mail Rewriting Agent (IMRA) and on Outgoing Mail Rewriting Agent. The behavior of these agents is specified by production/rewrite rules (match a pattern and take corresponding action, possibly recurring) on the mail message they are processing. The incoming agent is much like the existing framework for remailers. It is invoked through .forward and handles mail before it gets to yout mailbox. The outgoing agent is invoked when you send mail to do any rewriting necessary then (such as encryption, signture, etc.). Note that .signature handling is a grody hack in existing mail systems that directly implements a rather uninteresting piece of outgoing mail rewriting (I had fun writing that :-). It should just be junked for the more general scheme, which can support real crypto signatures (and .sig files, of course) for pseudonyms, outgoing encryption, automatic remailer routing (a header: 'Hops: 3' that would route the mail through 3 remailers to the eventual destination), etc. It of course won't be junked immediately, but the default behavior of remailers should certainly not be to strip anything that looks like sigs. Can we guarantee that all the tools that produce ascii encodings like uuencode will never produce the trivial pattern that the remailers thinks means 'signature.' For example, hypertalk comments start with '--', just like signatures.

1 0

Re: Why mailers should not touch the body
by jordan＠imsi.com 02 Jan '93

02 Jan '93

All the more reason why the signature should be in the envelope (i.e. one of the headers in 822-land, in the p1? part for X.400, etc), not the body. Where did this convention of signing at the bottom come from anyway? /jordan

1 0