December 2003 - cypherpunks-legacy

Transparent Email (WAS disable telnet to port 25)
by Alex Strasheim 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- > I don't have an answer to your question, but you did bring up something > I've been meaning to ask about for some time and I never really got > around to it; Are there any short-term plans to press for an RFC > utilizing digital signatures? With the exponential increase of mail > users, as well and the influx of Compu$erv, AOL, Prodigy and other users, > some methods for the transparent use of digital signatures needs to be > worked out before it becomes too difficult to implement change because > the commercial services have all the power. (or worse, before the > government decides for us.) Some still unformed thoughts on this subject: The big problem with transparent encryption and signatures is key distribution: if you've never sent a letter to me, your mailer will have to get my key (invisibly) before the mail can be sent. The big problem with key distribution is the web of trust: who gets to decide which keys are good? This is a subtle advantage that systems with centralized key generation have over systems like PGP, which let users generate their own keys. If big brother mints all the keys, then big brother can set up an authoritative keyserver. The best answer that I can come up with for this problem is to allow for several webs of trust to function simultaneously. Perhaps we would have a default web, which would have everyone's key in it. The idea behind the default web is that it should be able to return a key as often as possible, so we don't want to make it too difficult to submit keys for this web. But anyone else could devise his or her own web, and administer it however he or she pleased. A request to a keyserver would include a list of webs, in order of preference, that the user would be willing to deal with. At the end of the list would be the default web, in case nothing better was available. A web could be defined by a single top-level public key and a set of rules. Perhaps a text based program -- a sort of "meta-pgp" -- could check chains of signatures to validate a key. Suppose, for example, that I'm administering a web of trust. I set up the web so that I can deputize notaries who can in turn sign user keys. Lets further assume that all signatures are good for a year. A keyserver would return a text file containing: (a) the user's key, concated with a header specifiying the date it was signed by the notary, and (b) the notary's key, concated with a header specifiying the date it was singed by me. We'd want "meta-pgp" to be able to handle complex rules which would give it the flexibility to implement a wide variety of webs. Perhaps it could use prolog-ish style induction to determine if a key was good. Does this make sense? Is it something that was already proposed and discarded? == 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 iQCVAwUBLtmV+hEpP7+baaPtAQH3kgP8DmycpNrZKQRpyK1rclxJnIY2bdT5m4iM p7IQ7nI07PSMn+ldye2xG5jjms42CR0BVvk4hhdGzDJwcgdd3FHFC7xNHvhk+SOE 4EHqpyW+YdNSe3A7+sMZp30mgWEnvHOpnrU9UiMUIaC8gcLk3GlkXdxDG+SWGwv/ 1yesnbaUxYM= =p2UQ -----END PGP SIGNATURE-----

2 1

CALLING "CAPT'N BOB"
by Sandy Sandfort 17 Dec '03

17 Dec '03

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ SANDY SANDFORT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C'punks, BANDWIDTH ALERT: If you are not "Capt'n Bob" this message is a complete waste of your time. "Capt'n Bob, I send a message to your anonymous address; it bounced. Please send me a better address by private e-mail. Thanks, S a n d y ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

1 0

Re: Transparent Email (WAS disable telnet to port 25)
by norm＠netcom.com 17 Dec '03

17 Dec '03

At 1:34 AM 11/28/94, Alex Strasheim wrote: .... >The big problem with transparent encryption and signatures is key >distribution: if you've never sent a letter to me, your mailer will have >to get my key (invisibly) before the mail can be sent. The big problem >with key distribution is the web of trust: who gets to decide which keys >are good? .... If I have never sent you mail, consider how I got your e-mail address? You could have sent your public key to me along with your e-mail address. If your public key is too big you could include a phoneticized secure hash of your public key and I could check big brother (the CA). I suspect that initial bits of a public key serve pretty well as a secure hash. Perhaps all email addresses should be accompanied by such a hash. The more initial bits the harder to find a fake public key with sutiable mathematical properties and initial bits that agree with your real pulic key. If an email address and its associated PK are sent thru unauthenticated channels a man in the middle can substitute the PK. In the same situation, however, the man in the middle can substitute the email address! ....

2 1

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: A possible solution
by jrochkin＠cs.oberlin.edu 17 Dec '03

17 Dec '03

