December 2003 - cypherpunks-legacy

Dallas Morning News article
by Phil Karn 17 Dec '03

17 Dec '03

Dallas Morning News, July 23, 1994, Page 5F Cryptography tests rights of electronic word Tom Steinert-Threlkeld Cybertalk The electronic word appears to have fewer rights than the printed word. At least that could be the conclusion drawn from an unusual case emerging from the Bureau of Politico-Military Affairs in the U.S. State Department's Office of Defense Trade Controls. There, a book about encryption techniques has won an export license, but a computer disk containing the same information has not. The book in question is titled "Applied Cryptography", an attempt by data security consultant Bruce Schneier to translate 20 years of academic research in scrambling computer traffic "into terms understandable by mere mortals." In so doing, Mr. Schneier hopes to do "more to further the spread of cryptography around the globe than any single (encryption) product could." So far, his publishers, John Wiley & Sons, believe the 600-page tome has been doing almost that. Since its release in November, almost 15,000 copies of the book have been sold. Of that, between 1,500 and 2,000 have been to programmers and other interested parties abroad. Those foreign sales are possible because the book did not have to get an export license. Such controls are used by the State Department to guard against the spread of cryptographic methods that could be too difficult to break, posing a threat to national security. The book contains what Mr. Schneier estimates is about 100 pages of algorithms, hash functions and other lines of computer code that can be used to encrypt messages. But the Office of Defense Trade Controls in March rendered the opinion that the book "is not subject to the licensing jurisdiction of the Department of State since the item is in the public domain." No so with two disks containing the same "source" code. In a May 11 letter, office director William B. Robinson designated the disks as an article "under category XIII(b)(1) of the United States Munitions List." As such, the author would require an export license for the disks. The code itself was not a finished product. It would have to be "compiled" into an executable program before it actually could be used to disguise any data on a computer network. The code was also exactly the same as appeared in the book, or at least as nearly as possible, given the transfer to a magnetic disk. But that appeared to be enough of a difference for the State Department. Mr. Robinson stated, "The text files on the subject disk are not an exact representation of what is found in 'Applied Cryptography'. Each source code listing...has the capability of being easily compiled into an executable subroutine." A State Department official Friday translated the distinction this way: "The difference with the code in the book is you have to type it all in and correct all the errors" before it is usable by a computer programmer. The "value added" by putting the code on the disk is that it is already typed in. "That was the determination we made", the official said. Practically speaking, the distinction escapes the author, Mr. Schneier. Once one overseas programmer types in the code and corrects the errors, hundreds of copies can be easily made and shipped to any country. For the programmer who is too lazy to type, the book's pages even can be scanned in. "What do we think? Foreigners can't type? Or is the worldwide scanning industry influencing this decision?" he asks. Others see larger, constitutional questions. "They're trying to say electronic words have less protection than written words," said David Banisar, policy analyst with the Electronic Privacy Information Center in Washington, D.C. "That's not a proposition that I think any court will support." As more and more words -- from book, magazine and newspaper publishers, for instance -- become electronic, the issue could become critical. "When all words are electronic, they won't be able to be protected under the First Amendment" if this difference between words on a paper medium and words on a digital medium gains footing, he said. Phil Karn, an engineer and ally of Mr. Schneier, however, is appealing the stand on the disks. The State Department's view also is not the final law of the land. "It seems like kind of a foolish distinction and one which in any case is ultimately doomed to failure," said Internet Society executive director Anthony Rutkowski. The different rulings on the book and the disk are "utterly stupid, but that's the way bureaucracies work." Mr. Robinson and the trade control office's deputy director, Rose Brancaniello, declined to comment. Another officer, Tom Denner, said comment was prohibited by confidentiality provisions contained in section 38(e) of the Arms Export Control Act. ------ CyberTalk appears every other Saturday, discussing people, places and problems populating the world of computer communications known as cyberspace. Tom Steinert-Threlkeld can be reached at the Internet address, tomhyphen(a)onramp.net; at America Online, tomhyphen; or at Prodigy, trfj19a.

1 0

Re: e$: Cypherpunks Sell Concepts
by rah＠shipwright.com 17 Dec '03

17 Dec '03

