December 2003 - cypherpunks-legacy

Re: Clipper specifics
by koontzd＠lrcs.loral.com 17 Dec '03

17 Dec '03

>From: "L. Detweiler" <ld231782(a)longs.lance.colostate.edu> >Now, two Clipper chips will *not* work in conjuction with each other >unless each is fed a valid LEEF from the other. However, since the chip >does not accomplish this function (the communication, that is; it does >*create* the field), and it is handled outside the chip, there is no >guarantee that the system designer does not, for example, encrypt the >LEEF in the communications transit, thereby completely sabotaging the >`exploitative' tappability of the chip. >Hence there is a *very* real possibility that this scheme, or something >similar, could be used to gain Skipjack-level encryption without any >key escrow complications. I suspect the NSA is *extremely* worried >about this. They probably require that the chip purchaser promise to >use Clipper in a way that guarantees the LEEF is accessable >(plaintext). They may even create a contractual obligation wherein the >surrounding device (telephone or whatever) cannot be approved for sale >until it passes an NSA endorsed tapping test. (what fun!) I consider >this all very plausible and probable. (This would be a neat trick -- >use the chip itself to encrypt LEEF fields -- hah! twist an insecure >chip into a secure one, and spit in the face of the NSA!) Having read the chip spec for the MYK-78 carefully, being a chip/hardware weenie type, having military experience in cryptographic systems, and having exposure to Type I chips (which have a lot of similarity to clipper) there is a fundamental architecture feature of the MYK-78 that can be exploited. The MYK-78 allows multiple cryptographic contexts (encryption or decryption sessions) to be processed at the same time. This is intended to allow a chip with a single instantiation of the cryptographic algorithm to be used for full duplex communications. It requires all simultaneous encryption/decryption sessions to use the same session key although multiple cryptographic vectors (from different initial vectors) may be used. The MYK-78 is fast enough (bandwidth wise) to allow 20-30 duplex vocoder conversations, and could be used in a secure phone bridge using a single clipper chip. The undocumented or classified protocol requires that LEEFs be used for each session, extracted for transmission and input for reception. The chip requires that for every initial vector generated/requested that the included Law Enforcement Exploitation Field (LEEF or 'greened' LEAF) be subsequently input to enable decryption. The LEEF is output when the IV is read, the IV is part of the LEEF. (You can see that to use a single MYK-78 for multiple duplex conversations requires care in assuring that the distant end supplies its IV.) Cryptographic context for multiple sessions (send and receive sides for a single duplex path) is save through the use of save and restore context commands. To get around sending the LEEF we instead generate an IV, followed immediately by a save crypto context command (which produces the IV without the LEEF). The feed the IV (actually the LEEF to our own chip to enable decryption. We transmit the IV(sans LEEF) through separate protocol to the distant end. We receive the distant ends LEEFless IV and use it with the restore crypto context command to initialize the decryption session. This allows both ends to operate without actually transmitting a LEEF. Once decryption is enabled cryptographic resyncronization can be limited to exchange of LEEFless IVs. Securely exchanging IVs is not without difficulty. The clipper chip can't be used without establishing secure communications. Clipper chip modes can't be changed without requiring IV (and LEEF) introduction for other than ECB mode. One possibility is to use the chip in ECB mode with external XOR and feedback management to support a feedback mode. Likewise you could through the use of save/restore crypto context commands and by accepting the necessity for cryptographic restarts, switch the chip to ECB mode and encrypt the IV, say in a special key, for transmission to the distant end. A lot of dancing, but no one is allowed to cut in. -- >About the only company ready for Clipper chips is AT&T, and I think >they are using Diffie Hellman key exchange currently with some >proprietary algorithms (they have a license on Public Key directly from >PKP already) in their secure phones. I suspect any companies that come >out with new phone encryption equipment based on Clipper, if any are >insane enough to exist, will try to be compatible with the AT&T >`standard' (ug). As far as I know AT&T has not published their own key >exchange standard used by the phones, however. That is, it is >proprietary, and might even be protected by patents of their own! This >is a rare occasion where incompatibility is something to beam about! >From: rjc(a)gnu.ai.mit.edu (Ray) >"Cypherpunks Hack Hardware" > It seems logical that when the ClipperPhones come out, they will have >some kind of vocoder chip in them. (I doubt the (co)decoding will be >implemented on the Clipper chip itself) If so, cypherpunks can >take advantage of this situation. Not having seen a clipperphone (there are none currently available), one wonders if it is possible to play the above described trick with the clipper chip and implement your own communications protocol, capturing program control of whatever processor is used. This gives you skipjack security without big brother being inside. A mode switch could include compatiblility with the Escrowed Encryption Standard (EES). >From: "George A. Gleason" <gg(a)well.sf.ca.us> >Re your suggestion of a cypherpunk daughterboard to substitute for Clipper >in "secure" phones etc.: >I have a sneaky suspicion that AT&T won't be quite so cooperative. They >constantly do things in such a way as to make it darn hard to do anything >with their products except exactly what they intended to do. It might be >worth a try though... OTOH anything that creates more demand for AT&T phones >is a not-good thing in my view... we need an entirely competing product, and >preferably cheaper than an AT&T clipperphone + daughterboard, for obvious >competitive reasons. AT&T uses a proprietary vocoder known as ACELP, which will prevent knock off products without licensing. There are only a limited number of ways to prevent you from modifying their hardware. 1) Built In Test (BIT) features. The processor operating the phone could perform system level integrity checks and could refuse to work if the code space doesn't check out, say for valid memory contents being unmodified, or unused memory space not showing up blank. This could be defeated with access to instruction and data streams. 2) With a high enough level of integration no modification may be possible. (no visability or ability to modify instructions for operating the clipper chip) 3) Refuse to sell you the phones. Seems silly, but they already have rules on who they can sell to (U.S. citizens, corporations), under State Department rules. It seems probable they will do their own distributing and large customer could always be denied sales upon request of virtually any of the components of the U.S. government. 4) Tamperproof packaging of the phone (I don't think they'd get UL approval for self destruct devices), say erasing the vocoder algorithm. Sufficient numbers of false zeroizing should defeat this say, organizing a couple hundred customers to swamp the system. You would think a phone would be vulnerable to false zeroizing from throwing it in your briefcase. 5) Refuse to do maintenance and/or void the warranty. With a sufficient level of integration the phones become throw-aways upon failure. This doesn't affect organized crime. 6) legal barriers, largely ineffective (making it a federal crime to tamper with a clipperphone is a joke). Outlawing nonrecognizable encryption schemes (this could be spoofed, through the use of canned LEEFs with session keys you never intend to use, but allows some useful intelligence (the serial number) to leak. A single stolen and subsequently destroyed phone could supply the LEEF, but still serves as a red flag. The ability to not transmit the LEEF suggests the ability to recognize one. Intercepting and storing several thousand (over time) for use randomly as spoofed headers would hamper detection. This is all predicated on the assumption that at least NSA will test suspected crypto streams for clipper, and routinely do traffic analysis. You could imagine modifying the phone totally nondestructively, through the use of chip clips or whatever. -- >From: karn(a)qualcomm.com (Phil Karn) >Damn. Now I remember one of the points I meant to make in my NIST >comments, but forgot: if the LEEF is added periodically to the >ciphertext stream, that implies that the ciphertext data rate must be >greater than the plaintext rate. There is no evidence of anything at the chip level requiring periodic LEEF extraction. This would almost undoubtedly be handled at the communications protocol level. One would guess that the feds would be happy to have the LEEF occur every time you require crypto sync. Byte counts could be used to verify all this. --- All of this has to be apparent to at least the NSA, and I'm sure that no disreputable manufacturer will get to play with the clipper chips and build a product that doesn't adhere to EES. Having seen the certification process for implementations of Type I chips, product certification seems likely. Blackmarket demand can be generated from two sources: persons seeking more absolute privacy and criminals seeking secure communications. I am not at all bothered by the privacy aspect, but would be bothered by supplying or modifying phones for criminals, depending on the crime. It seems unlikely that there is any enforceable method to prevent modification of clipperphones, although discovery of a safe modification process could consume a large number of phones if countermeasures are included. All this is very sensistive to economy of scale. The more phone there are out there, the more blackmarket demand for modified phones and the easier it would be to avoid detection. The question is whether given the potential black market for modified clipperphones, whether skipjack is indeed secure against its creator. (sounds paranoid, I know)

1 0

(fwd) More on CIA's Internet Debut
by kelly＠netcom.com 17 Dec '03

17 Dec '03

Path: netcom.com!netcomsv!decwrl!spool.mu.edu!darwin.sura.net!udel!news!news.world.net!speedway.net!nyxfer!nyt From: nyt(a)blythe.org (NY Transfer News) Newsgroups: alt.conspiracy Subject: More on CIA's Internet Debut Keywords: pigs in the wire Message-ID: <XHFiac4w165w(a)blythe.org> Date: Sun, 26 Sep 93 20:35:32 EDT Reply-To: nyt(a)blythe.org (NY Transfer News) Distribution: world Organization: NY Transfer News Collective Lines: 93 /* Written 1:24 am Sep 27, 1993 by cwarren(a)peg.apc.org in igc:gen.bigbro */ /* ---------- "CIA, watching, watching, watching" ---------- */ Topic 189 CIA, INTERNET - TRUE! Response 2 of 3 agarton cafe.australia 9:00 am Sep 24, 1993 Internet From: <dlr(a)well.sf.ca.us> To: dlr(a)netcom.com Date: Wed, 22 Sep 1993 Found the following on the Well and thought it may be of interest. ***************************************************************** The following appears in the premier issue of "The Internet Letter." I'm not sure what exactly is meant in the third paragraph--it seems a bit garbled. Paul Wallner is actually the coordinator of the Intelligence Community's efforts on "open source" (unclassified information useful to intelligence analysts, etc.), and not just CIA's--technically he works for the Director of Central Intelligence in his role as IC coordinator. The Internet Letter is edited by Jayne Levin, and is apparently premiering at Inet'93. *************************************************************************** 004) CIA, U.S. GOVERNMENT INTELLIGENCE AGENCIES DEVELOP INTERNET LINK Fourteen U.S. government intelligence agencies, led by the Central Intelligence Agency, are developing plans that would allow them to share unclassified information via the Internet. "Everyone is using it [the Internet]," said Paul Wallner, CIA Intelligence Community Open Source coordinator, in an exclusive interview with The Internet Letter. "Why not take advantage of it ourselves and use it. "We're not looking at the Internet as a way to gather intelligence," Wallner said. "The Internet is not viewed as a source of information for us." The agencies that would use Internet to exchange "public" information are part of the National Foreign Intelligence program. They include the National Security Agency, CIA and the Defense Intelligence Agency. The intelligence community will use the Internet to share information and ideas among themselves and the academic community, Wallner said. For example, if the CIA were asked about the nuclear waste problem in Russia, "a good way" to find out would be to talk to the scientific community on the Internet, he said. The system in place now is inadequate. While each agency has its own internal electronic communications network, two intelligence analysts working at different agencies but on the same project cannot send E-mail to one another. There also are no electronic links between the intelligence and academic communities. Communication is carried out mostly by telephone. Because of security concerns, the internal community network will not be connected directly to the Internet, Wallner said. The CIA plans to address the issue of security by creating "air gaps" between classified and unclassified information. An air gap would create a physical space between an agency's internal network and an Internet link. "That allows us to have another check on hackers and potential viruses," Wallner said. He characterized the tone of the discussion over security as "technical." There are three phases to the project, and the first phase is expected to start next spring. It involves establishing nine prototype Internet "nodes" that will connect to an Internet backbone. The CIA plans to seek engineering support from private industry to help design the network's overall architecture. Unclassified materials produced by the Foreign Broadcast Information Service (FBIS) may be available for anonymous FTP (file transfer protocol). No decision has been made on whether a Gopher or WAIS (Wide Area Information Server) server will be used, Wallner said. The government is grappling with whether public distribution of FBIS publications via the Internet would violate copyright law. Selected FBIS publications now are available in print and microfiche to government agencies and universities. FBIS publishes eight daily reports, one for each geographic region of the world. The information is gleaned from news accounts, commentaries and government statements from foreign broadcasts, and it is translated into English from more than 80 languages. --------------------- Big brother is here and watching :) + Join Us! Support The NY Transfer News Collective + + We deliver uncensored information to your mailbox! + + Modem:718-448-2358 Fax:718-448-3423 E-mail: nyt(a)blythe.org +

1 0

ATM info?
by fnerd＠smds.com 17 Dec '03

17 Dec '03

Pardon the off-topic post, but I thought people here would know. Does anyone know of a good, technical but readable summary of ATM? (Asomething Transfer Mode) How are things addressed? How do you request a channel? What is the format of the headers? How do switches work? Etc. Thanks, -fnerd(a)smds.com

1 0

PGP Docs...
by frc%bwnmr4＠harvard.harvard.edu 17 Dec '03

17 Dec '03

Hiya Folks, I'm gonna assume that no one has the PGP docs in postscript or rtf format because no one has responded to my post except a couple other ppl looking for the same thing. So... I have converted the ascii txt files to WfW2.0 docs. I'll be uploading (to my account) a uuencoded file of them for windows ppl, and I'll do my best have a couple portable formats as well. (RTF, and probably PS) To folks who asked for copies: Gimme a couple days and I'll mail them out to you. Later FRC

1 0

need the verilog decryptor script...
by jet＠netcom.com 17 Dec '03

17 Dec '03

I'll do something very nice for the person who sends me, either electronically or on paper, the verilog decryptor. I'm not going to use it to crack verilog code for gain. (I need it for a demonstration for some folks.) jet 4546 B10 El Camino Real #189 Los Altos, CA 94022 or if you want to encrypt: -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.2 mQCNAiuStukAAAEEALzis/ofetFmRbpxV+33Bj1ptYdkPpgBelpU9mW51C0yJi3I 8jPmBlQ3AAbkqoFWiSCvsw9QkkszT5KMuHocGgMO6SAubH+eneBVoZaSZBEddVsT QZLsf2yKMMr6qDA0hkACeFeCmtM95KzeaePTCc/Hm91AxNcsduZT0W0+vi3bAAUR tCNKLiBFcmljIFRvd25zZW5kIDxqZXRAbmFzLm5hc2EuZ292Pg== =WFox -----END PGP PUBLIC KEY BLOCK-----

1 0

thx, anon person
by jet＠netcom.com 17 Dec '03

17 Dec '03

thanks to the anon person who sent me the crypto code. -eric, vainly attempting to improve security throughout the valley...

1 0

(1) a cypherpunk gold mine (2) RSA-PKP patent treatise (3) registration saturation (4) L.D. cypherpunk awards
by L. Detweiler 17 Dec '03

17 Dec '03

Cypherpunk Gold Mine --- Hello, Mark Riordan runs ripem.msu.edu and this has some *hot* files of interest to cypherpunks. He has a very complete DES library with many versions, BigNum packages, and a *lot* of collected files from the net on a wide variety of interesting topics. Many excellent and fascinating bibliographies too. Of particular current interest -- he also has the complete current ITAR online (as I noted earlier). I'm enclosing various file lists at the end of this document. RSA-PKP patent treatise --- Also, for everyone who has ever wondered about the RSA-PKP patent claims (and there's been a recent flurry on the list): An excellent and very authoritative posting on the subject was written by G. Irlam and posted to sci.crypt, etc. on May 20 1991. His email address in the file does not appear to work anymore, but this file is so well researched I am considering turning it into a FAQ on Usenet. pub/crypt/docs/public-key-partners-patents.txt Thanks to S. Bellovin for holding on to this, sending it to me in response to a query, and to M. Riordan for very quickly sticking it on the site after I uploaded it yesterday. Registration Saturation --- But I'm writing chiefly on the following subject. H. Finney, in his first brilliant post analyzing the ITAR relative to PGP distribution, noted that D. Bernstein posted an interesting note about his trials and tribulations in attempting to `export' a cryptographic algorithm SNUFFLE on sci.crypt. All he wanted to do was *post* to the newsgroup. He has a big batch of letters in a file he posted to sci.crypt that show the interesting relationships between the Commerce and the State Departments related to the `Arms registration' involved in legal cryptographic documentation distribution. This is an *extremely* important file for anyone that wants to see what the actual process of getting approval for cryptographic distribution entails, even for simply *publishing* simple algorithms. If anyone wants to `saturate the process' as has been discussed repeatedly on this list, this is a MUST READ. D. Bernstein went through this amazingly hilarious-at-times procedure as an academic exercise in showing the world how obtuse and bizarre the actual U.S. bureacratic structures are that regulate this stuff. Here's a guy that went through the whole surreal process just to POST to SCI.CRYPT. Its MIND BOGGLING. I've also uploaded the file to soda.berkeley.edu, but I don't know if E.H. will put it online (space is apparently very tight on soda). In the meantime, the file is ripem.msu.edu:/pub/crypt/docs/shuffle-export-hassles. for the hard-core cypherpunks who drool over code and algorithms, the code itself is in ripem.msu.edu:/pub/crypt/other/snuffle.zip Note: this and other files on the site (e.g. DES code) require that you submit an application attesting to U.S. citizenship and promising not to further distribute the code. (I don't know what has happened to D. Bernstein on the net. He used to be a great dogged flamer of people like Sternlight and Silverberg, but haven't seen him lately. I suspect he's working on a new important project and hasn't time for all the noise!) Cypherpunk Awards --- Finally, I should note that M. Riordan and D. Bernstein are sci.crypt FAQ editors, but other than that I don't know much about them except that they have both been instrumental in providing some *fabulous* public services over the internet, particularly to the cryptographic community. I vote them Cypherpunks of the Month (even though they're not on the list). D. Koontz gets my vote as Cypherpunk of the Week for the *sharp* analysis that twists Clipper into something useful -- sort of Security by Exploiting Exploitation. I sure hope Mycotronx isn't listening! We might find that LEEF/IV hole patched up in the next version! (nobody sneezed at the dumpster post, so I tend to think some of this stuff goes on in a vacuum.) I've asked him to put the Clipper specs he has pored over into a more public place (scanned for FTP site?) for other scheming cypherpunks to poke at. Ripem.msu.edu File Lists --- Here are some ripem.msu.edu indexes. Don't forget, you have to register to get some of these (particularly the code). Check out file /pub/crypt/GETTING_ACCESS. Flames for including this will be ignored. ===cut=here== FTP Directory /pub/crypt/docs Parent Directory luc-algorithm.txt dss-proposal.txt tmp nist-secure-hash.txt nsa-letter.txt merkle-khufu-khafre-snefru.txt crypt-bookstores.txt crypto-history-books.txt crypt-journals.txt secure-netnews.txt getting-nist-pubs.txt factoring-bibliography.txt polygonal-pubkey-algorithm.txt rsa-conf-93 ritter-cloak.txt sci.crypt-faq.txt crc-discussion.txt blair-crypt-lesson.tex.Z public-key-overview-by-nist.txt.Z scientific-american-pgp-letter.txt rabin-algorithm.txt des-break.ps.Z golding-weak-consistency-dissertation.ps.Z password-certification-authority.ps.Z fast-random-nums.txt enigma-wiring.txt shuffle-array.txt crypt-sites.txt md5-cryptanalysis.txt crypto.bib rsa-faq.ps.Z rsa-public-key-cryptography-standards secret-sharing.txt des-validation.txt arj-encryption.txt playfair-challenge.txt luc-public-key-paper.ps.Z zero-knowledge-proofs.txt goldbug-book-dedication.txt nonlinear-combiners.txt clipper-chip.txt dss-subliminal-channels.txt nist-capstone.txt nist-dss-clipper-testimony.txt dod-pmsp-messages.txt msdos6.0-compression-calls.txt software-cryptophones.txt letters-against-clipper.txt elgamal-using-dss.txt english-trigram-frequencies.txt privacy-anonymity-faq.txt three-cryptographers-problem.txt crypto-random-num.bib kryptoknight-authentications-and-distribution.tar.Z arms-controls-phone-number.txt feal-algorithm.txt warlock-matrix-pubkey-algorithm.txt s-box-exam-question.txt rsa-nist-dsa-agreement.txt des-chip-paper-src-090.ps.Z tis-pem-faq.txt des-break-errata.txt itar-export-bibliography.txt dept-of-commerce-crypto-docs.txt sbox-overview.txt cpsr-statement.txt letter-against-nist-dsa-giveaway.txt shuffle-export-hassles.txt sbox-bibliography.txt ky-28-military-voice-encryptor.txt itar-july-93.txt williams-crc-guide.txt british-intelligence-books.txt des-key-search.ps idea-eurocrypt90.ps english-dictionary-ftp-site.txt intelligence-bibliographies.txt intelligence-journals.txt public-key-partners-patents.txt file /pub/crypt/other/CRYPT-COLLECTION.TXT =Index of Cryptology Programs =Compiled by Mark Riordan mrr(a)scss3.cl.msu.edu =Last updated 9 October 1992 Note: I can't seem to keep this document up-to-date, especially for the "docs" subdirectory on ripem.msu.edu. So, I have tried to create new files in the "crypt" tree with long, descriptive filenames. To find the latest on ripem.msu.edu, be sure to do an FTP rather than relying on this document. /mrr 22 Feb 93 Warning: the .zip files here were created with zip 5.0, not with pkzip.exe, and cannot be extracted with pkunzip. Get unzip.exe (also available at this site). cbw.tar.Z Robert W. Baldwin baldwin(a)xx.lcs.mit.edu Crypt Breaker's Workbench, circa Oct 1986. Program to help you cryptanalyze messages enciphered with the simple, obsolete program crypt(1). Reportedly used to help decipher R. T. Morris's worm (after the fact) from source code found on backup tapes at Cornell. enigma-peake.c Philip Peake (philip(a)axis.uucp in Paris) C program inspired by the World War II Enigma cipher machine, but the algorithm is not completely identical. enigma_2.zip Devours, et al. MS-DOS .EXE of a BASIC program that emulates the real WWII Enigma cipher machine. Unfortunately, source is not included. hill.zip John Cowan <magpie.MASA.COM!cowan> C program to implement Lester Hill's encryption scheme involving matrix arithmetic. I believe the algorithm dates to the 1920's. This code is from comp.sources.unix, Volume 17 (Feb 1989). i-hat-correlation-analysis.zip Douglas A. Gwyn <Gwyn(a)BRL.MIL> (Theory by many others) C code for various cryptographically useful statistical analysis functions: Kullback's information measure for a 2-way contingency table, Gamma and related functions (Poisson, Chi-squared, etc.), Pearson's Chi-squareed, etc. jones-splay-compression.zip Jeffrey Chilton, Douglas W. Jones <jones(a)cs.uiowa.edu> Compression/encryption program based on splay trees. C functions. linear-rng.zip William S.England (Theory by Stephen K. Park and Keith W. Miller) High-quality linear congruential random number generator. I doubt it's truly of cryptographic quality, though. In C, with instructions for adding directly into Perl. lucifer-outerbridge.c Richard Outerbridge <71755.204(a)CompuServe.COM> C implementation of IBM's Lucifer cipher, a predecessor of DES. Speed-optimized version of April 1984, but the algorithm is inherently slow. Includes program which implements CBC. lucifer-smith.c Jonathan M. Smith (original by Arthur Sorkin) C implementation of IBM's Lucifer cipher, a predecessor of DES. Version of March 1991. Includes main program. Pretty slow. md4dos.zip Jouko Holopainen <jhol(a)stekt.oulu.fi> (Theory by Ron Rivest) Fast DOS implementation of the MD4 message digest function. With DOS executable and C and 8086 assembly code. md5.zip Ronald L. Rivest, RSA Data Security rivest(a)theory.lcs.mit.edu Fast and popular one-way hash function in C taken from RFC 1321. Contains a test program. Version of April 1992. md5-karn.zip Phil Karn Very fast DOS 386 assembler implementation of Ron Rivest's MD5 hash function. Contains the Transform routine only (the time-consuming part). Uses Borland C. Version of February 1992. mrrcip.zip Mark Riordan <mrr(a)scss3.cl.msu.edu> Implementations of many classical cipher schemes (simple substitution, columnar transpostion, Playfair, "straddling checkerboard", Vigenere, and so on). Of historical interest only. Main programs all, most in C but some in FORTRAN (hey, I wrote 'em a long time ago). nsea.zip Peter C. Gutmann <pgut1(a)cs.aukuni.ac.nz> "Nonpatented Simple Encryption Algorithm"--actually fairly complex block cipher similar to DES. C functions and main program, with optional 8086 assembler module. In-depth description of algorithm, invented by author. okeefe_encrypt.tar.Z R. A. O'Keefe, Edinburgh. C code for a fairly simple block transposition cipher based on linear congruential random number generators. rot13.c Unknown This is the well-known "Rot-13" cipher used to obscure offensive Usenet postings. Complete C program (very short). scott-newdes.zip Robert Scott, Mark Riordan (mrr(a)scss3.cl.msu.edu) C implementation of NEWDES, an unfortunately-named block cipher (doesn't have much to do with DES, but probably has similar security) designed by Robert Scott and described in a 1985 issue of Cryptologia. The algorithm is fast and doesn't take much code. C functions & driver program included. setzer-trans.zip William Setzer <setzer(a)math.ncsu.edu> "Quick hack" C program that does transposition of 8192-byte chunks of its input, based on a random number generator. snefru2.5a.tar.Z Ralph C. Merkle (merkle(a)xerox.com) One-way fast hash function in C by a well-known cryptologist. C functions and test main program. Most people seem to use MD5 instead. Version of November 1990. snuffle.zip Dan Bernstein <brnstnd(a)nyu.edu> Encryption program which turns a secure hash function into a very good cipher. Oriented towards the Snefru hash function, which is not included here. Simple (but profound) C code. May be an old version. wpcrack.tar.Z Ron Dippold <rdippold(a)qualcomm.com> Programs to crack the encryption on WordPerfect 5.1 encrypted files. Source code in Borland C. --- DES implementations --- barrett-des.zip David A. Barrett <barrett(a)asgard.cs.colorado.edu> Fast DES implementation, with main program that works in Cipher Feedback mode. Sometimes known as "fast-des". Vintage Feb 1991. cdes-bishop.zip Matt Bishop, NASA Ames <bishop(a)bear.dartmouth.edu> Nice C main program/front-end to DES to implement just about every known mode of DES: ECB, CBC, CFB, OFB. Does NOT include an actual DES implementation. Includes man page. chalmers-des-1.0.tar.Z Stig Ostholm ostholm(a)ce.chalmers.se DES implementation with several utility programs and many useful extra functions. Runs on a variety of Unix systems. Pretty good documentation. Vintage October 1990. crypt-bsd-4.3-reno.c University of California at Berkeley This is the "crypt" password hashing function from BSD Unix. It necessarily includes an implementation of DES. Code is marked as being from 1990. I haven't tested it, but I believe it is probably quite slow. Nevertheless, it's probably in wide use. csu10des.zip Phil Karn <karn(a)Qualcomm.COM> (original by James Gillogly) Famous public domain DES implementation by Phil Karn of KA9Q fame. Includes C functions & main programs. This is one of the first public domain DES implementations, and many minor variations of it are floating around. This one, last modified March 1987, was posted to comp.sys.unix, Volume 10. Karn's DES is not as fast as most of the more recent DES implementations but it's a "classic". d3des.zip Richard Outerbridge <71755.204(a)CompuServe.COM> Fast, compact DES implementation from a longtime DES programmer. Includes optional double and triple DES encryption. C functions only; skimpy but adequate documentation. August 1992 version. desCore-2-How.tar.Z Dana How <how(a)isl.stanford.edu> Portable, very fast implementation of basic DES routines only. Supposedly the fastest C version around. Not so fast at key-setting (i.e., password hacking). This code was submitted to comp.sources.misc as Volume 29, Issue 80 and later updated in Volume 29, Issue 128. May 92 version. des-dist.tar.Z Antti Louko (alo(a)kampi.hut.fi) Fast DES implementation, with main program and C function library for arbitrary precision integer arithmetic. Also known as "alodes". Last modified September 1992, but most code seems to date from 1989. fdes5-baldwin.zip Robert W. Baldwin <BALDWIN(a)xx.lcs.mit.edu> Fast DES/crypt implementation in C (functions only) This seems to be 1989-vintage code. Evidently it was/is a favorite of password crackers. koontz-des.tar.Z David G. Koontz <2004ktz%ucsbuxa(a)hub.ucsb.edu> Fast but large DES C functions and main program. Dates to March 1991, at which time it was one of the fastest around. Good verification suite included. libdes-young-p2.tar.Z Eric Young (eay(a)psych.psy.uq.oz.au) This is one of the fastest DES implementations around. These C library routines are designed to replace the MIT Athena DES routines that MIT does not make available for export. Includes a main program and a test program. This is Patch level 2, from July 1992. I believe an earlier version was known as eBones. mitchell-des.zip D. P. Mitchell DES implementation in C, with minimal driver program. Version of June 1983. I don't know how fast this is. There's no documentation and the code is uncommented. pfdes.zip Stuart Levy, Minnesota Supercomputer Center Portable, fast DES implementation in C, from April 1988. Includes demo & benchmark programs. Warning: files need cleaning up (control-Z's and extra spaces in makefile). ufc-crypt-pl1.tar.Z Michael Glad, email: glad(a)daimi.aau.dk Ultra Fast Crypt, fast replacement for crypt(3), patchlevel 1. This comes from comp.sources.misc volume 28, issues 115-116, March 1992. allen-des486.zip Steve Allen, email: 73277.620(a)compuserve.com DES source (Turbo C & Assembler) & executable for MS-DOS. Requires 486 due to use of BSWAP instruction. Runs at 108KB/sec on 486-33. Includes triple-DES. Main programs as well as functions provided. June 1993.

1 0

Active Eavesdropping of Clipper Phones
by Mike Ingle 17 Dec '03

17 Dec '03

>From what I've read, the basic Clipper chip provides no key management, and AT&T is going to use DH. If there is no key certification involved, wouldn't this be vulnerable to active eavesdropping? In other words, cut the victim's phone line somewhere between his house and the central office. Connect up your tap. It just passes voice through, but when he goes secure, it breaks in and hijacks the key exchange. Instead of the two phones exchanging keys with each other, both exchange keys with your tap. Now you have two keys. Load each into a Clipper chip. Send the received data to one chip to decrypt, then to the other to encrypt with the other key, and send it on its way. Neither party would know he's being had - it is much like feeding someone a phony PGP key. The tap could use stock Clipper chips, with no need to reverse engineer, since they will be used for their intended purpose - to communicate with another Clipper at the far end. You could probably reduce it to a notebook computer and the guts of two AT&T ClipperPhones. There must be something to prevent this - isn't there? --- MikeIngle(a)delphi.com "Hey hey, NSA, how many phones did you tap today?"

1 0

Mykotoxin info (old repost)
by Anonymous 17 Dec '03

17 Dec '03

This is for Nate et al. - >Date: Sat, 15 May 93 20:32:35 PDT Howdy. The following is a sampling of the information I was able to grab out of the dumpsers outside Mykotronx. I have much more than this, but I'm fucking tired of typing. I found a used Selectric typewriter ribbon from the Exec Secretary, and their entire general ledger. Will post more as I get the time. Do not disclose the origin of this document (me) but you can publish it if you like to show that the people the government wants us to trust to keep the Clipper design secret, don't know jack shit about security. Information: Mykotronx Inc. 357 Van Ness Way (1 blk so. of Del Amo) Suite 200 Torrance CA 90501 (310) 533-8100 fax (310) 533-0527 STU III (310) 533-0738 Founded 1979 Resale # SR-AB 12-711252 Dunn & Bradstreet # 00-611-5281 Banking: Shearson Lehman Brothers Attn: Steve Scerra Acct # 509 24261 12011 21250 Hawthorne Bl Torrance, CA 90509 (310) 540-9511 Employee Names: Bob Gottfried, CEO Leonard J. Baker, President Ralph O' Connell, aka "The Father of COMSEC", NSA Lobbyist Mike Furusawa, Space COMSEC Manager Patti Linahan, Executive Secretary Kikuo Ogawa, Buyer R. Todd, W. Greenfield, KG-44B (Outrunner) Project John C. Droge, Personnel Bob Todd, Manufacturing Manager Landy Riley, Engineering Federal Express Acct # 1122-7492-8 NSA Contact Home Address: Ralph O' Connell 1401 Woodbridge Road Baltimore, MD 21228 (301) 747-6276 Principle NSA Technical Contact: National Security Agency Maryland Procurement Office Attn: N244 (CEB) (MDA904-92-G-0354/J.O. 5001) 9800 Savage Road Fort George G. Meade, MD 20755-6000 (301) 688-8086 NSA Accounting Contact: National Security Agency Maryland Procurement Office Finance and Accounting Office 9800 Savage Road Fort George G. Meade, MD 20755-6000 (301) 859-6715 KG-46 Tactical Decryptor Unit and KG-48B Outrunner Provisioning Conference participants: Robert Todd, Mykotronx Bill Greenfield, Mykotronx G. Burgio, NSA J. Gochnour, NSA J. Wimpy, Air Force Computer Systems Command S. Solis, Air Force Computer Systems Command To Be Discussed at meeting May 18 & 19, 1993 Outrunner Project Milestone Payments: 1. Preliminary Studies $268,074 2/14/92 2. Place Subcontract w/ VLSI $47,917 2/22/92 3. Complete PDR KG-44B $61,431 4/13/92 4. Complete PDR VLSI $71,090 5/19/92 5. Complete SFA Review VLSI $78,470 7/12/92 6. Complete CDR VLSI $106,638 7/17/92 7. Complete first KG-44B $166,641 8/12/92 8. Complete CDR $132,454 6/18/92 9. Complete tests 1st KG-48B $151,957 12/16/92 10. Complete fab VLSI $203,941 11/17/92 11a.Deliver 2 KG-44B to NSA $81,080 9/8/92 11b.Deliver 2 KG-44B to NSA $81,081 10/7/92 12. Complete Cryto Verif VLSI $152,223 12/16/92 13. Deliver 4 KG-44B to NSA $171,571 3/2/93 14a.Deliver 2 KG-44B to NSA $30,432 3/30/93 14b.Deliver 2 KG-44B to NSA $30,432 4/20/93 15. Deliver 4 KG-44B to NSA $60,864 4/24/93 16a.Deliver 1 KG-44B to NSA $15,216 4/28/93 16b.Deliver 3 KG-44B to NSA $45,648 5/12/93 17. Deliver 4 KG-44B to NSA $42,840 5/13/93 Total: $2,000,000 KG-44 VLSI Procurement: United Technologies Microelectronics Center 1575 Garden of the Gods Road Colorodo Springs, CO 80907 (719) 594-8000 fax (719) 594-8032 PO#5703-44ACN1 Feb 19, 1992 Invoice Date Feb 5, 1993 "Customer to pick up parts. Secret item handling. Secret Design KG-44LSI. Mykotronx P/N M20/00301XXX" Government contract # MDA904-92-C-A027 Group C Testing: $4,400 5 Parts @ $675ea $3,375 Job #BE-7281 Group C Samples PIC Number: HP67AG84WTDLC "Note: Group B samples also included with this shipment (ref Packlist #10128" "The export of this product is controlled by the US Government. The export of this product or the disclosure of related technical data to foreign nationals without the appropriate export license is prohibited by law." Test Plan for MYK-80: Statement of Work for Exatron Inc. 5/13/93 Develop test interface board for MYK-80 (176 pin TQFP) and I.M.S. tester. Interface to utilize "particle interconnect" system. Data on MYK-80 I.O. and IMS tester to be supplied by Mykotronx. Interface board to be installed in a work station which utilizes Exatron "PET" handler, tooled for the MYK-80; a vacuum pick-up device (manual, pencil type); work surfaces for JEDEC tray storage and operator support. The IMS tester will mount directly under the "PET" handler. Two "PET" handlers are to be quoted with two sets of specific nesting tools for the MYK-80. Installation in place at Mykotronx and initial operator and maintenance training to be included. Design review of the interface board layout, prior to release of the board to fabrication is to be held at Mykotronx. Manuals and Training Manuals subcontracted to: ELITE Technical Corporation Warren A. Griswold, President 1903 B Marshallfield Lane Redondo Beach, CA 90278 (310) 372-5616 CAPSTONE Financial Commitments by Mykotronx Basic VII Cap VLSI 10 $212,000 Sun 1 Yr maint hw&sw $2,700 Compass $159,400 IKOS Systems & sw $57,500 ELITE Technical Corp $8,000 IMS/Sun $119,000 Versatec Plotter $36,500 SJ (1) $71,200 SJ (2) $76,200 Exatron Test System $78,000 ROM Cell $60,000 AT&T $100,000 Surf Mgt (real estate) $13,900 Universal Shielding (Tempest) $20,600 Plotter maint $5,000 Litronics $225,000 Spyrus (1) $45,600 Spyrus (2) $44,800 Compass (2) $110,000 VLSI Tech $30,000 VLSI Tech (2) $163,000 VLSI Tech CAPSTONE TQFP $10,000 New Media NRE Design $18,700 South Coast Designers $14,600 South Coast $6,000 VLSI Tech Exponeniator Tamper Sys $163,000 Conres logic analyzer $3,200 VLSI Myk-78 tester $33,800 Here are exerpts of the general ledger of Mykotronx, the Torrance Based Big-Brother outfit that is going to make the Clinton Clipper wiretap chip. Period: 01/01/93 to 04/30/93 (first 4 months of 1993) Acct Descr Beg Bal Debits Credits ==1000 series== Shearson Lehman 286,511 2,620,096 2,670,822 Paine Webber 95,602 868 0 Dean Whitter 55,391 484 0 Petty Cash 3,000 0 0 Union bank payroll act 13,408 900,000 816,443 Accts rcvbl -customer 1,185,829 1,981,356 2,562,064 Accts rcvbl - eployees 7,125 48,450 55,575 Franchise tx rcvbl 2,165 0 0 Unbilled costs&fees 567,792 533,347 0 Raw inventory 172,252 0 76,064 Prepaid taxes 1,116 0 0 Prepaid sales tax 688 0 688 Equp/mach/furn 383,038 20,695 0 Accum depreciation 234,425 0 23,000 Deposits 9,272 0 0 ==2000 series== Accts Payable 482,895CR 1,869,477 1,684,555 Sales tax payable 147CR 176 0 Sales tax paid 0 0 0 FIT withheld 0 10,854 135,741 FICA withheld 0 0 56,622 CA state IT withh 0 0 36,163 CA state disability 0 0 8,730 SUI pybl employer 0 0 5,788 FUTA payable 0 0 2,007 FICA employer 0 0 56,621 Pd Payroll txs withh 0 290,820 0 401K withheld 0 0 42,712 Accrued payroll 25,637CR 343,682 318,045 Dental withheld 0 0 674 Dental plan pd 0 674 0 Withh 401K pd 0 42,712 0 Accrued bonuses 214,040 341,240 127,200 (holy shit - I wish I worked for a place that paid bonuses like that!) Accrued Vacation 44,252 0 0 Excess billings 139,216 154,706 55,036 Gross payroll 0 751,859 0 Gross payroll distrd 0 2,552 754,412 Lease obligations 4,911CR 0 0 ==3000 series== Common Stock 169,320 0 61,435 Capital disbursement 916,675 222,230 0 Retd Earnings, begng 2,385,020CR 0 0 ==4000 series== Sales, returns&allowc 0 6,014 2,577,323 Interest income 0 0 1,353 Int income tax free 0 0 2,490 ==5000 series== Consultants 0 47,395 47,395 Subcontracts 0 932,210 110,419 Other direct costs 0 62,265 5,454 Printing/repro costs 0 542 0 Equipment rental/leasg 0 1,537 1,537 Maint, repairs 0 1,761 0 Delivery 0 3,217 0 Postage 0 960 0 Materials/parts 0 186,252 22,423 Telephone 0 93 0 Travel 0 10,437 0 Inv Cost of Mfg Prod 0 76,064 0 Direct labor-Engnrg 0 240,341 54,172 Direct labor-Technician 0 129,839 37,459 Direct labor-Adminst 0 47,542 10,081 ==6000 series== Indirect labor 0 60,319 0 Holidays 0 32,867 27,331 Sick leave 0 3,276 0 Vacation 0 38,096 25,976 Retroactive pay 0 4,400 0 Job advertisments 0 655 0 Grp Med Ins non sharhl 0 25,522 1,818 Mykotronx pd payrl txs 0 64,417 0 Workers comp 0 9,554 1,418 Interest pd 0 0 0 Consultants 0 2,013 0 ADP Acctg 0 1,493 0 Real World Acct Suppt 0 1,485 0 Bank charges 0 155 0 Blueprints/repro 0 390 0 Proposals 0 2,817 0 Copier expense 0 514 0 Depreciation - elec eq 0 23,000 0 Dues & memberships 0 749 0 Education & Training 0 2,850 0 Employee relations 0 4,531 0 Business expense 0 7,431 0 Equip rental/lsng 0 4,458 0 Computer software 0 2,114 0 Insurance 0 9,061 1,380 Janitorial 0 20 0 Licenses & Permits 0 175 0 Maint, repairs 0 2,096 0 Delivery 0 995 13 Postage 0 942 0 Amort organiz expense 0 0 0 Taxes - franchise 0 2,763 0 Real & Pers prop tax 0 0 0 Rent 0 54,080 0 Subscriptions/books 0 325 0 Office/lab supplies 0 14,183 446 Telephone 0 7,961 36 Travel 0 10,296 1,303 Utilities 0 5,833 0 LTD Ins, non sharehld 0 2,877 594 401K Mykotronx contrib 0 17,411 0 ==7000 series== Special Bonus 0 132,200 123,200 (Double holy shit!) G&A Labor 0 103,4520 0 Legal Services 0 5,895 0 Board of Dir Expnse 0 1,078 0 Financial Svc 0 7,505 0 Totals 0 12,555,101 12,555,101 Other little items: Locks at Mykotronx installed and maintained by Torrance Lock and Key, 2421 Torrance Bl. Torrance, CA 90501 (310) 320-8840 For some reason, Mykotronx is over 90 days late paying a lousy $50 invoice. Mykotronx has a Mossler safe. It cost $1,693 when they bought it 11/27/90. They have never changed the combination. Outstanding VLSI purchase orders: VLSI Tech (Capstone) $212,000 AT&T (Myk-78) $71,200 Motorola (Myk-77) $76,200 AT&T (Misc) $100,000 Compass (Software) $159,400 VLSI Tech (Myk-78) $66,200 Litronics (PCMCIA Crypto) $225,000 VLSI Tech (Expoteniator) $163,000 VLSI Tech (Capstone TFQP) $10,000 VLSI Tech (Myk-78 fix) $68,500 VLSI Tech (Myk-78A proto) $11,000 VLSI Tech (Myk-78A prod.) $220,000 VLSI Tech (Myk-80 #1) $48,000 VLSI Tech (Myk-80 #2) $33,750 VLSI Tech (Myk-82) $80,000 VLSI Tech (Myk-79) $79,500 Their LAN was installed by Strategies, Inc for about $14,000.

2 1

Digicash: good description
by Mike Ingle 17 Dec '03

17 Dec '03

Does anyone know where I can get a good, lucid ASCII description of digicash systems? --- MikeIngle(a)delphi.com

1 0