December 2003 - cypherpunks-legacy

NSA into antigravity?
by Vladimir Z. Nuri 17 Dec '03

17 Dec '03

this apparently involves credible researchers, and it's something that would be pretty bizarre if the NSA is really implicated.. ------- Forwarded Message Date: Fri, 18 Aug 95 18:04:09 -0700 From: Albert Nanomius <nanomius(a)netcom.com> - ------- Forwarded Message Date: Thu, 17 Aug 1995 17:03:00 -0500 From: "chris (c.) currivan" <currivan(a)bnr.ca> To: snet-l(a)world.std.com Subject: NSA and science A post from alt.conspiracy: Francis E. Decstation <fed(a)cca.org> wrote: > >On July 19, Gerald Ollman and Robert Wayne, two researchers from the >University of Maryland geophysics department were detained in Fort Meade, >Maryland, apparently by agents of the National Security Agency, whilst >taking measurements of the Earth's gravitational field. After 18 hours of >questioning, they were released after being instructed not to discuss the >incident. Their equipment and results were not returned. > >Neither the University nor the NSA has commented on the incident. However, >it is believed that Ollman and Wayne were investigating a slight anomaly >in the Earth's gravitational field centered around Fort Meade. No reason has >been given for their detention.

2 1

Makes the News! (Was Re: SSL Broken)
by Robert Zach 17 Dec '03

17 Dec '03

The first trade mag article I have seen on the Subject has been delivered to my doorstep!! Check out COMMUNICATIONS WEEK August 21 PAGE 1 FYI -Rob

1 0

subscribing to cypherpunks
by ketcher＠ix.netcom.com 17 Dec '03

17 Dec '03

Lance Cottrell: Sandy Sandfort suggested I write to you about subscribing to cypherpunks. How can one do it? Thank you. Mike Ketcher

1 0

EPIC Alert 2.09
by Dave Banisar 17 Dec '03

17 Dec '03

