March 2004 - cypherpunks-legacy

chatroom conversation turing computable
by Major Variola (ret.) 18 Mar '04

18 Mar '04

http://news.scotsman.com/scitech.cfm?id=312492004

5 4

Re: chatroom conversation turing computable
by Major Variola (ret) 18 Mar '04

18 Mar '04

At 02:18 PM 3/18/04 -0500, Jack Lloyd wrote: > >The obvious next step is writing a bot that poses as an adult posing as a >kid. I think its easily (if crudely) simulated thusly: All you need is another kidbot which is 1. not controlled by the adversary 2. eventually uses keywords that trigger the adversary's kidbot. (Maybe the adversary waits for pictures before triggering?) All in all, fine AI games one can contemplate. One could also set up IRCs with kidbots and pedobots, in a highly verbal and abstract game of Spot the Feds. Robowars for counter-intel folks :-) Sounds entertaining but we are busy getting ready the little boxes that say "fear" in greek.

1 0

New remailer uses hashcash
by Steve Schear 18 Mar '04

18 Mar '04

"My remailer will only deliver postings which contain a valid hashcash token. To get your posting through you must provide a Hashcash token." http://www.panta-rhei.dyndns.org/hashcash/index.html steve --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com) Version: 6.0.605 / Virus Database: 385 - Release Date: 3/1/2004

1 0

Regulatory Malpractice
by R. A. Hettinga 18 Mar '04

18 Mar '04

<http://www.washingtontimes.com/commentary/20040317-082622-7954r.htm> The Washington Times Regulatory malpractice By Richard W. Rahn Published March 18, 2004 In today's parlance, George Washington was a victim of medical malpractice. When he became ill, he was bled by his doctors, which almost certainly hastened his death. Like Washington, the financial industry and its customers are now slowly being bled, which will be fatal for some. The "doctors" in this case are a group of politicians, tax and law enforcement officials, who are operating without the constraint of national boundaries or economic sense. People around the globe are justifiably concerned about terrorism and ordinary criminality. A certain international political class has used this anxiety to argue that since criminals and terrorists use money, all monetary movements and holdings must be monitored. Yes, it is useful to be able to trace the money trail of al Qaeda operatives. But does that mean all citizens of every country should be subject to having all their financial privacy destroyed? Furthermore, is it cost-effective to monitor almost everyone, or would both public and private law enforcement dollars be more wisely spent monitoring the activities of those individuals or groups known or strongly suspected of engaging in terrorist or criminal activities? The problem is there are now literally dozens of organizations issuing rules and regulations that apply not only to financial institutions but to all "money service providers," including such activities as pawn shops, used car dealers and real estate agents. The agencies within the U.S. government issuing the new financial rules and regulations include the Internal Revenue Service, the FBI, the Justice Department, the Financial Crimes Enforcement Network (FinCen) and the Federal Reserve. In addition, U.S. financial institutions and other businesses engaged in operations outside the U.S. or those involved in international transactions are also faced with a barrage of new rules and regulations from many foreign governments, plus the European Union, and from international institutions such as the Organization for Economic Cooperation and Development (OECD), the Financial Action Task Force (FATF) and the U.N. Millions of businesses are subject to at least some of these rules and regulations, and it is close to impossible to inform them of their obligations. Even the largest international banks, with huge staffs of lawyers and anticrime enforcement personnel, are unable to fully work through this ever-expanding morass of regulation. Smaller banks and businesses are at a competitive disadvantage because of the disproportionate effect of these regulatory costs. Some of the regulators are aiming at terrorists, others at ordinary criminals, and some at tax avoiders or evaders. Most of the regulations are directed at "money launderers," even though the term has a very elastic definition. Many of these new rules and regulations are overlapping, some are contradictory, some violate basic civil liberties and many are costly to administer and do not meet reasonable cost-benefit tests. Yet the Bush administration just announced a doubling in the budget for FinCen, as well as budget increases for many of the other financial rulemaking bodies. The reason we should care is that all of these extra, and in many cases totally unnecessary, costs are passed along to consumers of financial services as higher fees and more expensive and fewer choices in financial products. This directly translates into job losses not only in financial industries but in all businesses that rely on some outside financing. In addition, it will make it more difficult for low-income people, the young and recent immigrants to open bank accounts. We are now seeing, for the first time in our nation's history, a rise in the portion of our citizens without banking relationships. Costly regulations that force more people into the cash economy not only make life more dangerous for those who cannot open bank accounts, but also have the perverse effect of making it more difficult for law enforcement to trace funds of criminals. There is little evidence all the new rules and paperwork are having any appreciable effect on crime or terrorism, because there is an almost infinite number of ways to "launder" money, and organized terrorists and criminals can almost always find ways around the regulations. On the other hand, there is considerable evidence of damage to our pocketbooks and civil liberties from these regulations. The U.S. government should expand the jurisdiction of the "Office of Information and Regulatory Affairs" (OIRA) to include the IRS and the other financial and law enforcement agencies that issue financial regulations, and insist financial regulations meet strict cost-benefit and civil liberties' tests. In addition, an international organization is needed to apply the same strict cost-benefit and civil liberties' tests to all proposed regulations emanating from international bodies like the OECD, FATF, and the U.N., as well as those from governments that affect nonresident institutions. If financial institutions and their customers are weakened or bled to death by regulatory malpractice, the war against real criminals and terrorists will only be made more difficult. Richard W. Rahn is a senior fellow of the Discovery Institute and an adjunct scholar of the Cato Institute. -- ----------------- R. A. Hettinga <mailto: rah(a)ibuc.com> The Internet Bearer Underwriting Corporation <http://www.ibuc.com/> 44 Farquhar Street, Boston, MA 02131 USA "... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

