- cypherpunks-legacy - lists.cpunks.org

computer underground digest stuff
by an158409＠anon.penet.fi 17 Dec '03

17 Dec '03

Date: Fri, 20 Jan 1995 00:13:29 -0600 (CST) From: David Smith <bladex(a)BGA.COM> Subject: File 1--ACM Computers Seized by IIT (fwd) ---------- Forwarded message ---------- ACM Computers Seized By Illinois Institute of Technology "And let it be known throughout the world what was done this day..." Dateline January 17, 1995 Today sometime before noon today, the Illinois Institute of Technology seized the computer systems of the Association for Computing Machinery student chapter at IIT. 700 Student and Faculty users are not happy. And are now without their Email and other private files. The locations of the ACM systems is currently unknown, and the security of the system and the accounts on it is highly questionable, as it was quite literally riped out of the wall. ( a piece of the modem was found lying on the table ). The reasons given by IIT where that members of ACM are suspected of hacking into the computer of another IIT student group, and pulling several pranks. The memo sent to the Dean of Students details the hacking attempt, but no evidence points to ACM's systems or to any of their users, but the memo does make several unbacked accusations. And at this time, we can see no reason ACM would even be tied to the events. However because ACM members are suspect, the systems where unlawfully seized by IIT. IIT has no legal right to seize ACM's systems, nor anyone else, as they contain private accounts, files, and Email. Such rights are protected under the Electronic Communications Privacy Act (ECPA), which extended most of the protections of the federal Wiretap Act ("Title III") to electronic mail. Precidence established in the case Secret Service vs. Steve Jackson Games decided March 12, 1993 Needless to say, ACM members are not too happy about all of this. And the other 700 people don't seem happy either. --------------------------------------------- Dateline January 18, 1995 o Members realize that along with Troll, which is physicaly considered IIT's property even tho it was purchased with student funds, property of ACM members was also seized includind a network card, SIMM modules, and the modem that was broken by IIT during the seizure. o ACM recieves writen copy of allegations and supposed proof that ACM systems where used in the attempt. However the evidence clearly shows that other IIT owned systems where used and NOT ACM's systems. o Electronic Frontier Foundation is called and informed of the situation, and begins investigating the situation. o ACM HEARS THAT THE COMPUTER SYSTEM IS IN THE PROCESS OF BEING SEARCHED BY IIT STAFF, AND ACM MEMBERS NOW CONSIDER THE SYSTEM COMPROMISED. STILL NO EVIDENCE SHOWING ACM INVOLVEMENT. o Word continues to spread amung the IIT community, many more students and faculty are outraged about the seizure of their accounts and files. o Continued stress to students due to the lack of access to their Email, addressbooks, and other files. Email is now being lost in mass due to the o ACM systems removal, much of which is considered critical by many people. ACM members miss the Chicago ACM meeting due to the fact that all the info concerning time/location was stored on the seized systems. o ACM members miss the Chicago ACM meeting due to the fact that all the info concerning time/location was stored on the seized systems. ------------------------------------------------------------------------- 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: Lucky primes & omlets on my face...
by Hal 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- From: Nathan Zook <nzook(a)bga.com> > Recall: x^p = x mod p therefore, x^(p-1) = 1 mod p. So what we need is: > (x^e)^d = x^ed = x^(p-1)*i+1 = x mod p. This would only be true for prime p, but with RSA we are dealing with composite moduli. What we want is ed=1 mod phi(n), where phi(n)=(p-1)(q-1). (Actually you want to use (p-1)(q-1)/gcd((p-1),(q-1)). I forget what that is called.) Conceptually, I gather you are setting e = 0x10001, then finding its multiplicative inverse d mod phi(n) (or mod p-1 in your example). Then you are looking for other possible values for d. I am a little unclear on what the interval would be between suitable values of d. I think it would be phi(n)/gcd as above, or p-1 in your example, but I am not sure. > Let's try this again. > > Let 2*x be the target number of bits in the modulous. > > Let n be a large random number with x+2 digits. > Let n1 be the next multiple of 0x10001. > Let t2 be n1 mod 8, t3 be n1 mod 9, t5 be n1 mod 25, t7 be n1 mod 49. > > Loop: > For i = 2 to 7 > If n1 = 1 mod i and (n1-1)/i + 1 is not a multiple of {2,3,5,7} > If (n1-1)/i + 1 is prime. > { > Let k = 0's in n1/0x10001. > If k is in range, save and exit. > } > EndIf > EndIf > Next > n1 += 0x10001; > EndLoop > > Recall: x^p = x mod p therefore, x^(p-1) = 1 mod p. So what we need is: > (x^e)^d = x^ed = x^(p-1)*i+1 = x mod p. > > ie: ed = (p-1)*i+1 > or: (ed - 1) / i + 1 = p > > Now 0x10001 inverts easily, it is just n1/0x10001. By keeping track of > various quantities, we can eliminate all multiprecision divisions except > for the original one needed to get n1 and the t's, and doing increments > instead. I still don't follow this. Is k claimed to be d? Where do we verify that ed=1 mod (p-1)? ed would be n1, right? When you said "If (n1-1)/i + 1 is prime" did you mean "is p"? I really don't think this whole thing works. Let me tell you what I tried. I inverted e to get a correct d. Then I looked at different d's to find one with lots of 0's. This turned out to be useless! The reasons is that PGP does not use d. It uses the Chinese Remainder Theorem to do its exponentiation. The two exponentiations it does use exponents d mod (p-1) and d mod (q-1). Adding multiples of phi to d does not change these values (since it is a multiple of both p-1 and q-1). Now one thing you could do is to use in place of d mod (p-1), (d mod (p-1)) + k*(p-1) where we choose k to minimize the sum of the number of bits and the number of 1 bits in this expression. Unfortunately the PGP data structures do not store d mod (p-1), it is constructed on the fly when you do a decryption. So there is no where to save a pre-computed optimal value for the two exponents used in the CRT exponentiations. So, this was a good idea, but the implementation does not fit into the current structure very well. Hal -----BEGIN PGP SIGNATURE----- Version: 2.6 iQBVAwUBLzA/mhnMLJtOy9MBAQEjmAIAzQbwkia3F7+4F7tNUewKnZVYsBEhgoBk h5jem/qjUxFeGhYNUL/pSLKJPR+PlzleZmBQJyOlk3q7KL0ety851g== =EHVe -----END PGP SIGNATURE-----