============================================================= @@@@ @@@@ @@@ @@@@ @ @ @@@@ @@@@ @@@@@ @ @ @ @ @ @ @ @ @ @ @ @ @@@@ @@@ @ @ @@@@@ @ @@@ @@@ @ @ @ @ @ @ @ @ @ @ @ @ @@@@ @ @@@ @@@@ @ @ @@@@ @@@@ @ @ @ ============================================================= Volume 2.09 August 21, 1995 ------------------------------------------------------------- Published by the Electronic Privacy Information Center (EPIC) Washington, DC info(a)epic.org http://www.epic.org *Special Edition: Crypto* ======================================================================= Table of Contents ======================================================================= [1] "New" Crypto Policy Announced: Clipper II? [2] NIST Announcement on Key-Escrow Workshops [3] Documents: FBI & NSA Want to Ban Non-Escrowed Encryption [4] EPIC Crypto Web Pages Online [5] Upcoming Conferences and Events ======================================================================= [1] "New" Crypto Policy Announced: Clipper II? ======================================================================= The Clinton Administration ended a year of silence on August 17 when it issued a long-awaited statement on the Clipper Chip and key-escrow encryption. Unfortunately, the "new" policy is merely a re-working of the old one -- the Administration remains committed to key-escrow techniques that ensure government agents access to encrypted communications. The only changes are a willingness to consider the export of 64-bit encryption (if "properly escrowed"), the possibility of private sector escrow agents to serve as key-holders, and consideration of software implementations of key-escrow technologies. As EPIC Advisory Board member Whit Diffie observed in an op-ed piece in the New York Times, the new approach won't work. "While other nations may share our interest in reading encrypted messages for law enforcement purposes, they are unlikely to embrace a system that leaves them vulnerable to U.S. spying. They will reject any system that gives decoding ability to agents in the United States." Diffie further notes that "64-bit keys are not expected to be adequate." In a statement re-printed below, the National Institute of Standards and Technology (NIST) announced two public workshops "to discuss key escrow issues." More information concerning these meetings can be obtained from Arlene Carlton at NIST, (301) 975-3240, fax: (301) 948-1784, e-mail: carlton(a)micf.nist.gov. ======================================================================= [2] NIST Announcement on Key-Escrow Workshops ======================================================================= EMBARGOED FOR RELEASE: NIST 95-24 3 p.m. EDT, Thursday, Aug. 17, 1995 Contact: Anne Enright Shepherd COMMERCE'S NIST ANNOUNCES (301) 975-4858 PROCESS FOR DIALOGUE ON KEY ESCROW ISSUES Furthering the Administration's commitment to defining a workable key escrow encryption strategy that would satisfy government and be acceptable to business and private users of cryptography, the Commerce Department's National Institute of Standards and Technology announced today renewed dialogue on key escrow issues. A Sept. 6-7 workshop will convene industry and government officials to discuss key escrow issues, including proposed liberalization of export control procedures for key escrow software products with key lengths up to 64 bits, which would benefit software manufacturers interested in building secure encryption products that can be used both domestically and abroad. Key escrow encryption is part of the Administration's initiative to promote the use of strong techniques to protect the privacy of data and voice transmissions by companies, government agencies and others without compromising the government's ability to carry out lawful wiretaps. In a July 1994 letter to former Rep. Maria Cantwell, Vice President Gore said that the government would work on developing exportable key escrow encryption systems that would allow escrow agents outside the government, not rely on classified algorithms, be implementable in hardware or software, and meet the needs of industry as well as law enforcement and national security. Since that time, discussions with industry have provided valuable guidance to the Administration in the development of this policy. For example, many companies are interested in using a corporate key escrow system to ensure reliable back-up access to encrypted information, and the renewed commitment should foster the development of such services. Consideration of additional implementations of key escrow comes in response to concerns expressed by software industry representatives that the Administration's key escrow policies did not provide for a software implementation of key escrow and in light of the needs of federal agencies for commercial encryption products in hardware and software to protect unclassified information on computer and data networks. Officials also announced a second workshop at which industry is invited to help develop additional Federal Information Processing Standards for key escrow encryption, specifically to include software implementations. This standards activity would provide federal government agencies with wider choices among approved key escrow encryption products using either hardware or software. Federal Information Processing Standards provide guidance to agencies of the federal government in their procurement and use of computer systems and equipment. Industry representatives and others interested in joining this standards-development effort are invited to a key escrow standards exploratory workshop on Sept. 15 in Gaithersburg, Md. This workshop is an outgrowth of last year's meetings in which government and industry officials discussed possible technical approaches to software key escrow encryption. The Escrowed Encryption Standard, a Federal Information Processing Standard for use by federal agencies and available for use by others, specifies use of a Key Escrow chip (once referred to as "Clipper chip") to provide strong encryption protection for sensitive but unclassified voice, fax and modem communications over telephone lines. Currently, this hardware-based standard is the only FIPS-approved key escrow technique. NIST officials anticipate proposing a revision to the Escrowed Encryption Standard to allow it to cover electronic data transmitted over computer networks. Under this revised federal standard, the Capstone chip and other hardware-based key escrow techniques developed for use in protecting such electronic data also will be approved for use by federal agencies. As a non-regulatory agency of the Commerce Department's Technology Administration, NIST promotes U.S. economic growth by working with industry to develop and apply technology, measurements and standards. ======================================================================= [3] Documents: FBI & NSA Want to Ban Non-Escrowed Encryption ======================================================================= On a related note ... Declassified government documents recently obtained by EPIC show that key federal agencies concluded more than two years ago that the "Clipper Chip" key-escrow initiative will only succeed if alternative security techniques are outlawed. The information is contained in several hundred pages of material concerning Clipper and cryptography EPIC obtained from the FBI under the Freedom of Information Act. The conclusions contained in the documents appear to conflict with frequent Administration claims that use of key-escrow technology will remain "voluntary." Critics of the government's initiative, including EPIC, have long maintained that government-sanctioned key- escrow encryption techniques would only serve their stated purpose if made mandatory. According to the FBI documents, that view is shared by the Bureau, the National Security Agency (NSA) and the Department of Justice (DOJ). In a "briefing document" titled "Encryption: The Threat, Applications and Potential Solutions," and sent to the National Security Council in February 1993, the FBI, NSA and DOJ concluded that: Technical solutions, such as they are, will only work if they are incorporated into *all* encryption products. To ensure that this occurs, legislation mandating the use of Government-approved encryption products or adherence to Government encryption criteria is required. Likewise, an undated FBI report titled "Impact of Emerging Telecommunications Technologies on Law Enforcement" observes that "[a]lthough the export of encryption products by the United States is controlled, domestic use is not regulated." The report concludes that "a national policy embodied in legislation is needed." Such a policy, according to the FBI, must ensure "real-time decryption by law enforcement" and "prohibit[] cryptography that cannot meet the Government standard." The FBI conclusions stand in stark contrast to public assurances that the government does not intend to prohibit the use of non- escrowed encryption. Testifying before a Senate Judiciary Subcommittee on May 3, 1994, Assistant Attorney General Jo Ann Harris asserted that: As the Administration has made clear on a number of occasions, the key-escrow encryption initiative is a voluntary one; we have absolutely no intention of mandating private use of a particular kind of cryptography, nor of criminalizing the private use of certain kinds of cryptography. The newly-disclosed information suggests that the architects of the key-escrow program -- NSA and the FBI -- have always recognized that key-escrow must eventually be mandated. Coming to light on the eve of the announcement of a "new" Administration policy, the FBI documents raise significant questions as to the government's long-term strategy on the cryptography issue. Scanned images of several key documents are available via the World Wide Web at http://www.epic.org/crypto/ban/fbi_dox/ ======================================================================= [4] EPIC Crypto Policy Web Pages Online ======================================================================= EPIC is now making available an extensive series of pages on cryptography policy. Each page highlights an area of controversy and provides links to key documents. Materials include formerly secret government documents obtained under FOIA by EPIC and CPSR, reports from the Office of Technology Assessment, the General Accounting Office and others on cryptography. Topics include: o Efforts to ban cryptography o The Clipper Chip o The Digital Signature Standard o The Computer Security Act of 1987 The pages are available at http://www.epic.org/crypto/ More pages will become available soon. ======================================================================= [5] Upcoming Privacy Related Conferences and Events ======================================================================= Advanced Surveillance Technologies. Sept. 4, 1995. Copenhagen, Denmark. Sponsored by Privacy International and EPIC. Contact pi(a)privacy.org. http://www.privacy.org/pi/conference/ 17th International Conference of Data Protection and Privacy Commissioners. Copenhagen, Denmark. September 6-8, 1995. Sponsored by the Danish Data Protection Agency. Contact Henrik Waaben, +45 33 14 38 44 (tel), +45 33 13 38 43 (fax). InfoWarCon '95. September 7-8, 1995. Arlington, VA. Sponsored by NCSA and OSS. Email: 74777.3033(a)compuserve.com. Business and Legal Aspects of Internet and Online Services. Sept. 14-15. New York City. Sponsored by National Law Journal and New York Law Journal. Contact: (800)888-8300, ext. 6111, or (212)545-6111. The Good, the Bad, and the Internet: A Conference on Critical Issues in Information Technology. October 7-8. Chicago, Ill. Sponsored by CPSR. Contact cpsr(a)cpsr.org or http://www.cs.uchicago.edu/discussions/cpsr/annual 18th National Information Systems Security Conference. Oct. 10-13. Baltimore, MD. Sponsored by NSA and NIST. Contact: 301-975-3883. Managing the Privacy Revolution. Oct. 31 - Nov. 1, 1995. Washington, DC. Sponsored by Privacy & American Business. Speakers include Mike Nelson (White House) C.B. Rogers (Equifax) and Marc Rotenberg (EPIC). Contact Alan Westin 201/996-1154. 22nd Annual Computer Security Conference and Exhibition. Nov. 6-8, Washington, DC. Sponsored by the Computer Security Institute. Contact: 415-905-2626. Global Security and Global Competitiveness: Open Source Solutions. Nov. 7-9. Washington, D.C. Sponsored by OSS. Contact: Robert Steele oss(a)oss.net. 11th Annual Computer Security Applications Conference: Technical papers, panels, vendor presentations, and tutorials that address the application of computer security and safety technologies in the civil, defense, and commercial environments. Dec. 11-15, 1995, New Orleans, Louisiana. Contact Vince Reed at (205)890-3323 or vreed(a)mitre.org. Computers Freedom and Privacy '96. March 27-30. Cambridge, Mass. Sponsored by MIT, ACM and WWW Consortium. Contact cfp96(a)mit.edu or http://www-swiss.ai.mit.edu/~switz/cfp96 Australasian Conference on Information Security and Privacy June 24-26, 1996. New South Wales, Australia. Sponsored by Australasian Society for Electronic Security and University of Wollongong. Contact: Jennifer Seberry (jennie(a)cs.uow.edu.au) (Send calendar submissions to Alert(a)epic.org) ======================================================================= The EPIC Alert is a free biweekly publication of the Electronic Privacy Information Center. To subscribe, send the message: SUBSCRIBE CPSR-ANNOUNCE Firstname Lastname to listserv(a)cpsr.org. You may also receive the Alert by reading the USENET newsgroup comp.org.cpsr.announce. Back issues are available via http://www.epic.org/alert/ or FTP/WAIS/Gopher/HTTP from cpsr.org /cpsr/alert/ and on Compuserve (Go NCSA), Library 2 (EPIC/Ethics). ======================================================================= The Electronic Privacy Information Center is a public interest research center in Washington, DC. It was established in 1994 to focus public attention on emerging privacy issues relating to the National Information Infrastructure, such as the Clipper Chip, the Digital Telephony proposal, medical record privacy, and the sale of consumer data. EPIC is sponsored by the Fund for Constitutional Government and Computer Professionals for Social Responsibility. EPIC publishes the EPIC Alert and EPIC Reports, pursues Freedom of Information Act litigation, and conducts policy research on emerging privacy issues. For more information, email info(a)epic.org, WWW at HTTP://www.epic.org or write EPIC, 666 Pennsylvania Ave., SE, Suite 301, Washington, DC 20003. (202) 544-9240 (tel), (202) 547-5482 (fax). The Fund for Constitutional Government is a non-profit organization established in 1974 to protect civil liberties and constitutional rights. Computer Professionals for Social Responsibility is a national membership organization of people concerned about the impact of technology on society. For information contact: cpsr-info(a)cpsr.org If you'd like to support the work of the Electronic Privacy Information Center, contributions are welcome and fully tax-deductible. Checks should be made out to "The Fund for Constitutional Government" and sent to EPIC, 666 Pennsylvania Ave., SE, Suite 301, Washington DC 20003. Your contributions will help support Freedom of Information Act litigation, strong and effective advocacy for the right of privacy and efforts to oppose government regulation of encryption and funding of the National Wiretap Plan.. Thank you for your support. ------------------------ END EPIC Alert 2.09 ------------------------ _________________________________________________________________________ Subject: EPIC Alert 2.09 _________________________________________________________________________ David Banisar (Banisar(a)epic.org) * 202-544-9240 (tel) Electronic Privacy Information Center * 202-547-5482 (fax) 666 Pennsylvania Ave, SE, Suite 301 * HTTP://epic.org Washington, DC 20003 * ftp/gopher/wais cpsr.org

