- cypherpunks-legacy - lists.cpunks.org

Re: FCPUNX:McVeigh
by jamesd＠echeque.com 17 Dec '03

17 Dec '03

At 12:42 PM 6/4/97 -0400, Hallam-Baker wrote: > Bell's Murder Politics scheme was a censorship scheme. Surely people would be more inclined to kill politicians for what they do, rather than what they say. --------------------------------------------------------------------- | We have the right to defend ourselves | http://www.jim.com/jamesd/ and our property, because of the kind | of animals that we are. True law | James A. Donald derives from this right, not from the | arbitrary power of the state. | jamesd(a)echeque.com

12 15

Call for Papers: Jurimetrics Special Edition on PKI
by Robert Hettinga 17 Dec '03

17 Dec '03

--- begin forwarded text X-Authentication-Warning: blacklodge.c2.net: majordom set sender to owner-spki(a)c2.org using -f X-Sender: baum(a)world.std.com Date: Sun, 08 Jun 1997 09:46:14 -0400 To: spki(a)c2.net From: "Michael S. Baum" <michael(a)verisign.com> Subject: Call for Papers: Jurimetrics Special Edition on PKI Mime-Version: 1.0 Sender: owner-spki(a)c2.net Precedence: bulk *** Announcement *** JURIMETRICS Winter 1998 Special Issue on Public Key Infrastructure (Security in Electronic Commerce: Technology, Infrastructure and Practices for Certification Authorities and Digital Signatures) I. Contents of this Solicitation · General Information · Call for Papers · Criteria for Papers · Submission Information · Important Dates · Virtual Conference · Organization · Inquiries II. General Information We are pleased to announce the planned publication of a special issue of the Jurimetrics Journal of Law, Science and Technology that will exclusively address public key infrastructure (PKI) -- the law and technology of certificate-based digital signatures and secure electronic commerce. This announcement solicits articles for consideration for this special Winter 1998 issue, which is intended as a forum for attorneys, technologists, developers, and users interested in the legal aspects and implications of PKI. Jurimetrics Journal of Law, Science and Technology, published quarterly, is the journal of the American Bar Association Section of Science and Technology and the Center for the Study of Law, Science and Technology of the Arizona State University College of Law. The Information Security Committee, Electronic Commerce Division, Section of Science and Technology of the American Bar Association (ISC) explores and develops legal policy and foundation to support PKI and secure electronic commerce. The ICSs current endeavors include research and work product concerning: accreditation of certification authorities, commercial key escrow guidelines, PKI evidentiary issues, digital signature legislative initiatives, CA and user liability, and other legal issues relating to secure electronic commerce. The discussions are moderated by the relevant Work Groups of the ISC, and the ISC is open to professionals of all disciplines with similar interests. In August l996, the ISC published the Digital Signature Guidelines. See Tutorial, Table of Contents, and List of Contributors of the Digital Signature Guidelines at http://www.abanet.org/scitech/ec/isc/dsg-tutorial.html. III. Call for Papers Papers are invited on all subjects related to applications of PKI and their corresponding legal issues. The special edition is structured as follows: · Preface · Introduction · Tutorial, Architecture and Technology · International Issues · Liability, Contractual, Intellectual Property, and other Substantive Legal Issues · Government Legislative, Regulatory, Policy, Enforcement · Accreditation of Certification Authorities (including licensure and other quality issues) · Miscellaneous Papers submitted should be concise and focused on the kernel rather than exhaustive detail of new ideas intended to be communicated. Papers should not restate basic PKI technology but instead refer to the common tutorial located in the introductory materials. We thank you in advance for your submissions to this special issue of Jurimetrics on PKI. IV. Criteria for Papers Preference will be given to papers that comply with the following criteria: · are no longer than 8,000 words (under 10 pages, 12 point type, single spaced) · provide appropriate annotation · include URLs in annotations, where available · consider both legal and technical issues/implications · involve joint authorship between a lawyer and technologist · are original works not previously published elsewhere · conformance to the instructions for prospective Jurimetrics authors posted at http://www.asu.edu/law/jurimetrics/author.htm V. Submission Information Send brief but informative abstract of one or two pages as an email attachment to jurimetrics(a)cnidr.org. If possible, please use Word 6.0 (Office 95) to facilitate handling. A one paragraph bio is also requested but not required. VI. Important Dates · Abstracts must be submitted by: 25 June 1997 · Deadline for submission of drafts: 15 October 1997 · Final version ready, after all cite checks and editorial changes: 31 December 1997 · Publication of Jurimetrics special issue on PKI: February 1998 VII. Virtual Conference All papers accepted to Jurimetrics Winter 1998 special issue on PKI will appear in full or abstract form in a Virtual Conference Center hosted by the ISC. The PKI community will have the opportunity to participate in discussions with the authors using e-mail and the World Wide Web. The Virtual Conference Center will feature a variety of electronic for a moderated by leading PKI experts for the facilitation of communication within the virtual PKI/law & technology community. VIII. Organization for the Jurimetrics Special Issue on PKI Guest Editor-in-Chief: Michael S. Baum, Esq., VP, Practices and External Affairs, VeriSign, Inc. Associate Guest Editors: Joseph H. Alhadeff, Esq., Director, Electronic Commerce, U.S. Council for Intl Business (USCIB) Warwick Ford, Ph.D., Director, Advanced Technology, Verisign, Inc. Theodore Ling, Esq., Baker & McKenzie, Toronto, Ontario. Charles R. Merrill, Esq., McCarter & English, Newark, NJ. Arthur F. Purcell, J.D., International Project Specialist, US Patent & Trademark Office Ruven Schwartz, Esq., Info. Security, West Group Business Manager XI. Inquiries If you need help or have questions which are not answered in the above information, please e-mail: jurimetrics(a)cnidr.org *** --- end forwarded text ----------------- Robert Hettinga (rah(a)shipwright.com) Philodox e$, 44 Farquhar Street, Boston, MA 02131 USA "... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire' The e$ Home Page: http://www.shipwright.com/

