- cypherpunks-legacy - lists.cpunks.org

Another Son of Clipper discussion paper
by Jim Gillogly 17 Dec '03

17 Dec '03

I sent along two discussion papers for tomorrow's NIST session on the revised plans for GAK last week. Here's the third. Jim Gillogly Hevensday, 14 Halimath S.R. 1995, 20:49 ----------------------------------------------------------------------------- Key Escrow Issues Meeting, September 6-7, 1995 Discussion Paper #3 Export Criteria Discussion Draft -- 64-bit Software Key Escrow Encryption As discussed at the SPA/AEA meeting on August 17, 1995, the Administration is willing to allow the export of software encryption provided that the products use algorithms with key space that does not exceed 64 bits and the key(s) required to decrypt messages/files are escrowed with approved escrow agents. On the same date, the September 6-7 key escrow issues meeting at NIST was also announced. The two principal topics at the meeting will be: discussion of issues of exportability of 64-bit software key escrow encryption and 2) desirable characteristics for key escrow agents. In order to help make most productive use of the limited time available at the upcoming meeting and to better focus deliberation, the following criteria are being distributed for discussion purposes. Since it is important that final criteria be clear, straightforward, consistent, and implementable, please review these draft criteria and be prepared to discuss how they may be refined and made more specific. --- Draft Export Criteria --- for Software Key Escrow Encryption Software key escrow encryption products meeting the following criteria will be granted special export licensing treatment similar to that afforded other mass-market software products with encryption. 1. The product will use an unclassified encryption algorithm (e.g., DES, RC4) with a key length not to exceed 64 bits. 2. The product shall be designed to prevent multiple encryption (e.g., triple-DES). 3. The key required to decrypt each message or file shall be accessible through a key escrow mechanism in the product, and such keys will be escrowed during manufacture in accordance with #10. If such keys are not escrowed during manufacture, the product shall be inoperable until the key is escrowed in accordance with #10. 4. The key escrow mechanism shall be designed to include with each encrypted message or file, in a format accessible by authorized entities, the identity of the key escrow agent(s), and information sufficient for the escrow agent(s) to identify the key or key components required to decrypt that message. 5. The product shall be resistant to any alteration that would disable or circumvent the key escrow mechanism, to include being designed so that the key escrow mechanism cannot be disabled by a static patch, (i.e., the replacement of a block of code by a modified block). 6. The product shall not decrypt messages or files encrypted by non-escrowed products, including products whose key escrow mechanisms have been altered or disabled. 7. The key escrow mechanism allows access to a user's encrypted information regardless of whether that user is the sender or the intended recipient of the encrypted information. 8. The key escrow mechanism shall not require repeated involvement by the escrow agents for the recovery of multiple decryption keys during the period of authorized access. 9. In the event any such product is or may be available in the United States, each production copy of the software shall either have a unique key required for decrypting messages or files that is escrowed in accordance with #10, or have the capability for its escrow mechanism to be rekeyed and any new key to be escrowed in accordance with #10. 10. The product shall accept escrow of its key(s) only with escrow agents certified by the U.S. Government or by foreign governments with which the U.S. Government has formal agreements consistent with U.S. law enforcement and national security requirements. Note: Software products incorporating additional encryption methods other than key escrow encryption methods will be evaluated for export on the basis of each encryption method included, as is already the case with existing products. Accordingly, these criteria apply only to the key escrow encryption method incorporated by a software product, and not to other non-escrowed encryption methods it may incorporate. For instance, non-escrowed encryption using a key length of 40 bits or less will continue to be exportable under existing export regulations. - - - Please also review discussion paper #1 (distributed earlier), which raises a number of issues involving exportability criteria and how exportable products could be designed. Discussion paper #2 (also previously distributed) presents questions involving key escrow agents. Note: These issues will be discussed at the Key Escrow Issues Meeting to be held September 6-7, 1995 (9:00 a.m. - 5:00 p.m.) at the National Institute of Standards and Technology (Gaithersburg, Maryland). The meeting will be open to the public, although seating is limited. Advance registration is requested, please contact Arlene Carlton on 301/975-3240, fax: 301/948-1784 or e- mail: carlton(a)micf.nist.gov. 9/1/95 -----------------------------------------------------------------------------