1 0

interesting quote, Baltimore Sun 8/21
by Thomas M. Swiss 17 Dec '03

17 Dec '03

Page 7A of today's _Baltimore Sun_ features an op-ed piece by Carl R. Eisendrath, "a former U.S. foreign-service officer", entitled "Bringing Light to Covert Operations", which cites an interesting quotation: "In the period between the two world wars, Secretary of War Henry Stimson closed the cryptography section of the State Department because, as he reputedly said, "Gentlemen don't read each other's mail." -Tom Swiss / tms(a)tis.com

1 0

Re: Newton 2
by ethridge＠Onramp.NET 17 Dec '03

17 Dec '03

<<crossed to cypherpunks>> >At 8:56 AM 8/21/95, Robert Patoine wrote: > >>Metroworks do Have a C Compiler for the Newton Hardware develloped for >>Sony-Magic Cap OS > >Magic Cap works on Magic Cap PDAs. The newton is not one of them. >Motorola uses magic cap for their PDAs, and I think AT&T does as well, but >that's an uncertainty. > Considering that AT&T markets PersonaLink as an e-mail service for MagicCap users i suspect they do support MagicCap in at least one of their PDAs. PersonaLink is, i believe, related to Telescript, which is the scripting language for MagicCap (OK, it's a bit more than a scripting language, but i'm not that into it). I've heard a few times that not having a C compiler prevents the implementation of PGP. Why? Do the RSA people refuse to license a non-C implementation. If so, can they still enforce their patent against someone who implemented it on a platform that didn't have a C compiler? But then i hear that the Newton will have some support for C development sometime this year. allen

