- cypherpunks-legacy - lists.cpunks.org

The Two Threads of Dr. Cohen
by cman＠communities.com 17 Dec '03

17 Dec '03

There are two threads to Dr. Cohen's arguments which bear separation. One thread, with the implications of deliberate wrongdoing on the part of Derek Atkins or others unnamed should be dismissed out of hand. His comments regarding the fundamental security properties of PGP and the burden of proof for software security are right on target. One has to draw the line somewhere with regard to what "they" are out to do. PGP may have had weaknesses from the beginning, but to suggest a deliberate change so subtle to escape PGP's original authors is to descend into the realm of paranoia. In addition, such allegations are extremely rude, and I think Dr. Cohen owes Derek an apology. At the same time, I think some apologies are in order with respect to some very good points raised by Dr. Cohen about software security. There is a whole sub-discipline of CS devoted to the construction of trusted computer systems, which if practiced can result in much greater assurances about the reliability and security of the resultant software. This is (I believe) the source of Dr. Cohen's assertion that the burden of proof is on those who claim something is secure. PGP is practically a poster child for how not to write a secure piece of software. It has had a great many authors. It is non- modular. It is large and complex. Simplicity is almost always sacrificed at the altar of even slight performance gains. It is absolutely infested with platform-dependent code. And these are only the problems that directly impact its security... it's also strongly tied to a tty-style interface and implements a poorly-designed format. With respect to "tiger teaming" PGP, I think it is a pretty hopeless proposition. It is never, ever going to be as secure as some people would like it to be. Given the past and current bug discovery rate, it is almost inconceivable that there are not exploitable bugs. This is not to say it isn't "pretty good", but it is not what someone with a formal background in real secure systems developement would ever bless as "secure". PGP needs to be thrown away and rewritten from scratch. This has, in fact, been done, but while this development effort has been incrementally better, it still doesn't qualify as a secure development approach. Also, nobody has this product yet for reasons that I won't mention as we don't need to start another tangential flamewar. In any event, I think it's important for people to realize that in the security community, the burden of proof _is_ on the software developer, not on those claiming security problems. I'm surprised Perry hasn't chimed in on this score yet, many of his posts allude to similar notions of security by design and by construction. Doug

1 0

Re: ssh protocol
by stewarts＠ix.netcom.com 17 Dec '03

17 Dec '03

Matt Ghio wrote (on cypherpunks): >I've been playing with the cryptotcp program available from utopia.. It >has some bugs but works pretty well, if you don't mind waiting 20-30 >seconds at the beginning. It does a Diffie-Hellman exchange and 3DES over >telnet. How hard would it be to add some sort of authentication to this >program? I haven't actually compiled the code (it's not very DOS-friendly), but it looks easily modified; some parts of the problem are still hard, such as identifying the client to the server. Some issues to deal with for adding authentication: 0) RSAREF2.0 would have been nice, and comes with D-H and DES. 1) The option negotiation is simple but hard-coded; it would be easy to add one thing at a time, but would benefit from a more flexible option-negotiator. That would also let you pretend it was just a general-purpose telnet-with- various-processors and avoid ITAR restrictions for the authentication-plus-compression bones version, but the authors, not being Yankees, don't have to worry about that. 2) Authentication means that some process on each machine is willing to make a digital signature using a private key - how do you store that key safely? For a client operated by a human, that's not a big problem; for a server, or a client operated by a program without a direct user-interface, it's harder. Do you just leave the key in a file (trusting root?) Do you only start the server daemon by hand? For most Unix applications, I suppose a root-read-only file containing the key is OK, since if a cracker can read that file you've got far more serious problems (and the cracker can take over your email anyway.) 3) One big difficulty in authentication systems is securely but conveniently exchanging authentication parameters; you don't want to risk man-in-the-middle by trusting keys you got from the other side (otherwise you could use plain D-H), but getting keys from a keyserver is slow and hard to integrate, and requiring the other side to already have your key parameters limits your usefulness. 3A) How do you know who you're talking to so you know which authentication data to use? For the client, that's pretty easy - the client knows it's calling server(a)foo.bar.edu, so it can get the keys in advance and not worry. (It still needs the PGP web-of-trust or X.509 hierarchy to validate the keys.) But how does the server know who the client is? IP address? What if it's spoofed? What if it does a DNS lookup, which gets spoofed? You could use a password-file equivalent, but that does mean you can only send mail to people who trust you? 3B) How do you do error recovery in PGP, i.e. you either can't find the other side's keys, or can find them but can't validate them because you don't have a web of trust that gets from you to them. Do you just fail the call? (That's secure but boring.) If you complete the call anyway, that means there's a major security risk, which is that Bad Guys can spoof keys by sending you keys you can't validate. 3C) If you use X.509 hierarchical certification, you _can_ just hand across the certificate instead of waiting for a PGP keyserver to respond, since the web of trust is built-in if you're part of the same hierarchy, but there's still the problem (for the server) of knowing whose certificate to use. #--- # Thanks; Bill # Bill Stewart, Freelance Information Architect, stewarts(a)ix.netcom.com # Phone +1-510-247-0664 Pager/Voicemail 1-408-787-1281 #--- # Crypto in 3-4 lines of perl --> http://dcs.ex.ac.uk/~aba/

