December 2003 - cypherpunks-legacy

Re(2): With friends like these...
by Theodor.SCHLICKMANN＠bxl.dg13.cec.be 18 Dec '03

18 Dec '03

We have to live with the fact that industry has a janus head. On one hand - and here we should follow their example - they are reluctant to allow somebody else to keep their keys in trust. On the other hand - in contradiction to the previous - they invest in development of key escrow systems including key management protocols which allow third parties having uncontrolled access to keys. Theodor Schlickmann

1 0

MS Access 97 deprotection?
by Peter Trei 18 Dec '03

18 Dec '03

An acquaintence of mine who runs a small consulting business here in Massachusetts called last night. He seems to be suffering from one of the classic aftereffects of a having 'disgruntled, about-to-be-ex-employee'; one of the database files on which his business relies has been encrypted within Microsoft Access 97, and he needs to recover the data. A quick look around at the obvious sites shows no generic de-protector, as there are for MS Word and many other systems. Anyone have any clue how he might get his data back? (I've already told him to consider the lawyer-based route). Send me mail - I'll pass it on to him. thanks, Peter Trei trei(a)process.com

1 0

PGP 5.0 doesn't tell me Which key a message is signed by! [SEVERITY 1]
by Bill Stewart 18 Dec '03

18 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Yow! I'm using PGP 5.0, with the PGPtray and the Eudora Plugin, in a version that appears to be b14c3 for Win95. When I receive a signed email message, or check with PGPtray, it tells me the message is from "User <email(a)foo.com>", but doesn't tell me it's from KeyID 0x12345678 or the fingerprint of the key or anything even vaguely difficult to fake. Thus, I've signed this message as Phil Zimmermann FAKE <prz(a)acm.org>, and if I'd left out the FAKE it would be difficult to tell it from a real Phil key. The GUI happily gives me a message box saying "Good signature from Phil Zimmermann FAKE <prz(a)acm.org>". We've been discussing 0xDEADBEEF attacks on Cypherpunks and Coderpunks, but this appears to be far worse - I hope it's been fixed for the production version? -----BEGIN PGP SIGNATURE----- Version: 5.0 beta Charset: noconv iQBVAwUBM5u51kEvGqT1DvpRAQHnwgIAzF7uBmgsk9+c4IZObsnXBJBHuCFEUsMr 3V64azY6Wp156SFgDPGODQvQxzDiQCb96hUz2RK2j7DxfekOZ7rzjw== =u93K -----END PGP SIGNATURE----- # Thanks; Bill # Bill Stewart, +1-415-442-2215 stewarts(a)ix.netcom.com # You can get PGP outside the US at ftp.ox.ac.uk/pub/crypto/pgp # (If this is a mailing list or news, please Cc: me on replies. Thanks.)

1 0

Re: Thoughtcrime (Re: My War) (fwd)
by Jim Choate 18 Dec '03

18 Dec '03

Hi, Forwarded message: > Date: Mon, 09 Jun 1997 18:35:34 -0700 > From: Lucky Green <shamrock(a)netcom.com> > Subject: Re: Thoughtcrime (Re: My War) > Let us assume that it is unethical to force children to participate in the > production of child pornography. (For the benefit of Kent and the more > ignorant people on this list, I will state that I firmly believe this to be > true, despite the fact that doing so should be irrelevant for the argument.) > Furthermore, let us assume that there are a number of individuals who enjoy > looking at hard core child pornography. > The question then is: does going after the distributors provide a benefit > to the children being (potentially) used for such pictures? > The answer is clearly no. Assuming, tacitly of course, that the supply of distributors is unlimited. If the resource is limited, as it actualy is, by getting the distribution node you in effect cut many people off. Thus forcing either total denial or else direct intervention, thus raising the chance of getting caught because more persons would be involved than would normaly be the case. This in effect clearly indicates a benefit to going after the distributors. This argument can be extended to the film-maker as well. Now some will say that it doesn't matter, somebody else will always pop up. The problem with this is that we have a limited population and there are only a statistical percentage going to be interested in the activity. This implies that there is some set of persons who will not participate. The trick is to get the non-participants to be the larger of the two. > By limiting the distribution of an individual > picture, you increase the total number of pictures required to satisfy > market demand. That means more children will be required to meet demand. By extension then full and complete public distribution would minimize it completely. So, you are seriously stating that we should put such pictures on the daily television, say during childrens hour? Now if we follow this further we are left with the image of our government hiring children to pose for said images because the supply of 'actual' images had diminished. That is truly a case of the pot calling the kettle black. Plus the sicko's get free, danger free, thrills at the public expence. Wooo, just what I want my tax dollars spent on. We are clearly dealing with a cusp-shaped function here. The implication being that some form of regulation is beneficial if we want to actualy reduce child abuse. > Thus, by going after the distributors, Se7en causes more children to be > violated by child pornographers. Or just possibly making the supply even more scarce because fewer and fewer are willing to take the chance of making a few bucks. > The only question that remains is: how can he live with this? > > Logic != base emotions, Ahmen brother! Otherwise, feldercarb. _______________________________________________________________________ | | | Moderation in all things, including moderation. | | | | -I wish I could remember- | | | | Jim Choate ravage(a)ssz.com | | The Armadillo Group www.ssz.com | | Austin, Texas, USA 512-451-7087 | |_______________________________________________________________________|

1 0

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

18 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

Julf ordered to reveal anon IDs
by nobody＠huge.cajones.com 18 Dec '03

18 Dec '03

> Julf Johan Helsingius (Julf) has been ordered to release the identity of the poster of one of the Scamizdat series of confidential materials. "The Court of Appeals of Helsinki (Helsingin hovioikeus) has upheld the decision of the local court of Helsinki, in which Johan 'Julf' Helsingius was ordered to reveal the user id of the person who used the anon.penet.fi server to repost parts of Scamizdat, a collection of secret Scientology scriptures. "In its decision dated 4th of June 1997, the Court of Appeals orders Helsingius to reveal the names in 30 days after the decision becomes final. If he doesn't try to appeal the decision it will mean that he has to reveal the user id within three months. He might appeal the decision to the Supreme Court within 60 days, in which case the whole thing will take longer, regardless of whether the Supreme Court chooses to consider the case or not. "The following ID's were used to send material through anon.penet.fi: an498608(a)anon.penet.fi, an545430(a)anon.penet.fi "The material was a repost of Scamizdat #11, in several parts. The original repost was done on 15.2.1996, and partly repeated 12.3.1996." Message-ID: <5n7g0v$h75(a)reimari.uwasa.fi>

2 1

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

18 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

Re: FC97 in July Wired
by Robert Hettinga 18 Dec '03

18 Dec '03

About the third thing I imagined, after imagining the world's first financial cryptography conference, and, better yet, having it on Anguilla in February; and, after imagining it as Wired's featured 'Deductible Junket'; was imagining a nice feature article in Wired on the conference after it was all over. Thanks to Charles Platt, I now figure I can die and go to heaven, as all three have happened. :-). Out of Town Newspapers in Harvard Square says they'll have the July Wired next Friday. It appears that Vince gets a subscription down in Anguilla, which got there yesterday, and probably everywhere else, I reckon. So, the checks may take 90 days to clear in Anguilla, but at least the mail gets there on time... Stay tuned for details (as we imagine them :-)) about FC98, and about the FC97 conference proceedings, which should be published by Springer-Verlag this summer. Cheers, Bob Hettinga, General Chairman, Financial Cryptography, 1997/98, Anguilla, BVI P.S. if you, or anyone you know, is interested in FC98 sponsorship or exhibition space opportunities, please contact me. --- begin forwarded text Resent-Date: Sun, 8 Jun 1997 08:57:10 -0400 X-Authentication-Warning: online.offshore.com.ai: list set sender to fc97-request(a)offshore.com.ai using -f Date: Sun, 8 Jun 1997 08:57:04 -0400 (AST) From: Vincent Cate <vince(a)offshore.com.ai> To: fc97(a)online.offshore.com.ai cc: ois-news(a)online.offshore.com.ai Subject: FC97 in July Wired MIME-Version: 1.0 Resent-From: fc97(a)offshore.com.ai X-Mailing-List: <fc97(a)offshore.com.ai> archive/latest/57 X-Loop: fc97(a)offshore.com.ai Precedence: list Resent-Sender: fc97-request(a)offshore.com.ai The July issue of Wired magazine has an article about the Financial Cryptography 97 conference held in Anguilla. -- Vince ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Vincent Cate Offshore Information Services Vince(a)Offshore.com.ai http://www.offshore.com.ai/ Anguilla, BWI http://www.offshore.com.ai/vince ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ --- 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/

2 2

PGP key fingerprint spoofing
by Adam Back 18 Dec '03

18 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

Dems Critique Crypto Policy
by John Young 18 Dec '03

18 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