December 2003 - cypherpunks-legacy

Unofficial transcript of Bernstein hearing published
by John Gilmore 17 Dec '03

17 Dec '03

EFF has published an unofficial transcript of the hearing in front of three judges at the Ninth Circuit Court of Appeals in San Francisco on December 8. The hearing discussed whether the export controls on cryptography are an unconstitutional prior restraint on publication. See http://www.eff.org/pub/Privacy/ITAR_export/Bernstein_case/Legal/ There is no news on the judges' decision from that hearing. John Gilmore Electronic Frontier Foundation

2 1

CAD Stego (fwd)
by Jim Choate 17 Dec '03

17 Dec '03

Forwarded message: > Date: Sun, 18 Jan 1998 19:31:38 -0500 > From: John Young <jya(a)pipeline.com> > Subject: CAD Stego > This repeats a suggestion from 1994 about using computer > assisted design programs to conceal text or other data: > 3. The scale feature is useful to reduce, say, a text > of any length, or any digital object, to the size of a pixel. Assuming your color palate is deep enough to support the compression. > 4. Or, the text can be distorted by scale and dimension > to appear to be a line serving another function. Don't you think they are going to wonder why *that* line is so varied in color? Or assuming deep color pallettes, why so many colors are selected when only a few dozen are actualy used in the drawing? > Then the message could be distorted or hidden as > described above, for piggy-backing on an innocent- > looking document issued, I suspect they'll wonder why that particular file is so much larger than the other graphics files with the same number of layers. > 7. Big shortcoming: how to securely transmit the location > (virtual coordinates) of the hidden message and what Look for the pixel that has the unique color mapped onto it. > 8. Medium shortcoming: Full-featured CAD programs are > expensive, however, the popular lite versions are cheap > and can usually read the pricier output. And can't handle more than a few dozen colors and limited layering. This suggestion is unworkable in application. ____________________________________________________________________ | | | The most powerful passion in life is not love or hate, | | but the desire to edit somebody elses words. | | | | Sign in Ed Barsis' office | | | | _____ The Armadillo Group | | ,::////;::-. Austin, Tx. USA | | /:'///// ``::>/|/ http://www.ssz.com/ | | .', |||| `/( e\ | | -====~~mm-'`-```-mm --'- Jim Choate | | ravage(a)ssz.com | | 512-451-7087 | |____________________________________________________________________|

1 0

New Software Controls
by John Young 17 Dec '03

17 Dec '03

TH points out that there's a broad new provision in the BXA Wassenaar rule for controlling telecommunications software under Category 5, Part I - Telecommunications, quote: You might want to highlight the following section ... not sure of the entire context ... but this isn't something that I'd seen before. It looks like control of any software that can transmit data. c.3. ``Software'' which provides the capability of recovering ``source code'' of telecommunications ``software'' controlled by 5A001, 5B001, or 5C001; For the citation see: http://jya.com/bxa-wa/cat51.htm#5D001c3 --------- We've broken the rule into several components for easier access to the Commerce Control List revisions. See: http://jya.com/bxa-wa-rule.htm

3 2

Voice Coding Controls
by John Young 17 Dec '03

17 Dec '03

DM notes of the BXA Wassenaar rule for voice coding: After looking at some of the Wassenaar docs, I was surprised to see that the CCL wants to regulate speech encoders that operate at less than 2400 bps. Surprising because it was encoding, not encryption, that was being regulated. This is disturbing. This at first seemed to put some of the Nautilus development team's software in jeopardy, but I believe that by the letter of the law (or regulation) that all coders in Nautilus are not subject to the CCL, as they only go as low as 2400 bps and not less than. For citations of voice coding in Category 5 - Telecommunications: http://jya.com/bxa-wa-cat5.htm#5A001b10 http://jya.com/bxa-wa-cat5.htm#5A991b6a

1 0

Re: non-transferable signatures (Re: Crypto Kong penetration.)
by James A. Donald 17 Dec '03

17 Dec '03