At 5:41 PM 8/6/94 -0700, Eric Hughes wrote: >The obstacles are certainly not for electronic money, which the Fed's >been using for some time now, but rather for electronic cash, which >includes anonymity. We've chased each other around a tree like this one before... Let's see what the differences are this time. I've been doing some thinking about this... Anonymity can come out of retail settlement of e$, if the transactions aren't tracked. We've talked here before about how you think that the tracking of those transactions at the retail level is pretty trivial, so the cost to the user of traceable e$ may be meaningless. I'm not so sure that that's the case, and I think (I hope!) I remember Perry agreeing with me on that point. But if we fiat the argument just to see where it takes us, we come to the sheer volume of transaction records themselves. Is it possible to accurately estimate the cash transaction load of an economy? I bet that if we could, you'd see that the data from each transaction would cause the problem news servers have by several orders of magnitude. The information would get dumped pretty frequently. This is probably the same problem the NSA has now picking out signals to listen in on, but running down an audit trail is different, it's a historical process. Since you don't know whose transactions you need, you need to keep them all. True, this doesn't keep TLAs from trying trying to drink from a firehose, or more to the point, to free-dive to the bottom of the Marianas Trench (if they could keep all of the data), or high-dive into a wading pool (if they couldn't). Hmmm... >The USA provides a fair amount of financial >privacy to everyone but the government, particularly law enforcement. >So the _business_ case for privacy is largely felt to be already >satisfied by the regulators. When *every* business transaction can be scrutinized (as much as physically possible, per above) at any time, for any reason the government deems necessary, it makes a sizable business case *for* traceable electronic cash. This is probably the place to put the lever on the business community. >The Treasury department, among others, really _doesn't_ want >non-recorded transactions. Unless the banking community as a united >front _does_, I don't think it will happen domestically (USA) before >other deployments. If there's not a united front, it'll be divide and >conquer. Non-recorded transactions exist already. It's keeping them from dissapearing that we're really talking about here. It's quite possible to get banks to present a united front. They have one of the largest lobbies in Washington. They have fought reporting requirements tooth and nail with some considerable success, but every time they get greedy (S&Ls) the noose tightens. It might be the threat of international deployment and regulatory arbitrage which brings them around, and fires up the lobbying apparatus on our side of the issue. It has worked before (gold, et.al.). On the other hand if those reporting requirements are frictionless, they don't *need* to fight it, do they... It's time to leave the ring. Somebody tag me. My brain hurts... Now to plug the topic of the thread a bit, how receptive would people in the crypto community be to participating in an annual dog&pony/schmoozefest for the suits? Who should chair the morning "primer" session? *E-mail* me with your ideas, everyone. Thanks, Robert Hettinga ----------------- Robert Hettinga (rah(a)shipwright.com) "There is no difference between someone Shipwright Development Corporation who eats too little and sees Heaven and 44 Farquhar Street someone who drinks too much and sees Boston, MA 02331 USA snakes." -- Bertrand Russell (617) 323-7923

4 3

Re: e$: Cypherpunks Sell Concepts
by rah＠shipwright.com 17 Dec '03

17 Dec '03

At 7:09 PM 8/6/94 -0700, Hal wrote: >There are two legal problems that I could see being used against digital >cash. The first is the civil war era prohibition on banks issuing private >bank notes. Where you stand on this one depends on where you sit. ;-). It seems to me that one could just as easily treat digicash as securities denominated in dollars, just like shares in a money market mutual fund, or more to the point, the actual money market instruments, repos, for instance. It's going to take a sophistical titan to get this through the courts, but if there's a market for digicash, hey, it can happen. It won't happen if this titan's employers never hear about it, though. >The second problem is the regulation of "scrip" and barter systems. This >was pointed out on the list last year by someone who had actually been >involved in a private barter or scrip system which was shut down by the >government, at great cost to all concerned. These regulations can be >found at 26 CFR 1.6045-1. From subsection (f)(5)(ii), "Scrip is a token >issued by the barter exchange that is transferable from one member or >client, of the barter exchange to another member or client, or to the >barter exchange, in payment for property or services". I think this one >will eventually get the "NetBank" people in trouble. (You call a 900 >number and in exchange for a charge on your phone bill they give you a >digital token you can exchange for property or services by participating >merchants.) Barter exchanges are required to get the names and SS numbers >of all participants and report their transactions to the IRS. This would >be inconsistent with the privacy we seek from ecash. Indeed. This is probably where we have a problem. The only thing I can think of here is that the technology of the internet and it's limitless opportunity for regulatory arbitrage. When you make the possession of a medium of exchange illegal you get the same problems that all closed economies have. With the internet, enforcement is half next to useless (an expression I picked up in Albuquerque a while back...). Like I said to Eric in the last post, it may be the threat of regulatory arbitrage that wins the day here, like it has in the past. To plug the thread a bit here, who should chair the afternoon business-heavy session? *Email* me your suggestions, please... Cheers, Robert Hettinga ----------------- Robert Hettinga (rah(a)shipwright.com) "There is no difference between someone Shipwright Development Corporation who eats too little and sees Heaven and 44 Farquhar Street someone who drinks too much and sees Boston, MA 02331 USA snakes." -- Bertrand Russell (617) 323-7923

