Once upon a time (1998) I prototyped a P2P system based on two simple ideas:
Once upon a time (1998) I prototyped a P2P system based on two simple ideas:
The possibilities inherent in this architecture were, and are, astonishing. Since it was a Web-style system, it was obvious -- yet still somehow surprising -- that applications could display anywhere. Less obvious was the ease with which I could make data, and even code, replicate. And all that before I implemented the notion of local proxies, which could intercept and act on browser-initiated connections to remote nodes.
Although there are a million reasons to use proxies, the one that motivated me was security. I wanted to see if I could encrypt the connection to a remote node, and I wanted to do it without having to implement SSL in my tiny HTTP listener. Today, I'd probably just use stunnel. But then, as an exercise, I added Blowfish encryption between nodes, as described in a section of my book. When it came time to post the sample software for the book, though, I removed the Blowfish implementation and substituted a non-cryptographic transformation. Why? I didn't understand the export regulations, but suspected there could be problems.
Times haven't changed much. Ray Ozzie recently called attention to the controversy of AOL's withdrawal of Nullsoft's WASTE.
...let's say that AOL really does regard this as proprietary software, as its web page now seems to imply, and that the shadowy Dick Pumpaloaf didn't just write the doc ... he indeed posted Justin's code without AOL's consent. Then AOL would have had to apply for an export license, which takes many many months for a technical review and, in our experience takes on average about six months just for renewals or major version modifications. [Ray Ozzie's weblog]
A bit of explanation is in order here. The source distribution of the WASTE P2P system included a Word file describing WASTE's architecture. (Apparently the acronym refers to the underground postal system in Thomas Pynchon's The Crying of Lot 49.) The file's author property is Dick Pumpaloaf, whose name was, as I wrote this, a googlewhack. The Last-Saved-By property is, however, Justin Frankel, the subject of this sensational Yahoo! News headline: Rogue AOL Subsidiary Leader to Resign.
I have, of course, destroyed any and all copies of the Software, including by deleting it from my computer, as per instructions. While investigating it, though, I was reminded of my own experiments with encryption and proxying. After establishing a private WASTE network behind my NAT, I took one of the nodes to a separate Internet-connected subnet, after punching a hole in the first subnet's NAT for port 1337, and connected back into the network. Then I created a new node on the outside network, and introduced it to the original outside node (by exchanging public keys). Now both nodes were visible to everybody on the inside network. WASTE nodes are routers; public keys are broadcast; nodes accept broadcast public keys by default. There isn't complete firewall/NAT transparency, but so long as any member of a private network is world-visible, it seems that way.
Ad-hoc and administratorless VPNs are the name of this game. It's what Groove does, and what other tools -- including WASTE and its successors -- will also do. For a long time, RSA's patent and trademark claims impeded a lot of the innovation that should have been happening in this area. Now, as Ray points out, there's still the export-regulation impediment, and ignoring it doesn't make it go away. I'm glad Ray's shining a light on this issue.
Let me see if I understand correctly. Take Winfosec for example. The company offers SIMP, a secure IM tool, and makes the source freely available. It is therefore subject to a notification requirement, which boils down to sending mail to crypt@bis.doc.gov, enc@ncsc.mil, and web_site@bis.doc.gov. OK. That's easy enough for Winfosec to have done.
There's also, Ray says, "an affirmative obligation to use efforts to block the 'rogue nations." Hence this Winfosec warning:
WARNING: You may not download SIMP or its source code if you are a resident of Cuba, Iran, Iraq, Libya, North Korea, Syria, or Sudan.
Notice: SIMP contains strong encryption, which is classified as a munition in the United States. If you live in the US and plan to redistribute either SIMP or its source code, you may be required to notify the US Bureau of Export Administration (BXA).
I see similar language at groove.net:
The software you are about to download contains restricted cryptographic functionality subject to U.S. export control law. You may not download this software if you are located in Cuba, Iran, Iraq (for some purposes), Libya, North Korea, Syria, or the Sudan. U.S. export control law forbids the export or re-export of this software to any destination in any of theses countries or to any person on the U.S. Department of Commerce's list of denied persons or entities or the U.S. Treasury Department's master list of Specially Designated Nationals and Blocked Persons. By downloading this software, you agree that you will not transfer it to any destination in (or to a national of) any of the countries listed above or to any person or entity on a U.S. denial list, and that you will comply with all import regulations imposed by jurisdictions other than the United States.
That also seems straightforward enough. But terrorists aren't any likelier to be stopped by such notices than are teenagers when confronted with "You Must Be Over 18" entry pages. Are Winfosec, or Groove, or others expected to do more? For example, to try to block specific ISPs or IP address ranges?
That would be quixotic anyway, for the very reason that WASTE demonstrates: the protean power of proxies. And of course the government can't come right out and say that. So it seems we'll continue to muddle along, trying to do the right thing, but worrying (some more than others) that we've done the wrong thing. I wish we could dispel this cloud of confusion and guilt that surrounds cryptographic software, and just get on with it. There's a ton of vital experimentation and innovation that still needs to occur.
Former URL: http://weblog.infoworld.com/udell/2003/06/11.html#a719