- cypherpunks-legacy - lists.cpunks.org

Phil Z Comments on ViaCrypt
by edgar＠spectrx.Saigon.COM 05 Sep '93

05 Sep '93

I received the following comments on ViaCrypt from Phil Z. Reposting here with permission. I'll try to forward a summary of your comments. ==================================================================== Subject: Re: Your visit To: spectrx!edgar (Edgar W. Swank) *Edgar* Date: Wed, 1 Sep 93 20:40:08 MDT From: Philip Zimmermann <szebra!columbine.cgd.ucar.EDU!prz> Hello Edgar. Thanks for your hospitality. I enjoyed our conversations during my visit. The PKP/Viacrypt contract requires that ViaCrypt use THEIR OWN RSA cryptographic engine, not PKP's or RSADSI's. I will be working closely with them to ensure that they do a good job on that. Actually, RSA calculations are fairly straightforward, and it's hard to screw them up. I will probably try to get them to stick with my own keygen routines, if they are allowed to use them in the PKP contract. The keygen stuff would be the most important place to look for any security holes. My discussions with ViaCrypt's president, Lenny Mikus, and his programming staff, suggest to me that they are genuinely interested in making a very secure product. It's possible, I suppose, that maybe I could talk to ViaCrypt about maybe publishing the source code for the rest of ViaCrypt PGP, minus the RSA engines that the PKP contract won't let them publish. We'll see. The current plans are for them to use the straight PGP source code with no changes except for using their own RSA engines. So publishing the source code would not yield many new insights anyway, since it's the same. Other than as a confidence builder, which is nice to have. You may repost this to cypherpunks if you wish. Phil -- edgar(a)spectrx.saigon.com (Edgar W. Swank) SPECTROX SYSTEMS +1.408.252.1005 Cupertino, Ca

1 0

Re: Remailer Reliability
by doug＠netcom5.netcom.com 05 Sep '93

05 Sep '93

sameer(a)netcom.com (Sameer Parekh) >install-script I can add this little feature. Which newsgroup? Should >someone create an alt.remail? How exactly would it be implemented? I'm >thinking that simply the user would do: > [...] > And the remailer would post to alt.remail: There are two problems here. One is that the remailer exposes itself and defeats traffic analysis avoidance. The other is a standard transaction processing sort of problem; the posting to alt.remail might fail even though all else worked. Although I've dealt with transaction processing problems, it's a tricky area, and I don't have a good text on the subject. Any recommendations? b44729(a)achilles.ctd.anl.gov (Samuel Pigg) said: >By breaking a message into pieces and sending them via different paths >to the same destination ("path forking"), this can only make traffic >analysis easier, because all the pieces lead to the same destination, >and you can follow any of them to get to the anonymous recipient. Depends on how it's done. As stated this analysis implies that traffic analysis is *always* possible, since after all, the message must somehow make it to its destination. In other words, I disagree. Traffic analysers will have access to only some limited subset of information. If a certain kind of blind remailing with multiple pathways is practiced, then traffic analysis can be statistically defeated. The bad guys might sometimes know that X sent a message somewhere. Other times they might know Y received a message. Only improbably (under ideal implementation circumstances) would powerful bad guys own so many machines & networks that they would be able to deduce both sender and recipient, and even then, if traffic were heavy (as it will be in some years), it would be a statistical rather than certain deduction. (This of course raises the (no doubt old-hat) problem that no single remailer can be trusted, since it might be in the hands of the NSA or KGB or something. In fact, since the NSA is famous for doing their job well, this list must have NSA watchers, no question, even without paranoia, and if I were them I'd be experimenting with remailers even now, to keep up with trends. We'll never know how many remailers are trustworthy, so we'll have to use statistical schemes to make compromise unlikely.) This is all standard parallel remailing stuff. Add to this the possibility that the different remailing paths may contain message fragments rather than full messages, and it doesn't really change the security relative to full message parallel remailing...unless it's done badly. Badly would mean that some remailer is the one that finally recombines fragments prior to final delivery. Better is if the recipient's host does the recombination (and I worry about *that*, too). This needs to be done in conjunction with other standard cypherpunk fare, of course. The major design problem I've had is not with security, it's with fault tolerance. Statistical fault tolerance is available, but I prefer leaving that kind to the underlying base systems and networks, and trying to find a top level algorithm that is 100% guaranteed to either work or report failure, so long as the host systems/networks don't fail undetectably. A handshake ACK of receipt would help, except that it might not get back even if the original reached its destination. Which is why I'm starting to think I need to research transaction processing more thoroughly; some years back I'd heard that a centralized server was still state of the art for 100% fail-safe/soft operation. Is this still the case? If so, then we'll have to fall back on probabilistic fault-tolerance, to avoid issues of central authority compromise. >follow them all), as only one will arrive there and the rest would die >after a number of remailer hops. This is actually less safe than an approach which requires multiple pieces to arrive via multiple paths. Bad luck might leave your one path completely in the hands of bad guys (posing as cypherpunks, let's say). >I really think that non-deterministic "smart messages" are the way to >go here. This I agree with; but the way that is done is critical. >A simple command language for the remailers would allow >the header construction software already being worked on by >ebrandt(a)jarthur.Claremont.EDU (CRM) and others to use tricks >like this to defend against attacks. Cool. More info? > The defense complexity would be a function of the users' >header construction software and needs. People who need "minimal" >anonymity would have simpler anonymous address blocks, as compared to >those who require "serious" anonymity, and the remailers themselves >would have a lighter load (not having to implement very serious >security for *all* messages-- just those that need it). Strongly agree. BTW I consider this emphasis on batch mail to be short sighted. I'm designing for interactive cyberspace. I have a complete algorithm in mind, except I think it still needs some more OLTP wisdom added in. People have been telling me for a long while that I should hook up with cypherpunks; seeing traffic over the last week since I joined shows me why I heard that from so many sources. Tip of the hat to y'all; this is a much juicier forum than I had guessed. I only hope I can continue weathering the storm of heavy traffic, on top of other email lists. :-) Doug