3 3

Cyphers Out There?
by an114＠vox.hacktic.nl 17 Dec '03

17 Dec '03

:: Encrypted: PGP -----BEGIN PGP MESSAGE----- Version: 2.6 hEwCTL2DNtw2i0EBAf4joQKrL2wlyfeRCIHGKaIlSnDhfNdSJ3+MPylu1fix0TIr E//Iw3Z9H2rdbVkJ4gyMQrE7kZzpquyys5ia4031pgAAAjb/CvnS8B2ZX0gpx+dh 8+7dS7i0vbwOePbd/6RIMaemyQhc98npIqQqWodr7z4a+hPp9PyBw5tVPa9N29CF 5b/X50eaeK9vuUVAp1qAB247LsqmQ+nWlFtVXlcy2M3AqZFG0KwvGCg1FLcrSIKj 4gEbp+qD42cetTBe3HFY45Xie1tcEVrTblpibIKZ41NgKcGdRJ8s+ivv/tKu+bDh pftPmiJjqIM1hpOtDqAQvlocP/j4RmxrZFCkdtmczAOKPhG0F6B4tmW/GKY7Kfdk 7vfhrMF6+8sAQSXLSp8xSCpjSGT/RsZKRNOLFK8E6QGCk5MToV5FBtCUd7sVSY7H t+GEsVT4KgLq1jdGGwrsegB99K4ttQ0rYxPn5xQUgUNt6ekOK3v2mfUHQbuY2rdf OTN+RHGRiFI8oplVYVUQGo0q/Ghl7P56TSxVZTHTrxRbFDc/xcnflQHsrVHS/9KC xxP3xuZTrCJaXrZEi8xZ2h/gyQB7xT7VdNvFm4KpFapkt9UP510+4YmyN06SSMq7 zSX4lmcihnf1FGt0A3Q5KOjUjzXz4V4xD9BYtC2Tg+Bp+QtVfJTVhSJ8u8tGs0cB LMSHkj5H2RocbhMhpnmm5Lqnwp+UgUWbH2cVNnx51DbAlOt1NrwetjXs75YZbtfw JBgLj2AOfAi5txky+4xZx/S2uSyrwe0OSFTsBXoSonSSRMjkBPjJ/H0d1XU715oN RSxlTlFIlS8GnUlaiq+eYhHp3sbZILS57A== =YwyP -----END PGP MESSAGE----- -------------------------------------------------------------------------- To find out more about the anon service, send mail to help(a)vox.hacktic.nl Please report any problems, inappropriate use etc. to admin(a)vox.hacktic.nl Direct replies to the sender of this message are -not- anonymised <YuK>

1 0

RE: (none)
by Jeff Gostin 17 Dec '03

17 Dec '03

Blanc Weber <blancw(a)microsoft.com> writes: > I really meant to ask 'where cypherpunks'. It had been a whole day & > more without the hordes messages and my day seemed empty, without code > or purpose, lacking controversy & jibber jabber. Actually, my response was more of a joke... More than a few people commented on the fact that WHO CYPHERPUNKS is the 'domo command to get a list of subscribers. Your name looked familiar from the list, so I decided to gamble a joke. Guess the joke's on me, eh? :-) --Jeff -- ====== ====== +----------------jgostin(a)eternal.pha.pa.us----------------+ == == | The new, improved, environmentally safe, bigger, better,| == == -= | faster, hypo-allergenic, AND politically correct .sig. | ==== ====== | Now with a new fresh lemon scent! | PGP Key Available +---------------------------------------------------------+

1 0

Re: RemailerNet
by jdd＠aiki.demon.co.uk 17 Dec '03

17 Dec '03

In message <9408062108.AA18761(a)snark.imsi.com> perry(a)imsi.com writes: > > Jim Dixon says: > > You can send from a very large network and forge your TCP/IP or > > (more difficult) Ethernet source address. But I can sit on the same > > network, build a table relating TCP/IP to ethernet (or whatever) > > addresses, and filter out messages that should not be there. There > > are commerical packages that do this sort of thing. > > Huh? > > If you are sitting on a network in England, which you appear to be, I > defy you to record anything at all about the ethernet addresses of the > machines that originated this message. [etc] Forgive my casual use of the English language. "A may send from a very large network and forge his or her TCP/IP or Ethernet source address. But if B is on the same network, he or she can build a table ..." The size of the source network is related to the difficulty of determining which machine is forging addresses. If you are ... sorry, one is on a large network, forgery without detection is much easier. Assuming idiocy on the part of correspondents may make for easy and fast responses, but it injects an undue amount of noise. -- Jim Dixon