1 0

Re: Saving Opportunistic Encryption
by Bill Stewart 18 Mar '04

18 Mar '04

The simplest way to get half-safe opportunistic encryption is the "Open Secret" shared secret, or equivalently, draft-ietf-ipsec-internet-key-00.txt's shared secret. Everybody who wants to use it just adds it to their ipsec's list of known shared secrets, and uses it unless something better is available. It doesn't pretend to be MITM-proof, but it's a start. Doing the whole job correctly is much harder, which is why Gilmore's do-the-job-correctly-or-bust project didn't achieve the "encrypting X% of the net by Christmas", where X>1 and Christmas < 2010. (This doesn't count the VPN market, which is what got the commercial support, even if many of the vendors used FreeS/WAN code, and it's a much easier problem even if ISAKMP/Oakley is a hard way to do something easy.) Forward DNS support is widely available, because anybody out there who doesn't want to run their own DNS can find a friendly DNS provider who'll sell them a subdomain they can use, e.g. joecypherpunk.FriendlyDnsProvider.net, and they can even do DNSSEC support (though obviously you can't walk the whole tree unless the roots are signed.) No ISP support needed. Reverse DNS support was pretty much a non-starter, because most ISPs don't give the user control over their reverse DNS space even if they bother to implement it at all. They're getting better, but you're still usually port123.box456.sfo.example.net, and forget getting DNSSEC support. You *could* make it work by building a separate Reverse DNS tree, like D.B.C.A.opportunistic-encryption.org, instead of hanging it off D.B.C.A.in-addr.arpa. You'd still have to get people to populate it, and make it scalable and DDOS-proof, but perhaps you could do it. Reverse DNS also has the problem that it's _not_ a 1:1 matching - a given IP address may have many virtual hosts on it, and therefore many domain names, and the domain names can be different for email vs. web vs. other protocols. So it can only work on a subset of the application space, even if you've got the control you need. Of course, forward DNS isn't really what you want, and reverse DNS mostly is, because there isn't a user interface to your IPSEC interface or routing tables, especially if the IPSEC box is some security gateway that the end user doesn't even have access to, so unless you want to invent some other protocol (not ISAKMP/Oakley/etc.) to seed the IPSEC Security Associations, all you've got to work with is the IP address of a destination, not a name. It's possible to play hackish workarounds that have the DNS server opportunistically fetch DNSSEC information, with the assumption that most people only talk to IP addresses that they got from DNS lookups, and it even has the performance advantage that you can do the fetch before you send out any TCP or UDP packets to the destination instead of stalling and risking timeouts. They're not hugely reliable, but they're a start, especially if you're going to fall back to "Open Secret". They're mainly useful for machines that are doing their own IPSEC encryption, rather than using some IPSEC gateway/firewall box - otherwise you need to build dodgy configurations like running the DNS server on the IPSEC gateway and making sure DNS caching and IPSEC SA caching times are compatible. Also, working at this level means you're not just hacking the kernel, or the kernel plus some helper daemons - you're hacking BIND and its competitors, and suddenly you become responsible for maintaining them :-) Another approach is to invent a whole new protocol, separate from ISAKMP/Oakley/SKIP/etc., which does a handshake to fetch keys. It either has to hit a server at the destination's IP address, implying a need for firewall transparency and compatible address spaces (probably works better for transport mode than tunnel mode?), or else have some mechanism for finding a key+config server. Hugh Daniel suggested rehabilitating Finger as the end-system protocol (after all, we've long since patched the security bugs that the Morris worm used back in 1988). If you're building a non-end-to-end mechanism that uses IP addresses as its lookup, you're getting awfully close to reinventing Reverse DNS, or else building some other vast coordinated effort with half-vast goals. On the other hand, if you're patching half of ISAKMP/Oakley anyway, might as well patch Photuris, which is much smaller, lighter, and more correct. Bill Stewart ---- Bill Stewart bill.stewart(a)pobox.com