-- At 10:48 PM 1/16/98 +0000, Steve Mynott wrote: > SMIME of course despite bad cypherpunk karma is easy and > maybe even works between mailers. Easy indeed, if all the keys from Verisign are correct and secured. It is indeed very easy to use SMIME. To use it so that it actually accomplishes the intended result is not so easy. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG Np4QfrajG+6u2ZHUc2AFBH0uTX9nCJxCUi7E2bpk 3CGDysj2FaqaZYBM4bRe6dvLCkbb0ltwLns5aFPQ9 --------------------------------------------------------------------- We have the right to defend ourselves and our property, because of the kind of animals that we are. True law derives from this right, not from the arbitrary power of the state. http://www.jim.com/jamesd/

1 0

Re: how to release code if the programmer is a target for (fwd)
by Uhh...this is Joe [Randall Farmer] 17 Dec '03

17 Dec '03

[Choate said he wouldn't "address" my message if I didn't post it to the list, so...] > > Eternity delivers data. It's up to the user to verify that the data is > > what they want > > > The original question was how to verify the eternity server source code. > > Assume for a moment that as a user of an eternity server the source is the > data I want. Ok... [...] > > * A random user who has the public keys of at least (thresh) number of the > > cypherpunks, optionally the key of the author of the document/product before > > the system becomes questionable, perhaps by looking in the NY Times > > for 1 Jan 1999 which has a full page ad taken out by Cypherpunks Anonymous > > with the PGP public keys for the 100 leading cypherpunks. > > Pretty expensive and rather unrealistic I suspect. The NYT ad? I think that was at least partly a joke (besides, if some cypherpunks did take out an ad, I'd predict propaganda in 2/3 of the page and fine-print PGP-key fingerprints in the rest :). > Where does this random user come from? Why does it matter? As long as she's competent enough to choose good verifiers and verify that those verifiers verified the code in question, it all works out in the end. > What is '(thresh)'? What good would an anonymous key signature provide? Thresh is the number of signatures from trusted people/keys required to trust a section of code, a value set by the user. An anonymous sig would be very little good but I think he was talking about including the author's sig if he's not anonymous. > [...] How do we know that some number of these cypherpunks aren't turned? We don't. There is no way to operate without *some* trust; this reduces it from the code being shown to be secure if the author is not spookized AND The author is capable to check his/her code AND the key he signed it with is good to the code being good if those conditions are true for one (or a few) of the many cypherpunks on the user's trusted list who signed the code. > Are you proposing that the user test all 100 of the signatures? Well, I think he's proposing to have a script check them and the user personally make sure the script is doing what it should. > Which realistica[l]ly is the only way to verify any given one of them. Not > very many people will go to that extreme simply for grins and giggles. > > > * The piece of code to be verified is bloody long, that is, longer than > > any one cypherpunk can afford to verify alone (shooting practice, > > installing the minefields and poison gas sprinkler system, etc. take > > lots of time) Not to mention churning out that propaganda for the NYT ad, becoming tolerant to pepper spray, preparing various fake identities for use, proving Blowfish secure and then breaking it, constructing a doomsday weapon using only a straightedge and compass, etc. > > The standard is programs over ~10k lines is not comprehensible by a single > individual on a line by line basis. Might be, but this code has to be more than just understood -- it must be painstakingly checked for subtle flaws and bugs. Welcome to the world of adversarial quality control. > > > * The user can tell by visual inspection that a small compilation > > system does what they want it to do, and can understand basic logic > > enough to tell what signatures imply. > > 'small compilation system' of what? What who wants it to do? The author? > Mallet? The end user? The C/Java/whatever compiler, I suppose, and also the signature checker, and she's checking that they carry out their stated purposes. ... > > 2) The user wants to run the code, because it's Just That Cool. > > We're talking here about users who want to get data that is illegal or > otherwise incriminating or dangerous to one group or another. In particular > let's consider the situation of a Lebanese freedom fighter in Isreal or > perhaps a 'Free Burma' revolutionary in China. I think the issue was one of users who want to get eternity server source they can trust -- not necessarily getting it *from* Eternity. > > > 3) No one can verify the entire code. So, Cypherpunks begin signing > > small sections of the code with their own previously-established key. > > Their keys are established as their reputation is established on > > the list, or perhaps by personally meeting these people, in the > > traditional PGP web of trust scheme. There is no central Cypherpunks > > Registry, just a decentralized mesh. > > Which doesn't effect the ability of Mallet to resign that code at the users > end in order to break the users local security. Unless you're exposing a new weakness in the trust model PGP uses, Mallet can't do that, providing the user has done good key authentication and hasn't listed one of Mallet's goons as a trusted code-verifier. > > > 4) The user executes the compilation script. > > [material describing script verification deleted] > > Mallet can re-write said script [...] Yup, that's why the user has to check it by hand. Lots easier to check a script and a compiler for doing their functions than to check an eternity server for subtle bugs. > > > I fail to see how the specifics of Eternity are relevant -- it's > > just basically a PGP web of trust issue. The transport is irrelevant -- > > it's untrusted code until it's been verified by people the user > > trusts. > > The end user may not have people available to trust is the point. Well, if you can't verify it yourself and you can't trust other people to verify it, my advice is to give up; you cannot be sure of *any* public keys in that case, so any message you encrypt might be encrypted to one of Mallet's keys; any sig you check might be signed by one of Mallet's keys. > The reason the transport mechanism is relevant is that it is much easier to > spoof a verification script if the user is not going to be surprised with 24 > hour turn around on requests, whereas a responce time measured in minutes > lessens the window of opportunity to Mallet significantly. If Mallet is a NSA spook who's half as good as my hacker buddy Phat Atta and knew about the script ahead of time, the user can't trust the script without verifying it herself, whether it takes milliseconds or millenia to get the response. > > It may come as a surprise to you and others but not everyone in the world > can pick up a phone and call a 100 people all over the world and not raise > some suspicion. Ah, but either I am more mistaken than usual or you only need a few of the signers to be trusted, not all of them. > > > Implementing a keyserver in Eternity has the same issues > > While it is perfectly permissible to design Eternity or any data haven with > inherent key servers, I believe it is a bad idea from a design perspective > because it makes the code even larger, decreases the potential for monetary > motives for indipendant key servers to appear, and if the server is > compromised then the key server is also. Not sure, but I think he's talking about putting up a key server in Eternity (i.e., the rolling hills where data can roam without fear, as opposed to putting it in the Eternity). > It is more expensive if Mallet can be forced to deal with two [independent] > operators then a single monolithic operator. > > [rest deleted] --------------------------------------------------------------------------- Randall Farmer rfarmer(a)hiwaay.net http://hiwaay.net/~rfarmer