1 0

Software Glitch FYI
by lindat＠iquest.net 17 Dec '03

17 Dec '03

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 *******************************************************************************

2 1

Re: a hole in PGP
by danisch＠ira.uka.de 17 Dec '03

17 Dec '03

> This is where you are very wrong. I am not saying that "if you can't > find any holes it must be secure". What I am saying is that the > source is available, and thousands of people have looked at the > source, and none of them have found any holes in it. It is definitely much more difficult to implant a backdoor into a program which is available as source code than into a black box. BTW: Has anyone ever found a modified and weakened version of pgp ? Hadmut

1 0

Re: There's a hole in your crypto, dear Eliza dear Eliza...
by Andrew.Spring＠ping.be 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- >How do I know PGP IS secure? I don't. That doesn't mean I don't use it or Doesn't the NSA certify the security of cryptosystems? I wonder what they'd say about PGP? -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMB/gUI4k1+54BopBAQEozAP/dTYfpk4aENquuhdmmAqWKFtHhcPFsj47 BL6F9QpA61eGaJ8T8hiuBlq9RBj8KYtQ0881CwLmiSztv1+uJxWWS11hb26l0zeD tZ3I9JXgFJSC4Pkv2i84D5VbnFfL0W+7yWFsgJUgg++c9UUDVW7xcwSmUfVrqgE+ hVuFyCK/cDM= =NXYL -----END PGP SIGNATURE----- -- Thank you VERY much! You'll be getting a Handsome Simulfax Copy of your OWN words in the mail soon (and My Reply). <Andrew.Spring(a)ping.be> PGP Print: 0529 C9AF 613E 9E49 378E 54CD E232 DF96 Thank you for question, exit left to Funway.

2 1

Re: commerical busters
by WOOD＠VAX2.ROCKHURST.EDU 17 Dec '03

17 Dec '03

ON: 31-JUL-1995 20:14:46.10, dan(a)netmarket.com wrote: > At 8:50 PM 07/31/95, Patrick May wrote: > > > My dim memories from a project I did for Sony a couple of years > >ago are that commercials are separated by a fixed number of black > >frames and some, at least, have tracking information encoded so that > >advertisers can monitor how often they are played. I'll try to dig up > >more info. > > From: dfitzpat(a)interserv.com > Wednesday July 26, 1995 -- ShopTalk > > - -- > > NEW VCRs TAKE ON COMMERCIALS POINT-BLANK > > By Jonathan Takiff > Philadelphia Daily News Staff Writer > > > Already besieged by Washington politicians over the content of TV > programming (and threats of a show-blocking chip), television > broadcasters are about to be hit with another whammy. This time it's > VCRs that automatically blank out commercials. > > <snip> > > $$$$ $$$$$ $$$$ > -----BEGIN PGP SIGNATURE----- > Version: 2.6.2 > > iQCVAwUBMB193KZKaCr9f/gtAQFa5AP/ZEmtSM/hSXb6zcFHDmv9Me0thtAqqCxZ > 7COYgWxuLkl78+y/INpFKW861mrNig1UlO8Q+vDImKK3qUmTS1tzRWNIH9XVyYtA > pJ05g/Z/WKUPx17jd2no9oRqut4bziLa4iMj59B/4nxAhIjEtE5TZFP6okCQ1HGm > qbFhOteJavc= > =Opny > -----END PGP SIGNATURE----- > dan Hello all, I have thought about this before, as usual my ideas are not new. My vision was like this. 1. Develop a few methods to recognize commercials through cable T.V. a. The blank spaces between broadcasting? b. Analysis of image information? c. Analysis of sound information? d. Understanding cable T.V. protocols? e. etc? 2. My commerical buster would work on a delay. a. The broadcast information would enter a queue. b. The broadcast information would be evaulated. c. If all of the tests for commericals passed, display. d. If any of the tests fail, the T.V. goes blue, and my CD player is served. e. The time of delay is dependent on the time to analyze the broadcast information. I wish it could happen, I hate commericals. Many Thanks, ------------------------------------------- | "Computers are boring and slow." | | | | David Wood | | Information Systems Specialist? | | wood(a)vax2.rockhurst.edu | -------------------------------------------