4 3

Re: Emergency File Wipe Algorithim
by Andrew Loewenstern 17 Dec '03

17 Dec '03

Lucky Green writes: > Didn't I just read a day ago that Robert Morris (ex-NSA) cautioned > that one should never underestimate the time and effort an opponent > is willing to put into recovering your data? > > May I also point out that the rules of economics do not apply to > the federal government, since it insits - quite successfully - on > having a monoploy on using lethal force to extract arbitraily large > amounts from hundreds of millions of working Americans? As always, Rubber Hose Cryptanalysis(*tm, patent pending) is usually the cheapest way to go...if you're a federal government. But not all threats are that serious. For instance, I have no fears that the admins here would grovel over the oxides on RAM cells in order to determine the pass-phrase of my PGP key if they suspected me of doing something naughty (even if they knew this was possible, which is unlikely). You can get really paranoid about security and rightly so if your opponent is a federal government. However, pushing key-material bits around RAM in order to prevent them from being burned into the chips is probably going to do you little good if, for instance, a hardware keystroke monitor is surreptitiously installed in your keyboard (which is likely far cheaper and easier than analysing RAM chips and maybe even disk platters). BTW, this is not a troll and I know that the possible constitutionality of court-ordered disclosure of passphrases or key-material has been hashed over many times in the past here, but have any cases with this particular attribute gone through court yet? There were reports even years ago of pedophiles and other agents of the Four Horsemen using PGP to encrypt diaries and such, have any of these cases gone to court yet and did the prosecution attempt to force the defendant to reveal a passphrase?? andrew (wonders how many readers will take their keyboards apart to look for radio transmitters)

2 1

RE: VCRPLUS Huffman code
by James A. Tunnicliffe 17 Dec '03

17 Dec '03

>On Tue, 5 Sep 1995, Peter Trei wrote: > >> >> > Has anyone worked out the VCRPLUS code? >> > > <chomp> > >> Code which implemented this partial crack was published on the net, >> and the VCR+ people got very upset about it - apparently they make > > I believe the code is in the cookbook archive at ftp.ee.ualberta.ca, >but when I just tried to confirm I got timeouts. > > Brian Among many other places, you can get this off my Web page, in: http://www.inference.com/~tunny/crypto/primer.html - Tunny ______________________________________________________________________ James A. Tunnicliffe | WWWeb: http://www.inference.com/~tunny Inference Corporation | PGP Fingerprint: CA 23 E2 F3 AC 2D 0C 77 tunny(a)Inference.com | <--finger for key 36 07 D9 33 3D 32 53 9C ======================================================================

1 0

Son of Clipper (commentary)
by Jim Gillogly 17 Dec '03

17 Dec '03