2 1

Re: CAD Stego (fwd)
by John Young 17 Dec '03

17 Dec '03

Jim Choate wrote: >This suggestion is unworkable in application. Why the focus on color, the easiest thing to avoid using, or layers, ditto? Superfluous for serious CAD, these dainty decorations from Martha Stewartville. Most messages could be concealed in "hatched" objects, bit-bloated as they are, indistinguishable from the elements used to hatch. All black and white; maybe a dot of red for cashmere dupe. In fact, CAD is so bloated with dumb cad-jockey features, and sleazebag work-monitoring logs, it puts most ordinary programs (even air-boss MS) to shame, and could hide a herd of rustled Mex longhorns as easily as the Bush family hides dryhole oil reserves, without any more trickery than sandpapering new boots to look worn. Anyway, Jim, I gather from your remarks that you've not fiddled for endless low-paid months and years to figure out how to cheat the evil bosses and automatic work-snoop feature, while onion-siphoning the Net for horny fare under guise of urgent file transfer to foam-mouth ne'erpays. Underground (so to speak) swapping of digital work avoidance tips is a huge use of global bandwidth riding on the backs of big fat docs for globular structures for maggoty thugs. (Although not nearly as gigantic as the porn trade stego-supporting Net infrastructre growth -- over 50% of Net traffic and rocketing.) Who knows how much illicit info is riding the porn river in and out of the most secure sanctums of tyrants?

