- cypherpunks-legacy@lists.ogf.org

Cascading-Automatic aliases
by mjr＠netcom.com 10 Jan '93

10 Jan '93

Hal Finney: > I think it would be better to only provide anonymity when asked. Johan Helsingius: > It all depends on the intended target audience. I have to agree with Johan here, and with the way all (?) the Aserver creators/administrators have chosen to go. Consider the following scenarios, assuming that Person-X does not know anything about the particulars of the Aserver(s) he/she is routed through when making a direct *reply* to an anonymous message. A) Person-X doesn't care if he/she is aliased when he/she replies, but he/she is aliased anyway. consequence: Not much, the message still gets through (as would a re-reply, so if the Person-X *wants* to make his/her identity known later he/she can always state it in a message body). B) Person-X *wants* to be aliased in his/her reply, but *isn't* because the Aserver doesn't do it automatically, and person-X isn't aware that such a "switch" needs to be thrown. consequence: Potentially disasterous to person-X! I submit that automatic aliasing, by default, is consistent with the very purpose of Aservers, more exactly their intended, legitimate, uses! This doesn't mean that Aliasing software shouldn't contain some provision for turning ON a switch that passes you through un-aliased, but this switch should be for users who KNOW the server and how to modify its default behavior. I wouldn't object to such a switch, but personally I don't see much use for it either. Once I knew I wanted to reveal myself to someone, I could just tell him/her in a message body. If they want to reveal themselves to me, they can do likewise, and then we can address each other's machines directly, bypassing the Aserver(s). Now if these same creators/administrators would only *turn off* the automatic (default) message saying: "An alias [ALIAS####] has been created for you on Aserver(a)somewhere.in.the.world" the privacy of what seems to be a growing, potential, aliasing network (Anetwork) would be significantly enhanced. Reversing the default here would be consistent with the "most conservative assumption" approach otherwise already taken with respect to auto-alias. matthew rapaport Philosopher/Programmer At Large KD6KVH mjr(a)netcom.com 70371.255(a)compuserve.com

1 0

Politics of Rmailers
by mjr＠netcom.com 10 Jan '93

10 Jan '93

***** norm(a)netcom.com (Norman Hardy) ***** >I can imagine a system administrator choosing to require that >all mail originating from his machine include a signature that >correctly identifies the local name of the sender. I can too, but I suspect they wouldn't last long, particularly if they were commercial systems and their paying users felt that the anonymity option was something to be desired. I worry about institutional constraints much more, particularly at the national level "All machines on the Internet in this country will insure that mail originators are identified...", etc. Even this can be overcome technically though (smarter signature strippers). >This obviously does not include the entire population for at least the >recipient is not sympathetic. This isn't necessarily so. I can appreciate some other person's desire to remain anonymous in certain kinds of transactions. Also, people in other parts of the world seem much more sensitive to issues of privacy then we here in the US tend to be. >If society polarizes into camps then there may be remailers in >each camp. A remailer in one camp is unlikely to service messages >from the other. Well maybe, but this goes against the philosophical, political, and technical grain of the International Internet as it now exists. I note that the world already *is* polarized into camps to a greater or lesser extent. If there is eventual political and social fallout from the use of alias remailers, I think it would be more of an us (the Internet community who use remailers) vs. them (everyone else) kind of thing. I have detected murmurs of dislike for people who use remailers just on general principles (i.e. you should take responsibility for what you say). matthew rapaport Philosopher/Programmer At Large KD6KVH mjr(a)netcom.com 70371.255(a)compuserve.com

1 0

Trailing blanks in PGP
by Hal 10 Jan '93

10 Jan '93