1 0

Dems Critique Crypto Policy
by John Young 17 Dec '03

17 Dec '03

These views from Democratic legislators on the SAFE crypto bill is excerpted from House Report 105-108, dated May 22, 1997, which reports on the recent hearing testimony, DoJ's critique, and Goodlatte's responses to administration criticism. It cites the Blaze et al report on the risks of key recovery, Sun's alliance with Elvis, current litigation and non-US commercial exploitation of the crypto stalemate. http://jya.com/hr105-108.htm (94K) ----- ADDITIONAL MINORITY VIEWS John Conyers, Jr. Rick Boucher. Zoe Lofgren. Maxine Waters. William Delahunt. Martin T. Meehan. We offer these additional views not to foment dissent but to encourage dialogue with the Administration on the issues related to encryption. We would like to work with federal law enforcement and national security agencies to address their concerns. We sympathize with the difficulties faced by investigative and security agencies in combating crime, terrorism, and espionage. We believe it is quite legitimate for the Administration to be concerned about the uncertain impact that strong and ubiquitous encryption products may have on law enforcement and national security agencies. We realize that it may ultimately become impossible for government agencies to decipher intercepted or retrieved data and communications that have, by encryption, been transformed into a seemingly unintelligible form. We recognize the days of cracking strong codes are nearly gone. Unbreakable codes (256-bit key algorithms can generate more possible solutions than there are particles in the known universe) are already widely known. Private security experts and sophisticated hackers have already realized this and are beginning to develop ways of attacking the vulnerable points before and after the information is encrypted (i.e., on the sender's hard drive or at a ``good-guy'' recipient such as a bank). We suspect that law enforcement and national security experts within the government are acquiring similar capabilities. But these alternative (and more subtle) approaches are not reflected in the Administration's current public policy toward encryption. The Administration's current encryption policy, a policy that runs back at least to the Bush Administration, creates more problems than it resolves. The policy is a combination of encryption export controls and a key escrow system by which the key to the code encrypting the information is to be held by a third party (so it may be made available to the government). We need to be honest about this situation. We don't expect most narcotics traffickers, terrorists, or criminals to respect export restrictions on encryption when they don't respect our underlying drugs or weapons laws. And we don't generally expect anyone who employs encryption in furtherance of a crime to readily give their keys to some third party so they may be made available to the government. The Administration maintains that there is a commercial need for key recovery. While that may be true to some extent, there appears to be little or no demand for the all- encompassing system they want to mandate. Experts have uniformly concluded the government's proposed system is either excessively costly and complex or insecure. In part, this is true because the government seeks access to real-time communications and data transmissions, rather than the ability to recover stored data. The Administration insists it doesn't want domestic restrictions on encryption. We are concerned, however, that the Administration policy does have this effect. Development of software programs, including those utilizing encryption, occurs at an amazingly rapid pace, so it is not feasible for computer software and hardware companies to develop separate products for export and for domestic use. As a result, as a practical matter, only products that are exportable, with weaker encryption or with government-approved key recovery-escrow, can be marketed at present. We fear that current encryption policy, encouraging as it does weaker encryption, makes every American more vulnerable to illicit or surreptitious access to our computer files, our phone conversations, and personal information, and thus exposes our citizens to hackers, terrorists, and thieves. It is ironic that what is trumpeted as an aid to law enforcement may instead compromise individual and corporate security. What we have here is not only a combination of export controls and a key recovery system that does not work, we have a system that compromises the competitiveness and security of this nation's software and hardware industry, as well as our privacy rights. As conceded by Administration witnesses, the proposed key recovery system can succeed only as long as there is no non-conforming encryption software readily available in the market. But there is already an abundance of such software, some of it freeware, that is readily available over the Internet. The proposed key recovery system can not work unless the United States persuades every other nation to adopt key recovery. We can safely say we are unlikely to obtain the agreement of Libya, Iran, Iraq, or North Korea. In addition, the efforts to date of David Aaron, U.S. Ambassador to the Organization for Economic Cooperation and Development (OECD), to obtain a consensus in support of key recovery resulted instead in a consensus opposing it. The Administration's policy has therefore been a strong market incentive: (a) for non-participants (in the Administration's key escrow program) to make non-standard, secure encryption available, and (b) for U.S. companies to set up abroad in "encryption havens'' so they may legally market strong, secure encryption products to customers who decline to make their "international key'' available to diverse governments around the world. There are already U.S. companies establishing ties with foreign companies in Japan, Russia, and elsewhere. Nor is this policy without its cost. It is estimated that, if the U.S. persists in its current policy through the year 2000, we shall lose 200,000 jobs and $60 billion each year. This is what it will cost this nation to lose the cryptography lead we enjoy and the competitive expertise necessary to maintain our market position. Unfortunately, our discussions to date with law enforcement and intelligence agencies have not admitted of the possibility of any further relaxation of export restrictions as part of the broader process essential to resolving this complex question. Nor has the Administration offered to consider alternatives to its key escrow or key recovery system. H.R. 695 need not be the end of the process but the beginning of a real dialogue. This is what we would like to happen. We continue to remain hopeful that the Administration will acknowledge the shortcomings of its current policy and sincerely hope that this will happen soon lest more serious damage be done to our industry, to our security and to our privacy. [End exceprt]

1 0

PGP key fingerprint spoofing
by Adam Back 17 Dec '03

17 Dec '03

