December 2003 - cypherpunks-legacy

hunting for no hole in PGP
by hoz＠univel.telescan.com 17 Dec '03

17 Dec '03

>How do you propose that a user's keystrokes can be analyzed? I have an idea. (many voices groaning...) The "reduced keyspace" and the "subliminal channels" fear both come from the mysterious process of choosing the 128-bit IDEA key. The other bogeyman that I hear the most about in PGP is the public/private key generation. Random numbers scare people, including me. Could PGP use and IDEA key that is the MD5 hash of the "random number" (the way it is currently calculated) concatenated with the message itself? It would be easy to verify that the correct key had been selected. It would be impossible for some "ghost" in the random number routines to use a predictably reduced keyspace, or to send subliminal data, because its output never (directly) gets sent. Something similar could be done during public/private key generation. Have the PGP folks considered doing something similar? Sometimes this seems like a good idea to me, and other times it looks like useless effort and one more opportunity for something to go wrong. Rick F. Hoselton (who doesn't claim to present opinions for others)

1 0

Re: Attacks on PGP
by tcmay＠sensemedia.net 17 Dec '03

17 Dec '03

At 2:51 AM 8/1/95, Matt Blaze wrote: >Tim, > >My impression (based on reviewing papers for the last few CRYPTOs and >EUROCRYPTs) is that the reason for the lack of "practical" papers is >primarily that not very many of them get submitted. In fact, I think Right, but it's a kind of vicious circle. What I meant about cryptanalysis not really be "academic" is that not much status attaches to having broken a specific message. >there actually are a fair number of cryptanalysis papers at CRYPTO, >at least compared with the even smaller number of papers there that >describe new ciphers. Anyway, cryptanalysis IS part of the mainstream >of the academic crypto world these days (consider differential >cryptanalysis, linear cryptanalysis, etc.) I guess this is my bias, as I think of the "differential cryptanalysis" as not really being cryptanalysis :-}. In the sense that it's basic research unto itself, not the grungy cracking of an actual cipher. But you're right that the stuff on Wiener's estimates for a DES-cracking machine, on the differential cryptanalysis work, etc., _does_ make it into Crypto. Ditto for breaking ciphers (showing them to be flawed). I just never see papers describing actual attacks on specific systems...maybe those who do such things are talking? I guess the bottom line of what I'm saying is that if some person or group wants to be a "tiger team" to try to find flaws in PGP, to try to break it, this would be a nifty thing. I doubt anyone on this list disagrees. --Tim May .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay(a)sensemedia.net | anonymous networks, digital pseudonyms, zero 408-728-0152 | knowledge, reputations, information markets, Corralitos, CA | black markets, collapse of governments. Higher Power: 2^756839 | Public Key: PGP and MailSafe available. "National borders are just speed bumps on the information superhighway."

1 0

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