Edgar points out that PGP prepends a "- " string to every line that starts with "-", and suggests that it would not be much further to go to strip trailing blanks. While I sympathize with the problems Edgar and others have with trailing blanks messing up signature checking, it turns out that the "- " quoting is done at a different stage of the processing than signature checking. When a signed message is created, it is first "canonicalized", which presently means only that each line is made to end with a carriage return line feed. The signature is then calculated on this form. For the cleartext signature, the message is then wrapped in the "-----BEGIN PGP MESSAGE-----" lines, and the quoting of lines starting with "-" is done. As Edgar surmises, this quoting is so that the end of the message can be accurately located, even if the message contains lines like "-----END PGP MESSAGE-----". On the receiving end, the message is first stripped of the -----BEGIN and -----END lines, and the "-" quoting is undone. The resulting message is then canonicalized (so that lines end with CRLF's) and the signature is calculated and checked against that sent with the message. Space stripping could be done fairly easily in the "unwrapping" process, along with the "-" de-quoting, as Edgar suggests. But it would still fail if the user signed a message which ended a line with a blank. In fact, if he ever did sign such a message, and the de-quoting routine were enhanced to strip trailing blanks, the message would always fail the signature check, because that necessary trailing blank will be gone. What really needs to be done is to change the definition of a "canonical text" message. Presently it only specifies CRLF line terminators. It would have to be enhanced to specify also that no spaces precede any CRLF. If this were done, then the canonicalizing process done at both ends would strip the trailing blanks before calculating the signature, and therefore trailing blanks would not affect the signature check. Presently, PGP "knows" that on a PC, canonical text form is the same as regular text form. That is because CRLF is the normal line terminator on a PC. So, canonicalizing is skipped on the PC, which speeds up signing and verification on this class of machines, which include some of the slowest on which PGP is run. Adding blank-stripping to the definition of canonical text means that all messages will have to be canonicalized on PC's, thus adding an extra processing pass which is avoided now. So there is some cost in doing this. There are also some compatibility problems, in that old signed messages which had trailing blanks would no longer signature-verify if we changed the definition of canonical text in this way. However, there probably aren't that many such messages, so this may be a tolerable cost. I do think we should consider making this change, as many people have complained about it. Hal Finney 74076.1041(a)compuserve.com Distribution: Cypherpunks >INTERNET:cypherpunks@toad.com

1 0

Delimiting text body in ARA
by edgar＠spectrx.Saigon.COM 09 Jan '93

09 Jan '93

On Jan 5, Hal commented on my suggestions for ARA using a Miron Cuperman remailer. > 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. I think "many mail agents" at least the one at this location, make it downright impossible to put an ARA into the header. Especially a chained ARA, which is part address and part body (to all except the last remailer in the chain). I think we are better off writing tools which will work now on the worst common denominator of mailers, rather than insisting that the world change so our solutions can be more elegant. Note that the user of an ARA is likely to be less computer & e-mail literate than the person he is responding to. It's easy to specify, to reply, mail to the [first remailer address]. Put this encrypted ARA block first in your message body, followed by your reply message enclosed in -----BEGIN MESSAGE BODY----- -----END MESSAGE BODY----- Only the text between these two delimiter lines will be received by the original sender, so your anonymity will be protected too. Note that this elegantly takes care of discarding the automatic sig of the responder, if any. Some here, like Richard Childers, don't want to protect users who might not understand that they need to suppress their automatic sig to maintain their anonymity with a remailer. People who run remailers have to be pretty gutsy anyway. They may get sued by disgruntled recipients of abusive or threatening anon msgs. It seems to me they don't also need to risk being sued by disgruntled message senders (or responders) who are embarassed (or worse) by inadvertantly revealing their identity in what they intended as an anonymous message. Note that your average civil jury is not going to be terribly computer-literate. Even a suit which loses is going to cost a lot to defend against. As to Hal's other suggestion: 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. Sound's like a good idea, but it's not going to save anywhere near 1/3 (4/3 - 1), at least with PGP, since (recall) PGP (at least by default) compresses before it encrypts. -- edgar(a)spectrx.saigon.com (Edgar W. Swank) SPECTROX SYSTEMS +1.408.252.1005 Silicon Valley, Ca

1 0

Trailing blanks in signed plaintext
by edgar＠spectrx.Saigon.COM 09 Jan '93

09 Jan '93

-----BEGIN PGP SIGNED MESSAGE----- Distribution: Cypherpunks <cypherpunks(a)toad.com> Branko Lankester <lankeste(a)fwi.uva.nl> I noticed something about PGP signed plaintext the last time used that feature to send a message to Cypherpunks. Apparently PGP takes any line beginning with 5 dashes ("-----") and adds "- " (dash blank) to it. I guess the purpose for this is to avoid confusion if the plaintext message should contain a PGP delimiter like -----BEGIN PGP SIGNATURE----- But in my particular case, what I specified in my input plaintext was -----END OF MESSAGE BODY----- (but with no indentation), but what came out was - -----END OF MESSAGE BODY----- Given that PGP is going to make changes like this to signed plaintext, I suggest there is no longer any reason to object if PGP also removes trailing blanks from signed plaintext. -----BEGIN PGP SIGNATURE----- Version: 2.1 iQCVAgUBK02ta94nNf3ah8DHAQFX8wP/dyusrml+2XH7XQtFcsQveGW3Zz3ib6K9 xGGV2hnvhwIHbFs4HIKTIVT0BFR6Y4SuqFMeF0BS16FIu47GmW8Q55iIhweDP7x5 +CUMXSynwQsz4XOMU/CpqNAwJifNoM9BwNu+RqfhIxwi6KxO1i3FwJjxPzE+uHkh Y7Mjl7Ytkd0= =0l/6 -----END PGP SIGNATURE----- -- edgar(a)spectrx.saigon.com (Edgar W. Swank) SPECTROX SYSTEMS +1.408.252.1005 Silicon Valley, Ca

1 0

Cascading Aliases
by mjr＠netcom.com 09 Jan '93

09 Jan '93

The discussion just above between Karl, Hal, Johan, and myself, has made me realize that the standard "bounce back" behavior of all the alias servers I've used so far actually defeates the purpose of remailer chains no matter how one embeds the forwarding information. When any person *first* replies to or originates mail across a remailer chain, a new alias is generated at each hop (however many). So far, that is good, a "most conservative assumption" approach, and it provides easily for reply channel maintenance. The problem is that each machine also reflects its new alias back along the chain to the message originator thereby revealing the entire chain to the message originator, something that might not be desirable to the party on the other side. The solution is very simple, just stop bouncing the new alias information back along the chain. This can not HURT anyone using the alias/remailer system because you never need to know what your aliases are as the conversion and forwarding process is automatic. If someone needs, for some reason to KNOW his alias for a given system (or all of them) on *his/her* chain, he/she can easily arrange to ping the server at the appropriate level. Besides not hurting any current operations, Stopping the *automatic* reply to sender about a new alias helps to secure everything a great deal more because it hides the "other guy's" chain, something that both parties might reasonably expect. matthew rapaport Philosopher/Programmer At Large KD6KVH mjr(a)netcom.com 70371.255(a)compuserve.com

1 0

New remailer in C.
by Hal 09 Jan '93

09 Jan '93

-----BEGIN PGP SIGNED MESSAGE----- From: nowhere(a)bsu-cs.bsu.edu (Chael Hall) > Fellow Cypherpunks: > > I am working on a program in C that will provide both anonymous > remailing capabilities and mail server operations. It's good to see more people working on remailers. The cypherpunks remailers have been written in Perl, which facilitates experimenting and testing of new interfaces. The idea might be to migrate them to C eventually for efficiency, but during this experimental phase we may want to try out new ideas, and it's easier to modify a Perl script than a C program. > If you cannot add your own header lines with your mailer, set > the subject to contain "Request Remailing" and use the following format: > > :: > Request-Remailing-To: user@host > Subject: Anything you choose > :: > > Any of the following fields can be placed within the "::" delimiters: > > Request-Remailing-To: > X-Anon-To: > Subject: > > The remailer is case insensitive and you can place the "::" lines > anywhere within the message. This is somewhat similar to the cypherpunks remailers; however, they accept the :: only at the beginning of the message, allow any fields to be put there that the user desires (not just those three), and terminate the block by a blank line. Does your alternate system have some advantages? > I forgot to add: If you are chaining remailers, you can use the > sequence "+::+" at the beginning of the line to pass the remaining characters > on that line through the remailer untouched. I do find the use of this string to produce rather complicated looking commands. The cypherpunks remailers get the same effect by just putting in blocks starting with :: and separated by blank lines: :: Anon-To: anon(a)anon.penet.fi :: Anon-To: nowhere(a)bsu-cs.bsu.edu This looks simpler to me. Hal Finney 74076.1041(a)compuserve.com -----BEGIN PGP SIGNATURE----- Version: 2.1 iQCVAgUBK05WUagTA69YIUw3AQGpaAP+LxpocNUI1/Zw3DAwwAxeKBtdj0sSyx8p 05xnI3FmklosxapVpcF/aVkDKL/FjzwBZ9ML5wt2m7UvqS1iX9UILQByPNAxTOKF TIuFKkjt2wT5ykvHRGLl6ZAB6w6PzkNiclHNJw4FFEaFzoxmnz3bQXatKBFFgGFd IjIMFF0d0Ig= =ztz0 -----END PGP SIGNATURE----- Distribution: CYPHERPUNKS >INTERNET:CYPHERPUNKS@TOAD.COM

2 1

Cascading Aliases
by mjr＠netcom.com 09 Jan '93

09 Jan '93

****** Hal <74076.1041(a)CompuServe.COM> ***** >My understanding was that everyone who tried to talk to him would get >two aliases assigned automatically. Yes I suppose, but I can ignore them. Let's see if I got this right. In the following scenario, I will represent alias servers and their aliases in the following way: A-123 where 'A' is the server, and '123' is the alias. I receive a message from Z-999. I have no idea how many servers this has gone through. I *originate* a message back to this person, but I sent it first through *my* preferred alias chain, so the message goes from me through A-123 -> B-456 -> Z-999 and then somewhere else (perhaps) before reaching its final destination. Now the Z server has never seen a message from B-456, so it automatically generates a NEW alias (Z-111) for that ID. Now machine Z bounces that new alias back along the chain B-456 -> A-123 and thence to me, informing me that an alias has been established on machine Z for my ID on machine B. It also uses that alias to send the message along to the next machine on the chain (if there is one) which also creates a new alias (never having seen a message from Z-111), and bounces it back, etc. I see that this is where I get to detect the alias path my recipient is using, but there is an easy solution (see below). So one or more new aliases will be generated (you are correct) in response to my original mail, BUT, I can ignore those aliases (once I receive them in the reflected mail) and never need think about them again because the link between B-456 and Z-111 is now established. Further translation will take place automatically with no further bounce backs in any future correspondence between the two parties *if* they both use their own chosen mail paths consistently. If in my next mail, however, I REPLY to Z-999 (i.e. I don't generate original mail), then another alias will be generated on the Z machine for mjr(a)netcom.com and I will also be informed of that, etc. Once again, however, I don't have to care about that. From the recipients viewpoint, however, mail has now been received from two different aliases that represent the same person (one for my original mail, and one for my REPLIES) There are two possible solutions while still generating automatic aliases: 1) Don't alias someone who hasn't specifically requested it (e.g. with a ping or something). This is probably not a good idea. I like the fact that these Aservers take a "most conservative approach" automatically assuming that someone wants to be aliased if they are originating/replying to an aliased ID. 2) Stop the alias-information-bounce-back unless someone specifically requests it (e.g. with a ping). This might do the trick. I don't have to KNOW what my alias number is even on the machine that does the first outbound and last inbound conversion. All the conversions along the chain are automatic, so why should I care what my alias numbers are? matthew rapaport Philosopher/Programmer At Large KD6KVH mjr(a)netcom.com 70371.255(a)compuserve.com