3 3

CRM (again)
by nobody＠shell.portal.com 04 Sep '93

04 Sep '93

-----BEGIN PGP SIGNED MESSAGE----- (Note: this was sent through a remailer, and the return address is inaccurate. My address is astrashe(a)nyx.cs.du.edu.) | I'm not saying that CRM actually uses a command language (it can't-- | nothing has been agreed upon/worked out yet!) but tools like CRM | would be able to use a remailer command language to tailor the | message's (or anonymous address block's) anonymity protection. | See that same long, boring post I made about a few suggestions | for what such a language could contain/be useful with. CRM doesn't do anything grandiose. All it does is pick a random path of a specified length from a list of remailers, and wrap up an input file with remailing requests, encrypted PGP tags, and nested PGP encryptions. For example, if you start out with a file like: - -+---snip----- Subject: Just a test... I'm going to wrap up this file with CRM and make a /bin/sh script that will mail it to myself through a chain of remailers. - -+---snip----- and do one of these: c:\>crm infile astrashe(a)nyx.cs.du.edu you'll end up (with no further intervention on your part) with the /bin/sh script that's at the end of this post. If you run that script, it will mail the above short note to me through a chain of three remailers. Each of the remailers gets PGP encrypted input. The subject line will show up as the subject on my mailer. (Please don't run the script; my mailbox is full enough already.) The reason I had CRM wrap the final output in a script is that because the chain of remailers is random, the first remailer in the chain varies each time CRM is invoked. This way you don't have to worry about keeping track which one to mail the cyphertext to. This is obviously more of a hassle than using elm to send your mail; but if you're already writing letters offline and uploading them (which you ought to be doing anyway, to take full advantage of PGP's protection), it's only marginally more difficult than mailing stuff without the remailers. And it could be argued that it's *easier* to use CRM and the remailers than standard mailing, because the shell script keeps track of the subject lines and the destination for you. You could write ten letters, wrap them with CRM, keep concatenating the new scripts onto a outgoing mail file, then upload the whole thing at once and mail it in one fell swoop. If you want a copy of CRM, let me know. (Write to astrashe(a)nyx.cs.du.edu, not the return address on this post). It's an msdos program, written in turbo pascal. - -+---snip----- #!/bin/sh # # This is a shell script produced by CRM. # sed -e '/^BEGINCRM/d' -e '/^ENDCRM/d' << \End_of_File > crm.tmp BEGINCRM :: Encrypted: PGP - -----BEGIN PGP MESSAGE----- Version: 2.3a hIwCPhjICRQCw4kBBACpc6PDQEH8FR03Y1nO1IgMiG/ypCqe9c4oFcZzmx8jQaJ+ hDLpM5VcCHCGEQJUcmd0i3FCOFw1qKsWY612BdYMETPGpfDvK7SOqTmzBESF/NHE VhYgUuk06AYlhpcH5hNZ85DDXJLVLL7EJ/sLWy2mmV0p3CrIHK0aljddQmPbbKYA AAL0GwZ1Z+1XUvIhKpyk2W4l2fbrGdfflox5TQy8MuBkgSAxelm5DNNdYz7IDD5w G1X0G/YETmOs//7u7xL8gPAx2dYUi2raLSCXJ941Y4FtRc2W2Eci4M0uiDIYbTNT 45YBFW+emw6jawLvwKj5jlF2QAqn/6wuT1Px+azZSS39z8jyzcClhEEaEQSGBGcg o1NpSR6Bk9myQG5hEezB7j92s+D6D6APkTtc/LgyX/UG3jkCt86dbrhljoGQcIku NDS2lWHEJEXUJ4I/QwL8gwZLKcVkyxW1h8GB1Y8/LjfhnrjQXjig1jumPqbzOmBu 1u4exeV/kFADW2iDq8trjzkcBI7k/xGljtkaR1I9lVhIimyMz8bUr1WYuUte5u4P 4SxK9lSdS8TnK4pDwaubDL41aZ4eERNxuquerXbH1x3L7eDbUuerSI+vCM4uinWS c/ZDsIGYc0xgNzg4bq9ji04KK/FA6Y5HsnKAkdNV2V65GaNxk8IwAlkSQBygvf0R kdwOkJ+Y1L+k05lkI7N5AXOF+5cZQMw2oZElsF9pvbflzRIkJJBn+//Zx9cDJE6I SaISCg/c/DFeuH21zyv06Xrs8kRvX7183dD6I40RuGx5pg5eOalbBZFTqda5PV6w C6jtv2GxjfNYmOFLo/7uRpscrfAr2APvdR6/cTfb869tR22DcfYUOI5COxU0VH++ Lwq5Z6wVykrYWSZbUePO0MjzzRWCnAYOdlbJN0qFJXceNSKKIjYwZR/M4HlUTwYn 14jIfgvekaKWXL2ydk11S2eCPl9GrbNyptJUSjVteMFO333xjeoPMKST/yybvVsH JTlKy0XfmV3jUzjiOxy2yCLxeTJRjXFK8gKtIPpgfD1TEYdBELDTbQSbqm0f4aWE uHFEMI59IHPS0Dunu+Yn2QNyCw0NJbvclBUyYqrRFMyPT8R4V8qECYwZtcHbtP2z eJxRlQNx43GHfS5GxgQdJGB4Urb0y3AhsuEm+gWYoX6xuJSQ+GRX =42WF - -----END PGP MESSAGE----- ENDCRM End_of_File mail remail(a)tamsun.tamu.edu < crm.tmp rm crm.tmp - -+---snip----- - -+ Alex Strasheim | astrashe(a)nyx.cs.du.edu | PGP public key available via finger -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLIj1fLGKvmrRrQghAQEniQP7BSeTbv9NtzMFAryrXAH0l6HdQ6dFTgxK AdWGts1zxGhJxoBO+ULwnaApuVgJoFz9iKEJ5GWWjpvs6f4tlG69MiTrb6vTW+0+ H8ceNIC15uyUWQR0fyy28SqgQhQLB2Ys3Y54fPDU5kvZKxa6hi38ZY6hTIg4b8BY 6zWwiGnJI2w= =kQ9/ -----END PGP SIGNATURE-----