I didn't want to mix my comments with the recent discussion paper I sent along, so here they are separately. Please refer back to my last msg to see the points I'm bitching about. It's a depressingly restrictive list of things to require for software escrow encryption. I can only conclude that they're not serious. Clipper itself fails to meet many of them, including (I think) #1, #2, #5, and #6. Rumor has it that Clipper does not meet #9 either -- at Crypto '95 somebody in the Key Escrow session said many government Clipper keys are not escrowed, and somebody in the back spoke up and said he owned such a chip. By the way, Moti Yung (noted crypto guy at IBM Yorktown Heights) presented more breaks in Clipper's protocols like those Matt Blaze found, and pointed out some aspects of Matt's break that he thinks make it more important than previously thought. Other things that bother me about the list: #1: If it's escrowed, there should be no need to limit the key length unless somebody's planning to cheat. #3: This rules out the possibility of escrowing individual session keys to limit the access of LE to sessions they are entitled by law to intercept. #5: Care to tell us how to create software that can't be patched? This is one that's been played in the marketplace and has lost. The battle between copy protectors and crackers has been decided in favor of the crackers: legitimate users largely refuse to buy packages that are too messy to deal with (e.g. they leave hidden files all over the disk, which may interfere with backups or other programs) or that use special purpose hardware (e.g. dongles that eat up a printer port). This one's a loser, I think. #6: This is clearly a research issue. Several speakers (even pro-GAK) at Crypto '95 said the policy decisions are being made before the research has been done. The protocols and system specifications are key here, and it's not obvious how this criterion can be met. It's not obviously impossible, but it certainly hasn't been solved in Clipper. #7: One of the Crypto '95 attacks on the Clipper protocol makes use of this misfeature of Clipper. It allows a broadening of the net of captured keys so that many more unauthorized messages may be read. #8: See #3 above -- let's wait on the policy decision until we have a policy debate. A mandated compromise is an oxymoron. I (for one) would prefer to see much more limited keys (like session keys) if Congress decides that the right to privacy is not infringed by these technologies. There's nothing in here that specifically excludes dividing your keys among multiple escrow agents; I assume this is still an open issue still, or that it goes without saying (one way or the other). #3 and #6 make it impossible to prevent LE from reading messages from before or after their legally authorized window. This is clearly broken. Again, this appears to be trying to put all the power in the hands of LE to the detriment of the people. It's advertized as a compromise, but I see nothing gained over Clipper I. The only differences appear to be that the escrow agent(s) may be private instead of government, and the algorithms may be something other than SKIPJACK as long as they are at least 16 bits weaker as well as being known algorithms. It also doesn't address the main problem with Clipper I: that it wouldn't work, since (like Clipper I) it will catch only crooks who are smart enough to encrypt but stupid enough to encrypt with a system they (should) know LE can read -- probably a null set. If, on the other hand, this is made mandatory for encrypted transmissions, it will create a new and unnecessary class of criminals, probably including myself (though I won't promise to break any laws at this point). This really burns me up. What do they think they're doing here? Am I missing a big piece of it? Jim Gillogly Hevensday, 14 Halimath S.R. 1995, 22:02

1 0

Re: Emergency File Wipe Algorithim
by shamrock＠netcom.com 17 Dec '03

17 Dec '03

At 16:20 9/5/95, Andrew Loewenstern wrote: [...] >andrew >(wonders how many readers will take their keyboards apart to look for radio >transmitters) Been there. Done that. Hmm, come to think of it, it's about time for another check. -- Lucky Green <mailto:shamrock@netcom.com> PGP encrypted mail preferred.

1 0

Scientology and police visit XS4ALL Amsterdam
by announce 17 Dec '03

17 Dec '03

