December 2003 - cypherpunks-legacy

Re: PGP hooks for Pegasus Mail?
by Lynne L. Harrison 17 Dec '03

17 Dec '03

At 09:52 AM 11/28/95 +0000, you wrote: >Anyone done anything regarding PGP hooks into Pegasus Mail? I'm >running it at home now (SLIPped into my Linux box), and I'd like to >find a way to integrate PGP into Pegasus Mail. > >Thanks in advance for any replies... Ed - I haven't heard of anything re: "PGP hooks into Pegasus Mail". At one time, Eudora and ViaCrypt were discussing it but, from what I heard, those discussions fizzled out. The easiest way to *integrate* is to use a front end program. Regards - Lynne ******************************************************* Lynne L. Harrison, Esq. | "The key to life: Poughkeepsie, New York | - Get up; E-mail: | - Survive; lharrison(a)mhv.net | - Go to bed." *******************************************************

1 0

Re: The future will be easy to use
by Jonathan Zamick 17 Dec '03

17 Dec '03

At 10:56 PM 11/26/95, James A. Donald wrote: >At 01:12 PM 11/27/95 -0800, Jonathan Zamick wrote: >> it >> means forming a group, made up of Cypherpunk members perhaps, but much >> smaller, and capable of working together. Also capable of handling not only >> the theory, but good solid code, GUI, PR, meetings, talking to the >> government, etc. > >Skip the talking to the government bit: Ignore, do not confront. I can't agree. The model of a successful enterprise includes feedback from different levels of participants. Regardless, the government will be taking a role in encryption. Thus even if they aren't a defining part of the development, bringing them to a limited extent into the loop, and finding even small areas which the government would support, helps provide better buy-in by the government officials who participate, helping the momentum. The point isn't to bring them into the design, but simply to use their feedback to optimize our PR approach. Jonathan ------------------------------------------------------------------------ ..Jonathan Zamick Consensus Development Corporation.. ..<JonathanZ(a)consensus.com> 1563 Solano Ave, #355.. .. Berkeley, CA 94707-2116.. .. o510/559-1500 f510/559-1505.. ..Mosaic/WWW Home Page: .. .. Consensus Home Page ..

2 1

Re: The future will be easy to use
by E. ALLEN SMITH 17 Dec '03

17 Dec '03