1 0

Denning and the cost of attack against SKIPJACK (fwd)
by nobody＠shell.portal.com 04 Sep '93

04 Sep '93

(forwarded from sci.crypt) On page 14 of the August 30, 1993 issue of Government Computer News Kevin Power reports that Dorothy Denning told the Computer System Security and Privacy Advisory Board that SKIPJACK would not be compromised by exhaustive attack methods in the next 30 to 40 years. I am reminded of a story, perhaps apocryphal. In the middle seventies Fortune magazine was working a feature on computer crime. Most of the experts that they interviewed told them that the security on most of the nation's commercial time sharing systems was pretty good. However, they admitted that one convicted felon and hacker, Jerry Schnieder, would tell them otherwise. Of course Fortune had to interview him. According to the story, the interview went something like this: Fortune: Mr. Schnieder we understand that you are very critical of the security on the nation's commercial time sharing systems. Jerry: Yes, that is right. Their security is very poor. Fortune: Could you break into one of those systems? Jerry: Yes, certainly. Fortune: Well, could you demonstrate for us? Jerry: Certainly, I'd be happy to. At this point Jerry took the reporters into the room where his "Silent 700" terminal was. He connected to the system that he normally used but deliberately failed the logon. When he deliberately failed again at the retry prompt, the system disconnected. Jerry dialed in again, failed a third time, and this time he broke the connection. He dialed a third time but this time he dialed the number of the operator. Jerry: This is Mr. Schnieder. I seem to have forgotten my password. Can you help me? Operator: Sorry Mr. Schnieder, there is nothing that I can do. You will have to call back during normal business hours and talk to the security people. Jerry: I am sorry too, but you do not seem to understand. I am working on something very important and it is due out at 8am. I have to get on right now. Operator: I am sorry. There is nothing that I can do. Jerry: You still do not understand. Let me see if can clarify it for you. I want you to go look at your billing records. You will see that you bill me about $800- a month. This thing that I am working on; it is why you get your $800-. Now, if you do not get off your a-- and get me my password so that I have this work out at 8am, by 9am there is going to be a process server standing on your front steps waiting to hang paper on the first officer through the door. Do I make myself clear? Apparently he did. Operator: Mr. Schnieder, I will call you right back. At this point he appears to have one or two things right. He changed the password, called Jerry back at the number where his records said that he should be, and gave him the new password. Jerry dumped two files and then turned to the reporters. With a triumphant smile he said "You see!" Fortune (obviously disappointed): No, No, Mr. Schneider! That is not what we wanted to see. What we wanted to see was a sophisticated penetration of the software controls. Jerry: Why would anybody do THAT? __________________________ The cost of an exhaustive attack is an interesting number. It gives us an upper bound for the cost of efficient attacks. However, it is never, itself, an efficient attack. It is almost always orders of magnitude higher than the cost of alternative attacks. The very fact that its cost can be easily calculated ensures that no one will ever encrypt data under it whose value approaches the cost of a brute force attack. History is very clear. "Black Bag" attacks are to be preferred; they are almost always cheaper than the alternatives. After those are attacks aimed against poor key management. These attacks will be very efficient when the keepers of the keys already work for you and where their continued cooperation and silence are assured. William Hugh Murray, Executive Consultant, Information System Security 49 Locust Avenue, Suite 104; New Canaan, Connecticut 06840 1-0-ATT-0-700-WMURRAY; WHMurray at DOCKMASTER.NCSC.MIL

