- cypherpunks-legacy - lists.cpunks.org

Re: TIS--Building in Big Brother for a Better Tommorrow
by Bill Stewart 17 Dec '03

17 Dec '03

>At 12:19 AM 2/23/96, P.J. Ponder wrote: >>The first paragraph here bothered me. If a user (or an organization) >>needs to have access to data that was encrypted by an associate ( or one >>of its employees) wouldn't sound practice require that the key not be >>entrusted to just one person? I don't see the need for any fancy >>"key-recovery" protocol with any outside entities. We can handle this >>internally in my shop. Some keys I give a copy to Alice, and down the >>hall Bob has some, too. If I get hit by the bus, they can get my company >>related data back. We don't need any "service" or "licensee" or "trusted >>third party" or any of that, thank you very much. And we don't need any >>one developing OTPs for us either, and we don't need government agencies >>keeping copies of any of our keys. Hear, hear! A decade or so ago, when I was a tool of the Military-Industrial Complex, we had key escrow and trusted third-party products, but they were appropriate technology - Big Ugly Safes that were rated for classified storage. If you had data or (physical) keys or safe combinations you wanted to protect, you could put them in the safes in the computer room or security office. The main thing we used the latter for was the combination of the computer-room safe, which we kept in a sealed envelope for emergencies. The same technique can work just fine for crypto keys today. If you'd rather use electronic storage than sticking floppies in a safe, encrypt the password with Corporate Security's public key, and email it to them with a Subject: line explaining what it is. Retrieval is easy, and it's _not_ automatic; a human needs to be involved, which is a Good Thing - this is _supposed_ to be an emergency backup. If you don't trust it, split the key and email to two different Corporate Security Management folks. If you don't trust the users not to send bogus keys, you shouldn't be trusting them with the information the keys protect. (System V being what it was in those days, we protected the root password to our computer by giving it to all the technically competent users so they could reboot the VAX or exceed system limits to get their work done. :-) #-- # Thanks; Bill # Bill Stewart, stewarts(a)ix.netcom.com / billstewart(a)attmail.com +1-415-442-2215 # http://www.idiom.com/~wcs Pager +1-408-787-1281

1 0

No Subject
by Raph Levien 17 Dec '03

17 Dec '03

