December 2003 - cypherpunks-legacy

Re: The Market for Crypto--A Curmudgeon's View
by david d `zoo' zuhn 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- // You cannot make money one the net, net reputations // do not count in jobs, academic or otherwise. I disagree here -- I've gotten a couple of jobs where my net reputation preceded me and was the primary motivator for my getting an interview. I was also told at one of them to continue posting as I did because they felt that their reputation was enhanced by mine. And "cannot make money on the net"? How do you see this? Much as I hate the metaphor, I don't make money on the local highways either, but they're a part of real life. I use them to do other things to make money. Neither are an integral part of the work that I do, but both make it possible for me to do the work in a fashion that I can handle (I refuse to live in my office ever again). Just because the reputations aren't digital yet, nor is the cash, doesn't mean that the Net isn't real life. It's as real as nearby I-94. And a lot more interesting and complex. -- - david d `zoo' zuhn -| armadillo zoo software -- St. Paul, Minnesota -- zoo(a)armadillo.com --| unix generalist (and occasional specialist) ------------------------+ send e-mail for more information pgp key upon request +---------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: 2.6.1 iQCVAwUBLttyl+80ah2ymxnRAQFP3AP/VOcxV7y9EE5a8humdh51i4qMd/f/bEHS Z5lvKJS7chVTTIwBTzBui/+3JIM8WmlSveiKBYVbGAuojQS3tC0g7phqVMKHPDCC vy2+/DzIbIILUvI/AQoSJm06Frfzgh1uYTiisr47Dznx2bLHlpLgep6xwwXkvCAM vKP1r0l7l+s= =oxCh -----END PGP SIGNATURE-----

1 0