1 0

REMAIL: list
by Karl Lui Barrus 04 Sep '93

04 Sep '93

-----BEGIN PGP SIGNED MESSAGE----- Q1: What cypherpunk remailers exist? A1: 1: nowhere(a)bsu-cs.bsu.edu 2: hh(a)cicada.berkeley.edu 3: hh(a)pmantis.berkeley.edu 4: hh(a)soda.berkeley.edu 5: 00x(a)uclink.berkeley.edu 6: cdodhner(a)indirect.com 7: hal(a)alumni.caltech.edu 8: ebrandt(a)jarthur.claremont.edu 9: remailer(a)rebma.mn.org 10: elee7h5(a)rosebud.ee.uh.edu 11: hfinney(a)shell.portal.com 12: remail(a)tamsun.tamu.edu 13: remail(a)tamaix.tamu.edu 14: remailer(a)utter.dis.org 15: remailer(a)entropy.linet.org 16: remail(a)extropia.wimsey.com NOTES: #1-#6 no encryption of remailing requests #7-#15 support encrypted remailing requests #16 special - header and message must be encrypted together #9,#14,#15,#16 introduce larger than average delay (not direct connect) #9,#14,#15 running on privately owned machines ====================================================================== Q2: What help is available? A2: Check out the pub/cypherpunks directory at soda.berkeley.edu (128.32.149.19). Instructions on how to use the remailers are in the remailer directory, along with some unix scripts and dos batch files. The public keys for the remailers which support encrypted remailing requests is also available in the same directory. Mail to me (klbarrus(a)owlnet.rice.edu) for further help and/or questions. -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLIOvDYOA7OpLWtYzAQGbDQQAvnyZ9XpGUntp483/trZQwyIb74jJEGgR ZpWwPWAlp2j3Vp1WW2JcnvHXIfVtU9r8g22JErwDalgq00NdXIrqIpf5ZllbXfQA XwNoq6hqeECeKtRG/nwc1NeLejFfi1QhA+tjL8yLbyvcZ+bawLbd58NmE7AODUK2 2vuRnYtz+WM= =xnSQ -----END PGP SIGNATURE-----