1 0

Re: Latency vs. Reordering (Was: Remailer ideas (Was: Re: Latency vs. Reordering))
by jdd＠aiki.demon.co.uk 17 Dec '03

17 Dec '03

In message <9408070005.AA17290(a)ah.com> Eric Hughes writes: > In a system that is carrying continuous traffic, random packet delay > is functionally identical to packet reordering. > > OK. Prove it. Here are some difficulties I expect you'll find along > the way. > > First, "continuous traffic" is the wrong assumption; some sort of > multiple Poisson distribution for arrival times is. Sigh. I say "A implies B". You say, "not A, and so proposition is incorrect". In elementary logic, you are wrong. IF the traffic is continuous, THEN random delays introduce reordering. The proposition is completely obvious. Do I really have to spell out a trivial proof? > This is by no > means a hypothetical. The backoff algorithms for TCP had to be > developed because packet streams are not continuous, but bursty. Under this modified assumption, you must remember that I proposed that noise packets be introduced to defeat traffic analysis. The bursts will be smoothed out. Not perfectly. Many of the characteristics of TCP/IP derive from its design being optimized for speed. RemailerNet would give less importance to speed, and more importance to opaqueness to traffic analysis. [snip] > Fourth, the problem is incompletely specified, since the distribution > of random added latencies is not made specific. Correct. You assume details that have not been specified, and then critique them at length. > If messages are fragmented, random delays on sending packets out is > functionally identical to reordering. > > This is false; a system that concentrates on reordering has provably > better average latency that one based only on adding latencies. If a message is fragmented into N packets, and then the dispatch time slot for each packet is assigned randomly, the packets are reordered. [Comments deleted ignore the fact that messages are fragmented, and so are irrelevant.] His arguments also ignore the fact that reordering messages of different lengths is useless as a defense against traffic analysis, suggesting that this is polemic rather than a serious argument. > More importantly, RemailerNet as described defeats traffic analysis by > more significant techniques than reordering. Reordering is a weak > technique. > > WHAT?? > > Anyone else listening to this: I believe the above quoted two > sentences to be distilled snake oil. I say again: reordering is not weak, it is irrelevant if messages are of signficantly different lengths and are not fragmented. > The introduction of noise, 'MIRV'ing of messages, > fragmentation of messages, random choice of packet routes, and > encyphering of all traffic are stronger techniques. > > Encyphering is necessary. Reordering of quanta is necessary. > > "MIRV" messages may actually decrease security; multiple routes may > decrease security; fragmentation may decrease security. Noise > messages may not be resource effective. > All the above claims require > some justification, and I have seen nothing robust yet. If by "the above claims" you mean the preceding two sentences, I do agree. -- +-----------------------------------+--------------------------------------+ | Jim Dixon<jdd(a)aiki.demon.co.uk> | Compuserve: 100114,1027 | |AIKI Parallel Systems Ltd + parallel processing hardware & software design| | voice +44 272 291 316 | fax +44 272 272 015 | +-----------------------------------+--------------------------------------+

1 0

Re: Latency vs. Reordering (Was: Remailer ideas (Was: Re: Latency vs. Reordering))
by jdd＠aiki.demon.co.uk 17 Dec '03

17 Dec '03

In message <199408070216.TAA09025(a)jobe.shell.portal.com> Hal writes: > This suggests, that IF YOU COULD TRUST IT, a single remailer would be just > as good as a whole net. Imagine that God offers to run a remailer. It > batches messages up and every few hours it shuffles all the outstanding > messages and sends them out. It seems to me that this remailer provides > all the security that a whole network of remailers would. > > If this idea seems valid, it suggests that the real worth of a network of > remailers is to try to assure that there are at least some honest ones > in your path. It's not to add security in terms of message mixing; a > single remailer seems to really provide all that you need. Yes, in an ideal world. Each additional remailer introduces another chance of being compromised. But in an ideal remailer network operated by real human beings, you cannot trust the operator. You would prefer that at least the points of entry and exit from the network be different, because this decreases the probability of the message being 'outed' by a very large factor. If you are seriously concerned about legal factors, you would prefer that the remailer gateways be in different legal jurisdictions. However, if you trust the operator and if this trust is guaranteed to be continued forever, the ideal number of remailers is one. -- Jim Dixon