1 0

Russian analysis of PGP
by karn＠qualcomm.com 09 Jan '93

09 Jan '93

Anybody familiar with the internals of PGP care to comment on this item that just showed up on sci.crypt? It's amazing to think that the famous "kremvax" joke was only a decade ago. Now the Russians are openly reviewing our cryptosystems for us. May you live in interesting times. Phil

3 2

Chaining addresses...
by Hal 09 Jan '93

09 Jan '93

-----BEGIN PGP SIGNED MESSAGE----- From: mjr(a)netcom.com (Matthew Rapaport) > >I think the lesson is that this process of automatic alias assignment > >may not be the best way to handle things... look at all the problems > >Karl ran into. > > If I understand Karl right, he got this cascade of aliases because he > tried to talk to HIMSELF through different accounts/aliases at alternate > ends of the chain. Since no one would want to do that (other than to > test things) normally, this wouldn't be a problem. My understanding was that everyone who tried to talk to him would get two aliases assigned automatically. Karl made the problem worse by talking to himself from two different addresses, but you're still talking about a lot of aliases. > >I still lean towards the idea of a "constructed" anonymous address, > >where I decide ahead of time which remailers I'll use, and in what > >order. > > But I already *do* control the order of use for MY mail, that means > stuff I send out and stuff people send to me in DIRECT reply to my > stuff. There is nothing to stop someone from sending to my id on pax say > through a first remailer of their own choice, provided they originate > the mail (i.e. a REPLY is not equivalent to ORIGINAL mail in this case). OK, so you can set up an anonymous address which, say, goes through pax and then penet and then to you. If someone replies to that address, they will be anonymous to you, by default; their anonymous address will go through penet and then pax. But if they didn't want that anonymous address, they could use one of their own (say, rebma to soda to themselves) first, then go to your address. Now when you reply to them, I guess your message will go through penet, then pax, then rebma, then soda, then to them. My feeling was it would be better if they could put a Reply-To: into the message that just meant to go to rebma then to soda to themselves, and get that Reply-To: to go through the pax-to-penet chain to you. Also, they would not get anonymous ID's assigned by penet and pax, ideally. Instead, you would reply to them using this Reply-To address and go through just rebma and soda to get to them. This will be simpler and faster than having all messages go through the union of both communicant's anonymous address chains. > As for picking my own alias, this sounds appealing but is actually much > weaker then a randomly assigned one. Besides that, it could be an > administrative nightmare for the sysadmins on the aliasing systems. I wasn't really talking about picking my own alias. It is more a matter of having a straightforward way to construct an anonymous address that goes through the specific chain of systems that I choose. Hal Finney 74076.1041(a)compuserve.com -----BEGIN PGP SIGNATURE----- Version: 2.1 iQCVAgUBK05Wa6gTA69YIUw3AQFy+QP/RAepMQETJWqM7szQ9ID0TAgrIvQc8ArH MX6S14lzb492skAIathLYllfyhN2TTO/gN+lCC4lvnzs9UOLJ2rlNzFxT8geV1yx MxKKzIZ39tMmyCXHx2cnH7ySHMoEVzp5TqXqQhEbmqn0k6c7hoL+sz6l43/g6rPL g++F+kRs2nQ= =0OfU -----END PGP SIGNATURE----- Distribution: CYPHERPUNKS >INTERNET:CYPHERPUNKS@TOAD.COM

1 0