- cypherpunks-legacy - lists.cpunks.org

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

encryption program posted to comp.sources.misc
by khijol!erc＠colossus.apple.com 31 Aug '93

31 Aug '93

Anyone else seen "syf" posted to comp.sources.misc? Someone oughta talk to Paul Vixie about posting XOR encryption programs... <sigh> -- Ed Carp, N7EKG erc(a)apple.com 510/659-9560 anon-0001(a)khijol.uucp If you want magic, let go of your armor. Magic is so much stronger than steel! -- Richard Bach, "The Bridge Across Forever"

1 0

Re: Free Electronic Cash
by thug＠phantom.com 31 Aug '93

31 Aug '93

> Exactly which corrupt EFF did you have in mind? Howabout some serious > facts rather than random accusations? Or did you just want to libel us? > > John Gilmore > Board of Directors, Electronic Frontier Foundation True or False, the EFF accepted money from AT&T in return for the EFF's support on various issues/bills before congress wherein AT&T came out on top in it's effort to commercialize parts of the Internet for it's own monetary gain? I've that's not bribery and corruption of what otherwise is supposed to be a non-profit organization, then I don't know what is. 'nuf said. Thug

3 2

Re: Help/Advice requested (fwd)
by Superuser 31 Aug '93

31 Aug '93

Through e-mail, gnu(a)toad.com writes: | | > Anyone have some ideas about how to implement such a beast? | | First you have to tell us what it's supposed to do. [ ... ] Sorry, I had assumed that people would know about registration schemes here. By the use of a (perhaps complex) algorithm, generate serial numbers that would be entered by the registering user which would effectively 'register' the program. There would be a routine in the executable that could detect a valid serial number and act accordingly. The algorithm to do this should be well-hidden into the code, as to discourage simple hacking and alteration... There are a wealth of schemes out there. For example, SCO UNIX uses a (albeit weird) scheme that involves a serial number and activation key which actually decrypts the executable (not what I want to do, really). INFORMIX uses a scheme that brands the executable with a serial number (very interesting). I thought of having an external program that would brand the executable with a serial number and perhaps some other hidden information in reserved spaces. Something like the program mentioned below would be effective in hiding the code. What else do you need to know? | > have run something like PKLITE on your executable) encapsulates the | > EXE file, encrypted, with CRC checks and debugger traps. | | Fine, it uses encryption and CRC and debug traps. Now, to what purpose? | What's the objective? What's the goal? Why? [ ... ] Here's a README from the distribution... Protect! EXE/COM 3.1 encrypt and still run .EXE's Registration $ 25.00 SDN_UTIL AUG93 PROTECT EXE COM CRC SECURE ENCRYPT SCRAMBLE FILES: PrExCm31.SDN Author: Jeremy Lilley Protect! EXE/COM is a powerful EXE/COM protection utility which thoroughly encrypts any EXE or COM file but still allows it to be run. And, files protected by it make a full CRC INTEGRITY CHECK every time they are run. This NEW version fixes many bugs found in previous versions of this program such as an infamous screen bug in v.3.0. Additions are made to make this program to prevent CRACKING, REVERSE ENGINEERING, and MODIFICATION even more. This program is one of the most powerful and cost-effecive solutions to problems with your programs' being modified by malicious hackers. With every other form of file security being nullified, Protect! has been renewed and can now secure your programs more than ever. What would you do if somebody were to add a TROJAN or 'MODIFY' a few screens to a program of yours ? Protect! can make this circumstance extremely unlikely for only $25. If a problem is detected, a message of your choice can be outputted to the user to tell the user exactly what to do. Instead of burying your head in the sand, get Protect! to protect your programming and software investment. Requirements: DOS 2.0 or higher, IBM or compatible PC, 256k RAM, & any executable file compression utility such as LZEXE, PKLite, Compack, Diet, or another program for compressing EXE files before they are scrambled and protected. [ .SDA Format is (c)Copyright 1993 The SDN Project ] [ SDN Authors-Only Info Line is 203-634-0370 USA ] -------- If you need more information, I can give you the author's email address...

1 0

What's wrong with PEM?
by collins＠newton.apple.com 31 Aug '93

31 Aug '93

After reading the RFCs for PEM (1421-1424), I am curious what other people think about PEM. For cypherpunks agenda, in what ways is PEM lacking? My take is: 1. PEM is a protocol, only applicable to mail (perhaps only to internet mail) while PGP is program that provides similar services for mail, but is also applicable to non-mail related encryption tasks. 2. PEM and PGP don't aggree on the symmetric algorithms (DES, IDEA). 3. PEM certificates are bulky, and transmission is encouraged. 4. PEM certificates are issued by Certificate Authorities, which would seem to preclude PGP's 'web of trust' model. These all seem to have answers: 1. PEM is protocal, PGP is a program that implements much of what PEM is... why not make PGP PEM compliant. 2. Propose IDEA as a symmetric algorithm for PEM. 3. Ha! PGP already has key servers. 4. Propose a revion to the certification scheme where USER certificates would be created by the owner and signed by non-certificate-authority acquaintances ala PGP. Yes, this would take time and effort. No, this should not be taken as an affront to our current and previous efforts. I think that we should persue _every_ avenue. If the only real problem with PEM is the trust model, and we can change that, then this would be a strongly legitimizing action. Scott Collins | "Few people realize what tremendous power there | is in one of these things." -- Willy Wonka ......................|................................................ BUSINESS. voice:408.862.0540 fax:974.6094 collins(a)newton.apple.com Apple Computer, Inc. 1 Infinite Loop, MS 301-2C Cupertino, CA 95014 ....................................................................... PERSONAL. voice/fax:408.257.1746 1024:669687 catalyst(a)netcom.com

1 0