3 2

remailer ideas
by Jonathan Rochkind 17 Dec '03

17 Dec '03

My newsgroup-RemailerNet ideas seem to be getting mixed reviews, but I think that part of the p roblem is that some people don't understand what I'm trying to accomplish. There are several features I think are extremely desirable in a remailernet infrastructure, which our current infrastructure doesn't accomplish, and which no proposed infrastructure that I've seen accomplishes either. I'm not certain my newsgroup/pinging idea addresses these concerns, either, but I'm going to lay them all out, and y'all can see what you think. These points aren't distinct, I realize. They're all interrelated somewhat. 1) New remailers should be able to enter the "remailernet" easily, and with a minimum of human intervention. If I decide to run a remailer, the infrastructure should provide a way to make it visible to all other particpants in the remailer net, other remailers and users. Whether the other participants make use of it or not, is another question, and would presumably depend on a web-of-trust kind of situation. But currently, someone who wants to stay current with this kind of info basically has to read cypherpunks, and take notes when people announce new remailers. Better, would be if this sort of "new remailer" info could be distributed automatically, to both users and other remailers. 2) Remailers should be able to leave the remailernet without devestating it. If my remailer is temporarily, or permanently, down, the remailernet should route around it. Again, the current way for operators to announce this would basically be to post to cypherpunks list, and maybe alt.security.pgp too. If other remailernet particpants miss the announcement, havok can ensue. If a middle link of your remailer chain is down, all you know is your messages aren't getting to their destination, you won't know which link is down. We shouldn't require all particpants to read cypherpunks religiously, and if an operator isnt' conscientious enough to post to the expected places, it shouldn't be fatal. Both users and remailers should have an automatic way of finding out about down remailers. 3) Remailers themselves should have a way of automatically learning the topography of the remailernet. If we want to form a cohesive black-box remailernet, remailers are going to need this info. Maybe they're sending fake padding between themselves to thwart traffic analysis. Maybe they're encrypting with the key of the next remailer down the line automatically for you. I don't know enough about it to know what methods are best, but it seems probable from discussion that remailers are going to need to do something that requires knowing about all the other remailers, and their PGP keys and such. 4) Users should have a way of learning the topography of the remailernet too. A way which doesn't require so much human intervention. I should be able to tell my software "send an anon message to X, put 10 links in the remailer chain," and it will do it. To use the remailer net, I shouldn't need to read cypherpunks in order to keep track of all various remailers, and which are up, and which are down. My software should do that for me. And again, your software doesn't need to use all the remailers that it knows about, it can rely on web-of-trust based on PGP signatures and such. [Although I'm not certain this is neccesary, as I've come to the same conclusion as Hal Finney: as long as you've got one (or maybe two) trustworthy remailers in the chain, you are pretty much okay. Although Jim Dixon points out that a concerted effort by the TLAs could make even finding one trustworthy remailer a serious chore. But this is an implementation problem; we're talking theory here at the moment.] 5) No one entity participating in the remailer net structure should be able to compromise the security of the net acting alone. For example, An "evil remai ler" operating solely for the purpose of compromising the remailernet shouldn't be fatal. This is a matter of degree to some extent: if everyone but you is "evil", you're going to be out of luck in just about any system. But the more robust the infrastructure is, the more evil participants it can handle before it cracks, the better. The current remailer net actually fulfills this requirement fairly well, but it's an important one, and worth noting anyhow. Now I think the infrastructure I've proposed that uses a newsgroup, as well as a pinging mechanism, fulfills all these requirements. But I'm not going to try to defend it now, instead, what do you all think about those requirements? Are they all in fact neccesary? Or desirable? Are there any more that should be added? Can you think of any infrastructure systems that might fill some or all of them?

1 0

Latest mention in Wired
by Al Billings 17 Dec '03

17 Dec '03

I noticed in the Sat Pirate article in the latest Wired (which I finally read this evening), there is a mention of the Cypherpunks in connection to PGP and opposition to the creation of a Police State. Page 128, I think. -- Al Billings mimir(a)io.com http://io.com/user/mimir/asatru.html Nerd-Alberich Admin for Troth - The Asatru E-mail List Lord of the Nerd-Alfar Sysop of The Sacred Grove - (206)322-5450 Poetic-Terrorist Lodge-Master, Friends of Loki Society

2 2