2 1

NEXT CHALLENGE...
by aba＠exe.ex.ac.uk 17 Dec '03

17 Dec '03

[Please note mail to me may bounce unless you are very careful with using addr aba(a)exe.ex.ac.uk, or aba(a)atlas.ex.ac.uk, as there are machines out here due to a physical breakin - a "RAM raid", I tried posting this on Sat, but the mailer was already out and mail is buffered, so may come out twice] A break down of Hal's challenge, could someone please check my logic in deriving an Andrew Roo's style config file for brutessl 1.0 and check my interpretation against Hal's interpretation in the previous challenge. Hal's previous challenge is indexed from his home page: http://www.portal.com/~hfinney/ I think the challenge file should look like this: -------------------------------------8<------------------------------------- # SSLbrute 1.0 parameter file for Hal Finney's 2nd SSL challenge as # posted to Cypherpunks on 19 August 1995. # # file checksum (ignoring # comments and whitespace) is 2977 CLEAR-MASTER fbc009916010a6153f8f36 CHALLENGE 07ea7b9d65eb61fabb4174e8453a5fc6 CONNECTION-ID d5e638d68ca8a1aeca2ef8c8e29602a4 SERVER-VERIFY 006599b6d2f2a736 -------------------------------------8<------------------------------------- Below I will give my resoning for each field. Each field as it is derived will be quoted with >>> Could a few people check that I have made no mistakes. Andrew Roos code is on: http://www.brute.cl.cam.ac.uk/brute/ as "brutessl.tar.gz", use "save next link as" in netscape (hold shift key down and click in Netscape 1.1). Could someone with a PC, and a 32 bit MS Visual C++ compiler handy compile a PC executable from the tarred files, some people won't have access to TAR under DOS, and a precompiled binary would be useful. Please send the binary to Piete if you do this (be sure to turn on all optimisations). I tried but my VC++ is not 32 bit, is it possible to produce 32 bit binaries which can be run from DOS with VC++ at all? Are the binaries you get with win 95 / win NT likely to run under DOS ? The keyserver will not be doling yet but please pickup the software ready to start. There is a unix based client, and a windows NT based client both available from that page. ---------------------------------------------------------------------- First message from client 0x80 0x1c 0x01 0x00 0x02 0x00 0x03 0x00 0x00 0x00 0x10 0x02 0x00 0x80 0x07 0xea 0x7b 0x9d 0x65 0xeb 0x61 0xfa 0xbb 0x41 0x74 0xe8 0x45 0x3a 0x5f 0xc6 0x80 0x1c Length field: 28 bytes follow in the packet. 0x01 MSG_CLIENT_HELLO 0x00 0x02 CLIENT-VERSION-MSB CLIENT-VERSION-LSB 0x00 0x03 CIPHER-SPECS-LENGTH-MSB CIPHER-SPECS-LENGTH-LSB 0x00 0x00 SESSION-ID-LENGTH-MSB SESSION-ID-LENGTH-LSB 0x00 0x10 CHALLENGE-LENGTH-MSB CHALLENGE-LENGTH-LSB 0x02 0x00 0x80 CIPHER-SPECS-DATA SESSION-ID-DATA 0x07 .. 0xc6 CHALLENGE-DATA [16 bytes] CHALLENGE is: >>> CHALLENGE 07ea7b9d65eb61fabb4174e8453a5fc6 first message from server 0x82 0x14 0x04 0x00 0x01 0x00 0x02 0x01 0xf6 0x00 0x03 0x00 0x10 0x30 0x82 0x01 0xf2 0x30 0x82 0x01 0x5b 0x02 0x02 0x01 0x8a 0x30 0x0d 0x06 0x09 0x2a 0x86 0x48 0x86 0xf7 0x0d 0x01 0x01 0x04 0x05 0x00 0x30 0x47 0x31 0x0b 0x30 0x09 0x06 0x03 0x55 0x04 0x06 0x13 0x02 0x55 0x53 0x31 0x10 0x30 0x0e 0x06 0x03 0x55 0x04 0x0b 0x13 0x07 0x54 0x65 0x73 0x74 0x20 0x43 0x41 0x31 0x26 0x30 0x24 0x06 0x03 0x55 0x04 0x0a 0x13 0x1d 0x4e 0x65 0x74 0x73 0x63 0x61 0x70 0x65 0x20 0x43 0x6f 0x6d 0x6d 0x75 0x6e 0x69 0x63 0x61 0x74 0x69 0x6f 0x6e 0x73 0x20 0x43 0x6f 0x72 0x70 0x2e 0x30 0x1e 0x17 0x0d 0x39 0x35 0x30 0x37 0x31 0x31 0x32 0x32 0x34 0x31 0x34 0x35 0x5a 0x17 0x0d 0x39 0x37 0x30 0x37 0x31 0x30 0x32 0x32 0x34 0x31 0x34 0x35 0x5a 0x30 0x7f 0x31 0x0b 0x30 0x09 0x06 0x03 0x55 0x04 0x06 0x13 0x02 0x55 0x53 0x31 0x0b 0x30 0x09 0x06 0x03 0x55 0x04 0x08 0x13 0x02 0x43 0x41 0x31 0x16 0x30 0x14 0x06 0x03 0x55 0x04 0x07 0x13 0x0d 0x4d 0x6f 0x75 0x6e 0x74 0x61 0x69 0x6e 0x20 0x56 0x69 0x65 0x77 0x31 0x26 0x30 0x24 0x06 0x03 0x55 0x04 0x0a 0x13 0x1d 0x4e 0x65 0x74 0x73 0x63 0x61 0x70 0x65 0x20 0x43 0x6f 0x6d 0x6d 0x75 0x6e 0x69 0x63 0x61 0x74 0x69 0x6f 0x6e 0x73 0x20 0x43 0x6f 0x72 0x70 0x2e 0x31 0x23 0x30 0x21 0x06 0x03 0x55 0x04 0x03 0x13 0x1a 0x45 0x2d 0x53 0x74 0x6f 0x72 0x65 0x20 0x54 0x72 0x61 0x6e 0x73 0x61 0x63 0x74 0x69 0x6f 0x6e 0x20 0x53 0x65 0x72 0x76 0x65 0x72 0x30 0x5c 0x30 0x0d 0x06 0x09 0x2a 0x86 0x48 0x86 0xf7 0x0d 0x01 0x01 0x01 0x05 0x00 0x03 0x4b 0x00 0x30 0x48 0x02 0x41 0x00 0xc7 0x24 0x0d 0xbd 0xfe 0x5f 0x21 0x09 0xb4 0x46 0x12 0xbb 0xc7 0x4c 0xbc 0x0c 0x98 0xe3 0x11 0x19 0x60 0x85 0x86 0x0a 0xa2 0xaf 0xae 0x8f 0xf9 0x43 0x86 0x92 0x1f 0xcc 0xd3 0x38 0xcf 0x92 0x14 0xa7 0x8c 0x89 0x07 0x26 0xd4 0x21 0x55 0xa8 0x43 0x2d 0xb4 0xec 0xce 0x24 0x73 0x5e 0x7c 0xe2 0xbe 0x22 0x2d 0xbd 0x96 0xbf 0x02 0x03 0x01 0x00 0x01 0x30 0x0d 0x06 0x09 0x2a 0x86 0x48 0x86 0xf7 0x0d 0x01 0x01 0x04 0x05 0x00 0x03 0x81 0x81 0x00 0x8f 0xbe 0x0c 0xae 0xc8 0xf0 0x22 0xef 0xae 0x83 0xb5 0xb1 0xe3 0xb4 0xd9 0xd6 0xa9 0x4a 0xb6 0x60 0x9c 0x0b 0x00 0x70 0x12 0x88 0x73 0xd1 0xef 0xe2 0x54 0xf6 0x3a 0xc7 0xa5 0xbe 0xe1 0xe0 0xdb 0x4d 0x20 0x10 0x3d 0x68 0x7c 0x8d 0xdb 0x16 0xf6 0x67 0xe7 0x1d 0x51 0xbc 0x19 0xa2 0xf6 0xbf 0x6f 0xa4 0x52 0xc7 0x7e 0x50 0x3d 0xb9 0x3e 0x1e 0x67 0xff 0xf6 0xf2 0x5d 0xe7 0x2b 0x7e 0x3a 0x7e 0x6c 0x40 0xb7 0x04 0x9c 0x2c 0x2b 0x89 0x0f 0x8c 0xb5 0x93 0xd8 0xac 0x94 0xe6 0x5f 0x84 0xe8 0x71 0x75 0x9e 0x10 0x6e 0x36 0xe6 0x14 0xfe 0xba 0xf8 0x11 0x71 0x9d 0x74 0x33 0x48 0x74 0xc1 0xba 0xcb 0xff 0x58 0x86 0x8c 0xba 0x9c 0x08 0xad 0xce 0x8a 0x02 0x00 0x80 0xd5 0xe6 0x38 0xd6 0x8c 0xa8 0xa1 0xae 0xca 0x2e 0xf8 0xc8 0xe2 0x96 0x02 0xa4 This is interpreted as follows: 0x82 0x14 Packet length, 532 bytes follow. 0x04 MSG-SERVER-HELLO 0x00 SESSION-ID-HIT 0x01 CERTIFICATE-TYPE 0x00 0x02 SERVER-VERSION-MSB SERVER-VERSION-LSB 0x01 0xf6 CERTIFICATE-LENGTH-MSB CERTIFICATE-LENGTH-LSB 0x00 0x03 CIPHER-SPECS-LENGTH-MSB CIPHER-SPECS-LENGTH-LSB 0x00 0x10 CONNECTION-ID-LENGTH-MSB CONNECTION-ID-LENGTH-LSB 0x30...0x8a CERTIFICATE-DATA [502 bytes] 0x02 0x00 0x80 CIPHER-SPECS-DATA 0xd5...0xa4 CONNECTION-ID-DATA [16 bytes] CONNECTION-ID is: >>> CONNECTION-ID d5e638d68ca8a1aeca2ef8c8e29602a4 Second message from client 0x80 0x55 0x02 0x02 0x00 0x80 0x00 0x0b 0x00 0x40 0x00 0x00 0xfb 0xc0 0x09 0x91 0x60 0x10 0xa6 0x15 0x3f 0x8f 0x36 0x5a 0x19 0x06 0x8e 0x58 0xc4 0xfa 0xd0 0x73 0xd4 0x6d 0x20 0x97 0x2f 0x85 0x95 0xb3 0xa5 0x97 0xb5 0xe0 0x63 0x91 0x61 0xb7 0x76 0x3c 0x4e 0x62 0x8b 0x02 0x2b 0x05 0x98 0xd4 0x14 0x44 0x63 0xf3 0x43 0x7e 0xa0 0xa8 0x3f 0x16 0xb2 0x43 0x4b 0x24 0x76 0xae 0xba 0x8c 0x89 0x71 0xde 0x25 0x6b 0xce 0x89 0x77 0x8a 0x30 0x2a This is interpreted as follows: 0x80 0x55 Packet length, 85 bytes follow. 0x02 MSG-CLIENT-MASTER-KEY 0x02 0x00 0x80 CIPHER-KIND 0x00 0x0b CLEAR-KEY-LENGTH-MSB CLEAR-KEY-LENGTH-LSB 0x00 0x40 ENCRYPTED-KEY-LENGTH-MSB ENCRYPTED-KEY-LENGTH-LSB 0x00 0x00 KEY-ARG-LENGTH-MSB KEY-ARG-LENGTH-LSB 0xfb...0x36 CLEAR-KEY-DATA [11 bytes] 0x5a...0x2a ENCRYPTED-KEY-DATA [64 bytes] KEY-ARG-DATA So CLEAR-MASTER is: >>> CLEAR-MASTER fbc009916010a6153f8f36 Second message from server 0x80 0x21 0x9a 0xc5 0xf7 0xd1 0x6a 0x5b 0x26 0x43 0x57 0x67 0x65 0xb6 0x3f 0x9a 0xe3 0x82 0x00 0x65 0x99 0xb6 0xd2 0xf2 0xa7 0x36 0xa0 0x7d 0xd9 0x94 0xcf 0xe2 0x33 0xb2 0x1b This is interpreted as follows: 0x80 0x21 Packet length, 33 bytes follow 0x9a...0x82 RC4 encrypted MAC [16 bytes] 0x00 RC4 encrypted MSG-SERVER-VERIFY (0x05) 0x65...0x1b RC4 encrypted CHALLENGE-DATA from CLIENT-HELLO message [16 bytes] Plaintext (MSG-SERVER-VERIFY plus CHALLENGE-DATA): 0x05 0x07 0xea 0x7b 0x9d 0x65 0xeb 0x61 0xfa 0xbb 0x41 0x74 0xe8 0x45 0x3a 0x5f 0xc6 Ciphertext (from SERVER-VERIFY packet): 0x00 0x65 0x99 0xb6 0xd2 0xf2 0xa7 0x36 0xa0 0x7d 0xd9 0x94 0xcf 0xe2 0x33 0xb2 0x1b SERVER-VERIFY is the encrypted MSG-SERVER-VERIFY plus the first seven bytes of the encrypted CHALLENGE-DATA: >>> SERVER-VERIFY 006599b6d2f2a736 So the completed challenge file is: -------------------------------------8<------------------------------------- # SSLbrute 1.0 parameter file for Hal Finney's 2nd SSL challenge as # posted to Cypherpunks on 19 August 1995. # # file checksum (ignoring # comments and whitespace) is 2977 CLEAR-MASTER fbc009916010a6153f8f36 CHALLENGE 07ea7b9d65eb61fabb4174e8453a5fc6 CONNECTION-ID d5e638d68ca8a1aeca2ef8c8e29602a4 SERVER-VERIFY 006599b6d2f2a736 -------------------------------------8<------------------------------------- Adam