At 5:35 PM 11/28/94, Aron Freed wrote: >Ok. You all have basically defeated the stiffer fines issue. > >The one issue remaining is do we want to live a life of anarchy. That depends on what you mean by "anarchy." I'm sure there are a few anarchists on the list, but they probably don't mean the same thing as you do by "anarchy". > Do we >want to live in total isolation? Do we want to be completely paranoid and >be always looking over our shoulder? Many of us already are. Except the kind of rules you are describing would increase our paranoia, not lessen it. The people we're already looking over our shoulder for are the people who would be enforcing the rules you are proposing. >You tell me how we solve that >problem. I still don't understand what "that problem" is. How does the existence of cryptography (which is of course what started this discussion. fittingly, since we're on cypherpunks here) make anyone live in total isolation, or be completely paranoid, or be always looking over his shoulder? I don't understand how strong cryptography does any of those things. What exactly is this "problem" that you see, and how is it related to cryptography? >I for one do not want to touch "1984" territory, but I don't >want to live in an anarchy either. About half the people I talk to think we're already "touching" _1984_ territory, and about the other half think we're already living in an "anarchy", so appearantly it's in the eye of the beholder. They mean "anarchy" in a negative sense of course, the same as you. I wouldn't mind living in an anarchy if it's the kind Mikhail Bakunin or Emma Goldman or Alexander Berkman or Petr Kropotkin advocated. You might pick up a book by any of those authors at your local public library, you might be surprised.

2 1

Re: Interfacing PGP with Pine (Script pointer)
by jamiel＠sybase.com 17 Dec '03

17 Dec '03

At 7:47 AM 11/25/94, Michael Handler wrote: > For a well written script to interface PGP with Pine: > > finger slutsky(a)lipschitz.sfasu.edu | pgp -f > mkpgp.txt.uu > > If you don't have finger access, mail me privately, and I'll send >the file to you. If you don't mind, could I have a copy? finger is disabled here... thanks, -j

1 0

I promise never... (Was: Re: Interfacing PGP with)
by jamiel＠sybase.com 17 Dec '03

17 Dec '03

to send mail before having my coffee and checking the cc:line again. Honest this time. -j -- On the internet, no one knows you're a deity. ___________________________________________________________________ Jamie Lawrence <jamiel(a)sybase.com> Soon ---------> <foodie(a)netcom.com>

1 0

Re:
by RGRIFFITH＠sfasu.edu 17 Dec '03

17 Dec '03

> >Realizing this is somewhat off-topic, has anyone heard of the >'internet liberation front'? > >- spooge > > According to today's WSJ it's the name used by hackers who broke into Pipeline Services, an Internet access provider in NY. Their intrusion was detected and stopped before major damage was done. They posted a message that "warned corporate America against commercializing the Internet into a 'cesspool of greed'."

1 0

Re: School Admins
by Ferguson 17 Dec '03

17 Dec '03

(My apologies for losing the article to which this is relevant) This is in regards to compiling PGP, and distributing it to those of us who are on restricted systems. My provider, the state government does not allow me (or anyone else) to use cc. The platform is DEC Alpha OSF/1, and if anyone has access to a compiler and would be willing to put the binaries for PGP(preferably 2.6.2, but I'll take what I can get :) and/or gcc up for ftp somewhere, I would be very grateful. Brad

2 1

Re: Transparent Email
by Alex Strasheim 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Ok, I should start off by saying I'm not sure I followed everything Eric said in his post, so this might not be a great answer to him. My proposal isn't for an all inclusive, everything to all people, security system. It certainly would't preclude people from using other, stand alone systems, from using multiple sets of keys, or whatever else they wanted to do. My posts were predicated on the assumption that transparent encryption and signatures are worthwhile and necessary. By "traansparent encryption and signatures", I mean email systems that work and look pretty much like the programs we're using now -- elm and eudora, for example -- but which do crypto work automatically, behind the scenes. I think we ought to be moving in that direction, for two reasons. The first is that most people -- including most of us -- aren't willing to do much work in order to sign and encrypt our email traffic. If there's any penalty at all in terms of convenience, most people probably won't use a secure system. The second reason is that I believe it's only a matter of time until someone else institutes a transparent, reasonably secure email system. What would happen if Microsoft instituted a secure email system for their online customers, but took control over keys away from users? I think that the result would be that everyone would embrace the new system, because it would be a gigantic improvement over the status quo. We would compare the new system to an idealized vision, in which everyone has total control over their keys, who they trust, and in which law enforcement officials can't retrieve secret keys at will from some central repository. But everyone else would compare the new system to what we have now: an email system which is vulnerable to forging, and which isn't secure enough to transmit credit card numbers. I think that if we can't field an alternative, usable system, something that's practical and easy to use, we're going to lose by default. I'm not under any delusion that what I've proposed is some kind of magic answer. I'm not a heavy hitter, in a technical sense, like Eric, Hal, Tim, and many of the others here are. But at the same time, I think there's some need for compromise. We need a transparent system that can embrace people who aren't willing to put a lot of effort into security, but at the same time is able to accomodate people who want to take more trouble for the sake of their privacy. > This whole area of key distribution has generated much confusion. A > perfect world is described, and then everyone is assumed to > participate in achieving this world. This approach of generality, > however, is notably more complicated than a world where responsibility > for security is partitioned, where each user does not have to worry > about all the possible systemic security issues. I understand this criticism. But if we abandon generality, I don't think we can achieve transparency. And as I said before, I think a transparent system is going to come out on top. It's true that what I proposed is complicated, but a lot of the net is pretty complicated when you take off the lid. I think it could still be made usable. > Proposition: You don't need to be responsible for making sure that the > other person is being spoofed; that's their responsibility. > > A common situation where this proposition makes a significantly > simpler system is exactly in the case described, where you and your > email correspondents wish to exchange keys. Suppose, in addition, > that you two met online and that your only channels of communication > are electronic. The goal here is to create persistence of identity; > identification with a physical body is not needed. Actually, I wasn't trying to identify keys with physical bodies, but rather with email addresses. But the whole point of the system is that there is no need for the two correspondents to worry about exchanging keys: it all happens automatically. People who are doing unusual things, like creating nyms, would of course be free to take unusual actions. > In the PGP case you start with your own key, which you trust, then > look for a chain of signatures to the destination. This chain can be > rather cumbersome to produce. It's overkill, as well, since all you > really needed to know is that the key was not being translated on your > own end. The PGP trust chain largely accomplishes that, true, but not > as simply as possible. I'm not sure I follow the last part of this. > Alternatively, you save the first piece of email that you receive from > your correspondent; it has a digital signature on it. Now _by > whatever means_, you obtain a public key by which to verify that > signatures on email you receive are the same. You yourself need to > ensure that you aren't getting spoofed; you can do this by, say, > having your correspondent send mail to two different locations, or by > using a second channel to obtain the key by, or by using a PGP trust > chain, if one is available. Again, I go back to my goal (which wasn't stated clearly enough in my original posts, to be sure) of transparency, and of trying to get the bulk of day to day email encrypted. > The original model for public key communications seems to have been > one channel with an interposer. The real world is much more > complicated than that. One can obtain good protection, at least as > good as a trust chain, by crossing organizational boundaries. The > argument that trust chains are better because they are cryptographic > carries no weight; the decision at each link to make a signature is of > social, not cryptographic, character. I agree with this 100%. This is part of what I was trying to accomodate. On the low end, we have a default web of trust, which is sort of crummy because it's not terribly difficult to spoof. Cryptographically, it's very sound, but socially, it's quite weak. But my goal was to meet this criticism by making the system open to other webs, and to place as few restrictions as possible on people who want to create and use alternative webs. Those alternative webs could tie email addresses and keys to physical persons, or to nyms, or to anything else they wanted. They could be as rigid or as lax as they pleased. And we as users could decide which webs we were willing to trust. > In particular, the design of PGP that ties key management inextricably > to encryption is bad and will contribute to an inflexibility that will > eventually sink PGP if it is not corrected. Could you elaborate on this? > Perhaps we would have > a default web, which would have everyone's key in it. > > This is a really bad idea. Some "public" keys should not be made > public, but rather revealed only to the correspondent. Forward > secrecy is the reason. If the public key has never been in the > possession of an opponent, and assuming the results of the public key > operation yield little or no information about the modulus, then when > the keys are changed and destroyed, no amount of factoring can find > the private key because the public key isn't around to factor. You could still do this. I did not phrase this well, and I can see where your concern comes from. I have a few nyms, and I don't publish all of my public keys. I didn't mean to imply that all public keys ought to be on the default web. I meant that you ought to be able to get *a* public key for an aribitrary address from the default web. I have used a couple of nyms over the past couple of years, and I haven't published those public keys or tried to associate them with my email adddresses. That would be, as you pointed out, a bad idea. But at the same time, I have a public key for my address here, alex(a)omaha.com, that I want to publish as widely as possible. Right now, it's available via finger at astrashe(a)nyx.cs.du.edu. The system I proposed is just an elaborate (probably too elaborate) substitution for getting the key via finger, with the intention of making transparent secure mail possible. Basically, it comes down to this: in a transparent system, if you want to mail me, somehow your mailer will have to get a copy of my key without your doing anything about it. More importantly, your mailer will have to decide if it should trust the key it retrieves without asking you. Otherwise, it wouldn't be transparent. The problem is: how do we let the machine make this decision on it's own, without imposing a single web of trust on users? That's what I'm trying to get at. > Eric > Thanks for the thoughtful response, I appreciate it. == 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 iQCVAwUBLtpn7xEpP7+baaPtAQHoIgP/SmOcR2a8PXEwHdF5ROfTmQ2GVxg0ZhlY LYvUKFB+phV7RZAjlP3OCpEjchxTpzaiJFgM4+wtKulrD0ZdGfyF6iGM+K8OTAql lWMfJ25/AvfTlqfBlZ0TAX4hkEWF5r3D65TpncgR7VOF8XErmFPPEvVCvZhx6Rd/ koZmgdTIoXg= =vJqj -----END PGP SIGNATURE-----

3 2