December 2003 - cypherpunks-legacy

The Focus on Clipper Details Plays into Their Hands
by tcmay＠netcom.com 17 Dec '03

17 Dec '03

I believe the focus on Clipper/Skipjack details and technical issues plays into the hands of those who want to deploy these systems. * By concentrating on issues of key length, escrow details, availability of the chips, etc., attention is shifted from the real issue--the mandatory use of Clipper (probably) and why this is so wrong--to the issue of _practicality_. * If the issue becomes _practicality_ instead of _ethicality_, then we ultimately lose, I fear. Any criticisms we successfully raise can be more or less responded to by the NSA, Denning, Sternlight, and so on. Then we'll look for new practical problems, and the chase will continue. Meanwhile, Clipper will be that much furhter along. * My response when people ask me about arcane details of key length, family keys, etc., is to just _snort_ and shake my head and say: "Who cares? I don't plan to use it." * I'm really not slamming those on this list who are actual experts on the Clipper system, as much as anyone outside the NSA can be of course. Their intelligent comments, their poking of holes, and so forth, has been useful. * My concern is that too much attention can be focussed on a fundamentally wrong idea, much like the syndrome of the pilot of an aircraft staring at his altimeter and tapping it furiously as he crashes. * If, for example, the Cypherpunks and others help to compile a list of questions about Clipper (and recall that we did just that about a year ago) and then these questions are answered or otherwise dealt with, where does this leave us? In my opinion, the very notion that one's private keys have to "escrowed" with the local cops is ethically flawed. If the proposal were that house keys had to be escrowed, or that personal diaries had to be escrowed, would we be debating the technical details of what kinds of envelopes the diaries would be sealed in? Granted, Cypherpunks is a techncally-oriented group, more so than legally or politically oriented (though most of us are politically aware and motivated by ideology), and so we have a store of knowledge about crypto that most folks don't have. Hence a focus on Clipper's arcane details is to be expected. But let's be sure it doesn't divert us away from a prinicple rejection of the whole concept of key escrow. --Tim May -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay(a)netcom.com | anonymous networks, digital pseudonyms, zero 408-688-5409 | knowledge, reputations, information markets, W.A.S.T.E.: Aptos, CA | black markets, collapse of governments. Higher Power: 2^859433 | Public Key: PGP and MailSafe available. "National borders are just speed bumps on the information superhighway."

2 1

Re: Very funny, Polyanna :-( [namespace pollution]
by Graham Toal 17 Dec '03

17 Dec '03

From: Eric Hughes <hughes(a)ah.com> contracting and for authentication. The current systems don't support this, and will, I suspect, not support this any time soon. In the meanwhile such policies will have to be created manually, even if their operation is transparent. >Whatever solution we can find will have to involve active support >from the keyservers I suspect. The key servers are just serving data. To add policy criteria to the key servers is to extend their functionality beyond their original intent. So? It has to be done *sometime* by someone. The point I was making was that for pgp (or any equivalent cyphered mail system) to work *en masse*, it has to be completely automatic and idiot-proof. I'm not talking about *us* here, I'm talking about your old mother, or Mac users, or the company technophobic managing director etc. What I see as desirable for such people is that their mail is encrypted whenever possible, but they don't have to do anything to make it happen. This means that the current web of trust scheme is not an applicable model, because these people have defined *no* trusted paths at all. We need some relatively trustworthy mechanism for getting pgp keys that will foil a denial-of-service attack - either the one I suggested where someone sets up a key for a mailing list or mail2news gateway (either maliciously or accidentally as with our friend Paulie-Anna) - or where someone creates a key for a specific person (as one joker did for Sternlight last year (this was a second one; Sternlight had one of his own first which he never revoked before he deleted his private key...)) which means that person won't be able to receive mail - if auto-pgp mechanisms become common. To me it looks like this has to be done by heavy-handed control coming from the keyserver admins, though I'd prefer that there was a more democratic way. Please suggest anything you think is appropriate... For the moment, I think that an auto-pgp mechanism will have to use a relatively secure server like SLED that can't have arbitrary keys added to it by all and sundry. If this is sufficiently different to the current key server mechanism that Eric doesn't object, then fine :-) Actually, the mechanism I forsee for doing this sort of thing is the tcp/ip interface to a keyserver that Ben Cox suggested last november. It *could* be bolted on to the finger server at wasabi, but I think the whole concept needs us to stand back a bit and think of what we really want before we start hacking. One mechanism that crossed my mind - when a new key is added, the keyserver that gets it first might hold on to the new key until after it had mailed the key owner and requested confirmation. This ought to be possible to automate. This would also block the cases where someone bulk uploads their keyring with keys on it which they'd been given in confidence, by people who didn't want their employers or government to know they were using pgp... Graham PS cc'd to alt.security.pgp - would the cypherpunks interested in this thread follow it there with me please?