There's a hole in your crypto, dear Eliza dear Eliza...
by Robert A. Hayden 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Alright, here's my 2 cents worth for this petty flamewar... Once upon a time, there was PGP 2.3. MIT had nothing to do with it. The population of the net that used the program was fairly small. In addition to being small, they were all (mostly) computer literate people. These people were confident in the security of PGP because the had read and understood the source code. It was checked and declared good. Then, in stepped MIT. I, and a few others, raised concerns about a possible conflict of interest with MIT distributing the code, and encouraged everyone to double check the code for back doors and other NSA nasties. It was checked and declared good. Now, we are in the present. MIT is still part of the equation. However, the demographics of the net have chaged. Fewer people are here that (by percentage) are computer literate to the level to do source code investigations. A few question why they shoudl trust PGP when they don't know it's secure. We, those who have grown up with PGP, point out that it is good, yet that really isn't a great reason to trust it. So the question is, why shoudl non-technical people believe that PGP is good? They don't have the skills to check it for themselves, and you have to admit that the associations of MIT with various TLAs are at the very least concerning. -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: PGP Signed with PineSign 2.2 iQCVAwUBMB2F0DokqlyVGmCFAQGhpgP9EIaGx3cHG78pFic0poPsgI/Yo1UNn6SY gRG9kfx3M1XzWITND5m2ywUx1B9n48hGoPfgP9ISvGoXDd5/yHgsY6uEjzZCGaLU tXzace1PvdjL5htH9prvh5GMoghCi34B9cDh01d1U2hKXEypj1pTRA+z+xWUfnGT teMJ9uEaOu0= =2aWA -----END PGP SIGNATURE----- ____ Robert A. Hayden <=> hayden(a)krypton.mankato.msus.edu \ /__ Finger for Geek Code Info <=> Finger for PGP Public Key \/ / -=-=-=-=-=- -=-=-=-=-=- \/ http://krypton.mankato.msus.edu/~hayden/Welcome.html -----BEGIN GEEK CODE BLOCK----- Version: 3.0 GED/J d-- s:++>: a-- C++(++++) ULU++ P+! L++ E---- W+(-) N++++ K+++ w--- O- M+ V-- PS++>$ PE++>$ Y++ PGP++ t- 5+++ X++ R+++>$ tv+ b+ DI+++ D+++ G++++>$ e++ h r-- y++** ------END GEEK CODE BLOCK------

3 2

Re: Set phone permit "wire" taps
by Rich Salz 17 Dec '03

17 Dec '03

Sorry to keep cluttering up the list. I'll try to make this my last message in this thread. You did not answer my request. Of course you're under no obligation to do so, but a claim like the following: >I've been arrested too amy times, an done enough local, state, and >federal time to know. Is just too hard to accept without verification. Please tell me, if not the whole list, where and when you've been incarcerated -- preferably at the federal level -- so that I can, say, call the warden and verify. >Now SHOW ME something. Sure, what? If you have more questions after looking at my homepage http://www.osf.org/~rsalz/ let me know. Or for more fun, here's my SSN: 314-15-9265. >You sure question a lotta credentials, >like you've REALLY been somewhere or done something. I don't see how these two parts relate, but I've never done anything cool like you might be thinking of. In my professional life I'm primarily a programmer who's written lots of code, and been able to give away some of it. I just think you're a fake. >Love Always, Kisses to you too, but I'm still waiting for an answer. /r$

1 0

pkzip cracking
by an264373＠anon.penet.fi 17 Dec '03

17 Dec '03

Does anyone have a utility to crack password encrypted/protected zip files? Or an address to download one? All replies / flames / pointers appreciated. Sauroth ---------------------------------------------------------------------------- To find out more about the anon service, send mail to help(a)anon.penet.fi. If you reply to this message, your message WILL be *automatically* anonymized and you are allocated an anon id. Read the help file to prevent this. Please report any problems, inappropriate use etc. to admin(a)anon.penet.fi.

1 0

Info
by Mabidex1 17 Dec '03

17 Dec '03

Hey guys, I know next to nothing on this sort of stuff, but I do have a friend that works at the phone company...I'm REALLY interested in learning the ins and outs of the trade... have any Ideas where I can start? what files I should read, etc... I would appreciate your help... Mabidex 102415.404(a)Compuserve.com

1 0

Re: Sex & Crime TV filter
by danisch＠ira.uka.de 17 Dec '03

17 Dec '03

> >However, to help derail this V-chip being mandated, what if we (I mean > >activists, writers of columns, etc.) "insisted" that _commercials_ be > >similarly labelled? > > I love it. Great idea, Tim! Someone in Germany developed a device which stops the VTR while they are showing the commercials, but it isn't available yet. Hadmut

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

Currency risk on bank accounts (Was: Zimmermann legal fund)
by stewarts＠ix.netcom.com 17 Dec '03

17 Dec '03

