December 2003 - cypherpunks-legacy

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: U.S. Banks are not all that bad
by Michael Froomkin 17 Dec '03

17 Dec '03

In message <v02120d01ac4219a2e38e(a)[199.2.22.120]> Douglas Barnes writes: > ... > > I must say that I've had some absolutely amazingly bad experiences > with banks in Asia, Mexico and Central America, so I'm a skeptic > when it comes to assuming that non-US banks are light years better. The U.K. banks make the U.S. look awfully good.... > Although I have no direct experience of European banking, I do know that > the European banking industry, taken as a whole, is substantially > behind the US banking industry in automation and efficiency. Most of Oh yes oh yes oh yes...and I've banked with Lloyds on and off for 12 years... > .... -- Michael Froomkin until Aug 6: michael(a)umlaw.demon.co.uk U.Miami School of Law London, England mfroomki(a)umiami.ir.miami.edu <-- this will still find me PO Box 248087 Coral Gables, FL 33124-8087 "Rain in parts, then dry" --BBC See http://www-swiss.ai.mit.edu/6095/articles/froomkin-metaphor/text.html

1 0

Re: Commercial killers
by tcmay＠sensemedia.net 17 Dec '03

17 Dec '03

At 1:00 AM 8/1/95, Robert Hettinga wrote: >God help me, all of this reminds me of a Carl Sagan book, of all things. >One of his science fiction characters was said to have made his first >fortune by building a commercial zapping chip for VCRs. > >Butthead Astronomer, indeed... There have been _billions and billions_ of proposals for commercial zappers. (Actually, not such a saganesque number, but dozens at least.) Harry Bartholomew was telling me a year or so ago about some ideas for detecting volume changes. I think, however, the problem of distinguishing commercial from non-commercial signal is, I think, a tough one. My point earlier was not to actually do this, but to suggest that if the V-chip is to code various kinds of content, then the logic is strong for commercial content to be similarly coded. (For example, schools often show taped broadcasts...they might claim that it would be harmful and improper for children to be exposed to beer commercial during school hours...) This would gore the ox of the advertisers, so they might quietly have the whole V-chip thing killed. --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."

3 2

BOOK: "Artificial Intelligence: A Modern Approach"
by tcmay＠sensemedia.net 17 Dec '03

17 Dec '03

On a lighter note, I've recently gotten a new book, "Artificial Intelligence: A Modern Approach," by Stuart Russell and Peter Norvig, 1995, Prentice-Hall, ISBN 0-13-103805-2. In 900 pages of well laid-out text, with excellent use of typography to make finding topics easy, it seems to be a great compendium of methods loosely called "AI." AI has gotten a bad rap, perhaps deservedly after the hype of the mid-80s, but the methods are useful for various purposes. This book is focussed on "agents," and lots of code fragments are available (in Common Lisp) for actual construction of agents. Topics that relate to Cypherpunks are scattered throughout the text, including stuff on planning, provably correct designs, game theory, simulations, neural nets, belief, and ontology. Lots more stuff, too. (If I were writing a formal book review, I'd say more. But this is just a pointer, so that interested folks can check it out at their local technical bookstore or university library.) Not a lot to do with getting PGP 3.0 out the door, and not a lot to do with building remailers, but stuff I find interesting. Let a thousand flowers bloom. --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: Pat Robertson Fears E-cash?
by tcmay＠sensemedia.net 17 Dec '03

17 Dec '03

At 12:31 AM 8/2/95, John Young wrote: > 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? I didn't see this, but even if I did it's not likely the subtleties of digital cash societies would be explored. There is the "digital cash society" we fear as an Orwellian surveillance society, with all transactions recorded. This is perhaps the future Robertson fears. There is the "digital cash society" based on Chaumian schemes and untraceability, similar to a "hard cash" society without proofs of identity at every stage, and I suspect Robertson would find much to like about this. (There are also the implications which Robertson might recoil at, too. :-}) So, hearing that "Pat Robertson is warning against a digital cash society" is not too worrisome to me. I suspect he means the stuff about Big Brother tracking us and the Number of the Beast, and so on. Don't forget he came out strongly against Clipper, early on. --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

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

17 Dec '03

