December 2003 - cypherpunks-legacy

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

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

(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

misc crypto stuff
by mycal (voices through your head ＠ 88.1MHz) 17 Dec '03

17 Dec '03

Cypherdudes, First a prediction, soon the news media will pick up on a major story on somthing like child porn being transfered around using something like PGP. It will get blown out of preportion, and there will be a call to outlaw anything but government approved government decodeable encription. The news media will do one of there steller jobs on how bad this encyption problem is and how there needs to be somthing done about it (see there handling of gun related stuph). The cattle, I mean ppl of this country that still don't know the first thing about computers, and even lots of those who, do will support the idea that something needs to be done (to protect those poor children) and congress will pass a law, call it the "communication security act" (don't you just love the names they choose for these laws that do the opposite of what they are titled). And since there is no crypto lobby that weilds much power (unlike the gun lobby), it will get passed, despite the outcry on the net, overloaded government email boxes and editorials from computer rags. Second, ever wonder why they picked 80 bits for the key length for clipper? I think they used the same criterea that they used when they picked 56 bits for DES. I'm somewhat sure that clipper, like DES is a sound encription method, but I'm also somewhat sure that 80 bits is not out of the NSA's realm of attacking if it was neccary (like there not being able to use the giant back door called key escrow). They probibly calculated that 80 bits is strong enough to provide a good level of protection against most cracking attemts that could be mustered from other governments and orginizations, but not against theirselvs, at least scailed for the preposed release date. 3rdly and finally, if anyone is interested I can send them, for educational purposes only, the source code for Zipcrack. It hacks Zip V1.1 only, and does a brute force attack, but it is economical for <7 character passwords. It could be modified to do things like a dictionary search, but I lost intrest a couple years ago. Anyway it is in C and is quite short. mycal

4 4

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

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

Re: Hacking ClipperPhones
by rjc＠gnu.ai.mit.edu 17 Dec '03

17 Dec '03

Mike Ingle () writes: > > > What do you think? > > I think I definitely want to see Clipper Phones hacked and slashed out of > existence, but as long as hardware hacking is required, their availability > will be limited to a small group of people who know how to use a soldering > iron. Why not concentrate on using commercial hardware (fast modems, > soundblaster cards with DSP, voicemail cards with hardware compression, etc) > to make a plug-and-play cryptophone using 3DES or IDEA, and PGP keys? That > will appeal to a much larger audience. We should definitely learn all we can > about the Clipper system, however. In a way, I agree, but I am skeptical on the price point we will be able to achieve compared to just cannibalizing a ClipperPhone for spare parts. Ideally, the "cypherpunk phone" should consist of 1) cheap v.32 modem (<$200) 2) cheap 8bit sampler/audio card 3) CELP vocoder ardware, or cheap DSP with it implemented in software 4) a fast 486 (to do real time 3DES/IDEA @ CELP rates) Most people already have 1,4, they need 2,3 which will cost anywhere from $300-600 depending on what kind of DSP you get. This is too much money for such a standard to proliferate. If the ClipperPhones are cheaper, we could do better to buy those and cannibalize them for parts. (maybe we could convince ZyXeL to add an "auto-CELP-comp" mode like v.42 to their modems with built in CELP? ) -- Ray Cromwell | Engineering is the implementation of science; -- -- EE/Math Student | politics is the implementation of faith. -- -- rjc(a)gnu.ai.mit.edu | - Zetetic Commentaries --

1 0

Re: Carl Ellison on 'The Death of DES'
by cme＠ellisun.sw.stratus.com 17 Dec '03

17 Dec '03

>Date: Wed, 29 Sep 1993 08:56:21 -0600 (MDT) >From: Michael Johnson <mpj(a)csn.org> >Subject: Re: Carl Ellison on 'The Death of DES' >To: Mike McNally <m5(a)vail.tivoli.com> >In-Reply-To: <9309291229.AA11549(a)vail.tivoli.com> >Message-Id: <Pine.3.05.9309290818.A2965-b100000(a)teal.csn.org> > In other words, des | tran really >isn't much stronger than des des | tran is exactly as secure as des. A final tran adds nothing. It looks messed up to a human, but there's no cryptographic value added. tran is of value *only* between two strong ciphers and its only value is to increase the size of the block affected by the surrounding ciphers. > , but des|tran|des|tran|des|tran|des|tran... >could be quite strong (not to mention slow). Try the new tran. The one originally posted had a slow (LC) PRNG. The new one uses subtract-with-borrow and it's faster. Another consumer warning: the s-w-b PRNG has a huge period but that doesn't make it cryptographically secure. If anything, this is probably the easiest PRNG to break. - Carl