From: XS4ALL Internet Postbus 22864 1100 DJ Amsterdam tel: +31 20 6222885 fax: +31 20 6222753 PRESS RELEASE ------------- Police and members of Scientology church enter offices of XS4ALL ================================================================ Amsterdam - thuesday september 5, 1995. Today at about 14:00, XS4ALL was visited by Mr. S. Braan, bailiff. He was acting on behalf of the Religious Technology Centre, better known as the Scientology Church, or Scientology for short. He was assisted by a local police officer and Mr. Hermans from the 'Nauta-Dutilh' legal firm that represents Scientology in The Netherlands. Also present were two computer experts (Mr. Ootjes and Mr. Van Suchtelen) a locksmith (to enter had we not been present) and two American employees of Scientology, Mr. Weightman and Ms. Jenssen. Scientology is filing for seizure of XS4ALL's computer equipment. Under dutch law, this means that a bailiff comes in to record your assets. In real-life, the computer-experts that were present have recorded the types and serial numbers of all the computers in our offices. They did not take any equipment, the continuity of XS4ALL's services is not in jeopardy. What is this all about? ----------------------- The Scientology Church claims that the XS4ALL anonymous remailer was used to disseminate documents over the Internet to which the church holds the legal copyright. This has led the church to ask the president of the district court of Amsterdam to grant permission for this seizure as a prelude to legal procedures concerning damages suffered by the church. The remailer in question has been disabled more than 2 months ago. During the visit of Scientology to XS4ALL this afternoon, the remailer was not the subject of any conversation. The organisation seemed totally preoccupied with the information about Scientology that one of our users has put on his home page. Part of this information is said to be a file to which Scientology holds the copyright. If we were to delete the file in question on the spot, they were willing to drop the seizure. Responsability of Internet Providers ------------------------------------ XS4ALL categorically denies any responsability for contents of users' homepages. The users decide for themselves what is on their homepage. Since XS4ALL does not edit the homepages and has no mechanism of control over the contents we strongly feel that the users themselves are responsible for what they say on their homepage. This whole affair demonstrates the need for clarity concerning the legal postion of Internet Providers. We are shocked that our offices can be invaded bij freshly flown-in U.S. cult members. If we as Internet providers are held responsible for what our users say, that will undoubtebly kill freedom of speech on the net. Scare-tactics ------------- XS4ALL is not alone in receiving this kind of attention from Scientology. Scientology, a semi-religious multinational, is at war with a number of people on the Internet. A non-organized group of people on the net has started to openly discuss the activities of the church. Until recently, the church has always managed to supress critical voices by means of sheer intimidation and by engaging in endless legal battle. One of the people that Scientology has a problem with is 'fonss', an XS4ALL user that publishes the F.A.C.T.-net Kit on his home page (http://www.xs4all.nl/~fonss) This kit (which can be found on numerous homepages all over the Internet) consists of a large number of documents that show the true face of Scientology. One of these documents is a piece to which Scientology supposedly holds the copyright and which has been added to the kit without the church's permission. Additional information can be found on the Internet: http://www.cybercom.net/~rnewman/scientology/home.html http://www.xs4all.nl/~fonss news:alt.religion.scientology news:alt.censorship news:alt.clearing.technology

1 0

approx of bignum^rational
by cman＠communities.com 17 Dec '03

17 Dec '03

Does anyone have a good method for approximating bignums raised rational exponents in the interval [0,1]? Thanks, Douglas Barnes Electric Communities

1 0

Re: SSL trouble
by Peter Trei 17 Dec '03

17 Dec '03

> >I did a distributed scheme for something else that had two levels, a master > >and a group of slaves. Only the slaves talked to the master. For this > >effort I think a variation of the idea would be better. Have all of the > >brutes contact the master, who will, in the first transaction assign them > >to the next slave in a round-robin fashion. > Why not just have the brutes pick a slave at random? Of course, you need > to give them a complete list of slaves to choose from. But then the only > difference between the master and the slaves will be that the master > doesn't get any keyspace (it's got it all to begin with) and doesn't > report any results upward. This is starting to sound like alt.sex.bondage.... Peter Trei Senior Software Engineer Purveyor Development Team Process Software Corporation http://www.process.com trei(a)process.com

1 0

"This discussion is off-topic, please take it elsewhere"
by tcmay＠got.net 17 Dec '03

17 Dec '03