1 0

Third World Man
by tcmay＠got.net 17 Dec '03

17 Dec '03

(Wow! I just trimmed 7 of the 8 names cc:ed on this message I'm quoting...I think the auto-quoting software most of use is getting out of hand. The trimmed recipients were; To: bdavis(a)thepoint.net, aba(a)atlas.ex.ac.uk, davby(a)ida.liu.se, Damien.Doligez(a)inria.fr, hfinney(a)shell.portal.com, asb(a)nexor.co.uk) Anyway... At 9:19 PM 8/20/95, Adam Shostack wrote: >| So ... has this proven that the banning of strong crypto is the correct >| way to go, and that, at least to some, credit card transactions using >| weak crypto will be acceptable to most (given the ease of getting CC#s >| other ways)? > > No. Banning strong crypto will not help; those darn furriners >are using it anyway. What it will mean is that the Information >Infrastructure of the future will bypass the United States, as without >strong cryptography, it is impossible to build a secure architechture. > > Should the United States wish to relagate itself to the status >of a third world nation becuase of terrorists, druge dealers, child >pornorgaphers and money launderers, that is indeed unfortunate. The U.S. is not likely to find itself relegated to third world status over this issue. Rhetorically, I wish it were so, but it just ain't. This issue--like the McCarthy hearings in the 1950s, the race issue in the '60s, the Vietnam war in the '60s and '70s, to name a few cases, _sounds_ really serious. And it is, as those cases were, but predicting the imminent collapse of American civilization is usually a lose. There is no way the technologlcal and manufacturing prowess of leading American companies will be substantially crippled. I would like to see export laws relaxed, especially as they are seldom effective, and so on. You know my views. But the likeliest outcome if strong crypto export remains hard, but import is unaffected, is that strong crypto will be imported from Europe and elsewhere. (It does not violate any laws that I am aware of to have a product for sale in the U.S. with "hooks" for arbitrary crypto, so long as that product and the hooks are not _exported_. Naturally, companies like Microsoft, Lotus, Novell, etc., do not want to have a U.S. version and an export version. But if they _have_ to, they can. My point is that this would certainly not relegate the U.S. to Third World status, at least not faster than many other trends are already doing.) Several European companies are strong in crypto, of course. --Tim May ---------:---------:---------:---------:---------:---------:---------:---- Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay(a)got.net (Got net?) | anonymous networks, digital pseudonyms, zero 408-728-0152 | knowledge, reputations, information markets, Corralitos, CA | black markets, collapse of governments. Higher Power: 2^756839 | Public Key: PGP and MailSafe available. "National borders are just speed bumps on the information superhighway."

3 2

Why 64 bit keys?
by JMKELSEY＠delphi.com 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- >Date: Sat, 19 Aug 1995 15:13:35 -0400 >From: shamrock(a)netcom.com (Lucky Green) >Subject: Re: 64 bit keys breakable by the NSA or just some random key length? >I think the obvious conclusion would be because 64bits is crackable >if need be and if you have the resources the goverment has. Not for >routine monitoring of undesirables, but for those special cases >where they don't want to expose their activities by requesting a >warrant. I think it's much more important to the powers that be (and that eavesdrop) that a key of up to 64 bits includes DES, which means that lots of system designers will use DES instead of (say) 3DES, IDEA, or Blowfish. It's virtually certain that NSA and others have built keysearch machines for DES. This gives NSA, et. al., a way around the key escrow scheme when they want it. Better yet, NSA can tell the FBI and BATF and such agencies where to find the technical papers on how to build one, without releasing any highly-classified information--those agencies can hire someone to build them one. This also keeps NSA from having to dirty its hands with law-enforcement surveilance. Of course, it will be interesting to see whether pressure is applied to keep people from offering "nonstandard" ciphers, especially things like Blowfish and SEAL, which have key scheduling algorithms that need a lot of memory and time. It's really only practical to build keysearch machines for very commonly used ciphers, and even then, it may be complicated. (For example, imagine a DES variant whose key schedule required several exponentiations modulo some 1024-bit prime.) >- -- Lucky Green <mailto:shamrock@netcom.com> > PGP encrypted mail preferred. --John Kelsey, jmkelsey(a)delphi.com PGP 2.6 fingerprint = 4FE2 F421 100F BB0A 03D1 FE06 A435 7E36 -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMDgfl0Hx57Ag8goBAQFa0gP/azECjB06onhSYTvLjkM2I7y2tOpC2BaB RACVMQn+Z5kVGaDM47eIM1TlRnIMlnEucuLryvqR3fMDCt6g90oDXe3rziWJedbH PxXYqgkPu1MmRfep+JWrtQ4wWsXxbPa10spTDFa8vKlGDcoohWU0W5ypgr454tlh KKPaC345vqQ= =td/F -----END PGP SIGNATURE-----

1 0

Majority in house support SAFE encryption bill, from SPAlert
by Declan McCullagh 17 Dec '03

17 Dec '03

---------- Forwarded message ---------- Date: Tue, 29 Jul 1997 10:19:36 -0700 (PDT) From: Declan McCullagh <declan(a)well.com> To: fight-censorship-announce(a)vorlon.mit.edu Subject: Majority in house support SAFE encryption bill, from SPAlert [From an alert put out by the Software Publishers Association. (I skipped the press conference.) --Declan] ---------- Forwarded message ---------- Encryption --------------- MAJORITY IN HOUSE SUPPORT PASSAGE OF ENCRYPTION BILL Rep. Bob Goodlate (R-Va.) and Rep. Zoe Lofgren (D-Calif.) will hold a press conference in room HC7 in the U.S. Capitol today to announce that a majority in the House of Representatives have signed on as co-sponsors of H.R. 695, the Security and Freedom through Encryption (SAFE) Act. SPA today called on the Clinton administration to immediately cease its opposition to the SAFE Act, which allows the free export of encryption products while providing American businesses with the tools needed to protect corporate data. "Forty years ago, John F. Kennedy wrote 'Profiles In Courage' on political leaders with the moral and political courage to resist the easy path and, instead, make difficult choices in the national interest. Today, members of the House passed this test of courage with flying colors," said Ken Wasch, SPA president. "On the other side of Capitol Hill, however, the ghost of J. Edgar Hoover lurks in the cloakrooms of the Senate. Rather than taking a courageous stand for America, some Senators would rather follow the administration's play book, trading personal freedoms for what they themselves admit is only marginal improvement." "House members have clearly studied the issue and recognize that burdening high-tech industries with oppressive regulation and restrictive export controls will only harm America and law enforcement in the long run. Law enforcement concerns cannot be addressed by mandating technology but by adopting policies ensuring technical progress and innovation occurs in the United States." The SAFE Act now proceeds to the Commerce, Intelligence, and National Security Committees, all of which have until September to vote on the legislation. For full text of the release, visit http://www.spa.org/gvmnt/releases/hmajority.htm. For access to Rep. Goodlatte's Web page regarding the SAFE Act, visit http://www.house.gov/goodlatte/encryption.htm. For full text of SPA's statement following the SAFE Act's passage by the House Committee on International Relations, visit http://www.spa.org/gvmnt/releases/encryptpr.htm. For further information, contact Lauren Hall at (202) 452-1600, ext. 313, or lhall(a)spa.org.

1 0