3 2

Re: Quantum Physics
by W. Kinney 17 Dec '03

17 Dec '03

I write, with head firmly implanted in a posterior orifice: >No. Protons and neutrons are hadrons. Hadron comes from the (Greek?) word >for "heavy", lepton from "light". The distinction you're trying to make "Baryon" comes from the Greek for "heavy". "Hadron" is a blanket term covering both baryons (like protons and neutrons), and mesons. Now back to your regularly scheduled cryptography. -- Will

1 0

Re: Crypto and new computing strategies
by Jim choate 17 Dec '03

17 Dec '03

> > Jim Choate wroate: > >The problem w/ the whole N - NP approach is that is assumes that the QM > >model behaves as we would expect it to, it doesn't. I think this is one of > >those assumptions that are better left un-made. I have worked w/ enough QM > >projects throug UT and Discovery Hall (Dr. Turner and Dr. Prigogine) that > >I am not comfortable assuming the QM world even cares about the N or NP > >issues we are debating. > > What effects at the quantum level lead you to this conclusion? Have you > noticed non-linear increases in computational power or other similar > occurrences? > > -- > Best regards, > > Curtis D. Frye - Job Search Underway!!! > cfrye(a)ciis.mitre.org or cfrye(a)mason1.gmu.edu > "Here today, gone ?????" > > > The whole problem w/ QM is that it is not, by its very nature, linear. Every logical thought pattern you have needs to basicly be thrown away when you deal with this real of physics. Consider an electron emitter that throws them out 180 degrees out. Because of the conservation of spin rules the electrons must have opposite spins. However, when they are emitted you can't tell what their individual spins are. However, when you measure one the other INSTANTLY orients to the other value (ie +/- 1). This change happens faster than light (there is no way a electron can emit a photon before you measure it unless it can somehow jump into the future and know a priori when you measure it. Very nasty problem w/ no explanation at this point. You can propose Tachyons and other exotic particles but detecting them because of their lower limit velocity (ie they must always travel faster than light) keeps us from measuring them. The point I am making is that the logical rules you use don't apply down here.

1 0

Re: Crypto and new computing strategies
by Jim choate 17 Dec '03

17 Dec '03

> > You wrote: > > >The point I am making is that the logical rules you use don't apply down here. > > I believe I see what you mean - your argument is that there's no way to > know whether or not there will be a dramatic increase in computational > ability through QM, whether it be through brute force or "smarter" quantum > techniques. What comes to mind immediately is a quantum-oriented genetic > decryption algorithm running on a QM computer. If this algorithm could > sense and maintain memory of subtle c-text differences, it could make > optimizing choices toward eventual decryption. > > I guess my confusion came from the notion that "well, you're only examining > one part of the state space at any given instant, so what's the big deal so > long as we increase key length to compensate" ? Under QM, it seems that > leaps, somewhat akin to human "intuition", could occur. > > I hope I'm closer to understanding your point. > > -- > Best regards, > > Curtis D. Frye - Job Search Underway!!! > cfrye(a)ciis.mitre.org or cfrye(a)mason1.gmu.edu > "Here today, gone ?????" > > > That sums up pretty nicely. Another aspect that I was getting at is that this is new and using the old rules to handle new technology has always been proven wrong historicaly. And I figure it is a cinch that Big Brother won't tell us ahead of time if we are wrong. Take care.

1 0

Cryptography banned in the Netherlands....
by mrs＠tinac.com 17 Dec '03

17 Dec '03

I have always thought that the Netherlands was a very liberal country. But now the government is proposing a law that totally outlaws the use of encryption methods. According to this proposal anyone that wants to use encryption have to register the keys they use with the government, thus allowing the government to decrypt anything they want to decrypt. It is also proposed to totally ban the sales of anything that can be used to encrypt data. Ofcourse this is a blatant violation of civil rights, but to my big surprise the opposition is not even acting upon it. According to them, the matter is not interesting!!!! It most certainly would not surprise you that this news has really outraged almost anyone in the computer and telecommunications industry. But the really sad thing is the procedure. Here in the United States there is a at least a public discussion about the use of the Clipper chip. In the Netherlands the government planned to approve this law before the upcoming elections in the beginning of May '94. Given the total lack of interest from the opposition it seems that they might actually succeed with these dirty scheme. Any comments???? Mike

4 3

Encryption Privacy for Digitized Money - please help!
by Stanton McCandlish 17 Dec '03

17 Dec '03

Can someone help out Jeff here? This could be important. Please reply via email to: Jeff Davis <eagle(a)deeptht.armory.com> Forwarded message:

1 0

Re: The Focus on Clipper Details Plays into Their Hands
by wcs＠anchor.ho.att.com 17 Dec '03

17 Dec '03

Jim Gillogly <jim(a)rand.org> writes: > > tcmay(a)netcom.com (Timothy C. May) writes: > > I believe the focus on Clipper/Skipjack details and technical issues > > plays into the hands of those who want to deploy these systems. > > I agree that focussing on the technical side is a diversion, and I have > been a major offender here lately. But I also think it's important that > we understand what it is we're opposed to. [....] > Understanding precisely how the government > claims they're protecting my rights is important to me, so that I can tell > them and anybody else willing to listen how they're not. Technical discussion (aside from being fun :-) is useful in understanding *what* the government is really up to, how much privacy/freedom is being stolen, what things they're telling the truth or lying about, and how much work it takes to break the systems they're proposing to implement or ban. It's also useful for understanding how to build systems that *do* protect privacy, and for showing how those systems are generally better technically than the privacy-stealing systems the government wants us to use. But as Jim pointed out, getting the details wrong can lose us a lot of credibility. Bill

1 0

Re: Another view of the CFP
by wcs＠anchor.ho.att.com 17 Dec '03

17 Dec '03

Harry Shapiro Hawk wrote: > The White House Guy wrote: > - Clipper-encrypted messages may be further encrypted with another > cryptosystem. However, messages may not be encrypted before being > encrypted with Clipper. > I can understand why they would want to do this as a policy. > e.g., they can see who is using other encryption > 1) Was he saying they would make this the law? > 2) Is there any technical reason it should be this way? The proposed standards I've seen on the net say you can't encrypt *after* using Clipper, because that makes Clipper key-theft useless. On the other hand, encryption with real systems before encrypting with Clipper is undetectable until after they decrypt the Clipper, so it's hard to enforce except on people who are already suspects, and is unlikely to be convenient to implement (for interoperability) on some of the major Clipper targets, like cellphones and fax machines. ...... Wiretap the usual suspects!