1 0

let's do it: NYT ad with hash of fingerprints (fwd)
by Jim Choate 17 Dec '03

17 Dec '03

Forwarded message: > Date: Sun, 18 Jan 1998 23:21:38 GMT > From: Adam Back <aba(a)dcs.ex.ac.uk> > Subject: let's do it: NYT ad with hash of fingerprints > I would have thought you would take out a cheap personals section > advertisement and print one hash output and a URL. The hash ouput > would be the hash of the hashes of a chosen set of public key > fingerprints. This doesn't provide the same sort of protection the original full page ad is supposed to provide. That full page ad will be accessible as a referenc a hundred years from now in just about every library in the country. The link to a webpage won't be. Distinctly different security animals. ____________________________________________________________________ | | | The most powerful passion in life is not love or hate, | | but the desire to edit somebody elses words. | | | | Sign in Ed Barsis' office | | | | _____ The Armadillo Group | | ,::////;::-. Austin, Tx. USA | | /:'///// ``::>/|/ http://www.ssz.com/ | | .', |||| `/( e\ | | -====~~mm-'`-```-mm --'- Jim Choate | | ravage(a)ssz.com | | 512-451-7087 | |____________________________________________________________________|

1 0

No Subject
by wabe 17 Dec '03

17 Dec '03

This is an e-mail which I am intentionally muddling by making it have very long lines and stuff. I plan on saving this too, to analyze later and try to recreate using some sort of silly "delete the misplaced carriage return" later. I'm not going to sign it though. So Bill Payne has the black box to sneakers but he won't publish it for fear the NSA will use it to read his e-mail and also because they pissed him off by trying to silence his critisisms of the way they handled something with Iran or something? I don't read legaleze very well.... -wabe

1 0

eternity economics (Re: (eternity) Eternity as a secure filesystem/backup medium (fwd)
by Jim Choate 17 Dec '03

17 Dec '03

Forwarded message: > Date: Sun, 18 Jan 1998 21:40:28 GMT > From: Adam Back <aba(a)dcs.ex.ac.uk> > Subject: eternity economics (Re: (eternity) Eternity as a secure filesystem/backup medium > Eternity helps here in that it obscures the poster's identity, and > reduces their exposure in that they personally don't have to send as > many messages. Eternity also helps ensure continued availability, at > least while somebody is funding that availability. True enough, the question becomes who does that continued funding help the most? > Releasing the data themselves is problematic. They may not wish to > accept the risk. Eternity provides a way to pay someone else to take > the risks in ensuring availability. Really? What is the difference? Mallet attacks the server itself who has only the resources available from the source, which I believe can assume safely, which is obviously less than the resource set of those who could actualy act upon or impliment the data under discussion. > The users is getting value for money from the eternity servers -- the > eternity server is providing the service of risk taking. Yes, at bargain basement prices that allow, if not even promote, a daddy warbucks to walk in and up the ante above what the source can pay. No, the source payment mechanism does not promote either server honesty or long term existance of controversial data. We're going round and round here, as I said earlier the views are diametricaly opposite. I would suggest we drop this discussion and let us see what happens over the next few years as it is clear that many people are working on different implimentations. Let's let the market decide which works best. ____________________________________________________________________ | | | The most powerful passion in life is not love or hate, | | but the desire to edit somebody elses words. | | | | Sign in Ed Barsis' office | | | | _____ The Armadillo Group | | ,::////;::-. Austin, Tx. USA | | /:'///// ``::>/|/ http://www.ssz.com/ | | .', |||| `/( e\ | | -====~~mm-'`-```-mm --'- Jim Choate | | ravage(a)ssz.com | | 512-451-7087 | |____________________________________________________________________|

1 0