Here follow one cypherpunk's impressions of the Internet Mail Consortium's Security Workshop (http://www.imc.org/security-workshop.html) on Wednedsday 21 Feb 1996. Since there will be official notes of the proceedings, I felt I had a little more scope to convey mood and feelings rather than dry technical facts. After all, I think the buzz will do more to determine what gets deployed than the technical merits. This document is available on the Web at: http://www.c2.org/~raph/report.html The setting ----------- Paul Hoffmann and Dave Crocker recently started the Internet Mail Consortium (http://www.imc.org) This workshop was its first major activity. Dave Crocker moderated the event, skillfully herding almost 70 secure email proponents and representatives from user communities through a very tough subject. The title of the workshop was "Resolving email security," but there was no real expectation that the issues would be resolved that day. What was expected (and what happened) is that people would get a better understanding of why secure email hasn't happened yet, what kinds of things could be done to make it happen. More impressively, there was "room consensus" for a few _very_ positive steps, about which more later. One of the goals of the IMC is to involve users, not just developers. I was ready to "officially" represent the "cypherpunk user community," but fortunately, I didn't need to. In fact, the strongest advocacy of strong crypto came from an employee of a "large service provider in America." Overall, I felt that the user communities were pretty well represented, and all important technical points got made. MOSS is dead, long live MOSS ---------------------------- There were five contenders on the field going into the day, and two and a half at the end. MOSS was one of the casualties. A lot of us were sorry to see it go, but eliminating candidates has got to happen if we're going to have interoperation. It's hard to say exactly what went wrong. MOSS had many advantages, and was a nice, clean, pretty standard. I think what doomed it was the lack of a good implementation. Even though MOSS is no longer considered a serious contender, one piece of it is still very much alive: the multipart/signed message format. At the end of the day, there was strong, nearly unanimous consensus that multipart/signed should be recommended as the signed message format for _all_ of the email encryption protocols. S/MIME: you can dance to it --------------------------- There was a lot of energy around S/MIME. People are implementing it. Internally, it's pretty kludgely, but it does provide pretty good cryptographic services. (as an aside, my favorite kludge anecdote is the fact that X.509 certificates use an IA5 character set rather than ASCII, so that the @ in email addresses has to be represented as (a) instead). The main thing people didn't like about the existing S/MIME spec is the signed message format. In the existing spec, you've got a choice between a message unreadable to non-S/MIME-aware clients, or duplicating the data. Neither alternative is very palatable. Apparently, though, a new version of the S/MIME spec _will_ incorporate the multipart/signed format of RFC 1847. This made almost everybody happy, although I'm sure all those S/MIME developers are a bit unhappy with the spec changing, and having to reimplement stuff. The biggest problem with S/MIME is that the signed and encrypted format reveals who made the signatures. Obviously, this has severe consequences for anonymous mail. Believe it or not, a lot of people care. For example, the car manufacturers do not wish to broadcast the email addresses of their employees over the net. One technical workaround is to do it the MOSS way - first, sign the message, resulting in an intermediate S/MIME message, then encrypt that into a second S/MIME message. I'd recommend that implementors make provisions for such recursive formats; I think it's likely that we'll see a lot of these on the Net. PGP: troubled, but still alive ------------------------------ The consensus was that S/MIME and PGP/MIME are the two viable email encryption protocols. Thus, PGP is still very much alive and kicking. PGP's fabulous strength is that it won't let you down cryptographically. That simply cannot be said for the other contenders. That said, much about the PGP effort troubles me. Perhaps the biggest problem is that there just aren't enough people working on it. >From what I understand, it's pretty much just Derek and Colin, and there's a _lot_ of work to do. I said before that I didn't think the public PGP/MIME release will happen until this fall, and I see no reason to change my estimate. By that time, a lot of S/MIME implementations will already be deployed. One strength of PGP has traditionally been its unity. PGP means one message format (the PGP one), one suite of crypto algorithms (the PGP one), one key format (the PGP one), one application (PGP itself). Most of the other proposals are modular in some way, especially with respect to algorithms. PGP is moving in that direction. The most visible evidence of that is the way PGP/MIME is being done. The prevailing philosophy of the PGP people is that the PGP application itself should not decode MIME formats - that should be the job of a separate application. It seems to me that this is going against the tradition, though. In the past, if you got a PGP message, you just ran it through PGP. Now you won't be able to do that. Also, the existing data formats (while pretty good) are going to get changed. The algorithms are going to "go modular" (although I don't think we'll be seeing a Fortezza implementation any time soon). This is going to cause a lot of pain for the installed base. Will it be worth it? We'll just have to see. MSP: not as bad as you think ---------------------------- Earlier, I mentioned that two and a half protocols survived the day. The remaining one is MSP. It's actually not a bad protocol. It has two features that none of the others have: the ability to label classified messages, and a cryptographically strong signed receipt. Both of these functions are highly important for government users. It looks like government suppliers are going to go ahead and implement it, and the government is going to use it. MSP has been around a while, but the effort to turn it into a serious alternative for general Internet use is quite new. Two specs got published this month: a MIME integration spec (sharing the same problems as the old S/MIME), and a spec for plugging in the RSA algorithm suite. With these specs in place, MSP would not be fundamentally that different than, say, S/MIME. My feeling is that the main differences are cultural. MSP still has a very ASN.1, OSI, governmental flavor. Its proponents are making the effort to be responsive to users, but I think there's still a bit of skepticism about that, perhaps misguided, perhaps not. It was announced that there will be a free reference implementation of MSP, available to US citizens. My kingdom for 40 bits ---------------------- I've been thinking about the 40 bit thing a lot. It makes me very uncomfortable. From the cypherpunk perspective, this should be nothing new or remarkable, but keep in mind that there's a _lot_ of pressure on companies to be able to make money in overseas markets. In one of the "modular algorithms" designs, it's not easy to figure out which algorithms your recipient can understand. Guess wrong, and your message goes out with 40-bit encryption. In my opinion, this is worse than no encryption at all, because it gives the false sense of security. Building such a failure mode into an email encryption protocol strikes me as a bad idea. This is my subjective impression, but I sensed that there was a collective delusion that US software developers would actually be able to sell a 40-bit product overseas. Certainly, Netscape has proved that it is possible, but then again, encryption is peripheral to the value of their product. You'd still be using Netscape even if it had no encryption at all, wouldn't you? How many https: URL's are even in your history.db file? For a "secure email" product, it's a different story. There were a few other things that led me to the conclusion of a 40-bit delusion. First, people still seemed to thing that the cypherpunk 40-bit cracks were a concerted effort by highly expert people, rather than the weekend hacks that could be duplicated by any competent sysadmin or grad student. I don't think the message really got through. If 40-bit email gets deployed, we need to make a few more high-profile cracks just to hammer it in. Finally, there's an almost religious belief that making the choice of algorithms indepenent of the encryption protocol will somehow solve the problem. From the point of view of the user, this is just not true. What the user selects is an encryption protocol, an algorithm suite, and whatever other parts of the spec were left open. What the user selects doesn't have any modularity in it at all. It's either a good protocol or a bad one. Maybe customers today think that 40-bit encryption offers some value, but I think they'll soon be disillusioned. This is something that cypherpunks can have a role in. In the medium to long term, it will become clear that 40-bit encryption offers no benefits, and in fact is dangerous. My advice to US developers: don't even try to export a 40-bit version of your product. Just leave crypto out of the export version. Your product will have better performance and many fewer configuration problems. Include 40-bit in the US product if you have to, but don't allow it to be used silently. For example, put up a little dialog that says, "are you _sure_ you want to use 40-bit encryption? It's not secure, you know." If care about offering crypto in the non-US market, form a partnership with overseas developers to add the crypto. Non-US developers, now is a fabulous opportunity. Get those implementations underway, the sooner the better. Coexistence ----------- Since there is no one single standard that everyone feels comfortable with, we will somehow have to deal with the coexistence of multiple conflicting protocols. Fortunately, this is something the Net is good at. Most serious email vendors plan to "implement everything that's real." That means S/MIME for sure, PGP/MIME assuming they can get their hands on a decent implementation, and MSP if they sell a lot of stuff to the government. If everyone follows this path, then we really will have interoperable secure email. Perhaps over the long term, one of the standards would come to dominate, perhaps not. I know that the deployment of secure email has been a year away for the past decade or so, but now I think it really is poised to happen. The implementation effort is very much real. Over the next few months, we will see some very high profile, mass market implementations. Before that happens, though, the protocols must actually become stable. It's a characteristic of _all_ of the viable protocols that they're still in flux, still in the process of being defined. But at least the direction is clear, largely as a result of feedback from this workshop. Consensus --------- At the end of the meeting, Dave asked the room for consensus on several points. First, there was strong consensus that the encryption protocols converge on multipart/security for their signed message format. Second, it was agreed that the proponents of the surviving schemes get together to list their differences, justify these difference, and commonalize things that don't _need_ to be different, also agreeing on a timetable concluding at the Montreal IETF meeting. I'd say that's quite a remarkable achievement for a such a difficult area. Raph Levien

3 2

Re: Hash of plaintext as key?
by Bill Stewart 17 Dec '03

17 Dec '03

At 09:56 AM 2/22/96 -0800, John Pettitt <jpp(a)software.net> wrote: >I have this application which encrypts software prior to distribution. I'd >like to pre-encrypt most of the data (individual files) and then just >encrypt all the individual file keys with a customer specific key at run >time. (This is mostly a CPU cycle saving thing). Depending on the security environment you're running in, this can be fine or can be dangerous; think about your threat models carefully. For some applications, it makes a lot of sense. It does give you a traffic analysis problem - Eavesdroppers can tell that you sent the same document to Alice, Bob, and Eve, but not Fred, in case this matters to you. You could strengthen it a bit by superencrypting the copy you send to the user with a very fast Snake-Oil algorithm, but Eve has the real document (and the version encrypted with the good algorithm), so she's got known plaintext for cracking messages sent to Alice and Bob if she wants. In a DES world, you might do almost-triple-DES by encrypting with two common keys up front and use DES with separate third keys for the final stage. With RC4 or RC5, that doesn't gain you much, since the difference between RC4/40 and RC4/256 is all in the key-scheduling phase, not the bulk part. >I thought I'd use the MD5 (or SHA) hash of the plaintext as the key. Plenty >of entropy in the entire plaintext, a different key for each file and if you >know the plaintext to calculate they key you don't need the key anyway! It doesn't really gain you anything; generating pseudo-random key bits isn't much work compared to encrypting the files or public-key encrypting the file keys to send to users, and there's no benefit other than getting some extra entropy bits (which you may want to do anyway to stir into your entropy pool in addition to using a random number source.) What it does risk, in case this threat matters, is that somebody who can guess the documents you might be encrypting can calculate their MD5s and trial decrypt. This lets them verify whether a given document is in the encrypted database, for instance. One of the NSA Rainbow Books discusses secure databases - maybe Purple or Gray? #-- # Thanks; Bill # Bill Stewart, stewarts(a)ix.netcom.com / billstewart(a)attmail.com +1-415-442-2215 # http://www.idiom.com/~wcs Pager +1-408-787-1281

1 0

SET spec available
by John Pettitt 17 Dec '03

17 Dec '03

The SET transaction spec is now available on www.visa.com (and presumably on www.mastercard.com although I didn't check). Highlights are: It cops out on the big one - how to identify card users in the first place to issue certificates. The MS/Visa 'credential' that looked like a certificate but wasn't has been replace by X.509 -- John Pettitt email: jpettitt(a)well.sf.ca.us (home) jpp(a)software.net (work)

1 0

Re: pcmcia
by geeman＠best.com 17 Dec '03

17 Dec '03

At 10:58 AM 2/22/96 +0000, you wrote: >I am just assuming that the Association (PCMCIA) has a way of distributing >specs, etc. You can call them in San Jose, CA @ 408 433 2273 $475.00 for non-members, paper only. $715, paper/CD both. >I also assume they have a web page and all that, maybe >even a citizen-unit subscribed to this mailing list who probably could >point us in the right direction. www.pc-card.com, I believe >I think PCMCIA cards offer a lot of >potential as wallets and general purpose privacy prophylaxis engines. Absolutely, and without doubt. They are coming. >I don't know anything about the technology, but the device drivers, et al, >could be publicly reviewed and recompiled on trusted machines, presumably, >and the device itself could be tested (I assume) with a publicly >available routine that once again one could install from source, etc. There are commercially available drivers, tested rigorously. Fortezza cards and s/w are very solid, as well as other cards derived from that type of technology. Fortezza cards are self-testing. > >how much do the slots cost to add on to pc's that don't already have them? >Is there a parallel interface, for instance, that can plug into a >printer port? SCM Microsystems, 408 370 4888 has a "Swap Box" product. I don't know the cost. >-- >PJ >------------------------------------------------------------------------ > >On Thu, 22 Feb 1996, Adam Shostack wrote: > >> P.J. Ponder wrote: >> >> | obligatory crypto comment: has anyone looked at the iPower card and >> | gotten one to play with? Where else could one get a PCMCIA card that was >> | programmable and had a little memory on it? How hard would it be to make >> | one - in other words, what could we get the cost down to for an >> | encrypting pcmcia card? there couldn't be much to it, really, could there? >> >> I got one, its very badly documented; theres some source in >> Visual basic for windoze. I haven't had time to track down real docs >> so I can do anything. Anyone know who I can call to get real >> documentation? >> >> Adam >> >> >> -- >> "It is seldom that liberty of any kind is lost all at once." >> -Hume >> > >

1 0

Re: Some children are rabid and need to be put down (fwd)
by Jim Choate 17 Dec '03

17 Dec '03

Forwarded message: > From: Eric Cordian <emc(a)wire.insync.net> > Subject: Re: Some children are rabid and need to be put down > Date: Fri, 20 Feb 1998 23:18:04 -0600 (CST) > Now she may have a legitimate problem, and may have started biting and > scratching in response to the counselor saying - "Good morning. You look > lovely today." Apparently the girls problems had been going on for a while, if the reports are accurate. Which raises the question of why she was still in a regular school environment in the first place. If it was a 'all of a sudden' attack then perhaps the instructor needs some looking into as well. I'd like to know what the 'significant blood loss' from scratches was refering to, as well as what experience the teacher had with the child prior to this. > It is rarely useful to take things like this at face value, especially > given the spin control talents of school administrators and the teachers > union. Agreed. ____________________________________________________________________ | | | When a man assumes a public trust, he should | | consider himself public property. | | | | Thomas Jefferson | | | | | | _____ The Armadillo Group | | ,::////;::-. Austin, Tx. USA | | /:'///// ``::>/|/ http://www.ssz.com/ | | .', |||| `/( e\ | | -====~~mm-'`-```-mm --'- Jim Choate | | ravage(a)ssz.com | | 512-451-7087 | |____________________________________________________________________|

1 0

Re: Internet shutdown Feb 29?
by sethf＠MIT.EDU 17 Dec '03

17 Dec '03

> This looks completely, totally, and insanely bogus, but I Yes. It would have made a good April Fool's joke. No reality to it whatsoever. > Anybody from MIT ever heard of "Kim Dereksen"? No such person listed as being employed at MIT. You can check how to use the MIT on-line directory by finger help(a)mit.edu There's also no "Interconnected Network Maintenance staff" at MIT, that I know about. > your users will be able to read it. Please pass this message on to other > sysops and Internet users as well. Thank you. This makes it a chain letter. NO! ================ Seth Finkelstein sethf(a)mit.edu

1 0

Re: Conference report - resolving security workshop
by Bill Stewart 17 Dec '03

17 Dec '03

At 04:55 PM 2/22/96 -0800, Raph Levien <raph(a)c2.org> wrote: > The biggest problem with S/MIME is that the signed and encrypted >format reveals who made the signatures. Obviously, this has severe >consequences for anonymous mail. Believe it or not, a lot of people >care. For example, the car manufacturers do not wish to broadcast the >email addresses of their employees over the net. > One technical workaround is to do it the MOSS way - first, sign the >message, resulting in an intermediate S/MIME message, then encrypt >that into a second S/MIME message. I'd recommend that implementors >make provisions for such recursive formats; I think it's likely that >we'll see a lot of these on the Net. Recursive-capable formats are clearly the way to go; the difficult problem is deciding how many layers of recursion to do while decoding (e.g. all the way down, or one layer at a time asking the user for each round), which is largely a user-interface issue rather than a platform issue, though it also lets you build limited-purpose tools instead of an all-singing, all-dancing camel of a platform. Unfortunately, the formats being considered give you too much known plaintext to make triple-encryption a useful way around the 40-bit-key silliness. */MIME has MIME headers, PGP has the (expendable but present) ------BEGIN. A new MIME header like X: parameters where parameters are ignored would limit you to three bytes of known plaintext, which is at least a start. >The prevailing philosophy of the PGP people is that the PGP >application itself should not decode MIME formats - that should be the >job of a separate application. It seems to me that this is going >against the tradition, though. In the past, if you got a PGP message, >you just ran it through PGP. Now you won't be able to do that. The prevailing philosophy is also that we need to build an API toolkit so PGP components can be easily included into programs. This means that PGP will inherently no longer be able to decode all the PGP-based messages, which may have different layers of other material wrapped around them. PGP/MIME is probably one of the better excuses for doing so, as are improved keyring-handling applications. > Earlier, I mentioned that two and a half protocols survived the >day. The remaining one is MSP. It's actually not a bad protocol. Where can we find the new specs for MSP? > It was announced that there will be a free reference implementation >of MSP, available to US citizens. Will it be GAK-enabled? #-- # Thanks; Bill # Bill Stewart, stewarts(a)ix.netcom.com / billstewart(a)attmail.com +1-415-442-2215 # http://www.idiom.com/~wcs Pager +1-408-787-1281

2 1

Using the political opportunity Was: Newt's phone calls
by Phillip M. Hallam-Baker 17 Dec '03

17 Dec '03

Sarah L. Green <greens(a)hiwaay.net> wrote in article <5bo2df$7ui(a)life.ai.mit.edu>... > On Thu, 16 Jan 1997, Phillip M. Hallam-Baker wrote: > > > > It was a conference call but over a cellular phone. Martin had hacked his > > Radio Shack Scanner using a well known technique. He had a radio ham > > license. > > > Phill > Actually I'd love to see this go to court & have the law itself > tossed out. How many years have the airwaves been free? Now it is > illegal to listen on the cellular frequencies. Well I would love to see the case go to court but I prefer to see someone else being harassed. I don't imagine for a minute that anyone will want to take it to court though. Newt can hardly want his crookery to continue to be before the public eye. He wants it buried as soon as possible so he can make similarly "arcane" charges "nobody understands" against Clinton. Interestingly the tax law that Newt broke was the use of non profit funds for political purposes. Newt should know all about these since the Republicans used these laws to shut down political comment by the likes of the Sierra club etc under Reagan. I know several people who used to be involved in non-profits who either resigned or changed the status of the group because the cost of administration and risk of politically motivated prosecution was not worth the tax advantages. Given the "butterfly under the wheel" nature of the Republican attack I would expect jury nullification in a big way. Meanwhile there would be several weeks of questions asking why Newt is not being prosecuted, only the Martins. Despite the fact that I don't think the Democrats are smart enough to mount such a conspiracy it would be a bloody good one if they had done. I think that the challenge the crypto lobby must take on is to use the event to raise public consciousness for crypto rights. What we probably need is a single issue lobby group that the media can call on for this and only this issue and nothing else. The energies of the CDT and EFF are inevitably spread between this and other issues such as the CDA. The problem is that a journalist does not immediately think EFF or CDT when a cellphone case comes up. A single issue crypto lobby could fill that purpose. Phill

1 0

Re: Should the Feds ban spam? (fwd)
by Bill Stewart 17 Dec '03

17 Dec '03

>At 16:36 -0600 2/15/98, Jim Choate wrote: >>Newspaper editors work according to policies and trusts empowered by the >>owners of the paper. They are allowed as a function of the views of the >>owners to express that choice as an *employee* of those owners. Those >>policies do not apply to the readers as would happen in the case of an ISP. >>Unless you propose that each person should have multiple accounts at >>multiple ISP's. At 06:43 PM 2/15/98 -0500, Declan McCullagh wrote: >This is so incoherent that it's not possible to turn into a positive statement. I found it pretty easy to parse, though incorrect - Jim assumes that each person will only deal with one ISP, and that getting spam filtering from that ISP means turning over control of all your incoming mail/news to the ISP. It's a bad assumption (even if I'm mistaken in claiming Jim assumes it :-) -- of course everybody should have multiple Internet service providers. As a Silicon Valley geek, I deal with several different ISPs offering dialup IP service, not counting my employer's dial and LAN access, or Metricom if I get it, but for most people, that's an exception. Dialup IP packet forwarding isn't the only service provided on the Net! I subscribe to a bunch of mailing lists, and even if I used an ISP that provided filtering services, I'd expect it to leave the mailing list traffic alone (and expect some of the lists to try and reduce spam sent to the list.) I also use a couple of mail forwarders - I advertise pobox.com, since it's convenient to have a permanent address even if I change ISPs. Occasionally I'll use a nymserver if I want to keep separate reputations, or an anonymous remailer for non-persistent or non-replyable email services. Pobox offers spam filtering, and while I don't use it, I think it's the service that gives you a summary of all the email it rejected if you want, which makes it much more likely that I'd buy such a service. I've found that almost all the mail I get addressed directly to my netcom address is spam (some of it's mail from real people with my old address, or mailing lists I haven't reconfigured yet.) It's convenient to be able to tell, just as I know that junk snailmail addressed to "Wired Stewart" is from the subscription I had a few years ago... I also have a couple of free services that I play with, and one of my cats has a Juno account she's been using to experiment with remailers on. And for new people getting on the net, it really makes sense to use hotmail or juno for a while until you know what you're doing, so you don't have spam following you around your whole life. Thanks! Bill Bill Stewart, bill.stewart(a)pobox.com PGP Fingerprint D454 E202 CBC8 40BF 3C85 B884 0ABE 4639

1 0