2 1

Re: Very funny, Polyanna :-( [namespace pollution]
by wcs＠anchor.ho.att.com 17 Dec '03

17 Dec '03

> >gateways, and suddenly people using auto-encrypting mail programs > >find that no-one can read their posts. > > Presence on a keyring means that a key exists, not that the owner of a > key has a policy that it should always be used, or that it should be > used by everybody. Both PGP and PEM get this completely wrong. Not > every key will be used for every purpose. Mere existence of a key > should not indicate permission to encrypt with it. PGP lets you choose which key to use when you care, and doesn't care what's in the Name field; if you want to implement behavior inside of that it will handle it transparently; e.g. "Digicash: Eric Hughes <hughes(a)accounts.cayman.digibank.com>" (though it would be nice if it had more Unix-like regexp code for selecting keys). > No current cryptosystem has a way of specifying policy in a public key > distribution system. I want separate keys for separate machines, Policy isn't really the cryptosystem's job; it's the application's. > >Whatever solution we can find will have to involve active support > >from the keyservers I suspect. > The key servers are just serving data. To add policy criteria to the > key servers is to extend their functionality beyond their original > intent. The intent of keyservers is to have a convenient mechanism for finding keys when you want them. Having specific keyservers keep track of specific bunches of keys is a reasonable use of that convenience. Maybe a bankers' association would run a keyserver to serve keys for banks and (if appropriate) for customers, with the location known by most of the common software, and maybe a remailer operators' group would do the same for their remailer cooperative. There are a lot of wys to use mechanisms... Bill Stewart

1 0