At 5:58 AM 9/5/95, Sandy Sandfort wrote: >~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > SANDY SANDFORT > . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . > >C'punks, > >This is not a crypto post, but those interested in threat models >and counter-measures might want to read on. This brings up an important issue. Sorry it is not written in C, or even TCL. I actually agree with a point the noted tentacle VZNuri ("visionary," obviously) wrote, namely, that people are getting entirely too apologetic (myself included, though most of my "apologies" have had an ironic edge to them) about posting things that are other than about coding in C, writing sockets for Windows, or breaking SSL. Folks, this list is about a _lot more_ than just some facet of writing software. It started as a wide-ranging list, with many topics, many interests. I don't think I need to try to list the topics, but they obviously include things such as legal issues, policy, PGP, remailers, digital money, money laundering, regulatory arbitrage, data havens, steganography, languages, frameworks, Unix utilities, and dozens of other related topics. We've covered hundreds of topics, and are probably the only such list on the planet that routinely considers the ramifications and ways of actually building the exciting ideas that the academics at the Crypto conferences discover and write about. (I can tell you that one of the main motivations we (Eric and I) had in starting the group was to take the academic abstractions, things like "bit commitment" and "dining cryptographers networks" and reify them into actual blocks of code, or running programs.) Some have argued that "Cypherpunks write code," which has been a short slogan making it clear that one of our main interests is in actually building and deploying these methods. This was a major goal in the spring of 1992 when Eric (Hughes, for any newcomers) and I spent time hashing out what is needed in crypto. As far as I'm concerned, we're on track. Remailers have advanced far beyond the early remailers, and that they exist at all is an accomplishment. The "theory" of remailers is immensely accelerated by having actual remailers in actual use to test theories against and to see real world behaviors. Likewise, message pools have been built. A working anonymous market (BlackNet, for example) has been instantiated, albeit not proliferated. Digital money in various forms (Magic Money, work with Chaum's DigiCash, etc.) has been used. Lots of other examples. PGP, hooks to mail programs (though a lot more are needed), key escrow considerations, etc. Of course, things have gone more slowly in some areas than in others. Digital money, and financial instruments in general, have proceeded in fits and starts. I suspect this indicates that things like money are not done lightly, and that many non-coding issues are intertwined in such a way as to make any "amateur" efforts problematic. But it's only through trying that the obstacles can be seen, so even our failures are useful. Is this "writing code" in all cases? Of course not. Not everything is coding. Planning and preparing is just as important. And consideration of threat models is part and parcel of writing code, else one will not know where to start writing code. Thus, for example, the hundreds of posts here on key escrow (and some of us anticipated Clipper six months before it was announced, allowing the Cypherpunks to hit the ground running as soon as it was announced) and GAK are useful in countering the arguments of those who have spent years planning such escrow (GAK) policies. What I'm getting at is that the "Cypherpunks write code" mantra does not mean that _only_ the few dozen folks actively writing C code can contribute. Indeed, many of the folks now writing code have _claimed_ that they were inspired to write some code in some area--remailers, digital cash, SSL challenges, whatever--by the discussions here on this list. Would they have been so inspired if all political, legal, and cultural discussions had been expunged, if only the arcania of programming and C were being discussed? After all, sci.crypt already exists, and even sci.crypt.research, so why should the Cypherpunks list even exist, as these groups are already ostensibly focussed on pure crypto issues. No, Cypherpunks is about more than just C programming, about more than just IETF issues, about more than just algorithms. I think it great that so much programming discussion occurs, that so much progress is being made. I just think some list.cops are going a bit overboard in their denunciations of "off-topic" posts, and their increasing shrillness in saying that anyone not out there writing Unix crypto programs should stop posting. Those who only want to read about "malloc" and "struct" are encouraged to use the filtering tools which they surely have access to and to stop telling us in shrill voices that posts are "off-topic." --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."

3 2

Re: Non-US SSL128 site
by Peter Trei 17 Dec '03

17 Dec '03

> > a) Use 128 bit SSL if the client allows it. > > b) Tell users which cipher is being used on a secure session. > Netscape's press release on the RC4-40 crack seems to have disappeared from > their home page, but I don't remember any specific mention of 128-bit > U.S.-only clients, just servers. > So what's up? Netscape sells a 128-bit US-only client for $39 Peter Peter Trei Senior Software Engineer Purveyor Development Team Process Software Corporation http://www.process.com trei(a)process.com

4 3