>> > > The US banking industry has gone to the dogs. The day a non-US bank offers >> > > an account that can be accessed over the net will be the day I close my US >> > > accounts. Some of the Channel Island banks offer accounts with ATM cards; I think some of them are in Jersey (you don't have to remind people you didn't say _New_ Jersey :-) >I open an account with U.S. $$ in a foreign bank who uses francs ... a month >later the franc loses 20 % of it's value as compared to the U.S. dollar. Happens to me all the time - I deposit my money in a dollar-based account, the dollar takes a dive relative to the Yen, so my account's worth 20% less in new Japanese cars... Most of the banks in major European banking centers and other banking-haven countries will let you have accounts in your choice of major currencies, and a number of the smaller countries have local currencies that keep parity with the US dollar or British pound. That means your account really has X US dollars in it, not X-US-dollars-converted-to-francs-on-deposit, or maybe X Bahamian dollars which are officially worth X US dollars but may be harder to withdraw quickly. There is still some risk that (for example) the Bahamas government may decide to default on its foreign debt by suddenly declaring the Bahamas dollar to no longer match US dollars, but you can only get away with that sort of thing once, so it's a desperation move, the kind of thing you do just before or after the revolution. You're more at risk from small private banks that are offering high rates of interest on foreign deposits because they're ripping off their depositors, e.g. BCCI or Nugan Hand, but that's more risk in the Caribbean than Europe (where the big risk is that they're paying you less interest than you might get in the US, or where the local tax on bank-interest may be higher than your US tax rate.) #--- # 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/

2 1

Re: punk's not dead!
by Andrew.Spring＠ping.be 17 Dec '03

17 Dec '03

>hello? i'am new on this stuff, help me! Sorry, this a mailing list for Country & Western music. -- 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.

1 0

QIK_san
by John Young 17 Dec '03

17 Dec '03

8-1-95. W$Japer: "Your Home Computer Will Soon Be Your Banker and Broker." The first on-line banking transaction will be a historic moment not unlike the first automobile sale or the first commercial airline flight. It will signal a commercially viable use of a new technology that may ultimately eliminate what until now we have considered the retail aspects of banking, stock brokerage and more. The implications are profound. The promise is electronic access to all financial transactions at substantially lower cost. One's personal computer can, in essence, become an in-home bank branch, brokerage outlet and financial planner. For example, with Intuit's software and with its union with American Express, Smith Barney and 17 large banks, consumers will be able use one link for the first time to access traditional banking, credit- and charge-card services, brokerage services, financial planning and more. The effect on the banking and brokerage business and their employees is going to be profound. The retail sales forces of banks and brokerage houses may shrink substantially, as may the ranks of financial planners. The number of bank and brokerage buildings may also shrink. QIK_san

1 0

Re: a hole in PGP
by Doug Hughes 17 Dec '03

17 Dec '03

>How is it "unscholarly, unprofessional, needlessly personal, and just >plain insulting" to question the idea that hundreds of thousands of >people are trusting their freedom to software that is probably not >secure? I think it is highly unprofessional to try to claim that PGP is >secure and to try to bolster that position by claiming that some >"Request for Comments" supports it when that same said RFC refutes it. ... ... >As far as the potential that they are working with the NSA to subvert >personal privacy, it is a potential, just as it is a potential that I am >working with the NSA to undermine confidence in PGP. The issue is and >should be, why (specifically) do you believe that PGP is secure. Here you go again. "Probably not secure". Earlier you make implications of trap doors. The only way for a trap door to be there, would be if one of the authors put it there. Otherwise, you would be suggesting that one dark night, on a new moon, the NSA snuck in to MIT, changed the source code, inserted a back door, and snuck out without anybody being the wiser. Implying there is a trap door is much different than implying there may be a flaw in the code itself that allows a security breach. I agree with Matt's assessment on your behavior Fred. Your statements lead me (among others) to believe that you think that one or more of the authors are not trustworthy and have tampered with the code to insert trap doors. His remarks on your statements being near-defamatory hit mighty close to home for this on-looker. I'm sure I'm not alone.

1 0

Provably Correct Crypto?
by Matthew James Sheppard 17 Dec '03

17 Dec '03

The shadowy figure took form and announced "I am Dr. Frederick B. Cohen and I s ay ... > > I don't accept the ability to compile it myself as evidence and I > > don't accept a summary of that source written in english prose > > The reason to believe that thttpd fulfills the claims it makes is > provided in some detail in the white paper on our server (see what's new > under http://XXX.XXX) A slightly more detailed version has been > submitted for a journal article, and hopefully will appear in a year or > two. > > [ A ton of crap which was exactly what I said I didn't want ] 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. > > 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." This sounds like performing a formal analsis to me. And you didn't address the intractability anyway. > 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 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. > > 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" -- <URL:http://www.comp.vuw.ac.nz/~matt> __________ .- __ / -- -\ __ . . . 0 / <___> ___ | =8' //\/ .^| _---_ / \ = / \ \/\ |o | = / o | | || | ... / =0=======0==| |----| |= Another drive by shooting on \_\_/ \_\_/ \_\_/ the information super highway.

2 1

Re: a hole in PGP
by Marc Horowitz 17 Dec '03

17 Dec '03

So Dr. Cohen, what do you use when you want to send a message across the Internet with better security than cleartext? What do your recommend to others? Marc

3 4

Re: Zimmermann legal fund
by nsb＠nsb.fv.com 17 Dec '03

17 Dec '03

At 12:20 PM 8/1/95 +0800, Enzo Michelangeli wrote: >Now, my main objection to opening a US account is that it's unclear >whether or not, for simply receiving payments there, a non-resident and >non-citizen account holder like myself incurs in any tax liability with >Uncle Sam's Inland Revenue. Can anybody on this list shed light on the >issue? Last time I checked, the guys at FV weren't sure either. The real question isn't based on your bank account, but on whether or not Uncle Sam thinks you are "doing business in" the US. This is the fundamentally thorny question that is raised by cyberspace businesses. Having payments made to a US bank account may make it more likely that the US will decide that you are doing so, but they could decide it anyway just because you have buyers in the US, or because you're using a US-based payment server. The laws are, to say the least, not clear on such points. As a practical matter, however, it is true that using a US account will make it easier for Uncle Sam to tax you if it decides that's appropriate. -- NB

1 0

Pat Robertson Fears E-cash?
by John Young 17 Dec '03

17 Dec '03

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?

4 4

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

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

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

Re: OS noise [Was: a hole in PGP]
by stewarts＠ix.netcom.com 17 Dec '03

17 Dec '03

>On Mon, 31 Jul 1995, Phil Fraering wrote: > >> For better or for worse, we all must use programs (or collections >> of programs) that large or larger: even if PGP could be implemented >> in 1 % of the current source code, it would still be running in an >> operating system that's cramped in 4 megabytes of ram, because that's >> a characteristic of the common modern operating systems. > >Ahem! Commiedore APOLOGIED when it released its 512K OS a couple of >years ago. These things _don't_ have to be this large. Foo. Unix used to work just fine in 64K+64K split I&D space on a PDP-11 :-) It got bigger when lots of stuff was added, especially networking and X windows, and I wouldn't want to go back to small machines. However, during one such discussion on comp.unix.wizards or wherever, Dennis Ritchie posted a nice article about "Mine is smaller than yours", saying "here's how big my OS is" (I think ~250K, and the OS was 8th or 9th Edition), "telnet over to foovax, it's this big", "datakit over to barmips, it's that big", "some other networking method over to some other machine, it's that big", "yet another protocol over to yet another bigger machine", "display size of the operating systems on my 256K Blit and Gnot terminal, etc. And QNX's kernel fits just fine inside the cache on a 486, though it wouldn't actually stay there much. #--- # 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

US vs Overseas Banks
by Duncan Frissell 17 Dec '03

17 Dec '03

At 07:05 PM 7/30/95 -0400, Lucky Green wrote: >Six years ago, you could walk into a Bank, show them your driver license, >and open an account. >Today, you need several pieces of ID. >Three years ago, you could withdraw money from your own account without >having your checkbook on you. >Today, they make you pay for a "counter check". >One year ago, you could walk into a bank an cash a check drawn onto an >account at the very same bank. >Today (Coast Federal), they make you pay a $10 check cashing fee. This depends on location. The Feds require that banks use the same ID to open an account that they would require to cash a check. The banks on the Left and Right Coasts are fairly restrictive (more restrictive than they have to be). Banks in the Heartland (particularly the Intermountain West) are much easier. With a little work, it is still possible to open accounts with "soft" ID in the more relaxed regions. Since these banks are accessible by ATM and Fedex and will soon be on the net (in some cases), they can be convenient to use. Likewise Canadian banks (which routinely offer US$ accounts). In the soft ID category, I place Employment ID and Student ID which you are free to make yourselves as well as the new secured credit cards; some of which can be obtained in spite of one's lack of existence. The latter make very good ID. >The US banking industry has gone to the dogs. The day a non-US bank offers >an account that can be accessed over the net will be the day I close my US >accounts. This will be the most interesting story of the next few years. I will be anxious to see if the new ease of "switching" money reverses the trend toward decreased financial privacy caused by the war on money laundering. DCF "If Work, Jobs, Income, and the Middle Class Dream are all over, how come more Americans and a higher proportion of Americans are now in paid employment than ever before in our history."

3 2

Re: a hole in PGP
by stewarts＠ix.netcom.com 17 Dec '03

17 Dec '03

>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 ? Not that I know of, but there were some versions with a bug in the random-input generation - I forget if that was with ~2.2 or ~2.6.0; Colin Plumb had something to do with it. I've recently acquired ViaCrypt 2.7.1 for WinDows, and one nice feature is that in addition to typing in random keystrokes, you can click your mouse in a box and wave it around to input randomness. #--- # 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

Re: a hole in PGP
by stewarts＠ix.netcom.com 17 Dec '03

17 Dec '03

> Now, my knowledge, time and resources are limited. I see that MIT >or whomever has made a program that, under test, is more secure than my >XOR 00000000 implementation. I may not fully trust them but it is better >than anything I could come out with. Foo. Clipper is better than anything I could come up with from scratch, and it's provably untrustable. (I could easily build better stuff out of existing pieces like DES and IDEA, but that's a separate issue.) Even Enigma's pretty strong, and look what it got its users... Some of Dr. Fred's distrust is well-founded. DES is also pretty good, and it's looking less and less likely that there's a secret NSA backdoor in it (other than differential cryptanalysis and maybe linear cryptanalysis), but it and IDEA and MD5 fundamentally depend on messiness and obscurity for their security (plus elimination of obvious holes.) Maybe the authors of IDEA are paid by the same space aliens who really run NSA? RSA has some provable strength to it, though it's not totally risk-free. (One Time Pads do too, and yet people manage to misunderstand and misimplement them almost as much as they mishandle keys.) If you want a provably strong cryptosystem, you could build one out of pure RSA, which would merely be painfully slow, but could be usable. Or you could build a Blum-Blum-Shub Random Number generator, and use it to generate one-time-pads (putting BBS into PGP version N+1 would be interesting...) However, the real weak point of PGP doesn't appear to be the algorithms, or the implementation (except ease-of-use issues); it's attacks on the computers themselves. TEMPEST is fun, if difficult and expensive, black-bag-jobs on keyboards are easy and effective if you're a good housebreaker, and you can always try viruses and trojan horses to distribute keystroke-stealers. I seem to remember that Dr. Fred was once a proponent of using viruses for good purposes for propagation of information or whatever? Anathema! #--- # 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

who cypherpunks
by Jonathon Fletcher 17 Dec '03

17 Dec '03

... oops. sorry folks

1 0