- cypherpunks-legacy - lists.cpunks.org

Atari PGP -is it available..
by ccat＠netcom.com 11 Jan '93

11 Jan '93

Does anyone know if there is a current version of PGP available for the Atari ST. Thanks!

1 0

Commie's
by Matt Willis 11 Jan '93

11 Jan '93

To this southern boy, it looks like the pinkos are slamming American (whoops, sorry, English) programming... :) "pgp in actual use is not recommended.", oh yeah, well our alphabet has more characters, so there... There were some interesting flaws that they pointed out... Could someone do a follow up and say what has been fixed in PGP version 2.1? If pgp cyphertext/encrypted data is predictable, I wonder how that would affect the "it'd take a Cray a year" figure? (or were the pinkos being overconfident) I actually like the Russians, but I'm just fulfilling my stereotype. peace :* +-------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

1 0

Chaining Pax and Penet.
by Hal 11 Jan '93

11 Jan '93

-----BEGIN PGP SIGNED MESSAGE----- From: Karl L. Barrus <barrus(a)tree.egr.uh.edu> > My original thinking was that once I established the id's in both > direction, when someone responded to anon.435@pax, they would be > allocated an id if they didn't have one. And since penet had by this > time seen anon.435@pax, no new id would be made, and the mail would > proceed on the me. The problem is this: when someone responds to your anonymous ID anon.435@pax, their mail _from_ Pax does not come from anon.435. Anon.435 is _your_ id. Instead, their mail from Pax comes from their own anonymous ID (possibly a newly allocated one). Then, when the mail goes to Penet, it sees this new "From" ID and allocates one of its own. The same thing happened when you sent to anon.435@pax from your system which already had a Pax ID. When the mail was forwarded from Pax to Penet, it was not marked as coming from anon.435. Instead, it was marked as coming from this already-assigned Pax ID. (I don't think you ever said what that already-assigned ID was.) Penet had not seen that ID before, so it allocated an alias for it and sent back to that ID. Penet's mail-back would _not_ go to anon.435, but rather to the Pax ID which it was replying to. Hal -----BEGIN PGP SIGNATURE----- Version: 2.1 iQCVAgUBK1F6D6gTA69YIUw3AQGMTAQAqXm7SdE6uyf+04J5GY3KU7dk7A2D7loC TeT+0UqpsSPOI+31YrJPww2h9XuwGylAZ9dqu/hPdolIzukjr+WiOKRyU34imezd iX9yYv3Ry3jCebcn9c79NY3zEQhjGh1LhqKmec5QLp3FjPB+gQZZypdaHz4GeDJF 4oDyArzKafc= =wZgY -----END PGP SIGNATURE----- Distribution: CYPHERPUNKS >INTERNET:CYPHERPUNKS@TOAD.COM

1 0

Politics of Rmailers
by norm＠netcom.com 11 Jan '93

11 Jan '93

Theodore Ts'o writes: If your mail system is broken enough that it inserts signatures without your permission, and you have no way to controlling it, it's broken. End of statement. Fix it or ditch it. 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 make this special point to illustrate a broader problem with remailers: They require operators of remailers to be sympathetic with the ends of the users of remailers. This obviously does not include the entire population for at least the recipient is not sympathetic. I suspect that technical solutions sought in recent mail will founder in presence of the politics of the operators of the remailers. I understand that routing your message thru at least one "friendly" remailer may be enough but if your reasons for using remailers are not sufficiently popular, then society, in some form, will pressure the friendly remailers to betray the sender without advance warning. 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. Barriers then arise. I think that the technical issues are only the tip of the iceberg.

4 7

both stripping and not
by tribble＠xanadu.com 11 Jan '93

11 Jan '93

With even current remailer architectures, it's trivial to simply have different services for normal remailing (which leaves body intact) and stripping services that grundge the message arbitrarily. When we really want anonymity, for instance, we will need message rewriting services that break the correlation between authors and writing style. A friend of mine looked into that material and claims that such analysis can do a depressingly good job at figuring out what messages were written byt he same author, even if the author tries to stilt his style. dean

1 0

No Subject
by Karl L. Barrus 11 Jan '93

11 Jan '93

Hal <74076.1041(a)compuserve.com> said: >My understanding was that everyone who tried to talk to him would get >two aliases assigned automatically. Actually, what I expected to happen was this: the acknowledgement of an anonymous id on penet for the anonymous id on pax would be generated, and this ack would be sent via the chain back to me (barrus@tree) since I established the chain. That is, I had linked anon.435@pax to an5022@penet to barrus@tree. Then, upon mailing to anon.435@pax from my other account (which already has an anonymous id established, so another would not be generated), the mail would proceed to an5022@penet, which would create an id and send it back to anon.435@pax. Now I expected this ack to then be turned right around, send to an5022@penet and then on to barrus@tree. So I was expecting the creation of another anonymous id, but the acknowledgement didn't go to barrus@tree. My original thinking was that once I established the id's in both direction, when someone responded to anon.435@pax, they would be allocated an id if they didn't have one. And since penet had by this time seen anon.435@pax, no new id would be made, and the mail would proceed on the me. Anyway, that was an experiment that seems to lead to explosive anonymous id growth :-) I agree with Matthew that not mailing back an ack would help cut down the flurry of mail, but it still results in all sorts of extra id's. I was hoping the whole thing would be like a pointer: mail to id1@pax forwards to id2@penet and then on to me with no extraneous account manufactured. But since we have our own cryptographically protected remailers, we cypherpunks can make our own remailing chains (Hal's constructed anonymous addresses). This way, you can decided on the path of your outgoing mail and your return mail: create the appropriate header, and attach your message on the end. To receive responses, just send a response header with the return path encrypted along with instructions to your recipient to cut the response header into a new file, add a message to the bottom, and mail to the appropriate remailer. (Note: I've used this method successfully twice, so it isn't too hard to do). Just remember that if your recipient doesn't have pgp, don't route your mail through extropia or their message will be blocked. If I get a chance I'll work on a program that will generate the appropriate header given routing input. /-----------------------------------\ | Karl L. Barrus | | barrus(a)tree.egr.uh.edu (NeXTMail) | | elee9sf(a)menudo.uh.edu | \-----------------------------------/

1 0

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