Well we're all aware of the 0xDEADBEEF attack, right? (PGP keyids, are the 8 hex digit number which PGP recognizes a key by. The 0xDEADBEEF attack (so christened by Greg Rose one of the people who independently rediscovered this attack) is where you generate a PGP key which has the same key id as someone else's key. This could confuse a keyserver, or a user into using the wrong key. This attack is fairly easy to do, just choose p ending in 0xDEADBEEF (or whatever the desired key id is), then start with q ending in 0x00000001, and add some value larger than 0xFFFFFFFF at each iteration doing your primality test, the p and q will then multiply to have the desired least significant bits of n). You may also have noticed that Gary Howland has a keyid of 0xc001d00d ("cool dude", get it). Anyway it seems that you can spoof the finger print also indirectly, which is much less obvious, as the fingerprint is the MD5 hash of the RSA modulus concatenated with the RSA public exponent. This was described recently on coderpunks. (I was forced to eat my words on coderpunks after declaring this was impossible without an exploitable flaw in MD5 or brute force of 2**128 bit search space, when someone explained the concatenation weakness). I'm not sure who it was that discovered this attack, or which list/newsgroup this was announced on, but this was the first I had seen it discussed. The concatenation is the weakness, as if you have an RSA key of: n = 0x1234567 e = 0x11 Then you can try n = 0x12345, and e = 0x6711. So you try factoring each n of this form, and if it has two factors p and q, then you can construct a key with the same fingerprint, but with different key. Anyone who bothers to would be able to factor 0x1234567 also, so it is not secure, but if you can fool someone into using this key in place of the real one, you can get their communications. It will be much easier to fool someone to use this key as the fingerprint is the same! Here's an example... Say we have a 1024 bit key, say e is small ( < 256). That means n || e is 129 bytes long. The e value must be represented by a whole byte. n can't be smaller than 384 bits (or PGP will reject it as too small to hold the required idea message key and padding), so that will give us 80 possible values for e and n. Lets use my 1024 bit key for an example. n = 0x99d61071378ee2c0c8c9c4b7786b203dedf2d6e526f24f7e83f3e0f960fb66b9 cb81c04e89d70689a4866f21ad1bb5ba6aee51469e5b59b121ba6f3f8d776b62 7253ba5dc9fca8155a565b9893f695d83a0496eb977ee4659ee20e0f2eb49b25 93c11487b377cc5d767c79fb985b464d4ae94a5f45e42e3b29c8b89d556a4a67 e = 0x13 So we could try: e = 0x6713 e = 0x4a6713 e = 0x6a4a6713 ... n = 0x99d61071378ee2c0c8c9c4b7786b203dedf2d6e526f24f7e83f3e0f960fb66b9 cb81c04e89d70689a4866f21ad1bb5ba e = 0x6aee51469e5b59b121ba6f3f8d776b627253ba5dc9fca8155a565b9893f695d8 3a0496eb977ee4659ee20e0f2eb49b2593c11487b377cc5d767c79fb985b464d 4ae94a5f45e42e3b29c8b89d556a4a6713 Here's the first candidate I found with only two factors starting from the smallest n value (384 bit n) so that it would be quicker to factorize (anything that took a long time to factor I moved on to next value). n = 0x99D61071378EE2C0C8C9C4B7786B203DEDF2D6E526F24F7E83F3E0F960FB66B9 CB81C04E89D70689A4866F21AD1BB5BA6AEE51469E5B59B121BA6F3F8D776B62 7253BA5DC9FCA8155A565B9893F695D83A0496EB977EE465 e = 0x9EE20E0F2EB49B2593C11487B377CC5D767C79FB985B464D4AE94A5F45E42E3B 29C8B89D556A4A6713 p = 0x6D q = 0x1694DA7CA7DC9B69CD9ECAAC8BCDF6A41988A31132573CFD6EF72CC44FFF5330 69074D8CB3F0974586892A25D2F3A08C19173D406266A82CCA3C3F4D705CAF78 23922972C20D99D8DBF07E2DE20CB5B3B3F747797B3A8D9 n = 0x99D61071378EE2C0C8C9C4B7786B203DEDF2D6E526F24F7E83F3E0F960FB66B9 CB81C04E89D70689A4866F21AD1BB5BA6AEE51469E5B59B121BA6F3F8D776B62 7253BA5DC9FCA8155A565B9893F695D83A0496EB977EE465 d = 0x0455419C3B8CCE54710EC04F9FA61F83A5E2363BE0D2E361886080716E7B8886 EA62B748F20B9E9E7F93F768616D3AF5F8785D514A82EE41CB1FF251FFB053FA 173D0B239D7BD1995B4F7DE3B2B112F911BE1304453EAC53 u = 0x0162AC862E1D88F2ACC3230A4AED13AEC3EA4A978387684ADA099644FF9FAA3D D51F6BA831347C5D12AD1CDC72F5FE40F66228E54573373C4A0F255A091879BC F2EA9509D46B673CB7C4EB8EDA0D6754DC373EA911653504 (Factorization courtesy of pollard rho / trial division code in the factorization code which comes in ssh-1.2.20, which includes a modified gmp-2.0.2 which has the code in the demos directory.) I checked RSA operation (with my .sig rsa program which works with hex numbers rather than formatted pgp keys) -- it works!! % echo hello world | rsa -k=9EE20E0F2EB49B2593C11487B377CC5D767C79FB985B464D4AE94A5F45E42E3B29C8B89D556A4A6713 -n=99D61071378EE2C0C8C9C4B7786B203DEDF2D6E526F24F7E83F3E0F960FB66B9CB81C04E89D70689A4866F21AD1BB5BA6AEE51469E5B59B121BA6F3F8D776B627253BA5DC9FCA8155A565B9893F695D83A0496EB977EE465 > out % % rsa -k=0455419C3B8CCE54710EC04F9FA61F83A5E2363BE0D2E361886080716E7B8886EA62B748F20B9E9E7F93F768616D3AF5F8785D514A82EE41CB1FF251FFB053FA173D0B239D7BD1995B4F7DE3B2B112F911BE1304453EAC53 -n=99D61071378EE2C0C8C9C4B7786B203DEDF2D6E526F24F7E83F3E0F960FB66B9CB81C04E89D70689A4866F21AD1BB5BA6AEE51469E5B59B121BA6F3F8D776B627253BA5DC9FCA8155A565B9893F695D83A0496EB977EE465 < out hello world % I'm off to pack this up as a PGP key, to see if PGP likes it! Well here's that key as a pgp key. Under no circumstances use it to encrypt a message you care about. Here's the public key. Type Bits/KeyID Date User ID pub 704/977EE465 1997/06/08 Adam Back <spoofed fingerprint DO NOT USE> -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.3i mQCNAzObE60AAAECwJnWEHE3juLAyMnEt3hrID3t8tblJvJPfoPz4Plg+2a5y4HA TonXBomkhm8hrRu1umruUUaeW1mxIbpvP413a2JyU7pdyfyoFVpWW5iT9pXYOgSW 65d+5GUBSJ7iDg8utJslk8EUh7N3zF12fHn7mFtGTUrpSl9F5C47Kci4nVVqSmcT tCpBZGFtIEJhY2sgPHNwb29mZWQgZmluZ2VycHJpbnQgRE8gTk9UIFVTRT6JAG0D BRAzmxOtOgSW65d+5GUBAQ27ArwOTveQTs0kjzBEMa09yWFs5+jNjv5tzSCngzXO bRzvwhTwWz4voR3ov2o0bGTYZF1biKRKeKqZzHb4Oq4XhD4TADdlmsxA5gQgbYFN 5K+tbgWEDQD53KFv =rlth -----END PGP PUBLIC KEY BLOCK----- Here's the secret half: -----BEGIN PGP SECRET KEY BLOCK----- Version: 2.6.3i lQGhAzObE60AAAECwJnWEHE3juLAyMnEt3hrID3t8tblJvJPfoPz4Plg+2a5y4HA TonXBomkhm8hrRu1umruUUaeW1mxIbpvP413a2JyU7pdyfyoFVpWW5iT9pXYOgSW 65d+5GUBSJ7iDg8utJslk8EUh7N3zF12fHn7mFtGTUrpSl9F5C47Kci4nVVqSmcT AAK7BFVBnDuMzlRxDsBPn6Yfg6XiNjvg0uNhiGCAcW57iIbqYrdI8guenn+T92hh bTr1+HhdUUqC7kHLH/JR/7BT+hc9CyOde9GZW09947KxEvkRvhMERT6sUwAHbQK5 AWlNp8p9ybac2eyqyLzfakGYijETJXPP1u9yzET/9TMGkHTYyz8JdFhokqJdLzoI wZFz1AYmaoLMo8P01wXK94I5IpcsINmdjb8H4t4gy1s7P3R3l7Oo2QK5AWKshi4d iPKswyMKSu0TrsPqSpeDh2hK2gmWRP+fqj3VH2uoMTR8XRKtHNxy9f5A9mIo5UVz NzxKDyVaCRh5vPLqlQnUa2c8t8TrjtoNZ1TcNz6pEWU1BIRbtCpBZGFtIEJhY2sg PHNwb29mZWQgZmluZ2VycHJpbnQgRE8gTk9UIFVTRT4= =lE9S -----END PGP SECRET KEY BLOCK----- Here are the fingerprints of spoofed key as compared to real key. Type Bits/KeyID Date User ID pub 704/977EE465 1997/06/08 Adam Back <spoofed fingerprint DO NOT USE> Key fingerprint = 18 B8 A0 65 9D 38 14 83 61 5A E6 AC 91 8B 9E 57 pub 1024/556A4A67 1993/06/08 Adam Back <aba(a)dcs.ex.ac.uk> Key fingerprint = 18 B8 A0 65 9D 38 14 83 61 5A E6 AC 91 8B 9E 57 Note the identical fingerprints! (Awesome). Key id of course is different. Also note that you can't decrypt directly with PGP, as I suspected, because the chinese remainder theorem used in decrypt to speed up the works barfs on small p. You can hack around that if you're bothered. It might be possible to find a spoofed fingerprint key with large p and q, so that this was not a problem. Below this post is my real key. This is a major security flaw, and I take my hat off to the guy who discovered it. As others noted (who were aware of this flaw) the solution is to consider the keyid as part of the fingerprint. That reduces by a factor of 2^32 the likelihood of the attack succeeding. I suspect that rules out the attack working for most keys. Also be suspicous of odd sized keys. Now if someones 2048 bit key has a 1024 bit spoof, you're in trouble. I'd be interested in estimates of the likelihood of this being possible for a randomly selected key. You could construct a key where the keyid matched, and the fingerprint matched for two different keys, using a combination of dead beef attack, and brute force to find a key with the keyid appearing two places in the key, and then trying to factor the n value at that point. Shouldn't take long. As far as PGP format goes, adding the length field into the digest would go along way towards fixing it. (Length fields for pgp big int representation is big endian 16 bit word representing length of following big int in bits). There might still be a small chance of doing the fingerprint spoof where the length fields both happened to be right. As you require a specific length field it would seem this attack would be 2^32 times less likely to succeed. This would make most keys safe. I wonder if there exists a key out there which would fall to this attack. (btw for people playing with this stuff, a useful program is pgpacket.pl by Mark Shoulsen, which displays pgp packets as hex numbers, see ftp.ox.ac.uk/pgp somewhere under utils). Adam My real key, so you can compare fingerprints. Type Bits/KeyID Date User ID pub 1024/556A4A67 1993/06/08 Adam Back <aba(a)dcs.ex.ac.uk> -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.3i mQCNAiwUXUEAAAEEAJnWEHE3juLAyMnEt3hrID3t8tblJvJPfoPz4Plg+2a5y4HA TonXBomkhm8hrRu1umruUUaeW1mxIbpvP413a2JyU7pdyfyoFVpWW5iT9pXYOgSW 65d+5GWe4g4PLrSbJZPBFIezd8xddnx5+5hbRk1K6UpfReQuOynIuJ1VakpnAAUT tBxBZGFtIEJhY2sgPGFiYUBkY3MuZXguYWMudWs+iQCVAwUQMiDfwUZRiTErSPb1 AQF/yAP8D1X2eAhXSc0P/X7lCHyBhWCl3pxa6oyGxFBOmUeOGfYna8CpJeMiTmZm akRWDYmJUiXscQUfd9qRv8eAeOtbvM87olSjm56Dlh4gYJFZRxZ6IhHlFJx3mPmp q9PnL+pSC41IIheRBJFzpKGD3LW9+VQwRAx9bXFJYyOFpx7vGJqJAJUCBRAwLhaV fjuD7tLfgD0BAYnfA/0XByiiqDX/cxgWt9syiobJ0TrTKloJcEgzxnKmqHH7rhqn wWGQA2pbWPGW1AwLtkeE+JYyk21YQZZxYWerK3JUi8a/ye4EaaJSs8mcw9YCwdPC Xa0nlalh09/FBEt83l5auNbw+zl9AcrOIGsTQcAr0Vy5nnV9IEfi6WZ3/aQ734kB FQMFEC/gRoaxVzBJFqEkZQEBEXcIAI6z9nUinIomouzB/3v1Fu9+kLOLiva+7Mp1 8UT40FXvHSabXe/cSV1//lnlYHJnfpJCPFSEjGox1pVBp9pLmiJBmubLfUrojIAn FDB081n6kB0B4BKb2rUiNghvT4CzpBZ149g/2NGscRIeQOCYkA2cBxT44v2luuqN 3Ahg9bWu+kjnxUKIK9Da/8D0ur5HiinBDevPiVf3/uoOdZ8F7alxqitBcC5ctIYR tr8fgdQq8is6dbeNxDMraV5vEpEN27AU4xOetymdFUufbU1K6Riw5TVZni9qXAgU ZS3zyFw7wqJ/SWILMWp+99ss921b+GpL+/m6S4j7LTXvFvcfy9aJAJUDBRAv2A0p Kci4nVVqSmcBAcfoA/9Pt3BeJ3TdTtQzb9DNT7LoXiQesYG68lzIl7BZsRvXoi2Q yeCPNc/juTGBnKBHgxZezJCW8TaKdJjNEncv7p+1o+9fwmy9UKWXskh6N+Y0ZlhJ bD0T+8+L+Wxpr6k3dao/GfOnCvw8vpvzDV9lnjtqe2B1mU5eAY76FFtZXvM9xw== =xN9o -----END PGP PUBLIC KEY BLOCK-----