2 1

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

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

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

Returned mail: unknown mailer error 126
by Mail Delivery Subsystem 17 Dec '03

17 Dec '03

The original message was received at Tue, 22 Aug 1995 12:45:26 -0400 from localhost [127.0.0.1] ----- The following addresses had delivery problems ----- "|/home/gheap/\+\ \+\ \# -vo /home/gheap/.elm/gheapfilter.log" (unrecoverable error) (expanded from: gheap) ----- Transcript of session follows ----- sh: /home/gheap/+: No such file or directory 554 "|/home/gheap/\+\ \+\ \# -vo /home/gheap/.elm/gheapfilter.log"... unknown mailer error 126 ----- Original message follows ----- To: cypherpunks(a)toad.com From: cypherpunks(a)toad.com Date: Tue, 22 Aug 1995 12:45:26 -0400 blah

1 0

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

17 Dec '03

At 9:41 PM 8/21/95, Adam Shostack wrote: > Strong cryptography is needed for a secure information >infrastructure. If American companies aren't allowed to build secure >infrastrucure, then parts of the infrastrucure will move overseas, as >insurance, liability, and deployment costs rise for a badly secured >network. > > This issue will not cause the USA to become a third world >nation, but it will contribute to large institutions moving their data >processing out. Tim, you've talked a lot about how companies will >move data centers out of the US to avoid 'expensive' laws; do you see >the ITARs as being in a different catagory, than say, the laws on >reporting a bankruptcy? Sure, they will move some parts of their operations to other jurisdictions. They already are, for various reasons. Most large U.S. companies are of course "multinationals." I didn't cite examples, and won't now. (But you can imagine a few of the many successful U.S. companies: Sun, Intel, Microsoft, SGI, Qualcomm, Altera, Merck, and on and on.) I am not saying that things are as they should be. And I am not a U.S. chauvinist. I really don't care which countries do well, so long as my investments continue to do well. My point was that hyperbole about the U.S. being on the verge of becoming a Third World nation is wrong. As Sternlight might put it, "arrant nonsense." --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."

1 0

No Subject
by Bryce Wilcox 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Here is an article that I just posted to alt.security.pgp and sci.crypt. Having had a couple of hours to calm down, it seems a little frenetic, but there is enough truth in it that I will now repost it to cypherpunks. Context: Someone was asking how he could go about verifying the identity of an anonymous interlocutor, so that he could sign his public key. - -----BEGIN PGP SIGNED MESSAGE----- Look, I don't have a lot of time here, but I need to say that this whole "certifying anonymous keys" idea is misled. The fact is, *I* *don't* *care* what your True Name is. I can only think of two reasons why you would need a person's True Name, and I doubt that anybody here can apply either of these reasons to anyone else here. Reason Number Uno, why you might want a person's True Name: Because you want to physically hurt them, or effectively threaten to hurt them. (Or send someone else to do it, like a hit man, policeman, etc.) Reason Number Dos, why you might want a person's True Name: Because you want to have sex with them. (Or as above, if you prefer to do it through proxies...) Okay now does anyone want to do any of the above two things to me? If not then *don't* *worry* about whether my public key is signed by anyone or not. It makes zero difference to you until such a time as one of the above motivations acquires. Zimmermann et al. were/are naive to emphasize the Web of Trust as a means of introducing strangers. With very few exceptions, strangers don't *need* to verify each other's physical identities! This fact is central to some of the more interesting social evolutions that information technology promises to cause. In retrospect, the emphasis in "pgpdoc1.txt" on verifying True Names via mutually trusted introducers will seem quaint. Bryce Announcement: I have had technical difficulties. If you sent me e-mail between Aug 5 and Aug 20 and didn't receive a response, please re-send. signatures follow: + public key on keyservers /. island Life in a chaos sea or via finger 0x617c6db9 / bryce.wilcox(a)colorado.edu ---* - -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Auto-signed with Bryce's Auto-PGP v1.0beta iQCVAwUBMDkLf/WZSllhfG25AQFhxwP6AzS0nus2QK8UEF5rvyqhFrwpzeAEE/Vr BwRXJtstk5ln2f3SRh7BSYfda/TQDJe2VRt0qMF1xNCt1VLP+QCyr06LqZ0i/qv0 /CpC85/QRAgpQtrgyFKR6v3Ryi3MbeiUQuEOSgU+OelvZ5XcoRP3o5WDp18N4+Pv 5ddGzIVXQEk= =5rxb - -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Auto-signed with Bryce's Auto-PGP v1.0beta iQCVAwUBMDk3AfWZSllhfG25AQGQCgQAld0FFtRVZgDKZ1ofok4pK9zAAqlJHCiO A+eLsSolfIvvfpTiE0viJUOuXIywnWzBT50js4LodwsQI4cKSVfnHdYNI4aoyQJf G2P7dy7BaryOj8C74U2gYYq8Lys6Mh/i640KEa77EV4ZEDpLhSi25R+LB58qjvwJ l705Z8I/Bhs= =+xrs -----END PGP SIGNATURE-----