Things are heating up between Fred Cohen and some of the rest of the list. I don't believe MIT is in collusion with the NSA or any other government agency to deliberately weaken or cripple PGP. I base this on having dealt with some of the MIT folks, with the various source code analyses folks have done, etc. However, I think it's a perfectly *fine* idea for some group to launch a cryptanalytic attack on PGP, or an attack based on any other approaches. This is the "tiger team," or "Team B" approach to finding flaws and weaknesses. I don't take the security of PGP only on faith, though analyzing it is not my bag, as they say. Rather, I use the Popper/Bartley notions of falsifiabilty and see truth as a process, not a state. Seeing lots of source code available, independent compilations on various machines, and believing neither Zimmermann nor Atkins nor Schiller, etc., would consent to inserting back doors into PGP, I am thus led to _believe_ that PGP is probably not so affected. Doesn't mean it isn't so, but I'm not overly worried about it. Still, more studies and technical attacks (technical, not verbal) would be welcome. One of the problems we in the "civilian cryptography" sector face is that we don't have much activity in cryptanalysis. (We've talked about this several times before, before Fred Cohen joined the list, for example.) The NSA and other intelligence agencies have not only code makers, they also have code _breakers_ (such as modern ciphers are breakable, which hasn't been the case much lately, if Bamford and Kahn are to be believed). Probably entire groups whose only job is to try to break the systems devised by others. (Modern ciphers are not as prone to breakage as earlier ciphers were, for technical reasons, so I suspect the number of cryptanalysts has shrunk since the good old days when they had more successes...there may only be a small contingent left...) The lack of cryptanalysis papers at "Crypto" has been striking...I was told that the program committee considers cryptanalysis to be less important than original research. (I can see the rationale in this, as Crypto is an academic/research conference, and there are really no "engineering" crypto conferences. And cryptanalysis might not even fit into an engineering conference very well, as cryptanalysis is traditionally a sort of "hobbyist" activity--if you've read Kahn you'll know what I mean.) Crypto comes in various flavors, from hardware implementations, to number theory, to Unix/IETF sorts of standards, to digital cash, and even to statistical analysis. It is dangerous to have a "monoculture" in which one topic is the trendy one and everyone is urged to work on that (whether the "that" is PGP or Java or anything else equally trendy). Most of the activity has been on adding hooks to PGP to make it usable in other programs, or on remailers. Not as much effort has gone into proofs of validity, systems analysis, etc. (Eric Hughes and I talked about this several years ago, before the Cypherpunks group was formed...the need for "Viper"-like systems with provably correct components, especially for digital money, etc.) If folks think PGP is flawed, or deserves an independent and critical look, then this is a good project for someone. (I think several such analyses have been made, however...this doesn't make it impossible for a flaw or backdoor to exist, but at least the code has been examined by various folks. I'm personally not too worried, though this has little suasive value.) (The Monoculture of Trendy Projects. My own programming mini-project, while proceeding slowly, is of a pattern extractor and "entropy estimator" for text. Stuff like measuring patterns, examining clusterings and author-specific patterns. I'm writing it as a bunch of "critic agents" who are responsible for different areas of analysis. In SmalltalkAgents. My point? There will be those who cite the "monoculture" and scoff at anything not written in C++ for Unix boxes, or not built to be Net-aware from the gitgo, or not written as applets in Java....oh well, in Digital Walden, one marches to a different drummer. Better to program the thing I _want_ to program rather than the things I _don't_ want to program, and hence _won't_. Final note: it'll be ready for use and maybe demonstration when it's ready. And ready when it's finished, finished when it's ready.) I've long appreciated Fred Cohen's work on viruses, so it's nice to have him on the Cypherpunks list. Maybe Fred can tell us if it's really true that he was stopped by U.S. Customs and held for many hours at the Canadian border when going to or returning from a conference where he described computer viruses.... --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."

6 5

Cypherpunks Santa Cruz (CSC)
by tcmay＠sensemedia.net 17 Dec '03

17 Dec '03

About a month ago I sent out a notice suggesting that we in the greater Santa Cruz area (Monterey, Carmel, Watsonville, Soquel, Boulder Creek, even parts of Santa Clara Valley, etc.) have a get-together occasionally, as the Bay Area meetings are quite far away (and possibly getting further away if they continue meeting in San Francisco). Response was better than I'd expected, with 17 people sending me notes asking to be kept informed of the thing. I just sent out a notice to them, partly to make sure my mail addresses are accurate and well-formed, and partly to update them on the meeting time (which will be Saturday, August 26th, the last Saturday of the month, at my house in Corralitos, CA). If you got my "CSC MEETING..." message, then you need do nothing further. If you did not get it, and wish to, send me a message. If you know of others in the area who may be interested, forward them this message. This mailing list is maintained manually, in Eudora Pro, so send me English messages, or the best approximation of English you can manage. --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: The Net (short movie review)
by cwalton＠earthlink.net 17 Dec '03

17 Dec '03

At 8:11 AM 7/31/95, Sandy Sandfort wrote: > >I hope the movie is very popular. It helps us by inducing >healthy cynicism with a dash of paranoia. I've been talking with a friend for years about PGP and crypto stuff. He wasn't interested. Yesterday, he saw The Net. Now he can't wait to learn how to use it. This is a good thing. I hope it's a popular movie too. Conrad Walton | cwalton(a)earthlink.net | http://XXX.XXXXXXXXX.XXX/~XXXXXXX/ ------------------------------------------------------------------------------ Without JOY, there is no STRENGTH. Without STRENGTH, all other virtues are worthless. Edward Abbey

1 0

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

17 Dec '03

> Clever back doors are not accomplished by an obvious program > change, but rather by the subtle use of some technique that appears to > do one thing when it actually does something else. As a good example, a > subtle interation with the rest of the environment could modify the key > generation algorithm after it is loaded. Unfortunately, PGP is too > large to verify against such back doors, so I ask again: > > Why (specifically) do you think the MIT version of PGP has no > backdoors and is not subject to attacks such as the one outlined in my > previous posting? This is a good question. Subtle backdoors hidden in such a program may be difficult to find out. It might be more effective to use the PGP file format, to understand pgp as a reference implementation, and to write you own pgp compatible program where you can generate your keys etc. in the way you prefer. Hadmut

1 0

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