6 6

Gubment Bombmaker's Cookbook
by Reply to: hahn＠lds.loral.com 04 Sep '93

04 Sep '93

Several days ago I made a post in response to the gentleman in Hartford's difficulty with the law. His problems stem from someone's posting to his BBS recipe(s) for bomb making. I mentioned, offhand, that a federal government publication exists containing such recipes. Mike Godwin responded asking for a citation, that it might be useful to the defense. OK, here it is: TM 31-210 Dept. of the Army Technical Manual Improvised Munitions Handbook published 1969 It contains chemical recipes for about a dozen explosive materials (both primary and secondary explosives) from easily obtainable ingredients, along with designs for fusing devices and explosive booby-traps. I have never tried any of these (to paraphrase Shel Silverstein, my eyes still see, my hair's unburned, and my fingers are still on my hands -- and I'd like to keep it that way), but my knowlege of chemistry and engineering convinces me that they all work. The book contains the disclaimer "For official use only" on nearly every page. It is, however, widely available at gun shows, which is where I got mine. I'll not reproduce any recipes here, but if the defence attornies for the gentleman in Hartford contact me and can prove who they are, I will be happy to share any info with them. __ | (V) | "Tiger gotta hunt. Bird gotta fly. | (^ (`> | Man gotta sit and wonder why, why, why. | ((\\__/ ) | Tiger gotta sleep. Bird gotta land. | (\\< ) der Nethahn | Man gotta tell himself he understand." | \< ) | | ( / | Kurt Vonnegut Jr. | | | | ^ |

4 3

Re: remailer reliability
by M..Stirner＠f28.n125.z1.FIDONET.ORG 04 Sep '93

04 Sep '93

