- cypherpunks-legacy@lists.ogf.org

Chaos up and running
by Chael Hall 02 Sep '93

02 Sep '93

I know, long time, no post... Well, I have been very busy this summer. The end result is that my machine (chaos) is finally online. I will be running an anonymous remailer (maybe more than one) from this site and intend to run a pseudonymous system like anon.penet.fi here. I have implemented it and need a little help incorporating PGP encryption. The machine is in a secure area and is under the exclusive control of me. At the moment, I am prepared to provide accounts to those who are willing to help improve the system in some way. If you feel that you can contribute, there are several avenues by which you can do so. For example (this is not an exhaustive list): 1. Upload cypherpunks-related files to the anonymous FTP area. 2. Telnet or rlogin to chaos.bsu.edu (147.226.53.28) and login as guest. Follow the instructions to request an account. 3. Write me (nowhere(a)chaos.bsu.edu or root(a)chaos.bsu.edu or nowhere(a)bsu-cs.bsu.edu or chall(a)bsu.edu or 00CCHALL(a)bsuvc.bsu.edu) with a request for an account. If you choose either option two or three above, please tell me what you intend to accomplish through having this account and in what positive ways your having an account will impact my system. Odds are, you will be accepted. There is great potential in having this system on the Internet. I am creating a mail server to aid in discussion about the direction that chaos is going to head. Anyone who would like input on this please send a request to be put on the mail server and I will set it up when we get a few brains together. This is just a quick note (it's lunchtime in Indiana) so if I glossed over anything or neglected to mention something, let me know. The following addresses might be of interest to you: remailer(a)chaos.bsu.edu anon.ping(a)chaos.bsu.edu and anon.help(a)chaos.bsu.edu For a list of anon.* addresses for specific functions, finger anon(a)chaos.bsu.edu We were having some lookup problems since chaos has only been online for two days... Please mail my nowhere(a)bsu-cs.bsu.edu account if you cannot access the system for any reason. Thanks, Chael Hall -- Chael Hall nowhere(a)chaos.bsu.edu Chaos Unlimited nowhere(a)bsu-cs.bsu.edu

1 0

NY tax on info services (whatever that means)
by plmoses＠unix.cc.emory.edu 02 Sep '93

02 Sep '93

I was sloppy in stating the test for a Commerce Clause problem with this law. Hopefully this is a bit more accurate: - First ask, Does this law affect interstate commerce? How and to what extent? - Then ask, Does the law burden interstate commerce in any way? - Next, Does the law have a discrete benefit to State (ie NY State) interests? - Finally, does the benefit to NY interest outweigh the burden on interstate commerce? Is the state interest more significant? Two caveats: - This is not offered for any purpose other than mere speculation and intellectual analysis. - Free legal advice is worth exacty what you pay for it. Paul

1 0

CRM, a new remailer's utility
by astrashe＠nyx.cs.du.edu 02 Sep '93

02 Sep '93

I've just written an msdos utility called CRM that I'd like to offer to the public for testing. CRM is supposed to make use of the encrypted cypherpunk remailers as simple as possible. This is how it works: you tell crm the name of the input (plaintext file), and the address of the person you want to send it to, and crm will affix the "Request-Remailing-To:" and "Encrypted: PGP" headers to the document and perform nested encryptions with PGP. It wraps the result in a /bin/sh script that will mail the cypher text to the first remailer on the chain when it's executed. If you did one of these on your msdos computer: crm tfile astrashe(a)nyx.cs.du.edu You'd end up with a file called tfile.crm that would contain the shell script. Then if you uploaded that to your unix account, and typed: sh < tfile.crm The message would be sent to me through a chain of encrypted remailers. A random list of of of crm's features: You can specifiy the subject line in the original text file, or crm will prompt you for it. You can put the destination address in the command line, or you'll be prompted for that as well. Output (.crm) files can be concatenated to make a single long script that will send more than one letter. The subject-line is embedded in the ciphertext. The number of links in the chains and the list of possible remailers is contained in a text file that can be located anywhere on the path. Crm is writen in turbo pascal 5.5 and the source comes with it. I wrote it all yesterday (except for some recycled code fragments), so it's kind of quick and dirty. If anyone would be willing to take a look at this, I'd be grateful. Once I'm convinced it's reliable (it *seems* reliable now) I'll upload it to soda. If you're interested, email me at astrashe(a)nyx.cs.du.edu and I'll send you a uuencoded version through the mail. Please put CRM in the subject of your letter so that it doesn't get lost in the shuffle. Thanks. Alex astrashe(a)nyx.cs.du.edu

1 0

MISC: DH key xchange
by Karl Lui Barrus 02 Sep '93

02 Sep '93

-----BEGIN PGP SIGNED MESSAGE----- Earlier somebody (Samuel Pigg?) asked for a D-H key exchange reference. It should be in any modern crypto textbook, and is easy to follow. Alice and Bob want to exchange keys over a hostile channel. They pick a prime p, a random number a, and exchange this information. Alice picks Ra, a random number less than p, and keeps it secret. Bob picks Rb, also a random number less than p. Alice calculates Ya = a^Ra mod p, and sends the result to Bob. Bob calculates Yb = a^Rb mod p, and sends the result to Alice. To recover the common key Alice and Bob will now use with each other, they raise the result the other person sent them to their secret random number, and take the result modulo p. That is, Alice calculates Yb^Ra mod p, and Bob calculates Ya^Rb mod p. Even if an eavesdropper gets a, p, and the intermediate Ya and Yb, the final key cannot be determined (due the difficulty of the discrete logarithm). Example: 1) Alice and Bob pick a = 11, p = 347 2) Alice picks Ra = 240 Bob picks Rb = 39 Alice and Bob keep Ra and Rb secret 3) Alice calculates Ya = a^Ra mod p = 11^240 mod 347 = 49 Bob calculates Yb = a^Rb mod p = 11^39 mod 347 = 285 4) Alice sends Bob Ya = 49 Bob sends Alice Yb = 285 5) Alice calculates Yb^Ra mod p = 285^240 mod 347 = 268 Bob calculates Ya^Rb mod p = 49^39 mod 347 = 268 Now Alice and Bob can communicate using their common key. Even if an enemy intercepts a = 11, p = 347, Ya = 49, and Yb = 285, the common key cannot be calcuated. (Well, they can here since I'm using small numbers, but with large numbers the discrete log problem is intractable). -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLIVzxYOA7OpLWtYzAQGzvQQAltkJR3xd/5YJt1pBt2/fWmCrRGqy0RFW ZZEL5ZHUNO9glaYOA39vUlRbZX8IDwHwKSDXJt98NsHH3WT5JJ0i52hy37mcWLOx 7FbsCo8MMjg2xOye3YLLzXa6a99ad5nV7/rk2pL+9mP0lNZdFcWGnfDvz/F5gqCF qMRAYby1KI8= =6ZSd -----END PGP SIGNATURE----- Karl L. Barrus: klbarrus(a)owlnet.rice.edu keyID: 5AD633 hash: D1 59 9D 48 72 E9 19 D5 3D F3 93 7E 81 B5 CC 32 "One man's mnemonic is another man's cryptography" - my compilers prof discussing file naming in public directories

1 0

KOH: disassembly
by Karl Lui Barrus 02 Sep '93

02 Sep '93

-----BEGIN PGP SIGNED MESSAGE----- About the KOH virus/program: I've receive two disassemblies of the program (but not the original source code yet; I haven't had a chance to try to contact the author). I'm not sure that either person who mailed me the disassembly wants to take credit for it, publically at least :-) so I'll just thank them here for their work, and answer questions in email (although one of the disassemblies includes an email address). One person indicated that KOH really isn't a virus at all, so maybe this can be answered by folks who know more about such matters than I do! Apparently the fast encryption method is indeed an XOR; other than that I haven't had a chance to look over the code. I am interested in the IDEA implementation that KOH includes. So, if you are interested in copies of the disassembly, let me know. I had one report that KOH locked up an 8088 PC from a tester (thanks!). I'd try to post something intelligent about the code but I just haven't looked at it enough to comment. -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLIV0DYOA7OpLWtYzAQFP0wP+KrWx2hlne9XRdwOi/3uL//6sy7Bus69U ZvBD7OVUTa9NQEjwlSRlUHEQq/WKnPVZwGhqXLMyIXz6A+DaMTt1NgsQ/RnbHNT0 I9tDUYnSOMA84LRYPP14ZFW+1tWdPtLFI3mOumVr/RyEhz7PJnkKdFVPoCZYWZd9 a9n3yF6YKV0= =X0M4 -----END PGP SIGNATURE----- Karl L. Barrus: klbarrus(a)owlnet.rice.edu keyID: 5AD633 hash: D1 59 9D 48 72 E9 19 D5 3D F3 93 7E 81 B5 CC 32 "One man's mnemonic is another man's cryptography" - my compilers prof discussing file naming in public directories