2 1

Re: Pat Robertson Fears E-cash?
by Peter Trei 17 Dec '03

17 Dec '03

The relevant verses are in Revelations 13, where some of the actions by which The Beast can be recognized are given. Among them are: 16 And he causeth all, both small and great, rich and poor, free and bond, to receive a mark in their right hand, or in their foreheads: 17 And that no man might buy or sell, save he that had the mark, or the name of the beast, or the number of his name. Millenialist Christians tend to regard this as a method by which the faithful will be shut out of the economy, since the pious will refuse such a 'mark'. E-cash is a bit of a reach from this, but some of them (eg, Robertson), extend the verses to cover all forms of trackable transactions. I suspect that if someone could get him to realize the privacy aspects of true anonymous ecash, he'd like it. Just don't propose an implantable cryptographic token :-). Peter Trei Senior Software Engineer Purveyor Development Team Process Software Corporation trei(a)process.com

3 2

ANNOUNCEMENT: Mailcrypt 3.3 for GNU Emacs
by Patrick J. LoPresti 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Mailcrypt version 3.3 is now available. Mailcrypt is an Emacs Lisp package which provides a simple interface to message encryption with PGP. (You do use Emacs to handle your mail and news, right?) Features: Encryption, decryption, signing, adding keys, extracting keys, passphrase caching with timeout, multiple secret key (identity) support, a simple but flexible interface to Cypherpunk remailers (including chaining, response blocks, pseudonyms, and Mixmaster support), and an automatic keyserver interface via HTTP. *We* think it's the best interface to these functions anywhere, but then again, we're biased. The NEWS file is appended to this message. Obtain it through the Mailcrypt home page at http://cag-www.lcs.mit.edu/mailcrypt/ or from the FTP mirror at ftp://cag.lcs.mit.edu/pub/patl/ and enjoy! - Patrick J. LoPresti (patl(a)lcs.mit.edu) - Jin S. Choi (jin(a)atype.com) Tue Aug 1 15:00:27 1995 -0500 ====================================================================== Noteworty changes in Mailcrypt version 3.3: Numerous minor bugs have been fixed. Mailcrypt now requires at least FSF Emacs version 19.28 or XEmacs version 19.12. Sorry, but anything else is too annoying. Support has been added for reading mail under (ding) GNUS. Noteworthy changes in Mailcrypt version 3.2: Mailcrypt now uses "start-process" instead of "call-process-region" to run PGP; this uses a pipe instead of a temp file for various inputs, including your passphrase. Ahem. All Mailcrypt commands now start with the prefix `C-c /' to bring Mailcrypt into line with documented GNU standards. `mc-insert-public-key' is now bound to `C-c / x' (an in "extract") instead of `C-c a'. `mc-deactivate-passwd' is bound to `C-c / f' (as in "forget"). `mc-read-mode' and `mc-write-mode' are now full-blown minor modes. So you can do, for example, `M-x mc-install-write-mode' from a Text mode buffer and have the normal encryption and signing commands available. The keymaps for the modes are configurable variables. Interactive commands `mc-encrypt-region', `mc-sign-region', etc. are now defined. If you use RMAIL and you say no to "Replace encrypted message with decrypted?", you will be dropped into RMAIL mode for viewing. RMAIL summary mode is now supported. Documentation in the form of a Texinfo file is now part of the distribution. Mailcrypt can now fetch a needed key from finger, HTTP, or any of a list of locally stored keyrings. `C-c / k' initiates a fetch manually; Mailcrypt will offer to initiate one automatically as appropriate during encryption or signature verification. The remailer functions now support Mixmaster. `C-c / d' can handle conventionally encrypted messages. -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Processed by Mailcrypt 3.3, an Emacs/PGP interface iQCVAwUBMB6GjHr7ES8bepftAQGXLQP/W4sWXEWficWMlQ340StWd+RC5pJmFh4d 9jlAodH/Gmv1slPmJy21WDPqeyp+3z5BJ8BUgz98e7rqooZ3tB7Fy6cT4Q3UJ0Gv +WZQBkNV4tT7bNjCQxjIE3QrowGBeko0CZIMwGlRujioguHMgHcm8XTJO37ZuypB Sn24f/uPkGc= =8f59 -----END PGP SIGNATURE-----