1 0

Re: Triple DES Wanted
by markh＠wimsey.bc.ca 17 Dec '03

17 Dec '03

> > I'm looking for a Triple DES file encryption program that takes arguments > in the same form as /bin/crypt or /usr/bin/des. Is there a /bin/3des out > there somewhere? Has anyone come across 3des.c? And if so, can you > point me in the direction where it may be found. Thanks.. > > If no such program exists, I think it would be very useful to the > cypherpunks community if it were made available. I'd also like to see a You could write one based on Richard Outerbridge's d3des. The essential routines are provided in the package, all you'd need to provide is the wrapper. d3des is the basis of what is currently used in RIPEM 1.1 I also used it in munge, which is an experimental encryption program I distributed a while back which encrypts with either IDEA or triple DES or a composition of the two in CFB mode. munge has an interface much like that of Unix "compress" (munge, unmunge, mcat &c.) I'd do things somewhat differently if I were going to redo it, but you can have it if you want it. Just don't ask me to maintain it or port it to anything else, as I don't want to put any more effort into it. There is significant ugliness in the code due to the fact that I was always maintaining backwards compatibility with previous versions. (if you want either munge or d3des, you can get by ftp it from either wimsey.bc.ca or ripem.msu.edu. Please don't export munge or anything from wimsey.bc.ca outside of the U.S. and Canada). Mark -- Mark Henderson markh(a)wimsey.bc.ca (personal account) RIPEM key available by key server/finger/E-mail MD5OfPublicKey: F1F5F0C3984CBEAF3889ADAFA2437433

1 0

spookey PGP problem... HELP!
by nate＠VIS.ColoState.EDU 17 Dec '03

17 Dec '03

OK, I'm running PGP 2.3a on an SGI Indigo R4000 (not that the machine really matters, but it might help). My keys were generated with PGP 2.2 (on teh Mac), and I have since (obviously) upgraded to 2.3 then to 2.3a. I just recently started to encrypt a lot of things with my own public key, and also noticed that the files encrypted with my pubkey were not necessarily decypherable by my secret key. I replaced my keyrings from backups make a while ago (they're just missing most of my public keys), and still no luck. I get the following error: Pretty Good Privacy 2.3a - Public-key encryption for the masses. (c) 1990-1993 Philip Zimmermann, Phil's Pretty Good Software. 1 Jul 93 Date: 1993/09/30 05:14 GMT File is encrypted. Secret key is required to read it. Key for user ID: Nathaniel David Sammons <nate(a)VIS.ColoState.Edu> 1022-bit key, Key ID AE9C65, created 1993/05/24 You need a pass phrase to unlock your RSA secret key. Enter pass phrase: Pass phrase is good. Just a moment... Error: RSA-decrypted block is corrupted. This may be caused either by corrupted data or by using the wrong RSA key. For a usage summary, type: pgp -h For more detailed help, consult the PGP User's Guide. What the hell? Sometimes it will decrypt the file (and sometimes not). I am very reluctant to issue a key-revocation certificate, since I would like to avoid this as much as possible, but it's not looking good. This is really worrying me. The data I encrypted is not that important, but it's still a MAJOR problem I am having. thanks, -nate -- +-------------------------------------------------------------------- | Nate Sammons email: nate(a)VIS.ColoState.Edu | Colorado State University Computer Visualization Laboratory | Finger nate(a)monet.VIS.ColoState.Edu for my PGP key | #include <std.disclaimer> | Always remember "Brazil" +----------------------+

1 0

spookey PGP problem... gets spookier...
by nate＠VIS.ColoState.EDU 17 Dec '03

17 Dec '03

