- 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 … [View More]

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 … [View More]

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 … [View More]

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 … [View More]

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.… [View More]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 | \-----------------------------------/ [View Less]

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/… [View More]

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 … [View More]

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 … [View More]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 [View Less]

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" (… [View More]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 [View Less]

1 0