5 4

AES Comments to NIST
by John Young 17 Dec '03

17 Dec '03

NIST has published the 33 comments received on the proposed Advanced Encryption Standard (AES) intended to replace DES. Several are quite extensive. In addition to those exemplars we've seen here by Bill Stewart and Bruce Schneier, there are remarks by several crypto luminaries, such as Ron Rivest and Clifford Adams (author of CAST), by NSA, by Canada's CSE, and by Certicom, 3Com, TIS, MasterCard, the ANSI X9 Standards Committee, the ABA and so on. http://jya.com/aes-comments.txt (103K)

1 0

Re: Fraud and free speech
by lucifer＠dhp.com 17 Dec '03

17 Dec '03

Tim May wrote: > > At 5:51 AM -0700 6/8/97, William H. Geiger III wrote: > >Well I think that there are some that would confuse the issue between 1st > >Amendment free speech and the issues surrounding fraud. Especially those > >in government who write the laws that regulate commercial speech. > > The mistake has been to extend "fraud" laws to non-contract situations, > e.g., ordinary speech (as distinguished from contracts). Any time that you see a thread in which Kent Crispin accuses someone of trying to "muddy the waters" you can pretty much guarantee he is trying to throw a logical curveball of his own. Kent added some tripe to the thread supporting his favorite theme, which is that it is the job of government to "enforce" contractual agreements. Naturally, he also extends the format of these contracts to include government authority to enforce criminal penalties for statements made by the great grandfather of the second cousin of the spouse of one of the person making the contract. Follow any thread after a Crispin post and you will find people arguing over issues he raises which have little basis in reality. > Contracts, with clearly stated conditions and with judgeable or > falsifiable/testable conditionals, are a matter for the courts (private > courts, in fact), but vague promises, advertisements, propaganda, etc. are > not. Dimitri wrote a couple of posts which dealt well with the original concept of two parties agreeing on an arbitrator/judge to settle contractual disputes (e.g. the court of Prince X) and the following usurpment of these free-will agreements by people in power who decree that _they_ are now the only valid arbitrator/judge in contractual matters. We now have a system where if someone breaks agreement with you the government locks them in a cage where there is no possibility of them paying you what they are contractually obligated to. The government doesn't give a fat rat's ass what your desires are for resolution of the dispute. They are always busy protecting the nebulous "other" rather than someone real, with a real interest in the situation. The government mandates that contractual agreements must be settled in a forum where the corporation with an army of lawyers can bury the attorney that Joe Average picked out of the yellow pages. When you enter into a contractual agreement with someone who has a guy named "Big Louie" as arbitrator, however, the government calls it organized crime. Pardon me if I fail to see the distinction. TruthMonger