1 0

Mac OS X and the Power Mac G5 Tech Talk Invitation
by Apple Developer Connection 18 Mar '04

18 Mar '04

============================================================ Mac OS X and the Power Mac G5 Tech Talk Invitation Tuesday: 20 March, 2004 Cambridge, Massachusetts <http://techtalk.apple.com/?Event=MacOSXCambridge042004TT> ============================================================ Dear Developer, The Apple Developer Connection is pleased to invite you to a "Mac OS X and the Power Mac G5" Tech Talk, Tuesday, April 20th at the Harvard University Science Center. This event is aimed at developers who want to better understand how to port their code to Mac OS X and exploit the horsepower provided by the Power Mac G5. Don't miss this opportunity to learn more about the latest technologies in Mac OS X and how to take advantage of them in your application. ------------------------------ TECH TALK CONTENT ------------------------------ During the Tech Talk, Apple technology evangelists will explore the powerful technologies designed to take the Macintosh platform through the next decade. Agenda topics will include: - Mac OS X Panther Technology Update: A walk-through of the modular system architecture of Mac OS X, explaining the latest developments in each of the major component layers in the OS. The focus of this presentation is on porting existing code to Mac OS X. - The Power Mac G5 in Depth: A discussion of the new Power Mac G5, focusing on technical specifications, the PowerPC G5 architecture, and optimization techniques for achieving maximum performance. - Xcode Tools Overview: A walk-through of the Xcode IDE and Apple's suite of robust performance tools that ship with every Power Mac G5. ------------------------------ DATE AND LOCATION ------------------------------ Mac OS X and the Power Mac G5 Tech Talk Cambridge, MA Tuesday, April 20, 2004 5:30pm Registration 6:00pm-9:00pm Presentations Harvard University Science Center Lecture Hall A, 1 Oxford Street Cambridge, MA. ------------------------------ REGISTRATION INFORMATION ------------------------------ There is no enrollment fee required for participation in this Tech Talk. You must assume your own travel and hotel expenses. Seating is limited and registration is taken on a first-come, first-served basis. We expect this Tech Talk to be very popular, so we encourage you to reserve your space immediately by filling out the registration information at <http://techtalk.apple.com/?Event=MacOSXCambridge042004TT> Upon receipt of your reservation, if space is available you will receive a confirmation email with further details and lodging options. You are not guaranteed a place without this confirmation. If you have any questions, please contact us at <techtalk(a)apple.com>. We look forward to seeing you at the Tech Talk! Best regards, Apple Developer Connection ____________________________________________________________________ You are receiving this invitation because you are an ADC Member who has agreed to receive Technical or Marketing information from the Apple Developer Connection. Your information has not been shared with any third parties. Questions about your ADC membership? Please contact us at <developer.apple.com/contact/programs.html>. ____________________________________________________________________ --- end forwarded text -- ----------------- R. A. Hettinga <mailto: rah(a)ibuc.com> The Internet Bearer Underwriting Corporation <http://www.ibuc.com/> 44 Farquhar Street, Boston, MA 02131 USA "... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

1 0

Mac OS X and the Power Mac G5 Tech Talk Invitation
by Apple Developer Connection 18 Mar '04

18 Mar '04

