December 2003 - cypherpunks-legacy

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

Can you spell 'Stoopid'? Sure you can... / Re: thought for the day, and my IRS Investigations report
by nobody＠REPLAY.COM 17 Dec '03

17 Dec '03

"David D.W. Downey" <Webmaster(a)CyberSpaceTechnologies.com> wrote: > Zooko Journeyman wrote: > > My interaction with Jim Bell pretty much amounted to condemning > > him and telling him to go to hell, CC'ed to cypherpunks. And > > I haven't received any IRS Investigations notes, so perhaps my > > e-mail address wasn't included in Jim's little black book. > Why does it always seem like there has to be someone out there that just > HAS to be an idiot. Dear Dave, Why does it always seem that it is the idiots who ask this question? Are you by any chance of fate related to the David Downey who spammed the cypherpunks list with an announcement of his attempt to "get a number of the other cypherpunk lists together under one umbrella," then sent several copies of his "Welcome to my fascist, censorous, pseudo-cypherpunk mailing list." message to the cypherpunks list (and subsequently displayed his lack of knowledge as to how to unsubscribe to a mailing list, let alone try to run one)? > From: "David Downey" <digital_matrix(a)hotmail.com> > To: cypherpunks-unedited-outgoing(a)toad.com > > unsubscribe cryptography-politics-pgp-l Welcome to The Privacy Channel's Cryptography-Politics-PGP-L. As you've probably guessed from the list title, this list is dedicated to the open, friendly, and intellegent discussion of Cryptography around the globe. "Open, friendly, and intellegent discussion." ???!!!??? Sounds like my "CypherPissing" mail folder would starve to death if it counted on your list for its sustenance. All are welcome here Thank God! I was afraid I wouldn't be able to discuss my pictures of the Pope with his dick in the mouth of children being held down by Mother Teresa. Now, let's get a few things out of the way. The Rules! I'm starting to smell leather. Is it 'Jackboot' leather? 1) ABSOLUTELY NO SPAMMING ALLOWED!!!! I'll can ya in a heartbeat, as well as speak to all the server owners that you traveled on. Are the capital letters meant to indicate shouting, a thick Nazi German accent, or both? And are you intending only to 'inform' on and 'cause trouble for' *bad* people? Will there be 'spankings' involved (or does this cost extra)? 2) You keep it kind of clean. Keep the swearing and such down to a minimum. Ex-fucking-cuse me? Is there a swearing 'minimum' which is *required*, or only a 'maximum' which is *allowed*? Do Tourettics require a note from their doctor to call someone who sucks dick a cocksucker? You can get your point across just as well without cussing. Right. Like there is a phrase other than "lying, fucking criminal, god damn, rat-bastard Nazi motherfuckers" that could possibly come close to describing our beloved legislators. Flaming others is also considered bad karma here. I'd like to see folks help each other around here. "Why can't we all just get..." "... along." - Rodney King "...a long nightstick and just beat the fuck out of a nigger." - L.A. Chief of Police After all, we are all we got! And "Wherever you go, there you are." And "Patience comes to those who wait." And "If God is Love and Love is Blind, then Ray Charles must be God." Will we be singing "Michael row the boat ashore." a lot on your list? 3) You try to keep as much as possible to the point, and to the content of this list. OK, but it's going to make it a lot harder to sell my '67 Chevy station wagon. (It's an "anonymous" automobile with stolen plates. Perfect for a cypherpunk.) If you really want to talk about something else, let me know. I'll get another list going. Great! Now I know who is in charge of giving me permission to talk and is willing to control the forum in which I do it. Up until now I have had to bear this terrible burden myself. 4) Respect others!!! Does the "!!!" imply "or else..."? 5) Finally, HAVE FUN!!!!! How? By telling you to stick your "rules" up your ass? "FUN" in a manner that meets your approval? Does your shouting "HAVE FUN" and the multiple exclamation marks mean that having fun is 'required'? If so, will Jim Bell be allowed an exception to this rule, or will he have to learn to enjoy being buggered by Prisoner #32289723? I'm done. Talk to you on the List. You were done before you even got started. And shouldn't you have said, "SHOUT AT YOU ON THE LIST!!!!!!!!!!!!!!!!!!!!!!!!!!!"? I think I'll join the "Miss Manners Cryptography List," instead. It teaches proper oppression etiquitte, such as which fork to stick in the eye of the Jackboots who kick in your door to demand your secret key, and how to choose the proper wine to go with the shit that the government dishes out. !have !fun, TruthMonger

