August 1993 - cypherpunks-legacy

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

anonymous mail
by remail＠tamsun.tamu.edu 01 Sep '93

01 Sep '93

PEM also reveals who signs messages, even when the message is encrypted. In other words, if I send you a PGP encrypted message which I also signed, the signature is hidden under the encryption. You do not know who sent you the PGP message (assuming a cypherpunks remailer or equivalent was used) until after you decrypt the first "packet" and gaze inside. PEM, on the other hand, reveals in the clear who signed the message, outside of the encrypted portion. Also note that to be PEM compliant, you *must* always sign your messages. So much for anonymous encrypted messages... There is something to be said for the PGP encapsulated approach...

3 2

(fwd'd) more Clipper inside?
by cme＠ellisun.sw.stratus.com 01 Sep '93

01 Sep '93

Check this out. Clipper inside the Apple get you bothered? How about Clipper inside all UNICES ? (all POSICES) Sorry if this is a repeat for folks.. - Carl Date: Mon, 30 Aug 1993 10:03:00 EDT Reply-To: TC11-I IFIP TC11 Global information <TC11-I(a)HEARN.nic.SURFnet.nl> Sender: TC11-I IFIP TC11 Global information <TC11-I(a)HEARN.nic.SURFnet.nl> From: Ambuel(a)DOCKMASTER.NCSC.MIL Subject: Call for Participation - POSIX Security Group X-To: tc11-i(a)HEARN.NIC.SURFNET.NL X-Cc: smaha(a)DOCKMASTER.NCSC.MIL, snapp(a)DOCKMASTER.NCSC.MIL, emery(a)D74SUN.MITRE.ORG, tsig(a)WDL1.WDL.LORAL.COM, wbr(a)MITRE.ORG, chang(a)ST1.NCSL.NIST.GIV, p1003.6(a)PERCH.NOSC.MIL, p1003.22(a)PERCH.NOSC.MIL, tc11(a)CIPHER.NL To: Multiple recipients of list TC11-I <TC11-I(a)HEARN.nic.SURFnet.nl> Status: RO _____________________________________________ Call for Participation The POSIX security working group will be concentrating on several new areas of security functionality at the October 18 meeting in Bethesda, Maryland. The group believes that these areas must be completed in order for the defined interfaces in P1003.6.1 and P1003.6.2 to be fully useful. These new areas include: Identification and Authentication Services Portable Data Formats Cryptographic Services Administrative Services Identification and Authentication Services POSIX 1003.1 and 1003.2 provide little functionality in the areas of identification and authentication. The security working group believes that services for identifying users and authenticating those identities is essential for protecting resources within a system. One proposal, from ICL, has been received to date on this subject. It will be distributed in the POSIX mailing and will be discussed at the October meeting. In addition, distributed issues of identification and authentication will be discussed so that a resulting standard will accommodate distributed identification and authentication technology. Any additional proposals for identification and authentication services will also be entertained. Portable Data Formats POSIX 1003.6.1 has defined several interfaces to create and manipulate security-related data items - access control lists, labels, capabilities, and audit records. However, the data items are not described to the level of detail necessary to use them in a portable way. For true application portability the format of these data items must be known. One proposal has been received, from Haystack Laboratories, for a common audit trail interchange format. This proposal will be included in the POSIX mailing and will be discussed at the October meeting. Any additional proposals for portable data formats will also be entertained. Cryptographic Services One proposal has been received, form NIST, which outlines interfaces for several areas of cryptographic services: user cryptographic database management, secret key cryptography services, and public key cryptography services. The secret key services include encryption and data integrity, as well as key management. The public key services include encryption and digital signatures, as well as key management. The proposal will be included in the POSIX mailing and will be discussed at the October meeting. Another proposal may be submitted by the October meeting and will also be discussed. Any additional proposals for crytpographic services will also be entertained. Administrative Services The security working group met with the administrative services working group (P1003.7) to discuss what interfaces and utilities need to be defined to provide portable application writers with a standard method for administering security-related data items. The original scope of P1003.6 excluded this functionality because P1003.1 and P1003.2 excluded this functionality. However, these utilites and functions are essential for application writers to provide truly portable applications. Any proposals in this areas are encouraged and will be discussed at the October meeting. Proposals in these, or other, security-related areas are welcome and can be mailed to the chair for enclosure in the POSIX mailing and the agenda for the meeting. This will allow members of the working group to review the proposal and be prepared for discussion at the meeting. Proposals will also be accepted at the meeting, but only in written form. This makes it more likely that a proposal has been thought out and keeps discussion focused on a tangible document. In order to plan for the agenda for the working group meeting, please forward your name, email address, area of interest, and expected duration that you will be at the Bethesda meeting. Addresses for the chair are listed below. The hope is that a large group will be available for discussion all week, but sometimes that is not quite reality. If you can only attend a few days, or would like to present something on a specific day, please provide that inforamtion and the agenda will be created accordingly. Questions and written proposals can be sent to the chair in any of the following ways: U.S. Mail: Lynne Ambuel Attn: I94 Department of Defense Fort G.G. Meade, MD 20755-6000 Internet: Ambuel @ dockmaster.ncsc.mil FAX: (410) 850-7166

2 1

Encryption policies of Fidnet, etc.
by remail＠tamsun.tamu.edu 31 Aug '93

31 Aug '93

Forwarded from alt.cyberspace: ------------------------------ ->> Joseph T Dickinson was mumbling something about Encryption <<- JTD> It is illegal to encrypt messages period. JTD> E-mail encryption is illegal Depends on your network and where you live. It is illegal to use PGP in the United States due to its use of a copyrighted algoritm. It is *NOT* illegal to use it anywhere else in the world. Other encryption methods are legal. In Fidonet (the largest *amatuer* mail network), it is against policy to encrypt 'echomail' (Fido version of newsgroups), but perfectly acceptable to encrypt *direct* netmail (Fido email delivered directly to the recieving system without regard to its location). Routed netmail (email passed from system to system before eventually arriving at its destination) may be encrypted provided each sysop whose node the message passes through agrees that the message may be encrypted, otherwise, it has to be sent en claire. On RIME (Relaynet International Mail Exchange, the *2nd* largest amatuer run network), email is regularly encrypted as part of the networking and routing software in use by the network. Sending routed, reciever-only mail is not only common, but *encouraged*, since it cuts down on the overhead of the other systems in the net. You'd have to look at the network's topology to see why; it's basically a 'tree' formation in which nodes at the bottom feed their newsgroups up to the topstars and recieve them from the topstars. Keven ... Get the facts first - you can distort them later! ___ Blue Wave/QWK v2.12

1 0

Re: What's wrong with PEM?
by cme＠ellisun.sw.stratus.com 31 Aug '93

31 Aug '93

-----BEGIN PRIVACY-ENHANCED MESSAGE----- Proc-Type: 2001,MIC-CLEAR Originator-Name: cme(a)ellisun.sw.stratus.com Originator-Key-Asymmetric: MIGbMAoGBFUIAQECAgP+A4GMADCBiAKBgCl79/jl0DEVl1GQzOHlzjDmChDDxnWO Acd7jShj2x1vclFh6vbHx9IJqkQdwNhNAWf8XnTrqBDN+VSBc1qdT6nSEAbNPxHD XcvY2DudhuRaRBVLgUQ4scTK657m90Q+bTL5yIh2MaFipUw9BgbIXPTDlksSskWP 9oHjo+pCJC+lAgMBAAE= MIC-Info: RSA-MD5,RSA, D6p2f/wP8D4TOg3vWp7JGoGdKw4iL3bQeSFiany6kDNAdS8Tt65pSqb99zUpBN7v 13Cu+LQhS0OA0jpyv+/DpkdjiW3GgECX05YkfIzd4iOF0CI/76pPoV65hIgdi5ze tcnBn6hr/fcBUByM+nWp0BIi/tApWp1xl/iEUOBiuwU= >Message-Id: <9308311508.AA08669(a)newton.apple.com> >Date: Tue, 31 Aug 1993 08:08:33 -0800 >From: collins(a)newton.apple.com (Scott Collins) Hi Scott. I think you have PEM right -- except that there's RIPEM which does file encryption/decryption just like PGP. I've built a shell script for my mailer (Mail) which invokes either RIPEM or my own secret key algorithm so it's a bit more convenient. Once I get purchased PGP, I'll add PGP to that list. I hope to use the same key for PGP and RIPEM. (1024 bit RSA). - <<Disclaimer: All opinions expressed are my own, of course.>> - Carl Ellison cme(a)sw.stratus.com - Stratus Computer Inc. M3-2-BKW TEL: (508)460-2783 - 55 Fairbanks Boulevard ; Marlborough MA 01752-1298 FAX: (508)624-7488 - -----BEGIN RIPEM PUBLIC KEY----- User: cme(a)ellisun.sw.stratus.com PublicKeyInfo: MIGbMAoGBFUIAQECAgP+A4GMADCBiAKBgCl79/jl0DEVl1GQzOHlzjDmChDDxnWO Acd7jShj2x1vclFh6vbHx9IJqkQdwNhNAWf8XnTrqBDN+VSBc1qdT6nSEAbNPxHD XcvY2DudhuRaRBVLgUQ4scTK657m90Q+bTL5yIh2MaFipUw9BgbIXPTDlksSskWP 9oHjo+pCJC+lAgMBAAE= MD5OfPublicKey: 39D9860686A9F075A9A83D49589C677A - -----END RIPEM PUBLIC KEY----- -----END PRIVACY-ENHANCED MESSAGE-----

1 0

Re: anonymous mail
by markh＠wimsey.bc.ca 31 Aug '93

31 Aug '93

> PEM, on the other hand, reveals in the clear who signed the message, outside > of the encrypted portion. Also note that to be PEM compliant, you *must* > always sign your messages. So much for anonymous encrypted messages... There are also performance concerns here. There is no reason to take the substantial amount of time it takes to sign, if you don't want to sign a message. On the other hand, in terms of anonymity, you can always generate a self-signed key with TIS/PEM (I forget the exact term they use in the TIS/PEM docs, but you can just make yourself a certificate which doesn't really say anything about your identity). -- Mark Henderson markh(a)wimsey.bc.ca (personal account) RIPEM key available by key server/finger/E-mail MD5OfPublicKey: F1F5F0C3984CBEAF3889ADAFA2437433