Uu> C'punks, it seems to me that the anonymous pool idea is underutilized Uu> by the remailers. I suggest that a remailer variation be developed Uu> that posts to an anonymous pool (some appropriate obscure newsgroup) Uu> indicating that a message actually was sent from the final hop. I'm not absolutely clear on what you are suggesting, but I suspect that alt.test can probably be made to serve your purposes. Before the password mess on penet (which kills automagic replies, unfortunately, as they haven't passwords), I used the autoreplies that come form various US & foreign sites in response to alt.test postings as a good shakedown of penet remailer reliability. I haven't messed with alt.test in a while so have pretty much forgotten the drill, but it was definitely useful at the time. ********************************************************************* * <m..stirner(a)f28.n125.z1.fidonet.org> - PGP Key D30909 via servers * * > What country can preserve its liberties if its rulers are not <* * > warned from time to time that their people preserve the spirit <* * > of resistance? Let them take arms!" - Thomas Jefferson, 1787 <* ********************************************************************* ___ Blue Wave/QWK v2.12 -- M. Stirner - via FidoNet node 1:125/1 UUCP: ...!uunet!kumr!shelter!28!M..Stirner INTERNET: M..Stirner(a)f28.n125.z1.FIDONET.ORG

2 1

No Subject
by anonymous＠extropia.wimsey.com 04 Sep '93

04 Sep '93

> ld231782(a)longs.lance.colostate.edu (L. Detweiler) writes: >C'punks, it seems to me that the anonymous pool idea is underutilized >by the remailers. I suggest that a remailer variation be developed that >posts to an anonymous pool (some appropriate obscure newsgroup) MC> No need to change anything. Just add a pool address to the MC> "Request-remailing-to:" line. MC> Miron Cuperman <miron(a)extropia.wimsey.com> Excuse me if I am misunderstanding the "obscure newsgroup" concept, but is not the "Request-Remailing-To:" feature of cypherpunks remailers unable to post to newsgroups, but only to individual or mailing list addresses? I have been told that only Penet's remailer could remail directly to newsgroups, obscure or otherwise. Thanks for any clarification.

2 1

JEROME SCHNEIDER
by Sandy 04 Sep '93

04 Sep '93

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ SANDY SANDFORT Reply to: ssandfort(a)attmail.com . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Punksters, Just a few comments about Jerome Schneider. In addition to the piece in /Fortune/ magazine, there was also a segment done on him by "60 Minutes." During that show he did an impromptu telephone hack for the "60 Minutes" interviewer. At the end of the segment when Schneider asked if he had gone straight, he answered "yes." But when he was asked how we could be sure of that, he replied, "you can't." Such a kidder. Contrary to the mythologized version of his computer crime career, Schneider was not that technically competent. What he was good at was bribing telco employees to get equipment ordering access codes and other inside information. Because he was a juvenile when he committed his computer crimes, he was able to have his record expunged. He gets mad when anyone brings up his criminal record, because, by law, he no longer has a criminal "record." I met Schneider a few years back when he was in the business of selling offshore brass-plate banks. He was in the process of burning his bridges with government after government from the Caribbean to the American Trust Territories. I gave him a call a few months ago to see if he was still selling banks through his company WFI. He said that he was out of that business. He has a new company called American National Securities which is a brokerage firm. If you buy an offshore bank, he will be more than happy to clear your trades through his company. If Doug Merritt, or anyone else is interested in offshore banking with a Cypherpunk twist, contact me. I'm working with several other Cypherpunks on some projects in that area. S a n d y >>>>>> Please send e-mail to: ssandfort(a)attmail.com <<<<<< ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

1 0

RE: PGP features
by albertson＠attmail.com 04 Sep '93

04 Sep '93

My feature list for PGP are simplier. I just want an integration of PGP into a commercial email package (such as Microsoft Mail or Lotus' CC Mail). It can't be that hard to do - can it? ---------- From: Edgar W. Swank To: Cypherpunks Subject: PGP features Date: Fri, Sep 3, 1993 11:46AM Brad Huntting recently posted: Perhaps it's time we polished the edges, added a few of the features that are lacking, and wrote up up an RFC for the PGP message format. Some features I'd like to see in PGP are: I've added my comments [with these full margins] as appropriate. The ability to send an encrypted message to multiple recipients without duplicating the entire message. The most logical way to do this would probably be to encrypt the random IDEA key once for each recipient. ??? This has been implemented in PGP since at least release 2.2. (Maybe 2.1, memory fails). Just specify multiple UserID fragments in the command line when encrypting. Note that if you don't specify a UserID in the command line, you -cannot- enter multiple ID's in the resulting prompt. This is in the -h help text: To encrypt a message for any number of multiple recipients: pgp -e textfile userid1 userid2 userid3 There needs to be a facility for having multiple signatures on a single document without making the signers sign each others signatures. Besides the obvious application of removing a signature from a document, this would also facilitate things like petitions where many people could asynchronously sign a single document, and latter assemble all the signatures together. This can be done via detached signature certificates, which can be gathered together and presented with the original document. To create a signature certificate that is detached from the document: pgp -sb textfile [-u your_userid] It should be possible (though certainly not mandatory) to hide the recipient's identity entirely. Not currently implemented, but being discussed. You can acheive much the same effect by using a another key-pair with a pseudonym in the UserID, to be distributed only through remailers or otherwise anonymously. The message format needs to allow for alternate forms of encryption (besides IDEA). Furthermore, the (shared key) algorithm used to encrypt a message should be hidden in the RSA encrypted part of the message along with the shared key. Ideally, a list of algorithms could be given which would allow the message to be optionally compressed before being encrypted, or encrypted two or more times with different algorithms. Not implemented, but has been mentioned. Triple-DES is one possible alternative. You can achieve multiple IDEA encryption by just using current PGP to encrypt twice (or more). Even if you encrypt to the same public key, the IDEA key used will be different. Compression can currently be turned off, if desired, via a CONFIG.TXT option, which can also be specified in the command line. Compression is also automatically turned off if the plaintext is recognized as the output of PKZIP or other popular compressors. If I'm confused and the PGP message format already supports some of these features, please correct me. Consider yourself corrected (:} -- edgar(a)spectrx.saigon.com (Edgar W. Swank) SPECTROX SYSTEMS +1.408.252.1005 Cupertino, Ca

1 0