December 2003 - cypherpunks-legacy

Re: Zimmermann legal fund
by Robert A. Rosenberg 17 Dec '03

17 Dec '03

At 17:57 7/30/95, Ed Carp [khijol SysAdmin] wrote: >When I lived in California, I banked at Security Pacific, then changed >over my account to BofA. When I left the bay area, I closed my account, >not knowing that someone had sat on a check for $120 - I thought it was me >just entering an ATM receipt twice (as I do from time to time). So, >someone from a place called ChexSystems sends me a letter, saying "well, >you had a check go through and the bank paid it, please pay us." So, I >send them the $120 or whatever it was. How old was the check when it was presented (and how long was it from the check's date until you had closed the account). If the check was stale then you have a valid gripe about the bank's behavior. I've dealt in situations where people are collecting checks which are going to be "stale" before they are submitted for processing yet there is no request to post-date the check nor setting up of an escrow account to hold/clear the money until it can be turned over to the correct owner (they collect voting fees for a convention where the winner gets the money but the holder of the election is the one who is being sent the check to sit-on [for up to 6 months] until the winner can be handed the stack of checks - There is a claim that the holder of the election can not open a segregation/escrow account due to bank rules or procedures).

1 0

RE:NRC Panel, Law Enforcement questions
by liberty＠gate.net 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Nice questions, John. To bring executive-branch accountability to a level more closely approaching absolute zero, the FBI might want a FOIA backlog of +8 years instead of "only" 5, but from what little I know of FOIA; its exceptions, combined with a hostile judiciary (led by Justice Scalia) are swallowing most of it anyway, as embarrassment _obviously_ hurts vital U.S. National Security Interests...[Note: IANAL, and I *am* a bit sarcastic!] I wonder, and perhaps my kind friend Hadmut can help me here, if there is an English translation of any and all Nazi-era German laws/regs regarding cryptography. As I [dimly] recall, Enigma was born as a private enterprise and the patent was only later taken over by government and classified after it was offered for sale to businesses (without much luck). These laws, if they exist, might make for interesting reading in side-by-side comparison with either Sen. Grassley's latest proposals, or with anything regarding cryptography coming from our paranoid FBI director. JMR -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Freedom isn't Freeh iQCVAwUBMB7vC21lp8bpvW01AQE9WQP7BxH6fBTRyxLX3Sw46oYSCbTHKukVC5Hc Z9nNSC35bazNa5QBCnr7pZjFUBmGXTzs4/NE2uyPbp34d3ojVJrgta9n+y8DX5uD yY4oMignyHGMPscac8OEkUmN+5T5gG1UKYpWv80Qt8sGfpyw3HCHOyE2YYFjpZ1y X+/ZDHvogj8= =dJ3T -----END PGP SIGNATURE----- Regards, Jim Ray "The people will again respect the law when the law again respects the will of the people." Jim Ray, Campaign '92 ------------------------------------------------------------------------ PGP key Fingerprint 51 5D A2 C3 92 2C 56 BE 53 2D 9C A1 B3 50 C9 C8 Key id. # E9BD6D35 ------------------------------------------------------------------------ Support the Phil Zimmermann (Author of PGP) Legal Defense Fund! email: zldf(a)clark.net or visit http://www.netresponse.com/zldf ________________________________________________________________________

2 1

anonymity review in law journal
by Vladimir Z. Nuri 17 Dec '03

17 Dec '03

Hi everyone, someone tipped me off to a law review article by Anne Branscomb entitled Anonymity, Autonomy, and Accountability: Challenges to the First Amendment in Cyberspaces 104 Yale L F 1639. I have not seen this myself or noticed it mentioned here but it might be an interesting read for anyone who has access to it, and useful as a footnote in someone's paper, web filling, pointer for reporters, fish wrapping, or bird cage lining. (as Alfred E. Neuman might note) ~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^ \ / ~/ |\| | | |> | : : : : : : Vladimir Z. Nuri : : : : <vznuri(a)netcom.com> \/ ./_.| | \_/ |\ | : : : : : : ftp://ftp.netcom.com/pub/vz/vznuri/home.html

2 1

Re: Pat Robertson Fears E-cash?
by Michael Handler 17 Dec '03

17 Dec '03

John Young: | A Foxhole-atheist swears Pat Robertson said last night that his | new book warns of a "digital cash society" and massive | theft by cyber-criminals. Did any believer hear this, or | know if this is what he prognosticates for e-cash bedevilment? ----- BEGIN EXCERPT ----- The 700 Club, March 8, 1995, 10:00 -- 11:30 AM [ ... ] PAT ROBERTSON: OK. Well, ladies and gentlemen, something a little bit more serious. You know, the Bible talks about a day when people won't be able to buy or sell except having a mark; a mark of what is called the beast. It's one of those things in Relevation that keeps coming up. Well, as technology increases, we see a little bit -- a little bit more. Now we've got digital cash that may on the way to your wallet, a card you can use for any kind of purchase, from health care to road tolls to pay-per-view TV. But are there hidden security dangers in this computerized wonder card? We've got a special report on this program. You don't want to miss it. [ ... ] ROBERTSON: Now that man [David Chaum!] is Jewish. I don't know whether he's speaking out of Relevations or not, but that is the scenario set forth ... in Relevation, that the -- the -- the cards are too -- too valuable to be lost, which means that -- that there has to be some other identification. And we just were speaking, prior to the program, about the possibility of, indeed, a tattoo that would carry -- just tiny little dots would carry -- all the information that is needed could be put on somebody's hand or wherever. It's -- it's that close, really. ... We've got a few years to go, but I -- I -- I -- I'm just -- and -- and the -- the -- the justification for all this is, `Well, we can't have people dealing drugs.' So let's -- in order to cut the drug dealers, let's take away the freedom and privacy of every other human being on the face of the earth, and that is a frightening prospect. [ ... ] ----- END EXCERPT ---- There's more, like an interview with David Chaum and Dave Banisar [EPIC], but I've got raw calluses on my hands, so I'm not doing any more typing tonight. ;-) PS to JYA: Communique top secret postal address / telephone facsimile machine access codes for possible transmittance of relevant sections for scanning and automatic distribution to the CP list via usual methods? Remember to use HyperMIME backchannel DC-net OTP public key MOST SECRET secret-shared subliminal-signature encoding methods to prevent intellectual property gestapo from homing in on location of Rebel base, no? ;-) -- Michael Handler | Cypherpunks: Civil Liberty through Complex Mathematics handler(a)sub-rosa.com | grendel(a)netaxs.com | ISO: Midrange good quality violincello, new or used, Philadelphia, PA | full size, with bow and case, in PA/NY/NJ/DE/MD.

1 0

Munition (RSA) Tshirt Testimonial
by Alan Penny 17 Dec '03

17 Dec '03

I got my RSA tshirt this week. It looks good! Features: - Way cool black with white lettering - Famous RSA code in 5 lines of perl code on front. - Same text represented in CODE 128 barcode (several bar code lines look kind of smudgy, I doubt that the bar code could actually be read by a scanner, but it looks cool!). - Text on back: "Warning this Tshirt is a munition, ITAR section..." I have worn the shirt out 2 times this week. Unfortunately no one seemed to be impressed by it :-( Maybe I will go browsing for a Pentium system at CompUSA with it on this week end and see if it draws any comment/notice. I got my shirt from: dhenson(a)itsnet.com (Don Henson) Don Henson, Managing Director (PGP Key ID = 0X03002DC9) West El Paso Information Network (WEPIN) Check out The WEPIN Store at URL: http://colossus.net/wepinsto/wshome.html Order it one or two sizes larger than you think that you need for a comfortable fit! Cordially, [-------------------------------------------------------------------------] [ Public pgp-key: email penny(a)tyrell.net with subject as 'send pgp-key' ] [ My opinions are mine. I have scored 90% on the the Turing Test. ] [ Alan Penny, penny(a)tyrell.net ]

1 0

Software Glitch FYI (fwd)
by Nathan Zook 17 Dec '03

17 Dec '03

---------- Forwarded message ---------- Date: Tue, 1 Aug 95 01:55 EST From: Dr. Linda D. Thompson - American Justice Federation <lindat(a)iquest.net> To: aen!news(a)iquest.net Subject: Software Glitch FYI A Congressman's aid called me today to explain that if you send email to all the Congressmen's offices at one time, the software at their end causes each Congressman to receive 50 copies. Please be sure everyone is aware of this glitch. To prevent 50 copies from being sent to each Congressman, it is necessary to break the mailing list into 5-10 addresses at a time. Every list I've ever received of Congressional Emails has annoying spaces and formats, so my list doesn't have that. It can be copied directly into a nickname box in Eudora or to a Bcc: list on a message. senator(a)boxer.senate.gov senator_brown(a)brown.senate.gov, sen_dodd(a)dodd.senate.gov, senator_lieberman(a)lieberman.senate.gov, joe_biden(a)biden.senate.gov, senator_coverdell(a)coverdell.senate.gov, tom_harkin(a)harkin.senate.gov, chuck_grassley(a)grassley.senate.gov, larry_craig(a)craig.senate.gov, dirk_kempthorne(a)kempthorne.senate.gov, senator(a)simon.senate.gov, senator(a)moseley-braun.senate.gov, wendell_ford(a)ford.senate.gov, senator(a)breaux.senate.gov, senator(a)johnston.senate.gov, senator(a)kennedy.senate.gov, john_kerry(a)kerry.senate.gov, senator(a)mikulski.senate.gov, senator(a)levin.senate.gov, mail_grams(a)grams.senate.gov, senator(a)wellstone.senate.gov, john_ashcroft(a)ashcroft.senate.gov, max(a)baucus.senate.gov, conrad_burns(a)burns.senate.gov, bob(a)kerrey.senate.gov, mailbox(a)gregg.senate.gov, opinion(a)smith.senate.gov, senator(a)bradley.senate.gov, senator_Bingaman(a)bingaman.senate.gov, senator_domenici(a)domenici.senate.gov, senator_reid(a)reid.senate.gov, senator_dewine(a)dewine.senate.gov, nickles(a)rpc.senate.gov, lugar(a)iquest.net senator_chafee(a)chafee.senate.gov, senator(a)hollings.senate.gov, tom_daschle(a)daschle.senate.gov, larry_pressler(a)pressler.senate.gov, senator_frist(a)frist.senate.gov, senator(a)hutchison.senate.gov, senator_robb(a)robb.senate.gov, senator(a)warner.senate.gov, senator_leahy(a)leahy.senate.gov, vermont(a)jeffords.senate.gov, senator_Gorton(a)gorton.senate.gov, russell_feingold(a)feingold.senate.gov, senator(a)rockefeller.senate.gov, everett(a)hr.house.gov, budmail(a)hr.house.gov, sbachus(a)hr.house.gov, jdickey(a)hr.house.gov, edpastor(a)hr.house.gov, dcaucus(a)hr.house.gov, woolsey(a)hr.house.gov, gmiller(a)hr.house.gov, sfnancy(a)hr.house.gov, talk2tom(a)hr.house.gov, petemail(a)hr.house.gov, annagram(a)hr.house.gov, tellnorm(a)hr.house.gov, zoegram(a)hr.house.gov, samfarr(a)hr.house.gov, george(a)hr.house.gov, andrea22(a)hr.house.gov, tellbuck(a)hr.house.gov, jharman(a)hr.house.gov, tucker96(a)hr.house.gov, housesst(a)hr.house.gov, rpackard(a)hr.house.gov, skaggs(a)hr.house.gov, schaefer(a)hr.house.gov, bozrah(a)hr.house.gov, cshays(a)hr.house.gov, delaware(a)hr.house.gov, kthurman(a)hr.house.gov, cstearns(a)hr.house.gov, canady(a)hr.house.gov, pdeutsch(a)hr.house.gov, hastings(a)hr.house.gov, jlinder(a)hr.house.gov, georgia6(a)hr.house.gov, saxby(a)hr.house.gov, ga10(a)hr.house.gov, runderwo(a)hr.house.gov, brush(a)hr.house.gov, luisg(a)hr.house.gov, hfawell(a)hr.house.gov, dhastert(a)hr.house.gov, durbin(a)hr.house.gov, johnhost(a)hr.house.gov, emailpat(a)hr.house.gov, edky01(a)hr.house.gov, mward2(a)hr.house.gov, bunning4(a)hr.house.gov, torkma06(a)hr.house.gov, jmoakley(a)hr.house.gov, cardin(a)hr.house.gov, tellhoek(a)hr.house.gov, congehlr(a)hr.house.gov, davecamp(a)hr.house.gov, repsmith(a)hr.house.gov, chrysler(a)hr.house.gov, lrivers(a)hr.house.gov, jconyers(a)hr.house.gov, gil(a)hr.house.gov, dminge(a)hr.house.gov, mn03(a)hr.house.gov, vento(a)hr.house.gov, tellbill(a)hr.house.gov, tocollin(a)hr.house.gov, oberstar(a)hr.house.gov, goldsmit(a)iquest.net talentmo(a)hr.house.gov, demldr(a)hr.house.gov, bemerson(a)hr.house.gov, bthompson(a)hr.house.gov, funnc02(a)hr.house.gov, thechief(a)hr.house.gov, mail2nc5(a)hr.house.gov, crose(a)hr.house.gov, myrick(a)hr.house.gov, chtaylor(a)hr.house.gov, melmail(a)hr.house.gov, epomeroy(a)hr.house.gov, zeliff(a)hr.house.gov, franksnj(a)hr.house.gov, dzimmer(a)hr.house.gov, mpforbes(a)hr.house.gov, lazio(a)hr.house.gov, tmanton(a)hr.house.gov, molinari(a)hr.house.gov, rangel(a)hr.house.gov, jserrano(a)hr.house.gov, engeline(a)hr.house.gov, boehlert(a)hr.house.gov, bpaxon(a)hr.house.gov, portmail(a)hr.house.gov, hokemail(a)hr.house.gov, istook(a)hr.house.gov, furseor1(a)hr.house.gov, pdefazio(a)hr.house.gov, murtha(a)hr.house.gov, jonfox(a)hr.house.gov, mchale(a)hr.house.gov, pa16(a)hr.house.gov, jspratt(a)hr.house.gov, cwilson(a)hr.house.gov, samtx03(a)hr.house.gov, barton06(a)hr.house.gov, doggett(a)hr.house.gov, frost(a)hr.house.gov, ggreen(a)hr.house.gov, enidutah(a)hr.house.gov, ortonut3(a)hr.house.gov, opickett(a)hr.house.gov, talk2bob(a)hr.house.gov, ninthnet(a)hr.house.gov, bsanders(a)igc.apc.org, repwhite(a)hr.house.gov, asklinda(a)hr.house.gov, dunnwa08(a)hr.house.gov, rtate(a)hr.house.gov, mneumann(a)hr.house.gov, badger02(a)hr.house.gov, roth08(a)hr.house.gov, commerce(a)hr.house.gov, slabmgnt(a)hr.house.gov, resource(a)hr.house.gov, housesst(a)hr.house.gov, smbizcom(a)hr.house.gov ============================================ Dr. Linda D. Thompson American Justice Federation 3850 S. Emerson Avenue, Suite E, Indianapolis, IN 46203 Telephone: (317) 780-5203 AEN News BBS: (317) 780-5211 Fax: (317) 780-5209 Orders (Visa/MC) 1-800-749-9939 Internet: lindat(a)iquest.net *******************************************************************************

1 0

Re: Provably Correct Crypto?
by fc＠all.net 17 Dec '03

17 Dec '03

> I stipulated I didn't want any such garbage, I specifically said > english summaries are not acceptable and you bombard me with them. > Yet you wont accept others opinion of PGP's security, which verbal or > other wise, can only be an abstract summary. The difference between my response to your question and your responses to my questions is that I tried to answer your questions. > > > You state that crypto should be poved correct and suggest a technique > > > otherwise known as formal specification. I agree, pgp should have > > > been written in Z-specs. If you take a course in formal specification > > > you will soon see the intractability of the technique wrt large > > > systems. > > > > I didn't say that. Perhaps you should review what I said before > > characterizing it. > > piffle! Your words: > "I think that this issue can generally be addressed by a divide > and conquer strategy. Prove that the called routines are > correct and confined under all possible parameters, do the > same for the calling routines, do the same for the interaction > between them, and I think you have it." I don't see wher I said anything about formal specification here or Z-specs. It's true that proof of correctness for large systems is a hard problem, and that is one of the reasons that the secure http daemon is designed to be small. However, the same has not been shown (as far as I am aware) for many of the other properties that may be interesting from a security standpoint. > This sounds like performing a formal analsis to me. And you didn't > address the intractability anyway. Problems worthy of attack, prove their worth by fighting back - Alan Perlis > > I have shown (not yet proven) certain things. A graduate student is now > > working on trying to prove the various properties I believe to be of > > interest in an automatic theorum prover he is working on. > > The work in automatic theorum proving is ongoing and not limited to > your grad student or your work. I never said it was and he is not my grad student. He is a grad student who made some comments on the daemons and decided he would be interested in seeing if some of these properties could be proven. > > I believe that these things are worth showing (and proving), but you > > may certainly feel free to disagree with these contentions. > > I said showing by english isn't good enough, proving would be > fantastic. I don't believe these issues reside solely with pgp and as > such you should question computability as a whole before using > "incomplete specification" in accusing one system to be flawed. And I told you that we are in the process of, but not finished with, doing just that. I never said that any such problems reside solely in PGP. > > > If you want prople on this list to repeat after you "I cannot be > > > certain there is no compromising bugs or backdoors in X" Then I will > > > go out on a limb and say everyone here will agree if system X is > > > sufficiently large. > > > > I don't believe I ever asked anyone on this list to repeat anything. > > All I did was ask questions and respond to responses to my questions. > > Your tiresome repetitive question was "Why do you belive X is secure" > I herby answer exactly as above "I cannot be certain there is no > compromising bugs or backdoors in X" If you are tired of hearing my responses to your comments, there is an obvious solution. -- -> See: Info-Sec Heaven at URL http://all.net Management Analytics - 216-686-0090 - PO Box 1480, Hudson, OH 44236

1 0

Re: A hole in PGP
by Paul Elliott 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- If I were going to create a hole in PGP, I would create a "bug" in PGP's key generation process which would limit the primes PGP chooses to a relatively small subset. Then when I wanted to break, I would factor by searching this small subset. I could also try to put a bug in the code that chooses a Random Idea key, making it choose from a small subset, that again could be searched. To put a bug in the idea portion of PGP would be difficult because people can check if PGP can intemperate with other implementations of IDEA. - -- Paul Elliott Telephone: 1-713-781-4543 Paul.Elliott(a)hrnowl.lonestar.org Address: 3987 South Gessner #224 Houston Texas 77063 -----BEGIN PGP SIGNATURE----- Version: 2.6 iQCVAgUBMB8adfBUQYbUhJh5AQEx3QP9Har9kb9731F/Nzl0p9kMDEhN6YaSmU4D HZ+Xhcwq8fA1EBZOzszmjG5gI2JZvciaQpA6vV+ZraKCoJljXB0Ud0AuRwJnxbSq K4gvmev2Hgi3soE1HWsF/ODmiO4be+haxfDrTYDNjVDP56XL1LH2Lxysx1cqrVqt DRZ4l0480PE= =eLP9 -----END PGP SIGNATURE-----

1 0

some discussion of rannos in PGP (was: of a hole in PGP)
by aba＠dcs.exeter.ac.uk 17 Dec '03

17 Dec '03

Fred Cohen <fc(a)all.net> writes on cpunks: : PGP is a product that is specifically disliked by the powers that be : because it provides free access to strong cryptography which is against : the public policy of the US government. That means that people in that : same said government likely feel it is their duty to make certain that : they can still read PGP mail. Certainly granted! Hence persecution of Phil Z. A bit difficult to achieve in the presence of available source code, I (and many others) are using PGP compiled by themselves. That doesn't prove there are no subtle back-doors but it rules out unsophisticated backdoors in distributed executables. (Even such things could be checked if someone got suspicious, things can be reverse engineered). Now to the question of what can be done practically to help further validate PGPs authenticity, and freeness from back-doors. The way I see it the only attack which you could reasonably expect to pull off in terms of being subtle enough to hope to get away with given full access to source is the random number generator. The code which actually generates the random primes, and converts them to PGP output format is reasonably short and well defined. Wouldn't take long to single step that and watch that nothing happened on the way out to file. Encryption is a similarly simple operation, M ^ e % n you could easily check that manually (with a certain small piece of perl even). Same for generation of IDEA keys. I don't really feel qualified to comment properly on the random number generation, but to me (I looked at the source in fair detail) it looks good. I mean there is real entropy being generated (timing key strokes against a high speed clock on PCs lower on UNIX systems typically) and the stirring operation looks good, MD5 + XOR on key. Presuming that the MD5 implementation is correct? Seems a pretty good likelihood to be, it's been given enough real world tests that you could do a very nice probablistic statistical confidence test on it. Which would easily say that it was correct to some huge degree of certainty. The legitimacy of using a high frequency clock to time intervals between key strokes, seems a very good way of generating random numbers. I mean there is most definately *some* entropy being generated, PGP makes reasonably conservative estimates of the amount of entropy generated, and stirs the whole number in (not just the expected entropy). I'm not saying your comments aren't useful; they are, and analysis and critique of the random number generation in particular is very important. Indeed given the sheer cost of factoring a 2048 bit RSA modulus, or of brute forcing a 128bit IDEA key, it is indeed a pertinent question as to whether any kind of brute force attack could be generated on the random number generation, which could be slighly cheaper than either of these. 128bits is a lot to play with. To me it looks good, but then I'm not a cryptographer, and also there is the kind of "NP problem aspect" to it all in that for reasonably complex code it will not be apparent whether a proof is possible with out looking at the specifics. Still I think some analysis of the random number generation code would be useful work. I'm not expecting to see a flaw, but doesn't mean it shouldn't be entered into with an open mind. I think it does not fall in the same league as the apparent difficulty of having a secure sendmail (you said a compromising couple of bugs seem to get found a couple of times a year), for the reason that what PGP is doing with it's random no generation is well defined, contained in a few lines of code, and only really relying on a couple of assertions: 1) MD5 is itself not inherently flawed 2) the MD5 implementation is correct 3) key stroke timings are a source of a safely conservatively estimatable amount of entropy 4) the key generation method does not narrow the search space 5) there are no other compromising bugs between key generation of the key and it being written to the keyring 1) Heh, not a lot you can do about that. Is it or isn't it? Time will tell. 2) Seems pretty likely to me there are test strings which come with the RFC implemenation, and it would be unbelievably unlikely that it should produce the complete set of tests and yet somehow still be flawed. Given that there are _no_ branches in the algorithm (ie just various permutations and bit twidlings based on the key info, which get mangled into the digest. 3) Pretty good I think, especially on a PC, which has a higher speed timer. Some entropy is surely generated, and with safe entropy estimation, and cryptographically secure stirring, it sounds pretty good to me. 4) For RSA keys, I don't think so, unless you believe that strong primes will agains become important. For current factoring algorithms strong primes are just as hard to factor as a completely randomly generated prime, except for certain primes which are in any have an infinitesimal chance of occurring. For IDEA keys there is little value added over a striaght ran no, as there are no special properties which an IDEA key must have. 5) I would assert is relatively trivial to demonstrate, a couple of hours with a debugger should demonstrate that. You could do testing more rigourously, test every branch, so that you have checked that the outcome is that the key gets written to the keyfile, with various options, not utterly fool proof of course, but pretty darn good given the simplicity. On the more philosophical side, with the idea that you can never be sure that folks aren't NSA agents with hidden agendas etc, well you can't be sure. But the open source and sheer number of folks reading is the best argument against this. That means that at least some true blue cpunks, "live free or die" types will read it in earnest, and examine very carefully. Another philosophical argument against PGP having any cleverly hidden "back-doors" in the form of purposefully weakened ran-no generators or what have you is that the NSA et all hate PGP with such vehemence. Heh if they don't like it, it must be good :-) And remember, say NO to key escrow :-) (It's no good having an ultra carefully validated PGP if you go to jail for being caught with a copy on your HD, welcome to the Land of the Freeh, and all you know. May happens sooner than expected, then the only folks using crypto will be the "live free or die" folks, plus of course the criminals who figure they have more to hide and would get in more trouble for what they are really up to than for a "possesion of crypto" charge.) Adam -- HAVE *YOU* EXPORTED RSA TODAY? --> http://dcs.ex.ac.uk/~aba/rsa/ --rsa--------------------------8<------------------------------- #!/bin/perl -s-- -export-a-crypto-system-sig -RSA-3-lines-PERL $m=unpack(H.$w,$m."\0"x$w),$_=`echo "16do$w 2+4Oi0$d*-^1[d2%Sa 2/d0<X+d*La1=z\U$n%0]SX$k"[$m*]\EszlXx++p|dc`,s/^.|\W//g,print pack('H*',$_)while read(STDIN,$m,($w=2*$d-1+length($n)&~1)/2) -------------------------------8<------------------------------- TRY: rsa -k=3 -n=7537d365 < msg | rsa -d -k=4e243e33 -n=7537d365

1 0

some discussion of rannos in PGP (was: of a hole in PGP)
by A.Back＠exeter.ac.uk 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Fred Cohen <fc(a)all.net> writes on cpunks: : PGP is a product that is specifically disliked by the powers that be : because it provides free access to strong cryptography which is against : the public policy of the US government. That means that people in that : same said government likely feel it is their duty to make certain that : they can still read PGP mail. Certainly granted! Hence persecution of Phil Z. A bit difficult to achieve in the presence of available source code, I (and many others) are using PGP compiled by themselves. That doesn't prove there are no subtle back-doors but it rules out unsophisticated backdoors in distributed executables. (Even such things could be checked if someone got suspicious, things can be reverse engineered). Now to the question of what can be done practically to help further validate PGPs authenticity, and freeness from back-doors. The way I see it the only attack which you could reasonably expect to pull off in terms of being subtle enough to hope to get away with given full access to source is the random number generator. The code which actually generates the random primes, and converts them to PGP output format is reasonably short and well defined. Wouldn't take long to single step that and watch that nothing happened on the way out to file. Encryption is a similarly simple operation, M ^ e % n you could easily check that manually (with a certain small piece of perl even). Same for generation of IDEA keys. I don't really feel qualified to comment properly on the random number generation, but to me (I looked at the source in fair detail) it looks good. I mean there is real entropy being generated (timing key strokes against a high speed clock on PCs lower on UNIX systems typically) and the stirring operation looks good, MD5 + XOR on key. Presuming that the MD5 implementation is correct? Seems a pretty good likelihood to be, it's been given enough real world tests that you could do a very nice probablistic statistical confidence test on it. Which would easily say that it was correct to some huge degree of certainty. The legitimacy of using a high frequency clock to time intervals between key strokes, seems a very good way of generating random numbers. I mean there is most definately *some* entropy being generated, PGP makes reasonably conservative estimates of the amount of entropy generated, and stirs the whole number in (not just the expected entropy). I'm not saying your comments aren't useful; they are, and analysis and critique of the random number generation in particular is very important. Indeed given the sheer cost of factoring a 2048 bit RSA modulus, or of brute forcing a 128bit IDEA key, it is indeed a pertinent question as to whether any kind of brute force attack could be generated on the random number generation, which could be slighly cheaper than either of these. 128bits is a lot to play with. To me it looks good, but then I'm not a cryptographer, and also there is the kind of "NP problem aspect" to it all in that for reasonably complex code it will not be apparent whether a proof is possible with out looking at the specifics. Still I think some analysis of the random number generation code would be useful work. I'm not expecting to see a flaw, but doesn't mean it shouldn't be entered into with an open mind. I think it does not fall in the same league as the apparent difficulty of having a secure sendmail (you said a compromising couple of bugs seem to get found a couple of times a year), for at least two reasons, one is that with sendmail the code being examined must take input from Charlie who is trying to mess the system up. So a deliberate attempt to foul the works, examining the source, looking for any kind of subtle weakness, or weird combination of inputs (which would almost certainly never occur by accident during normal usage) which could cause it to compromise security. For PGP for the section we are talking about (key generation) the only input comes from *you*, the person who is presumably trying to obtain security, not trying to generate a weak key through some tortuous input string. So things like the stack over flow with carefully crafted machine code for the particular architecture which was exploited with finger in the fave old example of the worm of yore, is not the kind of attack you need to be worried about (IMO). The second aspect in which analysing PGPs ran no generation, is different to sendmail or http type problems is that what PGP is doing with it's random no generation is well defined, contained in few lines of code, and only really relying on a couple of assertions: 1) MD5 is itself not inherently flawed 2) the MD5 implementation is correct 3) key stroke timings are a source of a safely conservatively estimatable amount of entropy 4) the key generation method does not narrow the search space 5) there are no other compromising bugs between key generation of the key and it being written to the keyring 1) Heh, not a lot you can do about that. Is it or isn't it? Time will tell. 2) Seems pretty likely to me there are test strings which come with the RFC implemenation, and it would be unbelievably unlikely that it should produce the complete set of tests and yet somehow still be flawed. Given that there are _no_ branches in the algorithm (ie just various permutations and bit twidlings based on the key info, which get mangled into the digest. 3) Pretty good I think, especially on a PC, which has a higher speed timer. Some entropy is surely generated, and with safe entropy estimation, and cryptographically secure stirring, it sounds pretty good to me. 4) For RSA keys, I don't think so, unless you believe that strong primes will agains become important. For current factoring algorithms strong primes are just as hard to factor as a completely randomly generated prime, except for certain primes which are in any have an infinitesimal chance of occurring. For IDEA keys there is little value added over a striaght ran no, as there are no special properties which an IDEA key must have. 5) I would assert is relatively trivial to demonstrate, a couple of hours with a debugger should demonstrate that. You could do testing more rigourously, test every branch, so that you have checked that the outcome is that the key gets written to the keyfile, with various options, not utterly fool proof of course, but pretty darn good given the simplicity. On the more philosophical side, with the idea that you can never be sure that folks aren't NSA agents with hidden agendas etc, well you can't be sure. But the open source and sheer number of folks reading is the best argument against this. That means that at least some true blue cpunks, "live free or die" types will read it in earnest, and examine very carefully. Another philosophical argument against PGP having any cleverly hidden "back-doors" in the form of purposefully weakened ran-no generators or what have you is that the NSA et all hate PGP with such vehemence. Heh if they don't like it, it must be good :-) And remember, say NO to key escrow :-) (It's no good having an ultra carefully validated PGP if you go to jail for being caught with a copy on your HD, welcome to the Land of the Freeh, and all you know. May happens sooner than expected, then the only folks using crypto will be the "live free or die" folks, plus of course the criminals who figure they have more to hide and would get in more trouble for what they are really up to than for a "possesion of crypto" charge.) Adam PS to any folks who may have sent me mail in the last couple of days, note the temporary change of email addr to: A.Back(a)ex.ac.uk due to local hw failure, similarly the same m/c was the WWW server, should all return to normal in a couple of days. (Talk about single point of failure, all the X-terms booted off it too). - -- HAVE *YOU* EXPORTED RSA TODAY? --> http://dcs.ex.ac.uk/~aba/rsa/ - --rsa--------------------------8<------------------------------- #!/bin/perl -s-- -export-a-crypto-system-sig -RSA-3-lines-PERL $m=unpack(H.$w,$m."\0"x$w),$_=`echo "16do$w 2+4Oi0$d*-^1[d2%Sa 2/d0<X+d*La1=z\U$n%0]SX$k"[$m*]\EszlXx++p|dc`,s/^.|\W//g,print pack('H*',$_)while read(STDIN,$m,($w=2*$d-1+length($n)&~1)/2) - -------------------------------8<------------------------------- TRY: rsa -k=3 -n=7537d365 < msg | rsa -d -k=4e243e33 -n=7537d365 -----BEGIN PGP SIGNATURE----- Version: 2.6.2i iQCVAwUBMB9U5ynIuJ1VakpnAQGLcgP/fNe2cBJKNJrKE3iHiFrHgUM4So/Q0nqg GYgJu+gYZIlnQSv6JUXBDWFw/29n/ARN9oENjxmgAs6rTiE9bjPhD8IuftGaENsF ou3v4Y04B/7UFG8sXx9Opdr0G6P+sHM7f+pdwkCW4rtWA1tclUigrkIF/+65Q0a4 iZN1c4Y23tk= =35BY -----END PGP SIGNATURE-----

1 0