1 0

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

17 Dec '03

At 3:46 AM 8/22/95, Jon Lasser wrote: >On Mon, 21 Aug 1995, Peter Trei wrote: > >> > The US is slipping into the second world as we >> > speak, with no signs of a turnaround ahead. Only the sheer size of >> > the economy keeps people from believing it. >> >> Just a nomenclature peeve - I'm not sure of the precise time and >> place the (first|second|third) world meme originated, but it seems to >> predate 1970, and until very recently it's meaning was clear: >> >> First world: Western (and Westernized) nations - mainly the US, Canada, >>Western Europe, >> Japan, Australia, & New Zealand >> >> Second world: Communist bloc (I can still remember the Cultural >> Revolution. Prior to that, the Communists seemed a monolithic force, >> marching in lockstep.) >> >> Third world: The rest, mostly poor nations. > >Erm, nope. The "First World" (or old world) was Europe and Asia; the "New >World" (not frequently referrred to as the second world, but hey...) The >third world was the developing nations. THAT (as far as I was taught in >history class, so it MIGHT be a lie...) was how the terms originated... Then you should sue your history teacher for giving you a defective education :-}. Perhaps she or he was of my generation and was at Woodstock when she should've been doing her homework. By convention, the First World is the set of "Western" nations, the democratic, capitalist nations. The Second World, though not often used as a term, is the set of Communist bloc nations. The Third World, by far the most commonly used term here, is the set of nations not formally affiliated with either the First or Second Worlds. These nations are often poor, though not necessarily poor, and so the "Third World" is often (incorrectly) associated with poverty. And, to confuse things further, the "lesser-developed countries," or LDCs, are often equated to the Third World. When a certain character in a television show referred to "Third World mutants," he was also referring to "your basic brown types." (His words, not mine. Ten credits to anyone who can identify the t.v. show and the character.) The term "Fourth World" has in the last 20 years come to refer to the countries which are so impoverished as to be almost hopeless. Bangla Desh is the canonical Fourth World nation. --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."

1 0

Re: DES & RC4-48 Challenges
by tcmay＠got.net 17 Dec '03

17 Dec '03

At 5:29 AM 8/22/95, hallam(a)w3.org wrote: >I think we can probably do DES within two years. > > Phill I strongly doubt it, and may be willing to bet money against it happening. (If "we" means someone or some group on this mailing list. If "we" means the Net, I still doubt it will happen.) If the "idea futures" and betting markets we've talked about here (which exist) ever take off, this may be a way to make some money for someone. For example, if someone was laying 10:1 odds that SSL would not be cracked in 1995.... And for the "do DES" bet, you need to differentiate (no pun intended) between a chosen plaintext attack and a more general attack. The differential cryptanalysis ("DC" gets another overload) method needs chose plaintext to cut the search space down to 2^47 keys. Wiener's hypothesized "million dollar DES cracker" may do the general attack, but I doubt anyone on our mailing list will do it. That is, the number of workstations and even supercomputers which would have to be lashed-together would be, ballpark, about 2^16 times greater than what was lashed-together for the SSL challenge. Maybe a factor of ten could be cut out with increased cleverness. Maybe. Call it a factor of "only" 6000 times harder than the SSL challenge. Hard to imagine this happening in the next two years. Maybe if much of the Net community was energized to run DES crackers instead of Flying Toasters, but a hard effort to organize...for fleeting reward. --Tim May ---------:---------:---------:---------:---------:---------:---------:---- Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay(a)got.net 408-728-0152 | anonymous networks, digital pseudonyms, zero Corralitos, CA | knowledge, reputations, information markets, Higher Power: 2^756839 | black markets, collapse of governments. "National borders are just speed bumps on the information superhighway."

1 0