- cypherpunks-legacy - lists.cpunks.org

Re: CISS TSP MISSI
by Rich Salz 17 Dec '03

17 Dec '03

I don't know which is more annoying: The silly 3/4K of Comments that the freezone remailer puts out. (The use constraints are useless to email recipients, after all); or That some anonymous bozo is posting open WWW data to cypherpunks. I hope that the first, at least, can be fixed. Avoid clutter; note the reply-to. /r$

1 0

Re: economic espionage (@#$%^&*) (fwd)
by nobody＠REPLAY.COM 17 Dec '03

17 Dec '03

NY Times, Oct 3, 1995, Business Employment Ad. 1984 Sarajevo, Olympics; 1995 Sarajevo, Battleground Every day in our world, new threats, new challenges, new missions emerge. The people of the Central Intelligence Agency are dedicated to meeting the missions of the day, providing information and resources that aid decision makers in solving the problems and responding to issues that affect us all. You can play an integral role in our mission, while advancing your own career. The Central Intelligence Agency is currently seeking professional men and women who will be comfortable living and working abroad. These positions entail extended overseas assignments in various parts of the world. Previous service in long-term foreign assignments, in either business or government positions, is a definite advantage. Changing international economic, political and social conditions make a broad range of professional backgrounds suitable for these positions. Your experience may be in economics finance, marketing, or general business. Scientific or technical experience in engineering disciplines, physical sclences, biological sciences, or any area of high technology research and development is of particular interest. These overseas positions require more than appropriate professional experience. Successful candidates must also demonstrate a high degree of individual initiative, self reliance and personal integrity. Naturally, the ability to speak or learn a foreign language is expected along with above average communications skills, both oral and written. A Bachelor's degree is a minimum requirement. Advanced degree or military service is a plus. All applicants must successfully complete a thorough medical and psychiatric exam, a polygraph interview, and an extensive background investigation. U.S. citizenship, or eligibility for citizenship, is required. CIA encourages applications from men and women of every racial and ethnic background from all parts of the nation -- we represent America and we want to be representative of America. We will respond within 30 days if your application is evaluated as being of interest. Central Intelligence Agency Dept. 15FS P.O. Box 12002 Arlington, VA 22209-8727 Fax: 703-482-7395 CIA is an equal opportunity employer [CIA eagle-headed all-points shield logo] [Motto] Meet the Challenge of a Changing World -----

2 1

Re: CYPHERPUNK considered harmful
by David C. Lambert 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Black Unicorn <unicorn(a)polaris.mindport.net> wrote: > On Fri, 15 Sep 1995, David C. Lambert wrote: > > > BTW, I'm not for changing the name of the list, but I do see the logic > > in a more establishment-friendly name to use when lobbying the public. > > Distrubute [sic] watered down cypherpunk "teachings" in more benign forms which > hide their true (Ohhh! Scary!) potential in an effort to make them commonly > acceptable to joe sixpack. I believe you misstate the point that people are trying to make. I haven't seen anyone advocating the "watering down" of any so-called "teachings" to "hide" any "true potential". The only thing that people have mentioned is that some of the less clueful out there have a knee jerk response to the name "cypherpunk". That's all. > Can't we all see what road this leads down? No. Please enlighten us. > At the risk of politicizing the issue, I wouldn't be the first to call this > "left-speak" or "term-sanitizing." And this matters because...? > Really the core issue is that the citizens of their respective nations > need to either: > > 1> See cryptography for the important individual rights issue that it > is and latch on to the basic desire for free and unmonitored commerce and > exchange without censorship or observation. > > or > > 2> Decide that they are not interested in the issues because these > issues are too radical, or simply because their own political ideas > fall left (or statist) of this spectrum. What exactly is it that you feel "the citizens of their respective nations" are doing right now, if not this? > in the end I > don't care if every joe sixpack on the planet uses real crypto, just so > long as those I am to conduct commerce (of data or goods) with do. If this is the case, then I'm at a loss to understand how you fail to see the merit in a "term-sanitizing", as you put it, in order to make the use of strong crypto desired and required by Joe Sixpack. How do you expect the legality of string crypto to survive unless Joe and his friends exert political pressure to keep it alive? Isn't it obvious that unless this happens, that strong (unescrowed) crypto is on the path to being outlawed (at least in the US, and several other countries)? > The final judgement will be in the advantage of velocity and security of > transactions and the wealth that this "allocates" to those wise enough to > adopt crypto exchange systems. Evolution in action. If this makes me > elitist, so be it. Elitist or not, this is beside the point. People are bringing up political and rhetorical concerns because they feel that political and persuasive methods are required *right now* in order to preserve the *legality* of strong crypto. I only care about whether Joe Sixpack wants strong crypto because if I can't persuade him that he does, he won't help me keep it legal in my country of residence. Once it's legality seems safe(r) from attack, he can go on using rot13 for all I care. David C. Lambert dcl(a)panix.com (finger for PGP public key) -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMFxSiapplsfgM88VAQGj5wQAoY2FQe0rh0InWF1xOmST91QDCy4TrYUj Y6Vnu/i3yspS/vDsKLMbIYAezAJEtgOPHEOf7Rv1Y4gKDyZNAJbYESXiYTQXD7O3 SNWNtb9nAT6l1RPqsnFR9yWAWYQ1CS3dLRpNpMBIqzL/HnKyKrgitLKQ530XtF8O 78u6jtmsBa4= =Jgoe -----END PGP SIGNATURE-----

3 2

Re: Mixmaster Licensing Offer Explained
by tcmay＠got.net 17 Dec '03

17 Dec '03

(I've trimmed the mailing lists I'm not on...) At 8:01 AM 9/17/95, Lance Cottrell wrote: > Permission is granted to distribute this document in any media for any >purpose as long as the entire document is distributed with the attached >digital signature intact, or the document is clearly marked as having been >modified with the locations of deleted text indicated. So sue me. :-} (That is, I'll treat this article in the normal way, trimming sections I'm not responding to and making note of elisions only where I think it important to.) ... >The company offering to license Mixmaster is Phoenix DataNet, a Houston >area ISP. John Perry, a person well known to this list and the remailer >community in general, is a Senior Systems Administrator at Phoenix. > >On Thursday I received a call from John. Some others at Phoenix had just >noticed a Mixmaster remailer he had been running on one of their machines. >Phoenix has several large corporate customers who need secure transactions >for some special applications. The core engine of Mixmaster is well suited >to that purpose. They offered to license the code from me to use as the >framework on which to build these other programs. In the process they will >rewrite many basic functions in Mixmaster that need major overhaul (e.g., >key management). We will incorporate those improvements back into >Mixmaster. This should lead to porting Mixmaster to several other >platforms, and to fixing most of my worst coding atrocities. First, I think it generally a Good Thing that remailer software gets commercialized and cleaned-up, or that at least commercial packages exist. (I'm not going to get into commercial vs. non-commercial and Microsoft vs. Gnu issues.) If Lance makes a bunch of money off this, more power to him. However, this commercialization raises some interesting issues. Others have dealt with various concerns about the code integrity, about features added, and even about TLA access. I'll address some liability and legal issues. * Will Phoenix DataNet be making the mix software available for purchase, or are they funding _internal development_? (That is, mixes for their corporate clients, which raises some interesting issues in and of itself, as discussed below.) * If Phoenix is planning to resell Mixmaster, or whatever they call it (as "Mixmaster" may remain a trademark of the appliance company which originated the name), what will be their liability for the various abuses which are likely to occur? None of the existing remailers/mixes has had "corporate" backing, and the "deep pockets" corporations are often presumed to have, so lawsuits have not gone after corporations. * On the other hand, if Phoenix is primarily aiming at internal use, for specified corporate customers, how will they stop others from using the service? If chaining is used, and absent any special "untraceable postage tokens" they might issue (as one way to control access), how will the Nth mix in a chain of M mixes "know" whether an incoming message can be remailed or not? (Schemes to sign the packets obviously flunk the anonymity test.) There are many other interesting issues which crop up when Giant Corporation begins to deploy and use remailers. What if, for example, the Justice Department claims that Phoenix and its customers are using remailers for price fixing and collusion? (Just to be clear on this, I personally have no problems with such collusion....but the Antitrust people see things differently.) (To be sure, telephones can and of course have been used to collude. Partly, wiretaps help here (until voice encryption happens...). But Justice has gone after airline reservation computer systems which they believe were used to "signal" price information. Imagine how overjoyed they'll be to see Phoenix DataNet deploy their system!) Again, don't confuse my arguing points here with any kind of advocacy of the Justice Department/Antitrust Division position. I'm only trying to think out what some of the legal issues will be that face the first U.S.-domiciled company to actually start selling remailers or to set up a remailer network for customers. Interesting times ahead. --Tim May ---------:---------:---------:---------:---------:---------:---------:---- Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay(a)got.net 408-728-0152 | anonymous networks, digital pseudonyms, zero Corralitos, CA | knowledge, reputations, information markets, Higher Power: 2^756839 | black markets, collapse of governments. "National borders are just speed bumps on the information superhighway."

1 0

planning for life during the crypto night (was Re: CYPHERPUNK considered harmful.)
by aba＠dcs.exeter.ac.uk 17 Dec '03

17 Dec '03

Black Unicorn <unicorn(a)polaris.mindport.net> writes: > > 3. Unescrowed crypto banned, with advanced stego, panic passwords, > stealth PGP, incorporated remailers all across international borders > making offenders impossible to identify or catch. > > [...] I believe the goal is to propogate crypto far enough to at > least have a salient "underground" participants. > > Some months ago I called for advanced stego and stealth PGP as well > as larger keys in the event we all had to go "into the crypto > closet" for a time. > > I call for them again. Guess you're saying that a future underground cypherpunk group is going to need tools to continue if the US plummets into cryptographic darkness. And you'd like to see these tools available now, as it will be difficult to distribute, and set up if the big ban is already on us. A pre-emptive safety precaution in the event that it happens. So what threat model do you envisage tools being needed to withstand? A couple of the things you list are realisable with little effort, one is a PGP with large keys, I am using a doctored to go to 16k keys (I did this to amuse myself with getting timings for how long encrypt / decrypt & keygen take for varying key sizes). The patch is small, and easy to figure out, just a couple of #ifdefs, various people posted their patches to do this to alt.security.pgp some time ago. I think there was at least one patched version of PGP distributed (unofficially of course - PGPs largest allowed key size being 2048 bits), though I don't have any URLs for such a beast. Part of the problem is people seem to frown on distributing PGPs with larger keys, or alternate versions of PGP, due to version control issues, and such. Technically easy to do tho. Adding stealth features to PGP, or even as standalone, aren't hard either. I've been trying to add Hal's improved stealth algorithm to Henry Hastur's stealth program. It's basically finished, except for the problem that I am unsure about the security of the construct: x' = f(MD5(x)) * N + x where 0 < x < N and 0 < x' < M where M is a power of 2, and M > 2^64 * N and f is just a scaling function If that is secure I'd be happy to release an updated version of stealth, but without assurance, it is necessary to include random numbers, and the best way I see to achieve that is to build it in to PGP, and use PGP's ran no utils directly. If you're talking about a different version of PGP, perhaps this wouldn't be a big deal anyway. So that's big key PGP, and stealth PGP. I'm presuming most people figure 128 bit IDEA is suitably unassailable, but RSA keys are a moving target, and less predictable due to improvements in factoring algorithms. Already people are talking about an academic RSA129 like attempt on a 512 bit PGP key. What are views about creating Yet Another version of PGP. I've read a few discussions of this kind of thing in the past on alt.security.pgp, and most people were against it. But I think some useful things could come out of it. The other problem is working with pgp2.x when there is a version 3.0 being worked on, not sure what stage 3.0 is at, any coding.. perhaps if a stealth capable pgp2.x was worked on, and a few features demonstrated, the 3.0 folks would be willing to take a look at it to evaluate the features for possible version 3.0 inclusion. Just don't want to go do a of work, and then get a polite cease and desist from those with interests in managing the version control of PGP. Good stego tools are the other main problem. My understanding is that all of the stego programs to date do it by just ripping out the LSB of an audio or graphic image, and replacing that with the bits from a message with a stealthed message. Sending masses of pictures around is kind of suspicious tho, I mean several a day, each freshly scanned from what? I guess if video conferencing gets here, it would be fun to add the stego into that noisy stream, same for internet phone. Text stego, with bits hidden in the entropy of english text seems a harder objective, but a useful one. I'm presuming that plausible deniability, and facilities for anonimity are essentials. How does one go about doing that? Using newsgroups to carry on a two level communication might be a good way of maintaining plausible deniability. Either a stego interface to remailers in other countries, so that the stego gateway to remailers scans it's newspool, decrypts messages addressed to it, and forwards that off to the anon remailers. The outcome could be a further text or graphics stegoed message for posting to a suitably high noise news group. The recipient is also scanning his news spool for stego messages addressed to him. Sounds feasible. Perhaps a proof of concept would be easy to knock up, if a place holder is inserted for the 'good text stego' program should go. There was a 'texto' posted a while ago which did something suitable. Adam

2 1

Intellectual Property and Crypto collision
by John Gilmore 17 Dec '03

17 Dec '03

> ELECTRONIC MEDIA PROTECTED UNDER COPYRIGHT LAW > A presidential task force has recommended that electronic transmission of > books, magazine articles and software should be classified as copies > subject to existing copyright laws. The task force also recommended that > it should be illegal to make or distribute products aimed at decoding > encrypted software without the consent of the copyright owner. Would this make it illegal to produce tools for decrypting key-escrowed software? :-) John

1 0

cypherpunks as a newsgroup
by shields＠tembel.org 17 Dec '03

17 Dec '03

PGP message

1 0

Re: Commercial Mixmaster
by tcmay＠got.net 17 Dec '03

17 Dec '03

At 8:34 PM 9/17/95, hallam(a)w3.org wrote: >I seem to remember that Julf took over Stephie's code from Wizvax which >used to >post into the alt.sex.bondage group. I suspect he has modified it since but I >don't think that there is much to it. Actually, it was the code of Karl Kleinpaste that Julf took over...I seem to recall Julf saying this in an article. In any case, this is what Karl claimed last year: "There are 3 sites out there which have my software: anon.penet.fi, tygra, and uiuc.edu. I have philosophical disagreement with the "universal reach" policy of anon.penet.fi (whose code is now a long-detached strain from the original software I gave Julf -- indeed, by now it may be a complete rewrite, I simply don't know); ....Very bluntly, having tried to run anon servers twice, and having had both go down due to actual legal difficulties, I don't trust people with them any more." [Karl_Kleinpaste(a)cs.cmu.edu, alt.privacy.anon-server, 1994-08-29] >How does the cypherpunks remailer work? Does PGP encrypt the signature of a >message so that the identity of the sender is unknown? Or is it simply PEM >style >encryption so that the DN of the sender is in the clear :-( Assuming this is a serious question and not a troll, cypherpunks remailers (at least the ones I have used) completely encapsulate a message. No stuff "dangles outside" the remailed part. When PGP encryption is used, nothing is outside the block. If Alice sends something to Bob's Remailer, Bob decrypts the message and may or may not find further encrypted blocks inside. Envelopes within envelopes. I can't imagine it being done any other way. (I'm not counting the remailers possibly signing the sent messages, as a way of protecting against tampering, but this reveals nothing about the senders.) --Tim May ---------:---------:---------:---------:---------:---------:---------:---- Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay(a)got.net 408-728-0152 | anonymous networks, digital pseudonyms, zero Corralitos, CA | knowledge, reputations, information markets, Higher Power: 2^756839 | black markets, collapse of governments. "National borders are just speed bumps on the information superhighway."

1 0

"Attachments"
by tcmay＠got.net 17 Dec '03

17 Dec '03

Why do people keep sending "attachments"? This was just a text article, and not an application (program), so why was it included as an "attachment"? At 8:27 PM 9/17/95, Michael Shields wrote: >Attachment converted: Macintosh HD:cypherpunks as a newsgroup (????/----) >(00005C4E) The message was, as Microsoft Word 6.0 saw it: -----BEGIN PGP SIGNED MESSAGE----- The general opinion seems to be that the netnews format is very convenient, though we should keep the list; but that entering Usenet or Altnet would lower the S/N. Why not, then, start a new hierarchy? Why not gate cypherpunks not to alt.cypherpunks or comp.security.cypherpunks, but to crypto.cypherpunks? We could feed it freely between us and set up NNTP servers which are open for just crypto.*. c.c would be the only crypto.* group for now, but it would also be easy to add more -- say, for the "respectable" splinter group, or for protocol WGs. We'd get the convenience of netnews without the high profile. I'm willing to run the gateway on news.tembel.org and feed other sites, if people think crypto.cypherpunks is a good idea. Opinions? - -- Shields. -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMFyEm+yjYMb1RsVfAQF1YQQAneg8c6yUKJUUybqepl52yqyS53OGrpLq YfdrMYaIxMWdWKNpMAAus/g8WjWMwYrrB4p+8/WLMm4HsUEHO2ouNzbraiyMRwaB NEhf0v/91h9jGniZIX5uQyqSdM/VC5YupWV0cITqKte9iLZR77C5hVqXBiLhRcwG YL8GwDP5tYw= =roIF -----END PGP SIGNATURE----- ---------:---------:---------:---------:---------:---------:---------:---- Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay(a)got.net 408-728-0152 | anonymous networks, digital pseudonyms, zero Corralitos, CA | knowledge, reputations, information markets, Higher Power: 2^756839 | black markets, collapse of governments. "National borders are just speed bumps on the information superhighway."

3 2

Friday's NIST Key Escrow FIPS Workshop
by Thomas Grant Edwards 17 Dec '03

17 Dec '03

I went to the NIST "Developing Key Escrow Encryption Standards Workshop" held in Gaithersburg, MD on Sept. 15, 1995. It turns out I know the guy who was running the conference so I knew I couldn't miss it...and I knew I had to wear my Cypherpunks t-shirt to show the flag (and it stood out, as there were few without suits there). I got to meet Dorothy Denning for the first time. I was mentioning how government key-escrow doesn't sound too bad to some in the libertarian/cypherpunk world, say for instance to ensure FOIA requests are not encrypted away. She said that would never be a problem, just getting the government to give you FOIA documents in the first place is the problem. In a nutshell, this was a conference to begin work on a FIPS for software key encryption escrow. Industry people there felt that a FIPS would be a great way to standardize key escrow for data recovery. However, except for one guy at IBM who said they tap employees phones alot, most industry people felt that it was not needed for tapping their real-time communications. There was a lot of talk from government people about the need for Law Enforcement to get access to encrypted real-time communication between government employees. This, to say the least, squicked many attendees, and there seemed to be much tension between the sides on that issue. I asked a couple of industry people and privacy advocates the question "Am I just paranoid, or is this FIPS a trial balloon for mandated civillian key escrow?" I got many "yes" answers. I also heard the occasional "this sounds like son-of-clipper" comments in the breakout groups. One noteworthy point is that RSA sent in a position paper to try to get the Digital Signature Standard replaced by RSA signatures for inclusion in key escrow FIPS due to its "virtual non-availability in commercial products," and noted that the US Govt. has free use of RSA sigs. Another noteworthy point is that NIST made clear that the key escrow FIPS should _not_ involve SECRET algorithms. The Workshop consisted of a discussion of goals and objectives by Ray Kammer (Deputy Director, NIST) and some initial thoughts on standards development by Miles Smid (NIST). Here is the gist of the overhead slides: The Goals of the workshop were based on the August 17 announcement by the Administration to allow for exportability of 64-bit software key escrow encryption, plans to allow Federal agencies to use Escrowed Encryption Standards compliant hardware devices for data communications, and the development of a FIPS for key escrow, implementable in software. This escrow FIPS would be used by Federal agencies in conjunction with FIPS-approved encryption techniques. This workshop was held to help begin the FIPS development. The workshop goals included 1) Providing input to the govt. on drafting a software key escrow encryption standard; 2) Helping govt. to identify additional policy and technical issues that need to be addressed and 3) providing the govt. with thoughts on drafting and follow-up The FIPS process involves developing the draft FIPS, a 90 day comment period, then addressing comments, and then it goes to the Secretary of Commerce for signature, and becomes effective six months after the signature. The purpose of the New Escrow FIPS is to foster a wider use of escrow technology...this means: no requirement for SECRET algorithms, software and hardware implementations, and exportability. It also will provide a government validation of escrow systems meeting the standard...theoretically allowing for security, integrity, and availability. Threats examined included compromise (unauthorized disclosure of keys and data recovery), and denial of service (modification or loss of keys, use of bogus recovery fields, and improper system operation). The FIPS will provide common formats and procedures which will facilitate data recovery and lower cost. Applicability of the FIPS will include the US Govt. and contractors. Applications include both stored and transmitted data. Encryption algorithms must be FIPS approved. And finally desirable features include: auditing, configuration control, backup capability, and efficiency. The questions asked to the breakout groups included: 1) Is a standard interface for the release of keys desirable? 2) What documentation is required? 3) How will operational procedures be developed? 4) How will conformance be validated? 5) Will security be evaluated? If so, under what criteria and by whom? 6) How will configuration control be maintained? 7) Are new FIPS-approved algorithms necessary? 8) Should escrowing be built into the Public Key Infracstructure? 9) Is a standard escrow system identification field needed? 10) Is split knowledge required? 11) Do systems which permit data to be encrypted for both storage and transmission need to provide for both kinds of escrow? 12) Does the government require special features (2-hour access, continuous real-time decryption, etc.)?

1 0