1 0

Australia next to ban PGP
by Andrew.Spring＠ping.be 17 Dec '03

17 Dec '03

> Path: ping.be!Belgium.EU.net!EU.net!howland.reston.ans.net!tank.news.pipex.net!pipex!sunsite.doc.ic.ac.uk!lyra.csx.cam.ac.uk!rja14 > From: rja14(a)cl.cam.ac.uk (Ross Anderson) > Newsgroups: alt.security.pgp,alt,politics.datahighway,aus.legal,aus.net.news,sci.crypt > Subject: Australia next to ban PGP > Date: 1 Aug 1995 17:53:50 GMT > Organization: U of Cambridge Computer Lab, UK > Lines: 57 > Message-ID: <3vlpne$cks(a)lyra.csx.cam.ac.uk> > NNTP-Posting-Host: nene.cl.cam.ac.uk > Xref: ping.be alt.security.pgp:9699 sci.crypt:4852 > > Australia's proposed crypto policy: > > (1) Banks will get key escrow > > (2) Other Australian residents will be forced to use weak crypto > > Source: talk by Steve Orlowski, Assistant Director, Australian attorney > general's department, given at the Cryptography Policy and Algorithms > Conference, Queensland University of Technology, last month. > > p 34: `the needs of the majority of users of the infrastructure for > privacy and smaller financial transactions can be met by lower > level encryption which could withstand a normal but not > sophisticated attack against it. Law enforcement agencies could > develop the capability to mount such sophisticated attacks. > Criminals who purchased the higher level encryption products > would immediately attract attention to themselves.' > > He mentioned that his department considered itself a suitable repository > for the government central decrypting unit, which would decrypt traffic > for local police forces. He also wants to escrowed keys for banks and > other organisations allowed to use strong crypto. > > Centralising the wiretap capability with the AG is represented as a useful > safeguard against abuse of power by local police forces. It would be > presented as a `data recovery' facility in order to reassure the voters. > > Centralisation will enable the AG to acquire the capability to use ``more > sophisticated techniques in circumstances where the key cannot, for > whatever reason, be recovered from escrow''. > > So the technical parameters would appear to be: 40 bit keys for the > masses, 56-bit escrowed keys for the banks, and a Wiener machine sitting > in Orlowski's office. Belt, braces and string. > > Curiously enough, he quotes a `Review of long Term Cost Effectiveness > of Telecommunications Interception' as saying that ``Encryption by > targets of their communications (both voice and data) is not considered > as a problem for TI at present in Australia'' and goes on to say that > ``there has been comparatively little market for voice encryption > products, although they have been readily available''. > > He even produces some good arguments for the EFF, such as that much of > the intelligence comes from the call log data and from calls to third > parties such as airlines and hotels which are not encrypted. > > He also says that the OECD countries will hold a meeting on National > Cryptography Policies later this year. While at the conference, I found > out that a classified meeting took place this March in Germany between > the signals intelligence agencies of the developed countries, plus > Australia and South Africa, at which the assembled spooks agreed to > press their governments to bring in escrow and/or weak crypto. > > Australia seems rather eager to lick Uncle Sam's boots on this issue. > I wonder what the payoff was? > > Ross -- Thank you VERY much! You'll be getting a Handsome Simulfax Copy of your OWN words in the mail soon (and My Reply). <Andrew.Spring(a)ping.be> PGP Print: 0529 C9AF 613E 9E49 378E 54CD E232 DF96 Thank you for question, exit left to Funway.

2 1

Mierda
by John Young 17 Dec '03

17 Dec '03

The New Yorker of July 31 writes on the indictment of six lawyers in Miami on drug-conspiracy charges: [Ex-Fed] Abbell continued to do legal work for the Rodriguez brothers, and in January, 1991, he hired an obscure Miami lawyer, Francisco Laguna, as a full-time associate. Laguna, who is in his thirties and was born in Colombia and speaks fluent Spanish, appears, from the indictment, to have been the most deeply immersed of all the lawyers in the day-to-day affairs of the Cali cartel. He maintained frequent contact with Miguel Rodriguez by public telephone. Unfortunately for Laguna, federal agents had obtained the code numbers of the debit cards he used to make his calls, and were able to intercept many of the conversations.

1 0