1 0

article in Science News
by bill＠twwells.com 31 Aug '93

31 Aug '93

For those into such things, it might be worthwhile to check out the articles on the last page of Science News, Vol. 144, No. 9, August 28, 1993. Interesting tidbits are "...computer scientist Dorothy E. Denning..." and mention of the panel that evaluated SKIPJACK. (Isn't Denning a lawyer turned ersatz cryptography expert? Or do I have her confused with some other "expert"?)

1 1

Re: Apple+Clipper
by lefty＠apple.com 31 Aug '93

31 Aug '93

Tim May says: >Yep, I was just making this point, that Apple is _already_ releasing >hardware with OS incompatibilities. (By the way, many/all? of the >newer Macs need a "system enabler" patch to run System 7.1, that is, >the standard System (OS) no longer runs on all machines. Actually, this has always been true. It's just that it was done in the form of patch resources internal to the System file prior to the release of System 7.1. It used to be that, in order to save disk space, one could go into the System file with ResEdit and remove the various 'PTCH' resources that didn't apply to the particular machine you happened to be using. The System Enabler scheme is simply a somewhat cleaner method of accomplishing the same thing: you now have a "generic" System file, with the various hacks segregated in the Enabler. -- Lefty (lefty(a)apple.com) C:.M:.C:., D:.O:.D:.

1 0

PGP: question
by Karl Lui Barrus 31 Aug '93

31 Aug '93

Cypherpunks, Are there any heavy implications, security and otherwise, to the truncation of the environment variable PGPPATH that occurs in buildfilename()? Background: I've been trying all sorts of stuff getting pgp to read config.txt when I'm anywhere else in my directory structure. My home directory is /home/klbarrus which as it turns out is a symbolic link another directory (it may even change from time to time). Since I never could get PGPPATH to work on my old NeXT account, and my home directory there was also a link to something else, I thought: AHA! PGP uses stat() and/or some other functions which don't follow symbolic links!! Nope, it does, so that wasn't it. So, I poked around the code more and found out that buildfilename() returns null if the length of getenv(PGPPATH) is greater than 50. This probably explains why it didn't work on the NeXT; PGPPATH was set to some huge path like /private/Net/tree/Users/barrus/Cryptography/pgp or something close, so buildfilename() returned null. But the pathname on my new account is definitely shorter than 50 characters, but I decided to try increasing 50 just to see what it would do. Right before remaking pgp I realized the mistake I had made, one that is (export) almost too embarrasing to admit :-) Anyway, any "deep" reason to return null if the length of the environment variable is > 50? Or is it just to keep the path relatively short, maybe to keep from breaking a system call on some machine out there? -- Karl L. Barrus: klbarrus(a)owlnet.rice.edu keyID: 5AD633 hash: D1 59 9D 48 72 E9 19 D5 3D F3 93 7E 81 B5 CC 32 "One man's mnemonic is another man's cryptography" - my compilers prof discussing file naming in public directories

1 0

Attacks on remailers
by hfinney＠shell.portal.com 31 Aug '93

31 Aug '93

>>>>> On Wed, 25 Aug 93 11:39:11 EDT, J_G_Thomas%CAASD1(a)mwmgate1.mitre.org said: Joe> A new protocol is probably the cleanest way to solve the Joe> problem of traffic analysis of messages addressed with Joe> encrypted address blocks. The best way to get security Joe> in a remailer chain is to nest your encryption, so only Joe> one layer gets peeled off in each remailer hop. That Joe> isn't possible with encrypted address blocks, since the Joe> sender will only know the address (and public key) of the Joe> first remailer in the chain. All hops after the first Joe> one must send the same message out as they got in, with Joe> just a layer off the encrypted address block. As I indicated in my long posting, it is not necessary to send out the same message that was received. Chaum proposed encrypting the message (the non-address-block portion) with a secret key at each stage, a key which would be revealed to the remailer (along with the address of the next address in the chain) when it peeled off its own layer of encryption. But if Joe> remailers talked to each other by first doing RSA-signed Joe> Diffie- Hellman key exchange, then encrypting the Joe> traffic, a packet snooper wouldn't be able to correlate Joe> incoming and outgoing messages. If no encryption is done on the message body, there is another attack for this case that I didn't mention. It is: Run a remailer. For every anonymous address floating around on the net, try sending a message to it. Look at the messages which pass through your own remailer and look for matches to the message you sent. Any anonymous address which includes your remailer as one of the elements will pass through you. You have then defeated all of the stages of the chain before yourself. In particular, if you happen to be the last remailer of the chain, you have broken the anonymity of the anonymous address. This attack, while not the most powerful on the list, defeats many of the principles of remailer chains, such as that the chain is as strong as its strongest link. It requires you to strongly trust at least one remailer in the chain (the last one), whereas without this attack you would not have to especially trust any single remailer. So it is sig- nificant. Diffie-Hellman encrypting messages between remailers would not help against this attack. Also, rather than DH it would be just as effective to use the public key of the next remailer in the chain, and more convenient: some remailers are not able to participate in TCP exchanges, being connected to the net by occasional uucp connections. This lack-of-TCP problem also impacts the proposal to use a public telnet port for message communication. Another problem with that proposal is that it would need the remailers to run as background processes. With the current software they can run as mail filters, which makes them much less conspicuous to system managers. The suggestion for remailers to send messages by telnet connection to port 25 of some other machine (rather than by piping to sendmail as they currently do) is perhaps reasonable (for those systems with TCP access), although it makes the remailer somewhat harder to set up since you have to find some other machine which will let you connect to their port. Also, I think some machines may log incoming or outgoing telnet connections to this port, since it is a common technique for mail forgeries. I have heard that most systems will actually not allow public telnet connections to this port. I don't know that much about how widely available telnet and other TCP/IP services are on the net, so if these techniques are more usable than I am suggesting I'd like to hear about it. Hal Finney hfinney(a)shell.portal.com

5 7