PGP Enhanced Messaging (PEM)
by Rick Busdiecker 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- I've made my PGP Enhanced Messaging (PEM) available via anonymous FTP on H.GP.CS.CMU.EDU in /usr/rfb/pem/. This is free software available under the terms GNU Public License. I'm enclosing some information from the +Read.Me+ file for the distribution archive (ftp://h.gp.cs.cmu.edu/usr/rfb/pem/) as well as the one for the the software itself. Changes since the most recent distributed version include: - New keybindings that meet RMS specifications. - Some fine tuning related to generating and verifying `header signatures' for messages that include lines starting with either "From " or ">From ". If you pick this up, please send mail to me <rfb(a)cmu.edu> to let me know. Rick ====================================================================== This is a distribution archive for PGP Enhanced Messaging (PEM). The files contained here are: +Read.Me+ This file pem.tar.gz compressed (with gzip) archive pem.tar.gz.asc PGP signed and armored compressed archive pem.tar.gz.sig detached signature for pem.tar.gz rfb(a)cmu.edu my public key block Notes: - There is no uuencoded file. pem.tar.gz.asc can be mailed safely. - If you're concerned about tampering at this archive site, you should fetch my public key block from elsewhere. The public key server at pgp-public-keys(a)pgp.mit.edu is a good place to get it. ====================================================================== PGP Enhanced Messaging (PEM) should not be confused with the Privacy Enhanced Mail standard (PEM). Information on integrating PEM into your GNU Emacs environment is included at the end of this file. The idea behind PEM is to provide a set of Emacs Lisp functions to augment common mailers and newsreaders with PGP related operations. PEM is implemented in layers. There are customization variables defined at each level. They are described later in this document. At the highest level, each supported messaging package has a file that implements the functions that are specific to that package. Currently there are: pem-mhe.el For use with mh-e.el, and Emacs interface to the MH mailer. pem-gnus.el For use with the GNUS newsreader. Appropriate hook functions are defined which add standard function bindings to the various modal key maps. Typically, the following bindings will be in place in any message related buffer: C-c C-d Decrypt next PGP block in current message C-c C-e Encrypt current message C-c C-i Insert a public key into a message C-c C-n sign aNd encrypt current message C-c C-s Sign current message C-c C-v Verify next PGP signed block in current message C-c C-x Extract next public key from message [ Note: This is a change from previous versions where, for example, C-c d and C-c D would be defined. RMS says to do bindings this way and leave those other bindings for users ] Where possible, in buffers which are for composing messages, the standard mechanism for committing (sending or posting) a message will be augmented to support signing and/or encrypting. In buffers which are not for composing messages, the upper case versions are also defined without the C-c prefix, e. g. "D" will decrypt the current message. A notable exception to this is the GNUS *Summary* buffer which has the following default bindings: D gnus-summary-mark-as-read-backward N gnus-summary-next-article V gnus-version X gnus-summary-delete-marked-with Note that in some contexts, some of these bindings don't make sense. They are still bound, however, the function to which they are bound signals an error indicating the operation is inappropriate. For example, it does not make sense to insert your public key into the body of a news article that you are reading. However, some `obvious' restrictions are relaxed when dealing with mail. When you attempt to encrypt a mail message which you are reading, it may be `self encrypted', that is, the message body will be encrypted such that only you can decrypt it. Each of the package specific files are built on functions defined in pem.el. It contains generic message operations and deals with issues like parsing headers and addresses, and identifying PGP armored regions. At the core is npgp.el -- New pgp.el -- so named as to avoid conflicts with the pgp.el, maintained by Gray Watson <gray(a)antaire.com> and Jack Repenning <jackr(a)wpd.sgi.com>, which is available through various elisp archives. This runs PGP asynchronously and is able to deal with the erratic prompting that PGP sometimes does. For example, the first time that you use an untrusted key, PGP will prompt asking if you're sure that you want to use it. npgp.el passes the question on to you, using standard Emacs prompting to get the answer from you. PEM also uses passwd.el by Jamie Zawinski <jwz(a)mcom.com> to read passphrases. -----BEGIN PGP SIGNATURE----- Version: 2.6 iQCVAgUBLttV6JNR+/jb2ZlNAQF26AP/fyq+fxLEeqlpaP7bu5oBakgDhkm4pTlf ejo6kmlm052y+g+ax/5LF3ZsHZw0GFKyg4ltL2C8rDcgPo8dPOqv49GfHeeuS1lE HsL/wWBmhwWqijw1bOu0KAogL1I0mumSx+oeYP0Rlea9rRb2cyYYta7X5r0dGFuDWwGoXOIb9yc= =7/tF -----END PGP SIGNATURE----- -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6 mQCNAi3iH2wAAAEEAMjRQMS6OEvdPUFX0HwxA0kYGAXUOde0Kklbdj/Gsf6QCgrA vfrLlW2jIv6Gqn345NZXQ5S45z+m4YlEZV78Ln3G1alxd22lXlo8RChs8QVdxgCX dkfVKJlcpJQfNWfrNHLMtaAB9+22p8nhGjBmTnuX5K0BQgMLCZNR+/jb2ZlNAAUR tB1SaWNrIEJ1c2RpZWNrZXIgPHJmYkBjbXUuZWR1PokAVQIFEC3iIcaIwD3rAd2b uQEBF4UB/iCxzTUBT+eAJCINmk9qkZYNWFhtt12zfyPSK9Ub2ruK6PGkjqE5HQ/b a7Fz49FX9Z70LOpJz11P9pPEmQ8CW3aJAJUCBRAt4iD6Fpk0o882PjUBATWEA/wP +WGx6GKaSHmEdtfNfGQPF70FPFRYKpugAwI/wZBHjtvNnsgTcI92Oby+b9QQDzgJ oXlerHeeoqeGpi8ZiKwIXproR5JBkB/4UuVkmIS1pP5T1D6BIUH27K6k87Yvz8JW GAqHfinoN3YOW4Fx9qZdo46aoRCGcYhTzTuXwyKxTIkAlQIFEC3iIIaTUfv429mZ TQEBmo8EAIHrwdeJ9sFb6Ro4iWxlED1OEMD+KYxfB2vu39uKGXEP1SB488uR1N7z jxcFHqZPliZ0tc2DhrUPpBY85JmI1IjtXXhS8Fbqc5Dp1Pnua+XjndaRpSSD29VH CgNvkf1S35w33GBAh8bVSgjvl8kZKOoDBV4v9ZbqG39+raZ+imAVtCBSaWNrIEJ1 c2RpZWNrZXIgPHJmYkBsZWhtYW4uY29tPokAlQIFEC48n6yTUfv429mZTQEBVwwD /iXo9pv/wFISdSwNKniNcHqogQLHjnZryzvjXNkDTvi0miBlzayozl/Q21a2nMEc 1MI8K3gNv/mP98Qw7xw5FD8F5zuY3XiFYr0GK4m0bqwixUfxkjBacb67mflCvaFS h8+K2k7Db6V0/MpV9t/VOzqjF4h5CFkoWAd+1Cr21OuQ =ruN3 -----END PGP PUBLIC KEY BLOCK-----

1 0

PGP Enhanced Messaging (PEM)
by Rick Busdiecker 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- I've made my PGP Enhanced Messaging (PEM) available via anonymous FTP on H.GP.CS.CMU.EDU in /usr/rfb/pem/. This is free software available under the terms GNU Public License. I'm enclosing some information from the +Read.Me+ file for the distribution archive (ftp://h.gp.cs.cmu.edu/usr/rfb/pem/) as well as the one for the the software itself. Changes since the most recent distributed version include: - New keybindings that meet RMS specifications. - Some fine tuning related to generating and verifying `header signatures' for messages that include lines starting with either "From " or ">From ". If you pick this up, please send mail to me <rfb(a)cmu.edu> to let me know. Rick ====================================================================== This is a distribution archive for PGP Enhanced Messaging (PEM). The files contained here are: +Read.Me+ This file pem.tar.gz compressed (with gzip) archive pem.tar.gz.asc PGP signed and armored compressed archive pem.tar.gz.sig detached signature for pem.tar.gz rfb(a)cmu.edu my public key block Notes: - There is no uuencoded file. pem.tar.gz.asc can be mailed safely. - If you're concerned about tampering at this archive site, you should fetch my public key block from elsewhere. The public key server at pgp-public-keys(a)pgp.mit.edu is a good place to get it. ====================================================================== PGP Enhanced Messaging (PEM) should not be confused with the Privacy Enhanced Mail standard (PEM). Information on integrating PEM into your GNU Emacs environment is included at the end of this file. The idea behind PEM is to provide a set of Emacs Lisp functions to augment common mailers and newsreaders with PGP related operations. PEM is implemented in layers. There are customization variables defined at each level. They are described later in this document. At the highest level, each supported messaging package has a file that implements the functions that are specific to that package. Currently there are: pem-mhe.el For use with mh-e.el, and Emacs interface to the MH mailer. pem-gnus.el For use with the GNUS newsreader. Appropriate hook functions are defined which add standard function bindings to the various modal key maps. Typically, the following bindings will be in place in any message related buffer: C-c C-d Decrypt next PGP block in current message C-c C-e Encrypt current message C-c C-i Insert a public key into a message C-c C-n sign aNd encrypt current message C-c C-s Sign current message C-c C-v Verify next PGP signed block in current message C-c C-x Extract next public key from message [ Note: This is a change from previous versions where, for example, C-c d and C-c D would be defined. RMS says to do bindings this way and leave those other bindings for users ] Where possible, in buffers which are for composing messages, the standard mechanism for committing (sending or posting) a message will be augmented to support signing and/or encrypting. In buffers which are not for composing messages, the upper case versions are also defined without the C-c prefix, e. g. "D" will decrypt the current message. A notable exception to this is the GNUS *Summary* buffer which has the following default bindings: D gnus-summary-mark-as-read-backward N gnus-summary-next-article V gnus-version X gnus-summary-delete-marked-with Note that in some contexts, some of these bindings don't make sense. They are still bound, however, the function to which they are bound signals an error indicating the operation is inappropriate. For example, it does not make sense to insert your public key into the body of a news article that you are reading. However, some `obvious' restrictions are relaxed when dealing with mail. When you attempt to encrypt a mail message which you are reading, it may be `self encrypted', that is, the message body will be encrypted such that only you can decrypt it. Each of the package specific files are built on functions defined in pem.el. It contains generic message operations and deals with issues like parsing headers and addresses, and identifying PGP armored regions. At the core is npgp.el -- New pgp.el -- so named as to avoid conflicts with the pgp.el, maintained by Gray Watson <gray(a)antaire.com> and Jack Repenning <jackr(a)wpd.sgi.com>, which is available through various elisp archives. This runs PGP asynchronously and is able to deal with the erratic prompting that PGP sometimes does. For example, the first time that you use an untrusted key, PGP will prompt asking if you're sure that you want to use it. npgp.el passes the question on to you, using standard Emacs prompting to get the answer from you. PEM also uses passwd.el by Jamie Zawinski <jwz(a)mcom.com> to read passphrases. -----BEGIN PGP SIGNATURE----- Version: 2.6 iQCVAgUBLttV6JNR+/jb2ZlNAQF26AP/fyq+fxLEeqlpaP7bu5oBakgDhkm4pTlf ejo6kmlm052y+g+ax/5LF3ZsHZw0GFKyg4ltL2C8rDcgPo8dPOqv49GfHeeuS1lE HsL/wWBmhwWqijw1bOu0KAogL1I0mumSx+oeYP0Rlea9rRb2cyYYta7X5r0dGFuDWwGoXOIb9yc= =7/tF -----END PGP SIGNATURE----- -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6 mQCNAi3iH2wAAAEEAMjRQMS6OEvdPUFX0HwxA0kYGAXUOde0Kklbdj/Gsf6QCgrA vfrLlW2jIv6Gqn345NZXQ5S45z+m4YlEZV78Ln3G1alxd22lXlo8RChs8QVdxgCX dkfVKJlcpJQfNWfrNHLMtaAB9+22p8nhGjBmTnuX5K0BQgMLCZNR+/jb2ZlNAAUR tB1SaWNrIEJ1c2RpZWNrZXIgPHJmYkBjbXUuZWR1PokAVQIFEC3iIcaIwD3rAd2b uQEBF4UB/iCxzTUBT+eAJCINmk9qkZYNWFhtt12zfyPSK9Ub2ruK6PGkjqE5HQ/b a7Fz49FX9Z70LOpJz11P9pPEmQ8CW3aJAJUCBRAt4iD6Fpk0o882PjUBATWEA/wP +WGx6GKaSHmEdtfNfGQPF70FPFRYKpugAwI/wZBHjtvNnsgTcI92Oby+b9QQDzgJ oXlerHeeoqeGpi8ZiKwIXproR5JBkB/4UuVkmIS1pP5T1D6BIUH27K6k87Yvz8JW GAqHfinoN3YOW4Fx9qZdo46aoRCGcYhTzTuXwyKxTIkAlQIFEC3iIIaTUfv429mZ TQEBmo8EAIHrwdeJ9sFb6Ro4iWxlED1OEMD+KYxfB2vu39uKGXEP1SB488uR1N7z jxcFHqZPliZ0tc2DhrUPpBY85JmI1IjtXXhS8Fbqc5Dp1Pnua+XjndaRpSSD29VH CgNvkf1S35w33GBAh8bVSgjvl8kZKOoDBV4v9ZbqG39+raZ+imAVtCBSaWNrIEJ1 c2RpZWNrZXIgPHJmYkBsZWhtYW4uY29tPokAlQIFEC48n6yTUfv429mZTQEBVwwD /iXo9pv/wFISdSwNKniNcHqogQLHjnZryzvjXNkDTvi0miBlzayozl/Q21a2nMEc 1MI8K3gNv/mP98Qw7xw5FD8F5zuY3XiFYr0GK4m0bqwixUfxkjBacb67mflCvaFS h8+K2k7Db6V0/MpV9t/VOzqjF4h5CFkoWAd+1Cr21OuQ =ruN3 -----END PGP PUBLIC KEY BLOCK-----

3 2

Re: Transparent Email
by shamrock＠netcom.com 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Eric wrote: >I am still considering the "sign-or-delay" proposal for the toad.com >server, that is, sign your articles to the list or they'll be delayed >and eventually rejected. Do it. Either it will work or it will kill the list. If it works, geat. If it kills the list, we would have failed in our mission anyway. - --Lucky -----BEGIN PGP SIGNATURE----- Version: 2.6ui iQCVAgUBLtrCYASQkem38rwFAQHTFgP/VrP8GACjMT4amw7Ws1+VP0HftgZUtCGW +xP59b4FDVUuZH/KH0Q0t9eGYyHBqYlhkr3M4eU/149+Q6Jz7u/juOXx5W638UKB Ujz4Mf4MnBHaEU5/famKmFTD/n+dGS2Gzds121SLnW3rmVU2rPcPYBRkvYAQQZ+f Q//TPjhoj5Y= =3+9F -----END PGP SIGNATURE-----

8 7

Re: Transparent Email
by John Young 17 Dec '03

17 Dec '03

Responding to msg by eric(a)remailer.net (Eric Hughes) on Mon, 28 Nov 9:54 PM >I am still considering the "sign-or-delay" proposal for >the toad.com >server, that is, sign your articles to the list or >they'll be delayed >and eventually rejected. Does not everyone get a complete header like the one below from Eric's post with incoming mail? This is presented automagically by The Pipeline's system. I had assumed that because every mail received here has such a header that everyone else could also see who sent my mail, signed or not. That is why I have not signed my posts. BTW, Pipeline does not allow anonymously-sent direct mail -- as a take it or leave it policy. So we cannot manipulate headers to forge from this Windows-driven end. John Young (redundantly, I thought) >From owner-cypherpunks(a)toad.com Tue Nov 29 00:01 EST >1994 > Received: from relay2.UU.NET (relay2.UU.NET >[192.48.96.7]) by pipeline.com (8.6.9/8.6.9) with ESMTP >id AAA09928 for <jya(a)pipeline.com>; Tue, 29 Nov 1994 >00:01:20 -0500 >Received: from toad.com by relay2.UU.NET with SMTP > id QQxsbj13332; Mon, 28 Nov 1994 23:59:02 -0500 >Received: by toad.com id AA15623; Mon, 28 Nov 94 >20:55:57 PST >Received: from largo.remailer.net ([204.94.187.1]) by >toad.com id AA15611; Mon, 28 Nov 94 20:55:29 PST >Received: (from eric@localhost) by largo.remailer.net >(8.6.8/8.6.6) id VAA02536; Mon, 28 Nov 1994 21:54:14 >-0800 >Date: Mon, 28 Nov 1994 21:54:14 -0800 >Message-Id: <199411290554.VAA02536(a)largo.remailer.net> >To: cypherpunks(a)toad.com >In-Reply-To: <199411282330.RAA00186(a)omaha.omaha.com> >(message from Alex Strasheim on Mon, 28 Nov 1994 >17:30:22 -0600 (CST)) >Subject: Re: Transparent Email >From: eric(a)remailer.net (Eric Hughes) >Sender: owner-cypherpunks(a)toad.com >Precedence: bulk >Content-Type: text >Content-Length: 6504

2 1

Re: Transparent Email
by Alex Strasheim 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- I think it's a bad idea to require signatures on the list, or even to penalize people who don't use them. People aren't signing their posts because it's too much of a hassle to do it from a dial up, netcom style, account, not because they're insufficiently committed to the cause. It seems to me that such a rule would stifle discussion and encourage people to store their keys on insecure accounts. The real solution is to try to build tools which will make it so easy to use crypto that there's simply no reason not to do it. And towards that end: I think Eric's point about separating key distribution from encryption finally sunk in. It's encouraging for me, because I think we're very close to being able to implement good transparent systems, at least if we put key distribution on the back shelf. I haven't totally thought it through, but it seems to me that it's almost a matter of assembling a few existing tools into a coherent system. I've just installed Raph Levien's premail as /usr/lib/sendmail on my system, and I'm happy to report that it's running well, despite the fact that my machine is a very puny linux box. This means that I can keep a list of addresses that ought to be encrypted in my ~/.premailrc file, and outgoing email to those destinations will be automatically encrypted and signed, no matter what mail software I happen to be using. This leaves the problem of passphrases for outgoing signatures and automatically decrypting incoming mail, but I think that cfs will let me kludge something together which will get around this. (My situation is a little unusual, because I'm running linux on a pc which is connected to the net via a static slip account. I don't think this would work well in other situations.) If, after I power on my machine, I mount an encrypted directory with cfs, and then connect my slip, I think I can get away with keeping my key unprotected with a passphrase as long as the keyring is stored in the encrypted directory. What's more, if my mail spool is stored in the encrypted directory as well, a filter which automatically decrypts incoming mail and deposits the plaintext in the spool would be feasible. A good filter would probably stick something in the text to let you know that it had come with a good signature. It would be sort of ugly, but I think it would work. I'm sort of new to cfs, though, and I'm sure how it would deal with multiple users (root, my main account, my cp account which recieves cypherpunk list traffic, etc.). But If it worked, I'd have a machine which: o talked to the rest of the email universe without difficulty, and which uses standard unix software o would automatically use crypto when sending mail to a list of email addresses, and which could automatically handle incoming crypto o would be reasonably secure when it was powered off == Alex Strasheim | finger astrashe(a)nyx.cs.du.edu alex(a)omaha.com | for my PGP 2.6.1. public key -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBLtrgPREpP7+baaPtAQHTlQP/RYcJi9u5iU0AY4SV1MqNGxAuQDfYwL2G LcJC5sxYreFGkpwwpA87fRcLi7PreAtS6vFg5tsMXiUXaNS15v1mCDfxr54AwO7C P3yyHWUTGg1I8CRbDUYlZqksrF3Bqzxy0pDRQGzPEFwP7k8ER72XXeVtIVc8K/zM CBW+smDOY/w= =43eM -----END PGP SIGNATURE-----

4 5

Re: Need program pointers
by an448＠FreeNet.Carleton.CA 17 Dec '03

17 Dec '03

Ben wrote: >Norton has a decent wipefile. I don't know if it exists with the current >distribution, but with 4.5(which I have) it has it. Norton's Wipeinfo is not too bad, but I have found one major problem and a few minor problems with versions 7 and 8: Major problem: The documentation says that Wipeinfo automatically disables Smartcan, the undelete utility. In fact, it doesn't do so, at least on my system. If you don't disable Smartcan manually, you can simply undelete the "wiped" files. For this reason, I no longer trust Wipeinfo to automatically disable my cache; I turn the cache off manually before using Wipeinfo. Minor problems: If you use the options to wipe file slack or unused space, Wipeinfo will not wipe the directory entries for deleted files. Using DiskEdit in hex view, you can still see that you once had a file called ?ECRET. However, using Wipeinfo to wipe a file will also wipe the directory entry. And Wipeinfo will only wipe some areas of the disk (track 0, for example), if you choose to do a "government wipe". Doing a "fast wipe" will not wipe these areas, even if you choose to wipe the entire drive. The documentation for Secure File System (SFS) has interesting information on wiping disks. Peter Gutmann says this: There is a commonly-held belief that there is a US government standard for declassifying magnetic media which involves overwriting it three times. In fact this method is for declassifying core (computer memory) rather than magnetic media. The government standard for declassifying magnetic media probably involves concentrated acid, furnaces, belt sanders, or any combination of the above. -- Yves Bellefeuille, Ottawa, Canada an448(a)freenet.carleton.ca (finger here for PGP key) ua294(a)fim.uni-erlangen.de

3 2

Re: Cypherpunks@hks.net service
by pfarrell＠netcom.com 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- >> It will sign any message sent to cypherpunks(a)hks.net with its >> (currently 384 bit) key and forward the signed message to >> cypherpunks(a)toad.com. > > No offense, but what's the point? What's next, automated key-signing The point is that if Eric insists on arbitrary rules that threaten the list, some bright c'punk will "write code" to circumvent the assinine rule. Use technology to solve problems... But that is why a number of folks have posted that the rule is at best ill conceived. Eric simply hasn't listented. Thus the recent mini-flame war that again lowers the signal to noise ratio on the list. He wants the world to use encryption. So do I. But the tools are not there for even the net-heads on this list. There is nothing close to tools suitable for Joe Sixpack. Changing the rules on c'punks won't change that. Pat Pat Farrell Grad Student pfarrell(a)cs.gmu.edu Department of Computer Science George Mason University, Fairfax, VA Public key availble via finger #include <standard.disclaimer> - --- [This message has been signed by an auto-signing service. A valid signature means only that it has been received at the address corresponding to the signature and forwarded.] -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Gratis auto-signing service iQBFAwUBLuCljioZzwIn1bdtAQEjewF+N4i7B7kdkeGyi+ggI4PjQAbQ6Uyl+45i mqbyWWGDptWY/nsZOmLmBnX8T64U1JuH =e2n2 -----END PGP SIGNATURE-----

1 0

Re: First Virtual?
by jya＠pipeline.com 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Responding to msg by eric(a)remailer.net (Eric Hughes) on Sat, 3 Dec 9:56 AM Not a big deal, but for Unix-fans who deign toy-PCs, PC Mag of December 20 has two brief pieces on First Virtual, indicating that its mass-market greenbucks are abuying hard pitch Xmas-adcopy. One dim-spots other "digital buck" services SpyGlass and Open Market, cash-poor things. See pp. 32 and 61. [First time use of the sig below, be gentle, still learning how to get PGP-signed message in this mailer.] - -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.2 mQCNAy6rxQQAAAEEANW657bMcILCSaEYHV46DQWojtHDv6UQ2qGz+6wG5g5Q7KMz QkQjM+fYNScW4fDUYH02wLG5x/E5hYwSaYal0k0b6G9m921QKqhVYj2+QzfiMqce N45t4GjSNBdwmNywZEyz5RKXbAWm78DmAt9Ro3M8AGvG1XrsU4Sb9hQ07hCVAAUR tB1Kb2huIFlvdW5nIDxqeWFAcGlwZWxpbmUuY29tPg== =F0Xj - -----END PGP PUBLIC KEY BLOCK----- - ------------------- - --- [This message has been signed by an auto-signing service. A valid signature means only that it has been received at the address corresponding to the signature and forwarded.] -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Gratis auto-signing service iQBFAwUBLuCvBioZzwIn1bdtAQGKqgGAnUpbIyAQ4aE1d0iHHZQLpj8yn2jRHruS oK8hqFI8AI07p0pMGl7kcgm1OefM/zOy =aTQt -----END PGP SIGNATURE-----

1 0

my key
by desert!desert!kafka＠consolat.xs4all.nl 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- - -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6whatever mQCNAiz8ExIAAAEEAMCOBYWuMLd+bWGzyLIO2Nr+jQOydZ3azOVkRtsz0sgaRmep UoMcAdpfAdDp3QzyQ5yzYfw5xqcFqiTJDaSNd0vncAHpsA2gQl727B1blg4qVlDY 5mNlJUG6CVrAq11eqI0pYIfw/uNlysvt/qKIEh4lK4ShLhBaab5mNggyLQMFAAUR tB9LYWZrYSA8a2Fma2FAeHM0YWxsLmhhY2t0aWMubmw+iQCVAgUQLnyB6lnfdBSN VpE9AQGB1QQAqQcj/2Vzml1gb9QsYsfRa9cQYMIn9xlOYcABtkIFiNoVfKnPu8s+ d+RMWCzpFcLjMVVFsS54RyBYF8tQ80ffWJWITQS0MPS8ucZn/RHjht4ZYu81NpY9 V1mG98Enm9HeFNSxcid5Q7VIP17AEUMzSqG3GLMcWKrHz/fBq4UGevG0H0thZmth IDxrYWZrYUBkZXNlcnQuaGFja3RpYy5ubD6JAJUCBRAtWR9SBN4BepzgcqkBAUfx A/4opPXbFsoGg/qvqmQACKXJcVTu0SCYRJlnT10fs8k57Qpz01E7gWqLprJ74JBW Pi9hjPih2AleNVEIiATQC/VFSI1IR293lX3+1UM+ET/D8EZsRlpQqiPw1//GLxAt X8tKjgMI292jyg3rtzcJ1dvlP+9PFX/yNLrHJ39UhrfWbokAdQIFEC3JH5a/Fnjq Veer/QEB7qcC/3DcCtqXAyVVEs5mmrq/aFTgBatg68iU7tLsz1882G2y2avoZla5 WlTVXaSTZhmA9PK+4vbsxOW9TG1avwZDVTKIl7ibQL0z04WOyBYaH1PxLcbjKwUm c2P/Cb8bVO889okAVQIFEC3JH386SFmmUgayqQEBIyEB/il0p2+45H8dFIqiaTt2 1AQP7gzJFzVBeU3McoHFrJMY6IH97jWpwGUICq136kn+8Ry5anW5I4ZmWRO6nmm5 TFuJAFUCBRAttLsHlHKYXXmU9wUBAYc5Af9eXImYLf3OfwvAFXLqFh1LLA3lBqM2 j1BBYibphrCZPq99Bm29ntwm3yfMFKobsNP5tOX6t9RbULo3qMnfyvrZiQCVAgUQ LbSdrFnfdBSNVpE9AQE0awP/Yr3tJmdwBTuHYEr0Jf2YMclLXkkFT1Q1XFim1UZK rDNeJhPJE0ppHR0Qqbmr7GIsLNjU1ThCcS0RnoHA7XA5GkeIO8M+EI4EUFWcxnJq aNKWASZZ0WY4WeLEWgNkYvi2kZ853nvszzIl5mSRu7iZN+CWO3NZEsVeCCeWtkgM EEeJAJUCBRAtsmhKvmY2CDItAwUBAca7BACO6MWkKbkzGpMVXpU8YckWeejod6rw YsWP72/eFxSLj/Hm2bwXvxsrMHbli1h0Vg1qUwXoqjoGFtXsdyTRubBvYNjZWlV7 +c/iKs0nTZjXRd3WINMcxoxNj8ocg+gBgMkkC4sH7bMPFbX1C3mw22l3K7qGnndL gfdRuYe00Vr2gokAlQIFEC2nH78Hrbnp9ffk/QEBmQgD/RmiG3wvn1N6AIQgGZvW mhbStQ6S5ak6wBODMMxcvtoiAwpQ6fMZ8SNFRte33IglC54GCA6Rr1eF+dzLMJ5j PUVph5DkW/bWP/TuY7L8aZFM7M09dN01eqFCRxhNSKWI8yiF6vDigE/Po/INlJB5 JKTjx9TUuyiN/eX8ixJ0eTC+ =io0v - -----END PGP PUBLIC KEY BLOCK----- _______________________________________________________________________________ kafka(a)desert.xs4all.nl Cryptoanarchy, MDMA, Tekkkno, SL-1200 <blink> Kafka's home page _______________________________________________________________________________ - --- [This message has been signed by an auto-signing service. A valid signature means only that it has been received at the address corresponding to the signature and forwarded.] -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Gratis auto-signing service iQBFAwUBLuCy7CoZzwIn1bdtAQGPVQF7BdmQzFQCE3GvRiFWRrfwB10Bwvh9XxEc tKwWorCuX8qmUd8VyajqgHLITJRqPyig =1wO5 -----END PGP SIGNATURE-----

1 0