3 2

Re: [ADMINISTRATIVIUM] Quadratic residues
by nobody＠REPLAY.COM 17 Dec '03

17 Dec '03

`A pen is mightier than a sword', not to mention Timmy C. May's pea-sized penis. He would be better served by a safety razor, possibly applied in a bathtub filled with warm water (something he has surely never been into). o /\O/ O Timmy C. May 0 \\ | 0-# // | / \

2 1

My War
by se7en 17 Dec '03

17 Dec '03

Way back when in 1995 when I stopped lurking on this list and became a regular poster, one of the things I quickly became known for was my on-line harrassment of those who had stepped over the line in one manner or another in a way that would ultimately hurt us as a group overall. Many old-timers here will remember my harrassment of Curtis Sliwa and Colin Hatcher of the Cyberangels (a.k.a. Guardian Angels). These were the fools who organized a worldwide volunteer police-wannabe force that searched out indecency (in the generic and ill-defined sense of the term) on the net, which when one dug further into their agenda, found it was just a ploy for funding and political power. My incessant harrassment led to the revelation of many things, most importantly that their leader had never ever been on the WWW, stating that he didn't have time to do so. This despite the fact he had time to organize a police force to patrol it. There have been many others since then, most not as evil as the Cyberangels. They each had their own reasons for harrassment. Among some of them have been Carolyn Meinel, O.J. Simpson, Captain Crunch, and Gambit. As many of you know, I make a living as a professional speaker, with federal government, military and intelligence communities as my core audience. Let me put any fears anyone may have to rest: my work concentrates in Information Technology more than anything else, and if I get into hackers and hacking, it is more pro-hacker than anything else. I am working to improve our image as a community of talented individuals. I recently went off on a serious rant with three different audiences on a topic I felt was seriously exaggerated/over-hyped/fearmongered/bullshit. That topic was child pornography on the Internet. If you believed the press, child pornography was all over the Internet and easy to get. This brought about even more press and some action by our legislators to crack down on the Internet. I conducted an eight-week long search for child pornography late last year in the middle of this hype. I searched for, followed literally tens of thousands of links and hacked into pay/private porno servers all over the world. My opinion based on my results, which were not having found a single picture of child pornography anywhere, was that this whole topic was a bunch of bullshit. Well, that all changed a few days ago. I had asked for a software crack in a public USENET forum to override the NT4.0 Server 120 day time limit. While never receiving the crack, some idiot from an anonymous address sent me a child porn .jpg file. Trust me when I say it was child porn; the girl was no older than four years old and was very graphic. I immediately deleted all trace of the message/attachment. I was also very pissed to say the least that some asshole sent me this. I looked around on IRC on #teensex, and by whois'ing several operators, found more insidious channels. Among them are: #preteensexpics #littlegirlsex #100%preteensexpics #100%preteensexfuckpics #!!!!!!preteensexpics There are many others. I joined several of these channels and found that upon entering each one, I was auto messaged about special kiddie porn servers dedicated to trading, e.g., PreTeenSexPics - FTP at 130.67.80.230 l/p ncc/ncc [|] I logged onto several of these servers, and upon doing an ls-la found directories dedicated, among others, to child pornography. CD'ing into these directories listed several hundreds of files such as: 9yoshowr.jpg 8&dad.jpg 4yrfuck.jpg 6thgrade.jpg 6yoanal.jpg These are some of over several hundreds of files in a single directory on a single server. There were dozens of servers. I learned the protocol to download on these servers was to uplaod pictures you owned and then the operator would give you "credits" of various ratios for downloading, i.e., upload two pictures, you get credit to download one picture. I uploaded generic garbage pics off of a commercial adult web site, and recived credit to download three pics. What I saw wanted to make me physically vomit (yes, these pics are long since overwritten with 1's and 0's and destroyed). To put any doubts at rest, the material was real and fit the names of the files mentioned above. I was also actively sent private messages by those looking to trade. I asked what they had, and the usual response was "anything and everything." Some of the more common messages were: "I have 4-12 year old girls both action or pose." "I have little boys and girls alone or together." "I specialize in adults with 4-8 year old girls." I started logging the channels. I wanted to silently gather IP addresses and email addresses. These people needed some genuine hacker terror. Among some of the more active and persistent traders were: (*denotes server in operation) * SylphFox has a ftp at 206.246.162.183 1:2 ratio, anon login * <hehe(a)ts33.dac.pace.edu> * <kiddie(a)t2o15p13.telia.com> <suicide(a)mail1.arnan.com> <alexis(a)broken.dartmouth.edu> <guinness(a)broken.dartmouth.edu> <nexgen(a)philly158.voicenet.com> <tuvak(a)ppp-5200-0403.mtl.total.net> <Triad(a)an108.tir.com> <seeme(a)star090165.galstar.com> <domain(a)port182-tnt-ak-2.ihug.co.nz> <lewisJ(a)user-37kb329.dialup.mindspring.com> name: Lewis Johnson <fungus(a)infounik.com> <tk(a)conc0-a03.conc.tds.net> <pyro(a)user-37kb97d.dialup.mindspring.com> <hat(a)dialin9001.slip.uci.edu> name: Tuyen Ha <phostis(a)har-ct5-03.ix.netcom.com> <polls(a)175-203-179.ipt.aol.com> This log was generated in thirty minutes on #100%preteensexpics. If their email address appears above, it indicates they were actively offering trades or had servers in operation. These people listed above *were not* passive participants in the rooms. This represents only a small sampling of the overall people in the room at the time. Average number of people in each room varies, but seems to number about 40 people per room. I logged out of IRC, and then went to USENET, in such rooms as: alt.binaries.erotica.children.pre-teen There I found several hundreds upon hundreds of .jpg files of real child pornography. Several messages also pointed to some WWW sites, such as: http://www.nudebooks.com For someone who took a virtual tour of the kiddie porn world for only one day, I had the opportunity to download enough files to fully max out an IOmega 100MB ZIP disc. **This is not an exaggeration.** Imagine how much could be, and has, been downloaded by those who are regular participants in this activity. Well, this whole situation is unacceptable. First, I would like to apologize to all those who have hired me in the past, and were subject to my emotional rants about how the whole subject was bullshit and not real. It is very real. It is disgustingly real. It is so real it will make you want to throw up, and I actually, physically did throw up last night. Second, in reference to previous conversation over the years on this list, and in the hacking community in general, I know this type of activity is not tolerated by us. I have given you enough information above to start identifying the players in this and the places they congregate. It would be my sincere hope that hackers of all abilities would spend a few moments each day and put their talents to use against these people. Yes, I am advocating malicious, destructive hacking activity against these people. Who are they going to run to? The police? "They hacked my kiddie porn server and rm -rf'd my computer!" Right...the police will be so anxious to lock us up left and right. These people need to be eradicated from the Internet. While that may never happen completely, enough harrassment will send a message that engaging in this type of activity in very dangerous, and can result in serious harrassment, public embarrassment and computer destruction. This is my war. It will be a public war. I don't care what happens to me by their community or by law enforcement. I feel secure enough that no jury in the world will convict me for taking these people out. I feel secure enough that no law enforcement agency will ever take action that would place me in front of a jury. And if by some chance I do end up being prosecuted, I know what I did was right. So, now start the logs of the channels and the actions of those in it. Now starts the public postings of these logs in various places on the Internet. Now starts the harrassment. Now starts the malicious hacking. Now starts the war. I don't expect people to join me here on this. If you do, you have enough information to start. I caution you to log what is going on, and to make sure you are hitting the guilty, so no innocent people get annihilated in the process. Make damn sure you know who you are hitting and why, and be able to back it up with the idea of having to justify your actions in front of a jury. And make *REALLY SURE* that if you do come across files of child pornography, that you *OVERWRITE AND DESTROY* these files immediately! You wouldn't want to be the one who ends up being prosecuted for being in possession of this type of material. I would also recommend getting an anonymous email account, such as juno.com, mailmasher.com, hacked, etc., so that you can conduct your activities without fear of the inevitable retribution of those who actively trade this shit when the heat starts getting applied to them. Of all the people who can help stop this, it is us...hackers. Not law enforcement, not the government, not the media. Not anyone. Just us, hackers who have the talent to do what no one else can. Please forward this message freely around the Internet. It is not copyrighted in any way, shape, or form. se7en

12 18

Re: Access to Storage and Communication Keys
by William H. Geiger III 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- In <3.0.1.32.19970609000938.00756910(a)popd.ix.netcom.com>, on 06/09/97 at 12:09 AM, Bill Stewart <stewarts(a)ix.netcom.com> said: >I've been using PGP Inc.'s PGP5.0 Eudora Plug-In, >and it decrypts the mail into the mail message buffer itself. When you >finish with that particular message (e.g. go to the next, or just close >it), you get asked it you want to save the modified message, and if you >say "yes" you'll have the decrypted message in your mailbox. However, >there's a negative about this - if you receive mail that's signed and >encrypted, and save the modified version, it loses the signature >information - so it may be more valuable to save the encrypted >version... Well this is why I tell everyone to clear sign the message first and then encrypt it. In my PGP GUI/E-Mail integration E-Secure this is the default behavior. IMHO encrypting & signing (-sea) is a PITA (for the reciever). I also verify signatures of all signed inbound messages and append the output from PGP to the bottom of the message so that you can see the results when the message is opened without having to re-run PGP. The user also has the option to either decrypt messages as they are retreived or to store them encrypted. I just released the first beta of my auto-encrypt code. That was quite fun to write. Myself am rather disturbed by how many PGP/E-Mail implmentations handle signing/encrypting of messages. One of my biggest pet peeves is when only the plain text of a message is signed/encrypted. I have seen this with more than 1 implementation and I see it as a serrious security flaw. Another issue that is usally missed is Bcc's. The whole purpose of using Bcc's is that you don't want the rest of your distribution to know that you have sent a copy to the addresses on the Bcc line. If you encrypt a message with multiple keys including keys for your Bcc's then your Bcc's will be known to everyone who recieves a copy of the message. What I have done to address this is to send seperate copies of the message to each address on the Bcc list each encrypted with only the one key for the address. You can have the strongest algorithms in the world but they do you no good if they are poorly implemented. - -- - --------------------------------------------------------------- William H. Geiger III http://www.amaranth.com/~whgiii Geiger Consulting Cooking With Warp 4.0 Author of E-Secure - PGP Front End for MR/2 Ice PGP & MR/2 the only way for secure e-mail. OS/2 PGP 2.6.3a at: http://www.amaranth.com/~whgiii/pgpmr2.html - --------------------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: 2.6.3a Charset: cp850 Comment: Registered_User_E-Secure_v1.1b1_ES000000 iQCVAwUBM5u7uo9Co1n+aLhhAQH/sgP/V/ulJSLuNEV+sBW1hAnRsbYizxUb3tbc eJtG6YZnhszgjmj0ybgA/yfIC3i9uXjvuZeRdyrD9YSTf0a0gWOkcAzhhB/A5XBj Kf80HEXiJhd9dLSxYUGD55QFQNtz1QGbEGCURLyCchuWa0KrpLUofvUZ0cfatk+3 VKbfYn0KMTA= =vvGI -----END PGP SIGNATURE-----

1 0

List of reliable remailers
by Raph Levien 17 Dec '03

17 Dec '03

I operate a remailer pinging service which collects detailed information about remailer features and reliability. To use it, just finger remailer-list(a)kiwi.cs.berkeley.edu There is also a Web version of the same information, plus lots of interesting links to remailer-related resources, at: http://www.cs.berkeley.edu/~raph/remailer-list.html This information is used by premail, a remailer chaining and PGP encrypting client for outgoing mail. For more information, see: http://www.c2.org/~raph/premail.html For the PGP public keys of the remailers, finger pgpkeys(a)kiwi.cs.berkeley.edu This is the current info: REMAILER LIST This is an automatically generated listing of remailers. The first part of the listing shows the remailers along with configuration options and special features for each of the remailers. The second part shows the 12-day history, and average latency and uptime for each remailer. You can also get this list by fingering remailer-list(a)kiwi.cs.berkeley.edu. $remailer{"extropia"} = "<remail(a)miron.vip.best.com> cpunk pgp special"; $remailer{"mix"} = "<mixmaster(a)remail.obscura.com> cpunk mix pgp hash latent cut ek ksub reord ?"; $remailer{"replay"} = "<remailer(a)replay.com> cpunk mix pgp hash latent cut post ek"; $remailer{"exon"} = "<remailer(a)remailer.nl.com> cpunk pgp hash latent cut ek"; $remailer{"haystack"} = "<haystack(a)holy.cow.net> cpunk mix pgp hash latent cut ek"; $remailer{"lucifer"} = "<lucifer(a)dhp.com> cpunk mix pgp hash latent cut ek"; $remailer{"jam"} = "<remailer(a)cypherpunks.ca> cpunk mix pgp hash middle latent cut ek"; $remailer{"winsock"} = "<winsock(a)rigel.cyberpass.net> cpunk pgp pgponly hash cut ksub reord"; $remailer{'nym'} = '<config(a)nym.alias.net> newnym pgp'; $remailer{"balls"} = "<remailer(a)huge.cajones.com> cpunk pgp hash latent cut ek"; $remailer{"squirrel"} = "<mix(a)squirrel.owl.de> cpunk mix pgp pgponly hash latent cut ek"; $remailer{"middle"} = "<middleman(a)jpunix.com> cpunk mix pgp hash latent cut ek reord"; $remailer{'cyber'} = '<alias(a)alias.cyberpass.net> alpha pgp'; $remailer{"dustbin"} = "<dustman(a)athensnet.com> cpunk pgp hash latent cut ek mix reord middle"; $remailer{'weasel'} = '<config(a)weasel.owl.de> newnym pgp'; $remailer{"reno"} = "<middleman(a)cyberpass.net> cpunk mix pgp hash middle latent cut ek reord ?"; $remailer{"wazoo"} = "<remailer(a)wazoo.com> cpunk mix pgp hash latent cut ek"; $remailer{"shaman"} = "<remailer(a)lycaeum.org> cpunk pgp hash latent cut ek"; $remailer{"hidden"} = "<remailer(a)hidden.net> cpunk pgp hash latent cut"; catalyst(a)netcom.com is _not_ a remailer. lmccarth(a)ducie.cs.umass.edu is _not_ a remailer. usura(a)replay.com is _not_ a remailer. remailer(a)crynwr.com is _not_ a remailer. There is no remailer at relay.com. Groups of remailers sharing a machine or operator: (cyber mix) (weasel squirrel) The alpha and nymrod nymservers are down due to abuse. However, you can use the nym or weasel (newnym style) nymservers. The cyber nymserver is quite reliable for outgoing mail (which is what's measured here), but is exhibiting serious reliability problems for incoming mail. The squirrel and winsock remailers accept PGP encrypted mail only. 403 Permission denied errors have been caused by a flaky disk on the Berkeley WWW server. This seems to be fixed now. The penet remailer is closed. Last update: Mon 9 Jun 97 6:45:22 PDT remailer email address history latency uptime ----------------------------------------------------------------------- hidden remailer(a)hidden.net #-##*---#### 38:53 99.99% weasel config(a)weasel.owl.de ++++--++--+ 2:09:06 99.95% squirrel mix(a)squirrel.owl.de +-++--++-++ 2:05:06 99.95% jam remailer(a)cypherpunks.ca ****** ***** 10:29 99.83% balls remailer(a)huge.cajones.com ###.-## #### 38:28 99.71% replay remailer(a)replay.com ***** ** ** 5:44 99.35% mix mixmaster(a)remail.obscura.com *.-.-----. 7:30:50 97.83% reno middleman(a)cyberpass.net -+--------+- 1:19:13 97.76% winsock winsock(a)rigel.cyberpass.net -+-------- 3:48:43 95.95% lucifer lucifer(a)dhp.com +++ +++ + 51:30 91.29% cyber alias(a)alias.cyberpass.net ***** ** * 15:59 88.67% nym config(a)nym.alias.net 3:02 0.05% History key * # response in less than 5 minutes. * * response in less than 1 hour. * + response in less than 4 hours. * - response in less than 24 hours. * . response in more than 1 day. * _ response came back too late (more than 2 days). cpunk A major class of remailers. Supports Request-Remailing-To: field. eric A variant of the cpunk style. Uses Anon-Send-To: instead. penet The third class of remailers (at least for right now). Uses X-Anon-To: in the header. pgp Remailer supports encryption with PGP. A period after the keyword means that the short name, rather than the full email address, should be used as the encryption key ID. hash Supports ## pasting, so anything can be put into the headers of outgoing messages. ksub Remailer always kills subject header, even in non-pgp mode. nsub Remailer always preserves subject header, even in pgp mode. latent Supports Matt Ghio's Latent-Time: option. cut Supports Matt Ghio's Cutmarks: option. post Post to Usenet using Post-To: or Anon-Post-To: header. ek Encrypt responses in reply blocks using Encrypt-Key: header. special Accepts only pgp encrypted messages. mix Can accept messages in Mixmaster format. reord Attempts to foil traffic analysis by reordering messages. Note: I'm relying on the word of the remailer operator here, and haven't verified the reord info myself. mon Remailer has been known to monitor contents of private email. filter Remailer has been known to filter messages based on content. If not listed in conjunction with mon, then only messages destined for public forums are subject to filtering. Raph Levien

1 0