From: IN%"raph(a)c2.org" "Raph Levien" 27-NOV-1995 17:11:37.38 It _is_ doable. I know the skill is out there. Wei Dai, Eric Young, Peter Gutmann, and others have proved themselves quit capable of writing good solid code. Sameer Parekh has done an incredible job with PR. Phil Karn, Dan Bernstein, and some others (who I'm not sure want to be named) are talking to the government. GUI I'm less sure about, but I'd hope that some cpunks would come out of the woodwork. ------------------ If you'd like a non-programmer user to test out the user interface, I'm available to some degree if it's usable on a VAX (and to a lesser degree for MS-DOS). Given the number of people like me who are interacting using a non-GUI interface for various reasons (including using a mainframe for email), I would suggest not making it specifically GUI-dependant. -Allen

3 2

Re: Bitbux could eliminate some domestic currencies?
by E. ALLEN SMITH 17 Dec '03

17 Dec '03

From: IN%"frantz(a)netcom.com" 27-NOV-1995 02:55:15.66 Gresham's law says that the bad money drives the good money out of circulation. Does this mean that real cash is better than ecash ;-). ------------------ You may realize this (due to the smiley), but what Gresham's law says is that hard to distinguish bad money druves good money out of circulation. If something is distinguishable, then it works the other way around (see the replacement of the ruble by the dollar in pre-modern Russia, for instance). -Allen

1 0

Re: The future will be easy to use
by Jonathan Zamick 17 Dec '03

17 Dec '03

At 9:26 AM 11/28/95, Perry E. Metzger wrote: >Jonathan Zamick writes: >> I can't agree. The model of a successful enterprise includes feedback from >> different levels of participants. > >This isn't an enterprise. The government is not a participant except >by their own desire to interfere. > >> Regardless, the government will be taking a role in encryption. > >What makes you say that? Besides, why would that be desirable on any >level? > >The Government will try to set standards and we will ignore them until >they try to force them on us by law, period. This discussion was based on a group of people getting together to create a new easy to use package for handling keys and such. The government is going to try to take a dominant stance, and mandate elements of it. That has to be assumed. Those elements we don't agree with will be ignored or worked around (depending if its government opinion or government law.) However, it is possible, even in an antagonistic relationship, to develop positive feedback. I may be cracked, but I'd like to think that it would be an advantage to find some area where the government and the Cypherpunk members do agree, to minimize the conflict over the areas where we don't. Still, this is getting past the original topic, and gets more into the religious level of whether there can be any cooperation when the two sides are Government and Good/Widespread Encryption. My stance is that currently, no, but that doesn't preclude it in the future. Others don't see it happening at all, or don't see it worth the investment to achieve. That is perfectly valid. --- Returning to the original topic though, do we want to get a smaller list together to spec out some ideas for the project that was discussed? A simple, transparent, tool which would allow people to use strong encryption without having to think about it? I don't have much time to contribute right now, but I can at least put together the list, and some ideas. Jonathan ------------------------------------------------------------------------ ..Jonathan Zamick Consensus Development Corporation.. ..<JonathanZ(a)consensus.com> 1563 Solano Ave, #355.. .. Berkeley, CA 94707-2116.. .. o510/559-1500 f510/559-1505.. ..Mosaic/WWW Home Page: .. .. Consensus Home Page ..

4 7

Re: The future will be easy to use
by E. ALLEN SMITH 17 Dec '03

17 Dec '03

From: IN%"perry(a)piermont.com" 28-NOV-1995 12:49:12.47 "E. ALLEN SMITH" writes: > Phil Karn, Dan Bernstein, and some others (who I'm not sure want to > be named) are talking to the government. If you call lawsuits "talking", not that talking is important. ----------------- Umm... I wasn't the one that wrote that. It was included in the message to which I was replying. -Allen

2 1

Re: The future will be easy to use
by Carl Ellison 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- >Date: Mon, 27 Nov 1995 11:06:13 -0800 (PST) >From: Raph Levien <raph(a)c2.org> > Form this perspective, let's take a look at the recent thread on >"establishing trust." Carl Ellison advocates the MOSS alias system. My >understanding of this system is that individual users associate "aliases" >with public keys. If done right, it can work well. However, from a >usability perspective, it is just one more trouble spot. Yes, it could easily be done wrong in such a way that the user gets confused rather than helped; burdened rather than relieved. I advocate aliases because that's how *I* think. I think in words so I assign my own names (aliases) for the people who populate my mental model of the world. By definition, these are all my correspondents. It's possible of course that some other people (of different Myers-Briggs type, perhaps) think differently -- not in words or aliases. If that's true, we should find out how they think and associate the right thing for them. For example, I had a friend (a painter/sculpter) who thought in images. She might prefer to use little pictures or icons (of her own drawing) as the aliases. > First, on what basis will users decide which keys are worthy of being >assigned which aliases? Public keys are big hunks of base64 encoded >gibberish. They are difficult to present in a user interface, difficult >to communicate in alternate, known secure channels (such as telephone >calls and face to face communication). There is no way that a person >could memorize one. That's true. What the user would have to see is some icon (or, for text-bound folks, a temporary unique string) until the user chooses and assigns the appropriate alias. That icon would have no meaning by itself. It would acquire a meaning by being associated with some message or set of messages: a) an attribute testimony (signed by someone with known authority to specify such an attribute -- the equivalent of a certificate) b) a set of messages signed by the key in question (tying the key to the source material from which the user formed his/her impression of the sender) I, the user, would want to be able to call up the set of defining messages for any key or alias at any time in the future -- just in case I get so many aliases that I forget who one belongs to. > The other issue is how much time and energy the user has to spend >keeping the alias database up to date. There is no way to communicate >securely with anyone who's not in the database. If the user is >communicating with a large number of people, then it's very tempting to >get sloppy. I keep a fairly large database of aliases already, in my .mailrc on UNIX. Eudora permits a similar DB. So do a number of other mailers. Users must be demanding this feature and using it. All I say we have to add to that is protection from tampering. > There's no way around it. This kind of system will not make it in the >big time. I wouldn't be so quick to dismiss it. > As I see it, any system that does must have the following >properties: > > * Some variant on the Web of Trust. Of course -- you have to have some means for communicating and recording attributions (that the person who owns a key is allowed to spend money on a given bank account; that the person who owns a key goes by the name Carl or receives mail at cme(a)acm.org; that the person who owns a key is a trusted developer of PGP; ...). > * Online key-servers for getting keys in real time. > * A clean mechanism for validating keys through alternate channels. These two have to go together -- but I'm curious what anyone means by "validating keys". I see this as the flaw killing certificate structures like X.509 or PGP's. [Even Steve Kent, a major X.509 advocate, seems to see this problem (with sadness, in his case).] I had a secretary once, long ago. I would drive her home from work occasionally -- or to parties -- when her husband wasn't around or wasn't interested in going someplace. One time, in passing, he noted that this arrangement was OK with him because he "trusted her". I trusted her, too. I knew her to be having affairs with various people (not me at the time) but he didn't. So we each trusted her but what we trusted her to be was different. Just saying that we trusted her wasn't saying anything. As soon as you qualify the "validated key" (e.g., to be allowed to spend money, etc.), you get to the signed attributes which I advocate over certificates. If all you do with the validated key is tie it to a text string which purports to specify a human being, as X.509 or PGP do, you haven't done anything for me. If all humans had unique names, then this might mean something to me (assuming I knew the human in question and knew his unique name). However, that's what killed X.509 -- the need for unique names. We don't have them and we're not about to adopt some new social structure which assigns them. Even if we did all adopt unique names, you postulated a *large* set of people to communicate with -- larger than my immediate circle of acquaintances, presumably -- so even a unique name would be meaningless to me because I would not have met the person in question. If the unique name certificate works at all it's because I have some mechanism (not mentioned in the certificate hierarchy design) for attaching attributes to the named person. However, if I haven't met the person in question, I don't have that mechanism already and it needs to be created alongside the certificate mechanism. I don't need testimony about the name (unique or otherwise) of the person who owns that key. I need testimony about the attributes of that person (PGP developer; fellow Cypherpunk; FBI agent; undercover NSA plant; permission to use a checking account; receives mail at xxx(a)yyy.com; ...). That testimony can be provided by referencing the key itself, rather than some (artificially unique) name which exists only to link the attribute to the key. The S/W which links these together and lets me find the various testimonies for a key has to be convenient -- but that was your original point and I concur. I object only to the implication that current certificate hierarchy thinking gets us closer to that goal than the direct signed attribute statements would. > There are three possible outcomes: we build it, the NSA builds it, or >Microsoft/Netscape builds it. This last outcome might not be so bad, but >only in the first one can we rely on our principles being advanced. Amen! - Carl +--------------------------------------------------------------------------+ |Carl M. Ellison cme(a)tis.com http://www.clark.net/pub/cme | |Trusted Information Systems, Inc. http://www.tis.com/ | |3060 Washington Road PGP 2.6.2: 61E2DE7FCB9D7984E9C8048BA63221A2| |Glenwood MD 21738 Tel:(301)854-6889 FAX:(301)854-5363 | +--------------------------------------------------------------------------+ - -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMLtON1QXJENzYr45AQGiEwP+OpETJDPJ8rWbur4oH/PCZqKWtXmzTquV 4QIwoZlXoK6RnZ60szR/qqPxjnj+TtsO8FOQK5lWurv+FG67ma5PfyNbxU+WFapY uxwop8Ivb3bw0uFT2oh2VE5owAYFkmqz7kd7GleEG33dGOUz7jSELugzL4Ag8zRF 40qPwsU7B08= =aeKx - -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMLtOvVQXJENzYr45AQH5RQP+JroFSz3bJapOGEqA2pfhZ1dn9d7VDEUd h/JLbhFkgYbzMGsVzpu20Ww0uOsOwxQR2ItLkaSlTG0O76rgATE2Cma9LEvdoque LMgN/xg0GmaSHoecHLuKJxRz/1xreKODuai2FvndyjspfgO/H6zrQOfhsWn3qa6a ZqnNaEY+kXw= =cuUk -----END PGP SIGNATURE-----

2 2

Who has the right to read your e-mail? Old hash, but I need to ask.
by (Bill) 17 Dec '03

17 Dec '03

A recent incident brought this up at work. If someone could point me to a site that would help explain the in's and out's of the laws regarding the following - Who has the right to read your personal e-mail. E-mail created at work? E-mail downdloaded at work? E-mail stored on a PC at work? Thanks vwbug(a)iadfw.net

1 0

Re: PGP hooks for Pegasus Mail?
by Siberia 17 Dec '03

17 Dec '03

It is happening...about a week off from the first beta release. Announcements will be posted to the Pegasus mail support lists and bit.listserv.pmail (as well as other appropriate posting spots). >Anyone done anything regarding PGP hooks into Pegasus Mail? I'm >running it at home now (SLIPped into my Linux box), and I'd like to >find a way to integrate PGP into Pegasus Mail. > >Thanks in advance for any replies... > > Ed - Namaste' Kimberly Long klong(a)phoenix.net Standing on the bare ground...all mean egotism vanishes. I become a transparent eyeball; I am nothing; I see all; the currents of the Universal Being circulate through me; I am part or particle of God. ~Ralph Waldo Emerson )O(

1 0

Re: [NOISE, sorta] Re: Inexpensive Crypto Boxes...
by Bill Stewart 17 Dec '03

17 Dec '03

At 10:04 AM 11/28/95 -0500, Mike Fletcher <fletch(a)ain.bls.com> wrote: > For those who don't know, the PSX is a CD based gaming console >released (in the US) in Sept by Sony. It's a MIPS R3000/25MHz processor >with some SGI-designed polygon chips, 2x CD-ROM, 1M RAM, 2M video RAM. There are a number of reasonably powerful game machines under $300, though that uses TV-screen video, which isn't enough for decent text; doing a $500 machine with a real monitor should be quite possible. However, to make it functionally useful, it needs at least a connector for a a disk drive - couch potato web-surfers can skip it, but anybody who wants to do real work will spend the $100-300 to add a disk, and probably add a CD-ROM as well. Without a disk, you can't do off-line reading, which significantly affects anyone using pay-by-the-hour network access services. (I used to use a diskless Sun with 40 MB RAM on an Ethernet, and it was usually fine, but I was motivated by not wanting a fan on my computer...) ObCrypto - you _can_ do decent crypto on a diskless machine as long as you've got some non-volatile storage for keys; a few KB should do, and the main applications would have to run in ROM. > The line between toy and real machine is getting more and >more fuzzy (we use a box here at work with the same processor to compile >for an AT&T telephony switch (which tells you how sad the AT&T product >is :) :))). Telephone switches don't need high-power CPU-crunchers, and the R3000 was quite a decent processor. They need clean, stable CPUs and appropriately-designed operating systems which are good at controlling lots of polled I/O devices - it's a PDP-11 job, rather than a Cray job. Generally the OSs have been hand-rolled, though it's becoming much more practical to use Unix to develop user-interface applications now that processors are fast enough to have short interrupt times. The previous switches used Intel processors - 386s let you do more than 8086s, pulling applications into the CPU instead of low-level logic. >How long until the NSA tries a Chinese Lottery attack hidden >inside a Nintendo cart? You've read "The Hacker and the Ants", haven't you? :-) #-- # Thanks; Bill # Bill Stewart, Freelance Information Architect, stewarts(a)ix.netcom.com # Phone +1-510-247-0663 Pager/Voicemail 1-408-787-1281

1 0