============================================================ Mac OS X and the Power Mac G5 Tech Talk Invitation Tuesday: 20 March, 2004 Cambridge, Massachusetts <http://techtalk.apple.com/?Event=MacOSXCambridge042004TT> ============================================================ Dear Developer, The Apple Developer Connection is pleased to invite you to a "Mac OS X and the Power Mac G5" Tech Talk, Tuesday, April 20th at the Harvard University Science Center. This event is aimed at developers who want to better understand how to port their code to Mac OS X and exploit the horsepower provided by the Power Mac G5. Don't miss this opportunity to learn more about the latest technologies in Mac OS X and how to take advantage of them in your application. ------------------------------ TECH TALK CONTENT ------------------------------ During the Tech Talk, Apple technology evangelists will explore the powerful technologies designed to take the Macintosh platform through the next decade. Agenda topics will include: - Mac OS X Panther Technology Update: A walk-through of the modular system architecture of Mac OS X, explaining the latest developments in each of the major component layers in the OS. The focus of this presentation is on porting existing code to Mac OS X. - The Power Mac G5 in Depth: A discussion of the new Power Mac G5, focusing on technical specifications, the PowerPC G5 architecture, and optimization techniques for achieving maximum performance. - Xcode Tools Overview: A walk-through of the Xcode IDE and Apple's suite of robust performance tools that ship with every Power Mac G5. ------------------------------ DATE AND LOCATION ------------------------------ Mac OS X and the Power Mac G5 Tech Talk Cambridge, MA Tuesday, April 20, 2004 5:30pm Registration 6:00pm-9:00pm Presentations Harvard University Science Center Lecture Hall A, 1 Oxford Street Cambridge, MA. ------------------------------ REGISTRATION INFORMATION ------------------------------ There is no enrollment fee required for participation in this Tech Talk. You must assume your own travel and hotel expenses. Seating is limited and registration is taken on a first-come, first-served basis. We expect this Tech Talk to be very popular, so we encourage you to reserve your space immediately by filling out the registration information at <http://techtalk.apple.com/?Event=MacOSXCambridge042004TT> Upon receipt of your reservation, if space is available you will receive a confirmation email with further details and lodging options. You are not guaranteed a place without this confirmation. If you have any questions, please contact us at <techtalk(a)apple.com>. We look forward to seeing you at the Tech Talk! Best regards, Apple Developer Connection ____________________________________________________________________ You are receiving this invitation because you are an ADC Member who has agreed to receive Technical or Marketing information from the Apple Developer Connection. Your information has not been shared with any third parties. Questions about your ADC membership? Please contact us at <developer.apple.com/contact/programs.html>. ____________________________________________________________________ --- end forwarded text -- ----------------- R. A. Hettinga <mailto: rah(a)ibuc.com> The Internet Bearer Underwriting Corporation <http://www.ibuc.com/> 44 Farquhar Street, Boston, MA 02131 USA "... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

1 0

Mac OS X and the Power Mac G5 Tech Talk Invitation
by R. A. Hettinga 18 Mar '04

18 Mar '04

--- begin forwarded text

1 0

[p2p-hackers] CFP: Workshop on Privacy in the Electronic Society (fwd from decapita@dti.unimi.it)
by Eugen Leitl 17 Mar '04

17 Mar '04

----- Forwarded message from Sabrina De Capitani di Vimercati <decapita(a)dti.unimi.it> -----

1 0

Re: Saving Opportunistic Encryption
by Eugen Leitl 17 Mar '04

17 Mar '04

On Wed, Mar 17, 2004 at 03:09:54PM +0000, petard wrote: > There's a well-supported extension for that: http://enigmail.mozdev.org/ > Actually, plans are in the works to make S/MIME an extension as well, so > the two will soon be on equal footing. PGP/GPG has failed to protect the bulf of email for same reason as FreeS/WAN failed to protect the bulk of TCP/IP traffic. In comparison, opportunistic encryption via StartTLS has been a modest success, simply because it's so easy to deploy at MTA level (it would be a lot more successfull, if postfix/exim/qmail shipped with working StartTLS, or at least apt-get install yourMTAhere-tls would set up the certs and config properly). Purists would scoff that plaintext is default fallback, hence initial key setup easily disruptable, and MITM, and whatnot. However, if keys are cached, key changes and sudden reverts to plain for known hosts are logged, and key fingerprints for hosts crosscorellated, potential meddling becomes far easier to detect, and if only after the fact. Passive taps are easy, stealthy active traffic manipulation, on a large scale? Could as well look out for fecal precipitation from porcine aviation. Should it happen, upgrading to a web of trust is always an option. -- Eugen* Leitl <a href="http://leitl.org">leitl</a> ______________________________________________________________ ICBM: 48.07078, 11.61144 http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE http://moleculardevices.org http://nanomachines.net [demime 1.01d removed an attachment of type application/pgp-signature]

1 0