1 0

Re: There's a hole in your crypto...
by ab411＠detroit.freenet.org 17 Dec '03

17 Dec '03

Phil Fraering writes: >Why are the arguments on either side so emotional? I'm rather hesitant to jump into this thread, but I think that one reason is that Fred's concerns have been misunderstood a bit. (If I'm wrong, I'm sure he'll correct me.) It seems that there are many people who are ready to leap to the defense of the honor of the programmers behind PGP, when they feel said honor is being impugned. I get the impression (as much from what I know of his background as from what he's said) that Fred is at least as concerned about PGP being a correct implementation of the various algorithms it involves as he is about back doors inserted by nefarious individuals. As I understand it, it is impossible to demonstrate the correctness of any program the size of PGP. And it would also not be possible to validate the compiler or the operating system. One thing I'm not sure of, though, is this: Would it be possible to verify a much smaller program, say, the RSA-in-3-lines-of-Perl? (Of course, you still would be left trying to verify the Perl interpreter, and the OS again.) And is there any way to build trusted system out of small, verifiable pieces? Since the way they're connected could also be questioned, I suspect that when you put enough of them together it's just as bad as the case of a single, monolithic program. But this isn't my area, so I don't know. Would it be possible to formally verify at least some parts of a large program like PGP? And would that add to the trustworthiness of the overall program? (Keeping in mind Fred's earlier remark about a seemingly-unrelated portion of the code overwriting the key.) -- David R. Conrad, ab411(a)detroit.freenet.org, http://web.grfn.org/~conrad/ Finger conrad(a)grfn.org for PGP 2.6 public key; it's also on my home page Key fingerprint = 33 12 BC 77 48 81 99 A5 D8 9C 43 16 3C 37 0B 50 No, his mind is not for rent to any god or government.

5 7

HEY_now
by John Young 17 Dec '03

17 Dec '03

8-02-95. NYPaper: "Pattern Emerges In Bomber's Tract: F.B.I. Says Attacker Stayed Close to a Few Campuses." In what was described as an important advance in the hunt for an elusive serial bomber, the Federal Bureau of Investigation said yesterday that it had traced a years-long pattern of academic involvement that took the self-described anarchist from the Chicago area to Salt Lake City to Berkeley, Calif. By matching his 17-year record of carnage against an analysis of a densely argued 35,000-word tract he sent to The New York Times in June, Government officials say they have concluded that the bomber is a student of the history of science who may have taken classes at or hovered around major university campuses from the late 1970's to the mid- 1980's. FCU_stu "Excerpts From Manuscript Linked to Suspect in 17-Year Series of Bombings." Role of Scientists: The system HAS TO force people to behave in ways that are increasingly remote from the natural pattern of human behavior. For example, the system needs scientists, mathematicians and engineers. It can't function without them. So heavy pressure is put on children to excel in these fields. FCX_txt Twofer: HEY_now

1 0

NYET--attempted formal specs (again)
by Nathan Zook 17 Dec '03

17 Dec '03