I just compiled 2.3a on a sun 4/280 in my Lab, and I was able to decrypt the files fine. The Mac version (2.3a) was also able to decrypt the files just fine. Hmmmmm..... -nate -- +-------------------------------------------------------------------- | Nate Sammons email: nate(a)VIS.ColoState.Edu | Colorado State University Computer Visualization Laboratory | Finger nate(a)monet.VIS.ColoState.Edu for my PGP key | #include <std.disclaimer> | Always remember "Brazil" +----------------------+

1 0

Re: Triple DES Wanted
by Matthew B. Landry 17 Dec '03

17 Dec '03

>wimsey.bc.ca or ripem.msu.edu. Please don't export munge or anything >from wimsey.bc.ca outside of the U.S. and Canada). This admonition rings a bell in my mind. Most of the US export laws seem to be based on "export outside US or Canada". So I'm wondering, are the comparable Canadian laws as strict about export of crypto software? Specifically, if US authorities won't stop us from exporting to Canada (placing files on Canadian FTP sites), will Canadian authorities stop us from exporting to Europe, et al. (foreign users FTPing the files from the deposit site)? Yes, it's a longshot. No, I don't have all the facts. Yes, I will probably get enough "clueless newbie" flames to set my Ethernet card on fire. I know all of these things. Could someone please answer the question? -- Matthew B. Landry ml7694a(a)american.edu (Finally!) mbl(a)ml7694a.leonard.american.edu

1 0

key-server down?
by J. Michael Diehl 17 Dec '03

17 Dec '03

Hi guys. I've been using the pgp key server for some time now, but lately I've been having problems with it. I send it commands (last 30 for example) and never get a reply. I believe I'm using the one on toxicwaste, but can't be sure since I have an alias for it and I'm not at my email account at the moment. Is this site down or am I just impatient? Thanx in advance. Lagers, J. Michael Diehl ;^) |*The 2nd Amendment is there in case the mdiehl(a)triton.unm.edu | Government forgets about the 1st! <RL> Mike.Diehl(a)f29.n301.z1 |*God is a good Physicist, and an even .fidonet.org | better Mathematician. <Me> al945(a)cwns9.ins.cwru.edu|*I'm just looking for the opportunity to (505) 299-2282 (voice) | be Politicly Incorrect! <Me> Can we impeach him yet? |*Protected by 18 USC 2511 and 18 USC 2703. PGP Key = 7C06F1 = A6 27 E1 1D 5F B2 F2 F1 12 E7 53 2D 85 A2 10 5D

2 1

REMAIL: Message expansion
by hfinney＠shell.portal.com 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- One of the problems with chaining remailers as we do it now is that the message becomes quite a bit larger as you wrap encryption layers around it, one for each remailer in the chain. Currently, the remailers are all text-based, which requires that the message be re-ascii'd at each stage of the encryption nesting. But ascii'ing a binary file using PGP's method increases its size by 1/3. If this asciification could be avoided at each step, the message would still grow as we add the PGP header and the remailing instructions at each step, but this would be more moderate. The PGP header is about 170 bytes, and the remailing instructions should not be more than 70 or 80 bytes, bringing the total to something less than 250 bytes per step. I did some calculations. Suppose you wanted to start with a message of, say, 4000 bytes which you will send through ten remailers. First off, we get an advantage because PGP will compress the message before encrypting it the first time. Let's suppose it manages to compress it by a factor of two. This means that we have a 2000-byte binary message as our actual starting point. In one model, we assume that we add 250 bytes per step. This is what it would be if we did not have to do the ASCII'ing process at each nesting. In the other model, we assume that we add 170 bytes, multiply by 4/3, then add 65 bytes for the "-----BEGIN PGP MESSAGE-----" stuff, and then another 80 bytes for the remailing instruction. This is how most of the chaining software actually works now. Setting up for a ten step chain, the first method produces an output file of 4500 bytes, while the second produces a file of 54046 bytes. This is quite a difference. If we wanted to add three more steps because we feel paranoid, the first method increases to 5250 bytes, while the second balloons to over 120K bytes! As a more extreme example, if the initial message was 10K bytes as we have sometimes seen here, a ten-step chain would produce an output of 7500 bytes without expansion, and over 100K bytes with expansion. (The smaller-than-input size in the non-expansion case is due to the assumed 2-to-1 PGP compression of the original message.) I think we should consider enhancing the remailers so this asciifying step is not necessary. It could be done something like this. As each remailer receives the message, it must be in ASCII since that is the only thing that makes it across the mail connections. It decrypts and de-ascii's it by running it through PGP just like it does now. Suppose this produces something like the following: :: Request-Remailing-To: <next remailer in chain> <binary data> The first part is in ASCII and is terminated by two new-line characters in a row. The rest of the message can be easily determined to be binary; in fact, it is a binary PGP file, one readable for the NEXT remailer in the chain. This could be detected because PGP puts special bytes at the front of the file. All the remailer has to do specially is to asciify the binary portion of the message, add the "Encrypted: PGP" header if we still use that, and send it off as it normally would. The next remailer receives a proper ASCII PGP message which it can handle by the same rules. Making this enhancment to the remailers would reduce the problems of message bloat caused by the redundant asciifying of the message for each stage of the remailer chain. As we move towards remailers which do batching and which do message padding so that all outgoing messages are the same size, it will be more important to avoid this bloat since one big message will force all others in the batch to be padded to that size by the remailer. Hal Finney hfinney(a)shell.portal.com -----BEGIN PGP SIGNATURE----- Version: 2.2 iQCVAgUBLKpGOqgTA69YIUw3AQGLCQQAgGTXKgPOtgbqs3Dab/PZZNR1XPmLqJIH nuf5Znj3bpOGGPFGPG5pBfSBmDn3U5uEnG7lMwKovSpXI6zxLv3IEd93X6oGaL5L 5SlZtqzWNgGGXIIVCwNkaio/W5DCvwYq3ZXPtOTWgDH4ZtKOPaifEFF885qv/VCw heGzkqREjWM= =qwkV -----END PGP SIGNATURE-----