1 0

MISC: cut & choose
by Karl Lui Barrus 02 Sep '93

02 Sep '93

-----BEGIN PGP SIGNED MESSAGE----- Earlier I mentioned cut-and-choose protocols as a way of protecting from signing a message that you really don't want to (ways of forging signatures on documents). The protocols are simple and rest on a probabalistic argument (similar in some ways to the "proof" in a zero-knowledge proof) - you can be certain to any degree you wish that you are not about to sign a harmful document. Essentially, Bob makes multiple copies of the document and appends random bits on the end of each. Then, he blinds each document with a different blinding factor, and presents all the copies of the blinded documents to Alice. But before she signs anything, she demands that all documents are unblinded, except one. Bob complies and produces the unblinding factor for all the documents except one, and unblinds them. Alice looks over the documents to verify their content, and if she is satisfied, she goes ahead and digitally signs the remaining document, which is still blinded. For example, say Alice is a digital bank. Bob wants to get $10 of digital cash, so he prepares a message, blinds it, and goes to the bank. However, Alice, who has read about the notary protocol, is leery of signing random strings, so Bob goes home again and prepares 100 messages, 100 blinding factors, and blinds each message with its own blinding factor. He shows up at the bank and gives Alice all the messages. Alice picks one message and hands back the other 99, demanding that Bob unblind them. So he complies, and Alice verifies that they all are in fact messages for $10. Satisfied, she digitally signs the last message, knowing that there still is a 1% chance that Bob cheated the bank by slipping in a $100 message with the $10 messages. So Alice can feel as comfortable as she likes by just asking for more messages. Say that cash messages look like this (with random bits at the end): This is $10 of digicash legal tender from First Digital. ADF!#$%@^%&gsu$ When Bob blinds this, it becomes unreadable so Alice can't verify that it is in fact a legitimate message (Bob may be trying to get Alice's signature on another document). But Bob does need to blind the message or the bank (Alice) can note the random bits, serial number, or whatever, and thus correlate the cash with him. The solution is the above protocol, which leaves an 1/n chance of fooling the bank, where n is the number of messages. Alice can ask for n messages where n is large, but there will still be a 1/n chance that Alice picks the special message and is tricked into signing it. (Say Bob slips in a message for $1000 into a bunch of $10 messages; he may get really lucky and have Alice pick the $1000 message, demanding he unblind all the rest to reveal $10 messages). However, this can get pretty expensive to implement for high confidence levels. Again, I'm sure a document forgery can't occur with PGP or even RIPEM (in the notary protocol manner) since neither program blinds messages: they calculate hashes, compress, encrypt, digitally sign hashes, but don't obscure messages by a multiplication factor. -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLIVz4YOA7OpLWtYzAQH0lgQAl3QZ6GFbWntDzuk+CKrkGyealZvHXlu5 stiq3OY+svoQCNRa2TjwJKS6htWsgqeYT4YUFwFV8YtfofavKqUGpuhveC3T5kjH DyKK9Ha1IVjrl5mX4uyz089nU45lQqKJKXCiplDLezRLiB1avVZmIyhdqOyB158W WTjwedeXUVo= =nzAD -----END PGP SIGNATURE-----

1 0

new remailer
by remailer＠netcom.com 02 Sep '93

02 Sep '93

Well not _that_ new. I've been operating it since Sunday. I am operating this remailer out of my personal account. It's interface is identical to the standard cypherpunks remailer as defined by the code I ftp'd from soda.berkeley.edu. I've modified the code to fit it to my particular administrative situation, so you should consider this remailer EXPERIMENTAL. Remailer Address: catalyst(a)netcom.com Remailer PGP Key: -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.3a mQCNAiyBTjoAAAEEAMIKpRnqXb82TOQpx/vEDwGPXndXaxtfiZeSLZqullWCEbd4 YkCHG/F1i3Wzq4Pgz6nSbb58vMS5RonY7+ZC6IHI8zBpp9oMW3u+lqbk8Z61x49d xwAKlE7Zsk/pOeGrqbsidm83WUqlSGgyOpvq0A8LzT4+WPra8ZvHue9jwOpJAAUR tChBbm9ueW1vdXMgUmVtYWlsZXIgPGNhdGFseXN0QG5ldGNvbS5jb20+ =MgMa -----END PGP PUBLIC KEY BLOCK----- Any message that has a header line of the form Request-Remailing-To: somebody@somewhere -- either in the header or with the header pasting operator (::) -- will get remailer handling. If a message does _not_ include any remailer commands, then it must actually be a message to catalyst(a)netcom.com (me). The message will subsequently be delivered to me. Note: badly-formed remailer commands may be equivalent to _no_ commands at all, and thus your message will be delivered to me, instead of getting remailed! I WARNED YOU. Comments, problems, questions > catalyst(a)netcom.com. Scott Collins | "Few people realize what tremendous power there | is in one of these things." -- Willy Wonka ......................|................................................ BUSINESS. voice:408.862.0540 fax:974.6094 collins(a)newton.apple.com Apple Computer, Inc. 1 Infinite Loop, MS 301-2C Cupertino, CA 95014 ....................................................................... PERSONAL. voice/fax:408.257.1746 1024:669687 catalyst(a)netcom.com

1 0

Re: NY TAXES CYBERSPACE, CRAM REACTS
by George A. Gleason 02 Sep '93

02 Sep '93

Yeah, I agree the tax is stupid, and I would certainly hope that some of the affected parties get together and start some kind of lawsuit on the basis of the discriminatory preference for paper media... ...but for God's sake, let's not sink to the level of calling for the assassination of elected officials... aside from the obvious legal issues, that puts us on *their* level. -gg

1 0

REMAIL: Alpha testers for installation script
by sameer＠netcom.com 02 Sep '93

02 Sep '93

-----BEGIN PGP SIGNED MESSAGE----- At the urging (urging, bah!-- I *wanted* a task-- He could've probably seen it in my eyes) of Eric Hughes, I have been working on a script so that the installation of an anonymous remailer (with PGP) is as easy as typing install_remail. At this point it works *flawlessly* on *my* system, so I'd like to see how it works on other systems. This is still an interim version, however, for it is not idiot proof. A small typo (such as mistyping the pathname of your pgp executable) will mean that you have to start over. That will change, but probably in another version. I want to get this out as quickly as possible so that more remailers can pop up like wildfire, and *then* I'll work on idiot-proofing it, so that *everyone* with a UNIX account and crypto-anarchist leanings (no matter their tech-expertise) can be running a remailer. This script in the non-idiot-proof version needs that ~/.forward and ~/remail both don't exist. If you'd like to help me test this thing, and see if it works on your system, please mail me, with some info about your system and your tech expertise. (So I know what to expect.) (I'm setting Reply-To: to both this account and cs60a-qu(a)cory.eecs.berkeley.edu, because cs60a-qu is where the install_remail-installed remailer is running there. [It may go down at any moment, so it would be appreciated if people could use it and test it, but at this point it wouldn't be wise to rely on it for anything important.]) Peace, - -- Sameer sameer(a)netcom.com -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLIWkQwvya0ihLgutAQENqgP+LR6cdm5Wy4jD6Ohl1g5iCR2JweTQRxPP 1AQ5KzW7MbRFhbO9l6wizSkYZE9emDR3YmpWTCZx2tpw+JucBk2C3GwtC4nMkY72 r7hgYwmwb41Fqe1MmfEzwAkvViYyRKSBhTxB869+54DYviHJ87jdxGG1gxxY5gmT uYNwHag7m7o= =IaYF -----END PGP SIGNATURE-----

1 0

NSA response to EFF Clipper Q's
by L. Detweiler 02 Sep '93

02 Sep '93

An EFF Online newsletter previously reported highlights from a list of questions submitted to the NIST/NSA regarding Clipper. That entire document is now available on ftp.eff.org in pub/EFF/legislation/clipper-answers. It makes reference to attachments on chip specifications that are not present in the text file. Overall, the document has rather numerous typographical errors for a government document, and it's unclear whether this is the result of the EFF scanning or whether they are in the original document. Also, at this point in the swift-moving arena, the responses are fairly dated, coming out long before the close of the expert review of the algorithm and a CSSPAB meeting at the end of July. Items in this review of the Clipper comments: - encryption regulation - constitutionality - Mycotronx, VLSI rationale, history of Clipper - Presidential directive & review procedure - key escrow in software - history of Skipjack - identification information in key escrow databases - notes on wiretap protocol - NSA cryptographic control wish list - Capstone capabilities - policy review - Clipper: a status report Encryption Regulation --- The major revelation in this document as reported here previously is the statement that the Administration has progressed far enough in the `policy review' to determine that `regulating private encryption' would be `imprudent' and `drastic' and that no new legilsation will be proposed to `limituse of encryption technology'. Unfortunately, in the characteristically maddening bureacratic doublespeak of the NSA, the previous statements suggest that this is the case only `because these measures may be sufficient to make key escrow encryption [widespread]'. Nevertheless the statement is extremely significant given various ominous sound bites in the media that suggested very clearly that cryptographic regulation was definitely `on the table' for consideration. Constitutionality --- The other major revelations as reported in the EFF document are the explicit attention to constitutional issues. However, the response is not very meaningful except to deny that any are relevant. In particular, it does not indicate the constitutionality of any enforcement or regulation in the area. >The key escrow technology only ensures that government agencies, will be >able to decrypt intercepted communications when lawfully authorized. It >neither expands nor contracts federal, state or local law enforcement >authority to access and decrypt communications. The key escrow technology >simply assures the continued feasibility of lawful electronic surveillance >under statutes that have long since been determined to be constitutional. Mostly the document is just a reformulation of the following idea in various ways: >it became clear >that a strategy was needed that could accommodate the needs of the private >sector for top notch communications security; of U.S. industry to remain >competitive in the world's secure communications market; and of U.S. law >enforcement to conduct lawfully-authorized electronic surveillance. Clearly, the writers' favorite words are `authorized' and `lawful' and here we are doubly reassured. Mycotronx, VLSI --- Here are a few other significant details in the response. For the first time there is official confirmation that the proposal goes back far previous to the Clinton administration: >The logic design contract for the microcircuit was awarded to MYKOTRONIX, >Inc. of Torrance, California, in late 1991 Mykotronx was chosen because: >This company provided a >unique combination of (i) expertise to quickly design custom cryptographic >chips, (ii) secure facilities, and (iii) the cleared personnel (At the TOP >SECRET level) necessary for the successful execution of the contract >requirements. Which makes me wonder. Has anyone with any serious sway in the NSA noticed the stolen Mycotronx documents yet? I would love to see the response to an FOIA inquiry on this one. Do they care? Did any heads roll at Mycotronx? >VLSI Technology of San Jose, California, was chosen as the chip foundry >based primarily on its technological capabilities to fabricate >microcircuits resistant to reverse engineering Selection of the vendors was >in accordance with U.S. government rules for sole source procurement. >other manufacturers that wish to enter the market and can satisfy the >technology and security requirements will be approved to manufacture these >microcircuits. Here we have the highly implausible suggestion that other companies will be considered to manufacture the microcircuits. Fat chance. Presidential Directive --- The document gives more detail about the Presidential Review Directive and Presidential Decision Directive behind Clipper. >The PRD called for interagency studies examining a number >of issues including, for example, the impact of the key escrow strategy and >the feasibility of implementing the key escrow technique in software. >Another issue to be addressed in the course of the review is the impact of >advanced telecommunications on law enforcement. While analogous in the >sense that both encryption and advanced telecommunications technology can >impede the effectiveness of authorized law enforcement electronic >surveillance, the two technologies present different issues and are being >treated separately. The results of the reviews are expected early this >fall. Hence, the `feasibility of implementing the key escrow technique in software' is `under review.' Later in the document, we have the point: >Because software is easy to change, secure software implementations of the >key escrow technique have been difficult to devise. We would welcome the >participation of the software industry in a cooperative effort to meet this >technical challenge. of course, users may continue to use existing >software encryption products. I don't recommend cooperating with the NSA in trying to devise `secure software' -- first of all, the suggestion that they will even have `security' in chip hardware is a fantasy and illusion; secondly, software is inherently free and unchained and nothing the NSA invents can ever change that; thirdly, cooperating with the NSA can be hazardous to one's economic health; and finally, probably no one in the NSA seriously believes that secure software implementations are possible, and are just throwing this out for cynical effect. Skipjack --- Information on SKIPJACK, confirming suggestions by some (e.g. A. Walker on sci.crypt) that the algorithm is based on earlier defense-oriented schemes in a long line of development: >Was the encryption algorithm specifically designed for the key escrow >initiative? > >No. The algorithm chosen for the key escrow microcircuit was originally >developed by NSA for use in U.S. government communications systems, albeit >not in the management of our nuclear arsenal as some have speculated. >Essentially the same cryptographic technology was under government >development and analysis for more than ten years. Although NSA does not >comment on the details of its design and analysis, the algorithm has >undergone intense expert scrutiny comparable to that used in the analysis >of cryptography intended for classified government systems. While the >algorithm was originally developed for unclassified defense systems, it >will be considered for certain classified applications in the future. Key Escrow Databases --- What about identification associated with keys in the databases? The NSA is in a catch-22 here. If there is nothing but serial numbers in a database, how do the key escrow agencies ensure that key IDs requested for wiretapping are associated with the given entities named in warrants? If they are present, how could such a scheme be maintained in anything other than an Orwellian Totalitarian Dystopia? The following is the first explicit commitment to total lack of identification information in the databases: >Some have expressed concerns that personal information could be contained >in the key escrow databases. The only information held by a key escrow >agent will be the chip serial numbers and the key component associated with >that number. Since the information in the key escrow databases will not be >associated with any particular individual, the database would be of no use >in identifying individuals or otherwise obtaining personal information >about them. Therefore, a key escrow agent will have no information about >the person owning or using equipment containing a microcircuit for which it >holds keys. Requests for a key component will be for a particular chip >identification number. No information regarding the identity of the target >of the authorized electronic surveillance will be provided to the key >escrow agents. Wiretap Protocol --- Interestingly, they say that when a wiretapped device is moved to a new phone number, they don't have the authority to tap it any longer: >If the subject of A surveillance were to move the device to another >location (and another telephone number), law enforcement authorities could >not legally monitor communications at other locations. This is because, as >noted above, electronic surveillance of wire or electronic communications >must be directed at some identifiable telephone, cellular telephone, or >computer facility. Therefore, before law enforcement authorities can >legally monitor any other telephone number in an effort to locate the >subject's encryption device, they must first satisfy a court that there is >probable cause to believe that illegal communications will occur over that >line. Major criticism is based on the fact that once a given key has been released, a phone is forever in the future insecure. For the first time we have the assurance >As added protection, law enforcement will have access to a key only so long >as it has authority to conduct a surveillance. Systems are being designed >to ensure that keys are destroyed when the authority to conduct a >particular electronic surveillance has expired. NSA wish list --- We get a wish list of realms in which the NSA would like to control domestic cryptography: >Concerns have been expressed about use of this key escrow technology and >these chips, in particular, across the panoply of new emerging >technologies, such as ISDN, TDMA, Cellular, CDMA Cellular, ATM, SONET, >SMDS, etc. Don't forget PEM -- D.D. gets really excited about that one. >It impossible to design key escrow encryption techniques that >are almost totally transparent to the system, given the transmission media >together with its propagation characteristics. Optimally, the system >should be designed with the encryption, if possible. The government intends >to work cooperatively with industry toward this end. Yes, just what every cryptography company wants, their personal NSA consultant breathing down their circuits. Capstone Capabilities --- Here's some notes on Capstone. Most capabilities also indicated by D.D. in her writings: >In addition to the key escrow technology contained in the >encryption-only chip, the enhanced chip also includes a Digital Signature >Algorithm proposed by NIST as a FIPS; a Secure Hashing Algorithm (SHA) >recently approved as FIPS 180; a Key Exchange Algorithm based on a public >key exchange, a general purpose exponentiation algorithm; and a general >purpose, random number generator which uses a pure noise source. This chip >is now being considered for installation in PCMCIA electronic cards and for >use in the Defense Messaging System. Personally, I wonder if the NSA intends to phase out Clipper from the beginning. The implementation could encrypt the law enforcement field under that more low-level chip. The Capstone chip will be the NSA's little `black box' miracle in every machine. Policy Review --- Finally, there are the indications that the `policy review' done in the Fall will cover the exportability of key escrow and the future cryptographic export control policy in the country concerning `marketability and foreign competition'. While everyone is desperate for a breakthrough here, the likely announcement will be that `no export restrictions will be placed on Clipper' and since the technology is completely suitable for all cryptographic applications (smirk) no other cryptographic devices will be approved for export. That's my guess, anyway. Clipper: a status report --- Current progress report on Clipper: the most serious hurdles for the NSA right now are imposing the Clipper FIPS standard and the DSA patent arrangement with PKP. The NSA has long demonstrated its complete obliviousness and imperviousness to public opinion no matter how loud or negative (consider early DSS endorsement). However, for the previous two standards, it has reached unprecedentedly screeching levels. The government will find it *extremely* difficult to go ahead with either in the face of almost uniformly hostile reception to both. Doing so is likely to raise a much larger outcry and warrant more desperate approaches on the side of the opposition (ala Zimmermann's `guerilla cryptography'). The future revelations in the DSS, Clipper, and `policy review' topics will be critical in indicating whether the NSA will take a more low-key and unobtrusive stance in regulation of domestic cryptography, with the original Clipper announcment its boldest step ever, or whether it will become even more paranoid and volatile in attempting to control and strangle natural, evolving domestic cryptographic developments. If you value your freedom, pray for the former.

1 0