I hope I'm not becoming Detweileresqe about this, but I've had some requests for these. Since not even I was satisfied with my original notation, I thought I'ld try again... (donning gear) -----BEGIN PGP SIGNED MESSAGE----- Copyright 1995, Nathan Zook. All rights reserved. NYET-- Non-Youths Exhibit Temperance. This is a rising, legitamate concern among parents that their children have all-to-easy access to porn on the internet. Last year, there were numerous proposals for various voluntary self-rating systems. AOL and Prodigy heavily censor their systems in various ways. This year, Senator Exon advanced his own proposal. Of course, this occured just about the time that SurfWatch came out. But none of these proposals can ultimately succeed. Here I restate my NYET proposal from last year for your consideration. The system is of necessity ISP-based. Home-based systems are subject to attacks at home. Since many (most?) children are better with computers than their parents, these attacks can be expected to succeed. Any ISP-based system requires that the ISP determine which customers are not of majority age and who is legally responsible for them. There are technical solutions to this problem which are part of the basis to the proposal. The elements of NYET are as follows: the ISP, monitoring software, the parent/guardian of the minor, and one or more ratings services. A NYET-ISP does not grant access priveleges to minors without prior contact with the (generically) parent of the minor. This contact includes explaining and helping configure the NYET software in accordance with the parent's wishes. The NYET-software runs as superuser on the ISP's machine. All minor accounts have a corresponding configuration file sitting in their account owner's parent's directory, which is locked with read/write by owner only flags. The correspondence between minor and parent accounts sits in a file owned by root and similiarly locked. The parent sets the configuration file to permit and deny access to various parts of the net. Since it is unreasonable for the parent to personally "rate" the net, it is expected that various organizations will form ratings services. The parent could then select various combinations of ratings criteria from these agencies as default. It is expected that the services would charge for their information. It is likely that these charges could be added to the monthly bill that the parent receives from the ISP. And the role of government? Right now--none other than to encourage parental involvement. Any attempt to force this, or almost any other, type of restriction by legislative "I say so" (fiat in Latin) will meet with fatal opposition. Until the legislature understands the net, the combined efforts of the millions who use the net will swamp any efforts to control it. Speaking of government, school internet access is the bane of any attempt by parents to control the access that their kids have to the net. Anyone seeking to limit children's access should look carefully at this experimentation. I post this proposal because I believe it to be one of the few stable attractors in this problem. I believe that Prodigy and SurfWatch amount to first iterations, and that the market will push them towards NYET. When it does so move, and a majority of ISPs provide or nearly provide NYET service, and ONLY then, the government might mandate the NYET standard. As a somewhat earlier measure, the government could offer to hold harmless ISPs that adhere to these standards--but only when the market has already handled the technical hurdles. I feel it necessary to reiterate the importance of the government waiting for a market solution to this problem. By its design, the net appeals to libertarians and anarchists. For many years, it has been accessible almost exclusively by people demographically predisposed to a libertarian or anarchist world view. The net.gods, when angered, can produce no end of michief. And since they designed the system, they won't be stoppable. -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMB73X34gWvtXVTwZAQFKsAP9E/NOfKrt7WwcvNdMlWzg8jneyVa19hL+ 9Ot7Ir4SigZJDDQ7hjxS2elJourCZpFWpBXFdKMbTGqTXMtmELZJu5qYidXDmV1i BAWHYI0RW2E6MszGSgAh1MDfUpY7/RO89CjsuP8M3aGVF44FOWpIoTRZnNhXRO9q xnA2tErpz+A= =NpaG -----END PGP SIGNATURE-----

3 4

Consumer Report: RSA T-Shirt
by Harry S. Hawk 17 Dec '03

17 Dec '03

I got my RSA tee-shirt the other day.. It came promptly and both of the shirts I ordered came. It was oddly shipped in a near see-through pouch. I'm happy over all with the shirt, the quality of the printing, and the construction of the Tee (all cotton, name brand tee).. I have only one complaint. THat is the "machine readable" rsa barcodes. TO my eye the printing job there is rather poor. I doubt it is machine readable (althought I don't have a 128 barcode reader to try it out with).. I'm disappointed as I doubt that the 4 line RSA code is NOT exportable since text books have been allowed previously to be exported. Machine readable materials have been called into question. My thoughts are that if it is not machine readable the shirt is much more a novelity then an munition (which is sorta why I bought it to begin with.. to be fair..).. Of course I hoped to be the first one on my block to own one. But when I went into the drug store the clerk asked me where I got it, noting someone else was just in there wearing one... /hawk -- Harry Hawk Manager of Computer Services Warwick Baker & Fiore 212 941 4438 habs(a)warwick.com

2 1