1 0

fido encryption.
by J. Michael Diehl 17 Dec '03

17 Dec '03

Hi all! I just conducted an experiment whose results indicate how far we (Cypherpunks) have to go in educating the American Public WRT encryption technology: I send an encrypted message via fidonet! (awk!) I had heard a rumor that fidonet forbade encrypted e-mail, but I had to find out for myself. Well, they do. Now I understand that these sysops are spending their own money and equipment to provide these services and have the right to regulate it in any way they see fit. That's not the point. The point(s) is/are: 1) They ACTIVELY enforce this policy. They don't simply say "no," they check (presumably) all of their user's email to enforce this policy. 2) They seem to be afraid to pass/store encrypted messages on their system. This indicates to me a lack of understanding of the concept of privacy. They seem to buy into the idea that "only BAD people encrypt email." We need to educate the electronic community before we can hope to educate the general public. The text of the messages follow with the names removed. BTW, the text of the plaintext message was "this is a test." Just thought you'd be interested. Comments? =========================================================================== BBS: The Tech Source Date: 09-16-93 (00:00) Number: 261 To: MIKE DIEHL Recvd: YES (PVT) Subj: Encrypted Mail Conf: (0) PrivateE-M --------------------------------------------------------------------------- This is a test. -----BEGIN PGP PUBLIC KEY BLOCK----- version: 2.2 mQCNAiu/jPkAAAEEAMGeUcJS+AfY32cDfy/v/UcA9JdqNOBOl/K37jFOBuCkXCSp lBa ---END PGP PUBLIC KEY BLOCK----- Mike, Please advise the sender of this message that I DO NOT allow encrypted mail to pass thru this system. I expect folks to abide by this rule voluntarily... I would hate to have to block all messages from this source becuase someone wishes to violate my policy :) BTW, the debate about "encrypted" mail with me is MOOT... I will not vary from my position... (just thought I'd let you know in case you wanted to try to convince me it is OK to allow encrypted mail...) please have the other person send encrypted mail directly to your machine... Thank you.. Sysop of Another BBS?

4 3

Files on DH, HM, RSA, & HP patents
by strick -- henry strickland 17 Dec '03

17 Dec '03

I've been spending the week in Washington DC, so I went by the Public Search Room of the U S Patent and Trademark office and requested the complete files on the four patents named in rfc1424 (see below). I have photocopies of nearly the complete folders, which include the initial proposed patent and all the written communication between the patent attorney and the patent examiner. (I think all four of these patents had all of their claims rejected on the first pass.) You see the patent examiner explain what is wrong, criticizing the patent, and the subsequent ammendments and more rejections until the patent is granted. (This is important information if one wishes to challenge a patent. You can see how various arguments were dealt with before and what likely responses from patent examiners are.) I'll bring all of this to the October Mountain View cypherpunks meeting, assuming it is Sat Oct 9. I'll also try and be ready to summarize the history of each patent. What are missing from my copies are mostly legal communications that had no techincal interest -- powers of attorney & calculations of fees. I also omitted most of the published articles that were referenced (several other patents and some scholarly papers) and some seemingly redundant diagrams. Of course, I also have copies of the final patents granted. The Search Room is an interesting place. I pulled several faux pas and got quite an education in patents and federal offices.... strick -------------- excerpt follows -------------- RFC 1424 Key Certification and Related Services February 1993 The Massachusetts Institute of Technology and the Board of Trustees of the Leland Stanford Junior University have granted Public Key Partners (PKP) exclusive sub-licensing rights to the following patents issued in the United States, and all of their corresponding foreign patents: Cryptographic Apparatus and Method ("Diffie-Hellman")............................... No. 4,200,770 Public Key Cryptographic Apparatus and Method ("Hellman-Merkle").................... No. 4,218,582 Cryptographic Communications System and Method ("RSA")................................... No. 4,405,829 Exponential Cryptographic Apparatus and Method ("Hellman-Pohlig").................... No. 4,424,414 These patents are stated by PKP to cover all known methods of practicing the art of Public Key encryption, including the variations collectively known as El Gamal.

1 0

Two basic questions...
by Andrew Thomas 17 Dec '03

17 Dec '03

First: Is there an FTP site with the excellent cypherpunk article from Whole Earth Review online? If there isn't, would someone be willing to email me a copy? Second: I couldn't find a clear answer from the pgp docs, is there any reason to upgrade your public key with newer versions of pgp? I generated my keys with 2.2 and am now using 2.3a, does this matter at all? I'm sorry if these questions have been addressed recently, I'm a little out of touch (I've got 700+ unread cypherpunks messages in my folder 8( Thanks, Andrew Thomas <aethomas(a)uci.edu> Distributed Computing Support - Office of Academic Computing University of California, Irvine dcs(a)uci.edu (714)856-8383 -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.2 mQBNAixX9koAAAECANP9I4cYQFIIspJ/GtCjgMh1F0mHSlNvdN+HoMy7mBN9xegI rxLEw1cKIK1pQNYhZBoI63kohSoqN5tYgDWU80kABRG0IEFuZHJldyBUaG9tYXMg PGFldGhvbWFzQHVjaS5lZHU+ =Pk2n -----END PGP PUBLIC KEY BLOCK-----

1 0

Re: Active Eavesdropping of Clipper Phones
by catalyst＠netcom.com 17 Dec '03

17 Dec '03

What you are describing is the classic 'man-in-the-middle' attack. It is not avoidable short of out of band signalling i.e., you know some fact/secret about the person you really want to talk to (like their public key) that does not go through the man-in-the-middle (to possibly be replace), and can't be faked. Even with such knowledge, you still have to design your protocol with care. The essence of one protocol that is proof against this attack is this: Diffie-Hellman key exchange, during which the two parties seeking privacy also exchange challenge data which is returned after being concatenated with the other parties a^x, and signed with their private key. These are only the central parts. Additionally, certificates might be exchanged etc. But even slight changes to this would make it less secure: e.g. if each party only sent the cryptographically signed a^x, then an attacker willing to build the log table to (much later) derive x (this person could even be the intended recipient) could use saved portions of a real exchange to mount a 'replay' attack. Also, choosing a system wide 'a' and 'p' increase the incentive to build the tables, much better to let people put their personal choice for 'a' and 'p' in their signed & sealed key certificate. This protocol is described in detail in a paper (that is not in front of me right now, so I'm a little fuzzy) that was published in 'Designs, Codes and Cryptograpy', a periodical originating in the Netherlands. I believe the authors were Diffie and van Oorschot(?), but I'm just can't remember off the top of my head. If Whit Diffie is reading this message, then surely he will know, I think, even if he wasn't the author. Without 'out of band' signalling, the clipper chip would certainly be subject to this kind of attack. My understanding is that Skipjack is symmetric, so that's no help. We already noted that straight DH key exchange is vulnerable. The only remaining hope, then, is that your phone knows some serial number or such about the phone you _intend_ to be communicating with, and that this fact is an unavoidable part of the IV such that once you know who the message is supposed to be coming from, you couldn't decrypt it unless it really did, and no one else could fake it. This is possible, but obviously teetering on the brink of asymmetry, and therefore, I think, unlikely. The man-in-the-middle attack is so well known, however, that clipper must have _some_ provision for it, and I just haven't read the right paragraph yet. Hope this helps, 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. 5 Infinite Loop, MS 305-2B Cupertino, CA 95014 ....................................................................... PERSONAL. voice/fax:408.257.1746 1024:669687 catalyst(a)netcom.com

1 0

Re: fido encryption.
by msattler＠netcom.com 17 Dec '03

17 Dec '03

At 00:33 9/30/93 -0600, J. Michael Diehl wrote: >We need to educate the electronic community before we can hope to >educate the general public. Damn straight. >BTW, the debate about "encrypted" mail with me is MOOT... I will not vary >from my position... (just thought I'd let you know in case you wanted to >try to convince me it is OK to allow encrypted mail...) please have the >other person send encrypted mail directly to your machine... Scary, isn't it? ----------------------------------------------------------------------------- Michael S. Sattler msattler(a)netcom.com +1 (415) 358-3058 Digital Jungle Software Encrypt now; ask me how. (finger for PGP key) "Don't Panic!" -- Douglas Adams "Don't Panic. Stay Cool." -- PRZ

2 1

Re: soda.berkeley.edu
by jrk＠sys.uea.ac.uk 17 Dec '03

17 Dec '03

It seems to be ok now. ftp> open soda.berkeley.edu Connected to soda.berkeley.edu. 220 soda FTP server (Version wu-2.1c(17) Wed Sep 22 18:58:23 PDT 1993) ready. Name (soda.berkeley.edu:jrk): anonymous 331 Guest login ok, send your complete e-mail address as password. Password: 230-Welcome to soda.berkeley.edu. We have recently upgraded our ftpd to 230-version 2.1c; it may still have some problems. 230-Mail bug reports to root(a)soda.berkeley.edu. 230- 230-Please read the file README 230- it was last modified on Wed Jun 2 17:02:13 1993 - 120 days ago 230 Guest login ok, access restrictions apply. ftp> The cypherpunks directory is still there too. BTW, when anon ftp servers ask you to give your email address as a password, how many of you do? -- ____ Richard Kennaway __\_ / School of Information Systems Internet: jrk(a)sys.uea.ac.uk \ X/ University of East Anglia uucp: ...mcsun!ukc!uea-sys!jrk \/ Norwich NR4 7TJ, U.K.

2 1

Business Week on PGP subpoenas
by an12070＠anon.penet.fi 17 Dec '03

17 Dec '03

BusinessWeek, October 4, 1993 p. 43, Washington Outlook SPY VS. COMPUTER NERD: THE FIGHT OVER DATA SECURITY Philip Zimmermann wanted to strike a blow for freedom. To help computer users keep data safe from snoopers, the Boulder (Colo.) software consultant and self-described "privacy activist" wrote a program making it easy to encode messages with an all-but-unbreakable cipher. And he offered it free through the network known as the Internet. Now, Zimmermann's gift to cyberspace has exposed an enormous gap in the Administration's vision of a high-tech future. The White House is promoting a data superhighway as a key to a competitive future. But the National Security Agency is trying to restrict the use of high-quality encryption, which experts believe business will need to take full advantage of the "information infrastructure." The focus of the fight is a program Zimmermann calls "pretty good privacy" (PGP). On Sept. 9, two software companies in Texas and Arizona that have been involved in publishing PGP received federal grand-jury subpoenas requesting documents and information about the program. CRACKDOWN. Although the government won't discuss the investigation, the computer world has a pretty good idea what's going on. Because sophisticated encryption allows friends and foes alike to protect communications, the software is subject to the same export controls as munitions. But PGP has popped up all over the world. The probe, says Zimmermann's lawyer, Philip Dubois, is aimed at "finding out how it occurred and whether an offence was committed." Oddly, the crackdown on software comes just as the Administration is loosening export controls on computer hardware. But the schizophrenia may be more apparent than real. "I don't think they've got the export policy together enough to be split," says a key congressional staffer. The underlying problem, explains Paul Freedenberg, a Washington attorney and export-controls specialist, is that "Clinton is very cautious about dabbling in national security. This is an area that has essentially been turned over to the spooks." Meanwhile, there is growing concern in Congress about possible damange to exports. Quality encryption software "is available from foreign manufacturers...and is easily transmitted using only a long-distance telephone line and a modem," complained Representative Sam Gejdenson (D-Conn.) and a high-powered bipartisan group of colleagues in a Sept. 20 letter to the President. "Yet the U.S. continues to control this computer software as a Munitions List item." Says Douglas Miller of the Software Publishers Assn.: "The U.S. government is succeeding only in crippling an American industry's exporting ability." While the goal of the NSA and other security agencies - keeping U.S. messages secure while allowing Uncle Sam to read those of both domestic and foreign bad guys - is laudable, technology may be rendering it impossible. "Law enforcers no longer have the inside track," says Eben Moglen of Columbia University law school. Experts agree that NSA officials are smart enough to see the writing on the wall, encrypted or not. But, says James Bitzos [sic], president of RSA Data Security Inc. in Redwood City, Calif., the agency wants to maintain as much control as possible for as long as possible. Today, intelligence agencies still have a shot at finding "needles in the haystack," he says. "If they lift export controls, they might as well go home." Still, the NSA can't stave off the inevitable for long. Gejdenson hopes to produce legislation by early next year to revamp government policy on high-tech exports. The result will probably include looser restrictions on encryption software - and a victory for Phil Zimmermann in his battle to keep snoops out of his cyberspace. By John Carey ------------------------------------------------------------------------- To find out more about the anon service, send mail to help(a)anon.penet.fi. Due to the double-blind, any mail replies to this message will be anonymized, and an anonymous id will be allocated automatically. You have been warned. Please report any problems, inappropriate use etc. to admin(a)anon.penet.fi.

1 0

Re: Active Eavesdropping of Clipper
by catalyst＠netcom.com 17 Dec '03

17 Dec '03

Mike Ingle quotes Matt Blaze (and I paraphrase): >[...] so the procedure for placing a secure call is to recognize >each other's voice in the clear mode, go secure, and read the hash >value to each other [...] you have to rely on prior knowledge of each >other's voice. [...] This is out of band WRT the encryption engine. Note that it can be used exactly like an asymmetric encryption key for authentication. You know the other persons signature/voice in advance and it is hard for an attacker to reproduce it. >[an attacker could] trick you into saying some numbers, digitally record >them, and then rearrange them and play them back. The 'replay' attack. Of course you always make the other person say the hash _and_ some (never reused?) data in a lump (re: my earlier post -- concatenate your challenge data with their a^x before signing) for instance: "Bob, please sing me the hash to the tune of 'Raindrops Keep Fallin' on My Head'" (Security can be fun). >Or introduce enough line noise so the person couldn't recognize your >voice, and read the fake key Signature not valid. Sorry Bob, I'll have to call you back. That is, _if_ it's really you. 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. 5 Infinite Loop, MS 305-2B Cupertino, CA 95014 ....................................................................... PERSONAL. voice/fax:408.257.1746 1024:669687 catalyst(a)netcom.com

1 0

Source for MacPGP 2.3
by jrk＠sys.uea.ac.uk 17 Dec '03

17 Dec '03

I wrote: >I have MacPGP 2.3 (the Macintosh application). From what ftp site can I >obtain the source? soda only has Mac source for 2.2. In fact, I've found that I do have the source for MacPGP 2.3 (although someone told me the source wasn't released yet). I can't remember where I got it though. I won't undertake to email it to anyone, nor to place it on anonftp indefinitely, as the only anonftp area I have is on my desktop machine. However, I'm not going to be around for about a week, so I'm willing to make it available during that time. Any last-minute demands for me not to do this for some reason? Tough, I'm about to leave, after which it's out of my hands. One-time offer, valid for one week only!! ========================================= MacPGP2.3 application, documentation, and source (for Symantec (Think) C 5.0.4), will be available by anon ftp on jrk.sys.uea.ac.uk, from Thurs 30 Sep (today) 14:00 GMT until Fri 8 October 08:00 GMT. Note that this machine is in the UK. It is the responsibility of those accessing it to satisfy themselves of the legality of their actions. These files are available strictly on an "as-is" basis, with no warranty, express or implied, concerning their contents. Instructions: ftp to jrk.sys.uea.ac.uk and give the following commands. user anonymous (Give your email name as password...or not. All transfers will be logged.) cd "RK's Public Folder" (Yes, there are spaces in the name of the directory. This is a Macintosh.) ascii get macpgp2.3src.sea.hqx.pgp (NB. If you are ftp-ing from anything but another Mac, the above file must be transferred in ASCII mode.) binary get macpgp2.3.sit Once you have these files, you need to do the following steps: 0. Put both files on a Mac, if they aren't there already. 1. Use Stuffit 1.5.1 or any decoder (such as DownLine) which understands that format to decode macpgp2.3.sit. This will give several files, one of which is the MacPGP 2.3 application. 2. Use the application to verify the signature on macpgp2.3src.sea.hqx.pgp and to strip the ascii armoring from it, creating a file macpgp2.3src.sea.hqx. (If you already have PGP on a unix machine, you can do this there and then transfer the .hqx file to the Mac.) 3. Use a BinHex decoder to decode macpgp2.3src.sea.hqx. This yields an application macpgp2.3src.sea. 4. Run that application, and it will decode itself into the source for MacPGP2.3. Paranoids should note that macpgp2.3.sit is not PGP-signed, and you only have my word that it does what I say it does. macpgp2.3src.sea.hqx.pgp is signed, but not by me, and I am not in a position to certify its signature. I use MPW C, so I haven't even compiled the source myself. I am *not* able to answer any questions about MacPGP itself, nor will I or anyone else be available during the coming week to sort out any ftp problems. I will probably be out of reach of email during that time as well. -- ____ Richard Kennaway __\_ / School of Information Systems Internet: jrk(a)sys.uea.ac.uk \ X/ University of East Anglia uucp: ...mcsun!ukc!uea-sys!jrk \/ Norwich NR4 7TJ, U.K.

1 0

FIDOnet encryption (or lack thereof)
by Just-in-time terraforming 30-Sep-1993 1008 17 Dec '03

17 Dec '03

>Mike, Please advise the sender of this message that I DO NOT allow >encrypted mail to pass thru this system. I expect folks to abide by this >rule voluntarily... > >I would hate to have to block all messages from this source becuase >someone wishes to violate my policy :) > >BTW, the debate about "encrypted" mail with me is MOOT... I will not vary >from my position... (just thought I'd let you know in case you wanted to >try to convince me it is OK to allow encrypted mail...) please have the >other person send encrypted mail directly to your machine... Heh. OK. Well, if one behaves "ethically", then I guess *that* closes the issue. It's his machine and he gets to make the rules. (this is my personally-adhered-to point of view) On the other hand, he doesn't seem to have protected himself against steganographic users (though the low bandwidth of steganography compared to obvious encryption may make the steg channel less useful). Others may choose to take this point of view- but it's your karma. -Bill

5 8

A Word From Bill
by Duncan Frissell 17 Dec '03

17 Dec '03

Since president(a)whitehouse.gov is not yet a full duplex operation, I wanted to take this opportunity to speak personally to all you cypherpunkian-Americans (and the odd foreigner) out there. I feel your pain. I understand your concerns. Your concerns are my concerns. As I said on September 14th: I want to say to my fellow Americans, when you live in a time of change, the only way to recover your security and broaden your horizons is to adapt to the change, to embrace it, to move forward. Nothing we do, nothing we do in this great capital can change the fact that factories or information can flash across the world, that people can move money around in the blink of an eye. Nothing can change the fact that technology can be adopted, once created, by people all across the world and then rapidly adapted in new and different ways by people who have a little different take on the way that technology works... ...I tell you my fellow Americans, that if we learn anything from the collapse of the Berlin Wall and the fall of the governments of Eastern Europe, even a totally controlled society cannot resist the winds of change that economics, and technology, and information flow have imposed on this world of ours. That is not an option. Our only realistic option is to embrace these changes... William Jefferson Blythe Clinton --- WinQwk 2.0b#0

1 0