December 2003 - cypherpunks-legacy

Re: Nuclear Weapons Material
by David K. Merriman 17 Dec '03

17 Dec '03

>> I don't know much about modern munitions, but I do know that armor >> piercing rounds may have no charge in them at all. Generally, when a >> round pierces one side of a vehicle, it loses enough energy and is >> suitably deformed to prevent exit from the opposite wall. It does, >> however, bounce around quite a bit, which can be plenty of fun in a >> tank loaded with equipment, munitions, and soldiers. > > I was under the impression that the most common techniquoe for >creating armour-piercing munitions was to use shaped-charges. While >depleted uranium has it's uses (being, as someone said, rather dense), >mass alone will not get through everything. A shaped charge will get >through more things more violently :) > And in the process, vaporize a signifcant amount of metal - effectively depositing a few microns (at minimum) of metal plating on everything inside the AFV (including passenger's lungs, skin, etc). My first choice would be not to be present for *either* event; far distant second choice would be taking my chances with riccochets. Dave Merriman - - - - - - - - - - - - - - - - - - - - - - - - - - Finger merriman(a)metronet.com for PGP/RIPEM public keys and fingerprints. Unencrypted Email may be ignored without notice to sender. PGP preferred. Remember: It is not enough to _obey_ Big Brother; you must also learn to *love* Big Brother.

1 0

Re: Nuclear Weapons Material
by David K. Merriman 17 Dec '03

17 Dec '03

>> I have seen the exact same chain-gun mounted on F-16's and A-10's here at >> Bergstron AFB in Austin at at least two different air shows. I am going on >> this alone. I do not know if this was ever an active use of the gun. >> > > Are we thinking of the same A-10? Tank-killer? The one that >houses a multi-barrel gun the size of a small car, and fires shells >which could pass for milk bottles in a dark room? I've seen an F-16, and >i don't think it could carry the chain gun off an A-10 - or have i >missed the point somewhere? > I worked a few months in the GE plant where they make these wonderful little toys ("GE - We Bring Good Things To Life" - hah!). The A-10 does indeed use the 30mm cannon, while the fighter aircraft use 20mm. Externally, the guns look *very* similar - you've got to get close enough to count the barrels (which is too damn close, if it _really_ matters :-) to be sure: 20mm uses 6 barrels, 30mm uses 4 (at least, at the time I was there - mid-80's). Either shoots 4,000 rounds/minute. Then you've got everyone's favorite, the 40mm, firing 3,000 rounds/minute through 3 barrels. If you had to compare a 40mm and a milk bottle in a dark room, the milk bottle is probably the small one :-) Not something I'd want to be on the receiving end of, in any case. Of course, we all realize that the size of the ammo refers to the projectile, not the casing, which is typically about half again the projectile diameter, for 'cased' ammo. I got to watch them light off all their little toys, with different types of rounds in them, while there - even after watching Navy guns fire, I was impressed. Dave (ex swab-jockey) Merriman - - - - - - - - - - - - - - - - - - - - - - - - - - Finger merriman(a)metronet.com for PGP/RIPEM public keys and fingerprints. Unencrypted Email may be ignored without notice to sender. PGP preferred. Remember: It is not enough to _obey_ Big Brother; you must also learn to *love* Big Brother.

1 0

Cash, cheaters, and anonymity
by tcmay＠localhost.netcom.com 17 Dec '03

17 Dec '03

Here's a long response. But it's my only post of today, as the list was going on and on about atom bombs, uranium sabots, and alpha particles, and with debate about why some of us are ignoring these posts and the posts of ranters and baiters. This topic is more in line with my reasons for being on this list. Sorry for the length. Hal Finney writes: >One question is the ease of theft in a digital cash environment, and >the consequences of claiming that secrets have been stolen. This >problem was recognized very early on in discussions of digital >signatures. The whole point of a signature is so that someone can be >held to a commitment. But an easy "out" would be to "accidentally on >purpose" let the secret keys be stolen, then to claim that the >signature was actually forged. Contrariwise, a business might >be vicitimized by actually having its secrets stolen and a forged >signature created that committed it to an unfavorable action. Hal is right the problem of *repudiation* or *disavowal* was recognized early on. Alice is confronted with a digital signature, or whatever. She says; "But I didn't sign that" or "Oh, that's my old key--it's obsolete" or "My sysadmin must have snooped through my files," or "I guess those key escrow guys are at it again." APPROACHES TO REPUDIATION **The purist approach: you *are* your key. If another biological unit obtains your key, he or she is effectively you. Guard your key carefully. **The modern American "excuse" approach: Hey, if you want to disavow a contract, like, just claim your key was stolen or, like, you lost it. I understand the reasoning behind adopting a more intermediate stance, but I think that only the purist stance will hold water in the long run.(A hint of this: untraceable cash means, for most transactions of interest with digital cash, that once the crypto stuff has been handled, whether the sig was stolen or not is moot, because the money is gone...no court can rule that the sig was invalid and then retrieve the cash!) [It is true that Chaum went to great lengths to develop system which preserve anonymity for single-spending instances, but which break anonymity and thus reveal identity for double-spending instances. I'm not sure what market forces caused him to think about this as being so important, but it creates many headaches. Besides being clumsy, it require physical ID, it invokes a legal system to try to collect from "double spenders," and it admits the extremely serious breach of privacy by enabling stings. For example, Alice pays Bob a unit of money, then quickly Alice spends that money before Bob can...Bob is then revealed as a "double spender," and his identity revealed to whomver wanted it...Alice, IRS, Gestapo, etc. A very broken idea. Acceptable mainly for small transactions. More on this later.] NEGOTIATED PROTOCOLS TO REDUCE RISKS However, just as most folks make arrangements with their bank/ATM machines (semantic meaning #2 of "ATM") to limit cash withdrawals to, say, $200 a day (it varies), so too can digital cash arrangements make similar contractual deals to limit losses. Some possible plans: * Plan A: The protocol insists on retinal scan or other biometric authentication between the "smartcard" used as the cryptographic keying device and the putative owner. The "Thunderball" plan. (issues: preserving anonymity with biometric authentication, spoofing of the channel between card and physical apparatus, theft of smartcard, etc.) * Plan B: The protocol only allows, say, $1000 per transaction. And no more than 3 transactions per day. Each transaction that is cleared sends a demon message to the account owner through a separate communications channel. (This sounds complex...the idea is to provide a signal that an account is being accessed, allowing the account owner to put a hold on the account. Even if he can't stop the transactions underway, or recently completed, because of the lags that may exist in this feedback, he can limit losses. Kind of a mix between off-line and on-line transactions....such mixes are to be expected, with the choice up to parties, depending on costs, risks, speed of communications, etc.) * Plan C: Use off-line cash only for "small" transactions, such as those now handled with physical coins and small bills. Use on-line clearing for larger amounts, with various forms of biometric security. This echoes how things are done today: off-line cash is what you can carry, in bill, coin specie, etc. Larger amounts (hundreds of dollars and up) is almost always handled on-line, via either credit cards (on-line clearing, albeit not anonymous/untraceable) or checks, cashier's checks, etc. (Coins and cash bills are really "on-line clearing" though, in that their existential properties make them acceptable immediately; they are not replicable, at least not easily, and hence can be conserved in transations. All the usual stuff about the nature of cash money.) Which will be used? (and there are many variants...) As usual, markets will allow choice. Many people will choose to limit exposure with Plan B-type transactions. Others will contract with insurance agents who cover risks by insisting on their own protocols for added security. (I don't mean conventional insurance agents, naturally.) MISCELLANEOUS STUFF >On the other hand, I would hope that people actually can learn to use >care in safeguarding their secrets. The pass words and PINs we use >today may be complemented by physical checks for voice patterns, thumb >prints, perhaps (ironically) handwriting. Another approach would be Most smartcards in use today support some form of local PIN entering, some way to provide a truly memorizable extra piece of identiy. Other biometric measures remain a hot area of research. Stroke recognition, thumbprints, etc. In about 5 years, when I think digital cash will be ready for prime time (pun intended), these additional mechanisms should be deployable, for a price. (Market-driven again: those who want to pay less in insurance will take better steps. Companies may adopt standards. Banks may enforce them.) ... >suggestions (one here a couple of days ago) to use various kinds of >information exchange between the authenticating device and the human >user in order to prove authorization in such a way that even a thief >who has snooped on past exchanges will not be able to use the device. >This approach is sometimes called the use of "pass algorithms". "Zero knowledge interactive proof systems" have been used for password systems; no amount of past snooping or eavesdropping helps. (Of course, the user still has to have physical security over his local computer, or PDA, dongle, or secret decoder ring.) This seems like a readily-solvable problem (and one we already accept with existing ATM machines). THE INCREDIBLE IMPORTANCE AND ELEGANCE OF ON-LINE CLEARING ... >Applying this to the double-spending case, I suspect that Bob Hettinga >is more on the right track in seeing the solution in the legal system >rather than a simple "shucks, you caught me" forfeiting of a bond >worth triple damages. There really should be no excuse for double *On-line clearing* for larger amounts is, in my opinion, the Right Thing. Networks are getting deployed widely and are speedy. ATM, SONET, ISDN, and all the rest. I want to elaborate on this, even though I think most of Hal's points are made with off-line clearing in mind. I want to make the case for why on-line clearing is the One True Digital Cash. Conceptually, the guiding principle idea is simple: he who gets to the train locker where the cash is stored *first* gets the cash. There can never be "double spending," only people who get to the locker and find no cash inside. Chaumian blinding allows the "train locker" (e.g., Credit Suisse) to give the money to the entity making the claim without knowing how the number correlates to previous numbers they "sold" to other entities. Anonymity is preserved, absolutely. (Ignoring for this discussion issues of cameras watching the cash pickup, if it ever actually gets picked up.) Once the "handshaking" of on-line clearing is accepted, based on the "first to the money gets it" principle, then networks of such clearinghouses can thrive, as each is confident about clearing. (There are some important things needed to provide what I'll dub "closure" to the circuit. People need to ping the system, depositing and withdrawing, to establish both confidence and cover. A lot like remailer networks. In fact, very much like them.) In on-line clearing, only a number is needed to make a transfer. Conceptually, that is. Just a number. It is up to the holder of the number to protect it carefully, which is as it should be (for reasons of locality, for self-responsibility, and because any other option introduces repudiation, disavowall, and the "Twinkies made me do it" sorts of nonsense). Once the number is transferred and reblinded, the old number no longer has a claim on the money stored at Credit Suisse, for example. That money is now out of the train locker and into a new one. (People always ask, "But where is the money, really?" I see digital cash as *claims* on accounts in existing money-holding places, typically banks. There are all kinds of "claims"--Eric Hughes has regaled us with tales of his explorations of the world of commericial paper. My use of the term "claim" here is of the "You present the right number, you get access" kind. Like the combination to a safe. The train locker idea makes this clearer, and gets around the confusion about "digimarks" of "e$" actually _being_ any kind of money it and of itself.) Off-line systems may be useful for paying for movies, toll roads, etc., but there the protocols can be set up to limit exposure to fraud. (Ontological constraints, such as number of movie theater attendees, etc., will limit the losses. Scams will likely still exist, but the problem seems manageable with some work.) And as networks get much faster, expect even off-line cash to fade. Depends on costs, insurance rates, benefits, and of course on regulations. >spending, even of a penny, and the penalties could be made strong >enough to deter most people. If a bank does not think they will be >able to find and prosecute a person who is withdrawing off-line >digital cash, they will probably not give any to him. Then if the The "first to the locker" approach causes the bank not to particularly care about this, just as a Swiss bank will allow access to a numbered account (or used to...please let's not have a dozen posts arguing about this, as is so often the case on this list!) by presentation of the number, and perhaps a key. Identity proof *may* be needed, depending on the "protocol" they and the customer established, but it need not be. And the last thing the bank is worried about is being able to "find and prosecute" anyone, as there is no way they can be liable for a double spending incident. The beauties of local clearing! (Which is what gold coins do, and paper money if we really think we can pass it on to others.) IS PROOF OF PHYSICAL IDENTITY NEEDED? ... >money is double-spent, the person who withdrew it would be prima facie >responsible, with a reasonable presumption that they did it unless >there is significant evidence otherwise. I don't know that this is >how it will work out but it is one possibility (unless the uncertainty >just scares everybody away - but I think the digital signature >experience will get people used to the concepts and problems). I recall some analyses of these situations a while back. I looked in my "Crypto" Proceedings but didn't find it. The danger of making the "person who withdrew it" a culprit if the money has already been "spent" is clear: he is just as likely to be an innocent victim of a setup as the guilty party. With off-line clearing, and not the "handshaked" beauty of immediate clearing, one has to rely on "trust"--tough with an anonymous person. On-line clearing has the possible danger implicit in all trades that Alice will hand over the money, Bob will verify that it has cleared into his account (in older terms, Bob would await word that his Swiss bank account has just been credited), and then Bob will fail to complete his end of the bargain. If the transaction is truly anonymous, over computer lines, then of course Bob just hangs up his modem and the connection is broken. This situation is as old as time, and has always involved protcols in which trust, repeat business, etc., are factors. Or escrow agents. REAL ESCROW AND TRUE NYMS Long before the "key escrow" of Clipper, true escrow was planned. Escrow as in escrow agents. Or bonding agents. Alice and Bob want to conduct a transaction. Neither trusts the other; indeed, they are unknown to each other. In steps "Esther's Escrow Service." She is _also utraceable_, but has established a digitally-signed presence and a good reputation for fairness. Her business is in being an escrow agent, like a bonding agency, not in "burning" either party. (The math of this is interesting: as long as the profits to be gained from any small set of transactions is less than her "reputation capital," it is in her interest to forego the profits from burning and be honest. It is also possible to arrange that Esther cannot profit from burning either Alice or Bob or both of them, e.g., by suitably encrypting the escrowed stuff.) Alice can put her part of the transaction into escrow with Esther, Bob can do the same, and then Esther can release the items to the parties when conditions are met, when both parties agree, when adjudication of some sort occurs, etc. (There a dozen issues here, of course, about how disputes are settled, about how parties satisfy themselves that Esther has the items she says she has, etc.) UNTRACEABLE MARKETS FOR ASSASSINATIONS To make this brutally concrete, here's how escrow makes murder contracts much safer than they are today to negotiate. Instead of one party being caught in an FBI sting, as is so often the case when amateurs try to arrange hits, they can use an escrow service to insulate themselves from: 1. From being traced, because the exchanges are handled via pseudonyms 2. From the killer taking the money and then not performing the hit, because the escrow agent holds the money until the murder is verified (according to some prototocol, such a newspaper report...again, an area for more work, thankfully). 3. From being arrested when the money is picked up, as this is all done via digital cash. There are some ways to reduce the popularity of this Murder, Incorporated system. (Things I've been thinking about for about 6 years, and which we discussed on the list and on the Extropians list. I'll save this for another time.) My point here is to show how on-line clearing works in conjunction with an escrow agent function.(Esther clears the cash, and can issue new cash to Bob, who "trusts" her that if he does the job, the cash will clear, as she's the escrow agent he's dealt with many times before.) THE DANGER OF EVER USING PHYSICAL IDENITY VERIFICATION >The other point I wanted to discuss was this issue of the bank >authenticating the people who receive the cash. This does raise the >spectre of a big brother system where there is some way to identify >people with 100% certainty. Obviously this could be abused. Danger! Danger! Danger! Any such system, that relies on physical IDs is substantially less private that banks today in many countries, and is not at all what I would call "digital cash." On-line clearing makes this unnecessary. >Without the authentication, you're not going to have off-line cash, >IMO. You will be stuck with on-line systems in which everyone has to >verify everything before accepting it. This means you pay a cost in >communications overhead and possibly other foregone opportunities. Agreed. But acceptable with a two-tiered system: - off-line cash for small transactions, with smartcards, "observer" protocols, and with built-in limits - on-line , immediately-cleared cash for larger transactions, also with various agreed-upon limits or requirements RISKS Is there a danger that people will lose the numbers that they need to redeem money? That someone could steal the number and thus steal their money? Sure. There's the danger that I'll lose my bearer bonds, or forget my Swiss bank account number, or lose my treasure map to where I buried my money (as Alan Turing supposedly did in WW II). People can take steps to limit risk. More secure computers. Dongles worn around their necks. Protocols that involve biometric authentication to their local computer or key storage PDA, etc. Limits on withdrawals per day, etc. People can store key numbers with people they trust, perhaps encrypted with other keys, can leave them with their lawyers, etc. All sorts of arrangements can be made. Where I'm not sure I agree with what Hal is saying is that _personal identification_ is but one of these arrangements. Often used, but not essential to the underlyng protocol. Again, the Swiss banks (maybe now the Liechtenstein anstalts are a better example) don't require physical ID for all accounts. (More generally, if Charles wants to create a bank in which deposits are made and then given out to the first person who sings the right tune, why should we care? This extreme example is useful in pointing out that _contractual arrangements_ need not involve governmental or societal norms about what constitutes proof of identity.) PAPIEREN, BITTE Hal goes on to talk about blinded credentials. A very important idea in our permission slip-happy society, and an idea that is not getting nearly enough attention. (Chaum's seminal "Transaction Systems to Make Big Brother Obsolete," from Oct or Nov of 1985, in "Communications of the ACM," remains required reading here.) But I also take a more radical view. Ask yourself why credentials are _ever_ needed. Maybe for driving a car, and the like, but in those cases anonymity is not needed, as the person is in the car, etc. Credentials for drinking age? Why? Let the parents enforce this, as the argument goes about watching sex and violence on t.v. (If one accepts the logic of requiring bars to enforce children's behavior, then one is on a slippery slope toward requiring television set makers to check smartcards of viewers, or of requiring a license to access the Internet, etc.) In almost no cases do I see the need to carry "papers" with me. Maybe a driver's license, like I said. In other areas, why? This gets to a core issue: the incredible benefits of locally clearing a transaction. Caveat emptor, buyer beware, etc. Cash on the barrelhead. In transactions where "future performance" is needed, as in a contract to have a house built, or to do some similar job, then of course the idea of on-line or immediate clearing is bogus...like paying a stranger a sum of money on his promise that he'll be back the next day to start building you a house. Parties to such long-term, non-locally-cleared cases may contract with an escrow agent, as I described above. This is like the "privately-produced law" we've discussed so many times. The essence: voluntary arrangements. Maybe proofs of identity will be needed, or asked for, maybe not. But these are not the essence of the deal. An interesting area. I apologize if this essay, while long, is not quite long enough to capture the ideas I wanted to express. To me, these are core ideas. Maybe not as core to those of you who favor talking about depleted uranium sabots (but what about Chobham armor and explosive armor?) or about "PGP rulz, d00d!," but core isseus to me. Your smileage may vary. --Tim May .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay(a)netcom.com | anonymous networks, digital pseudonyms, zero 408-688-5409 | knowledge, reputations, information markets, W.A.S.T.E.: Aptos, CA | black markets, collapse of governments. Higher Power: 2^859433 | Public Key: PGP and MailSafe available. "National borders are just speed bumps on the information superhighway."

5 6

Re: Nuclear Weapons Material
by jkbacon＠pacifier.com 17 Dec '03

17 Dec '03

> I was under the impression that the most common techniquoe for >creating armour-piercing munitions was to use shaped-charges. While >depleted uranium has it's uses (being, as someone said, rather dense), >mass alone will not get through everything. A shaped charge will get >through more things more violently :) > Depleted uranium is used in armor piercing rounds for three reasons: 1. High density 2. High hardness - not quite that of tungsten, but its up there. 3. Upon impact it ignites (like magnesium) and burns. The burning uranium melts steel and also produces uranium oxide in the process. If this isn't "violent" enough, try fission. Kirk

2 1

No Subject
by Anonymous 17 Dec '03

17 Dec '03

I thank Hal Finney for his thoughtful reply, and Tim May for his excellent essay. It looks like we can start to draw a stronger conclusion: there are serious holes in the assumptions made by offline digital cash protocols when applied to computer networks rather than manually operated smart cards. Hal's comparison of coin theft to digital signature protection and repudiation is apt, but usually Irving only has one or a few keys to protect, while he might have thousands of coins, issued by various banks. I doubt digital signatures will ever be used alone much for signing expensive contracts. A digital signature on an expensive contract, in addition to being repudiable, will be suspicious, since if few people accept such signatures as strongly binding (the initial state), they will not be widely used on expensive contracts, and thus their existance on an expensive contract will be suspicous. I predict it will become common practice, or even law, that digitally signed contracts over a certain amount are automatically invalid unless further precuations have been taken (signatures of notary witnesses, or perhaps some better crypto protocol designed for this purpose). The trouble with offline cash in a network environment is that the upper limit for fraud liability can be incredibly high. If there are hundreds of thousands of vendors on the net, a situation CommerceNet predicts before the end of the decade, and they are using this offline protocol, then even with small transactions the fraud could run into the millions of dollars. There's plenty of incentive for Irving to steal Jane's coins, run off to some place on the net that has no extradition treaty, and pump good change out of the vendors and into his Lichtenstein account to his heart's content. We may yet find protocols to mitigate or limit this kind of fraud -- make change traceable if linked to double spending, do random online checks as a cypherpunks poster suggested last year, or similar precautions layered on top of the basic protocol. But so far these problems haven't been put on the front burner of digital cash design, and already we have people out there selling offline cash on the network as a superior solution! Reliance on law enforcement flies in the face of cypherpunk goals, and indeed against the goals of good cops as well -- one of their most vocal complaints is about people setting up systems that are vulnerable to crime, putting them in unecessary danger. It also goes against political reality to think that a startup operation can lobby governments all across the globe to protect a system that is ideal for money laundering and tax evasion. Ain't gonna happen -- they'll let those "dirty money banks and money laundering net sites" rot; they may even give Irving a helping hand. I disagree that "there is no excuse" for double spending. If the software is implemented badly (no fault of the user), it might get mixed up with systems programs in such a way as to cause double spending. For example, if the system crashes and one must recover from a month old backup, one has to go through that old purse and determine which coins have been spent. If the software and/or user makes a mistake in this process, we get double spending. If a network burps and sends a vendor two coins where there should have been one, we get double spending. The possibilities for accident are legion and cannot all be foreseen. "Shit happens". A protocol that treats common accident the same as criminal fraud, when the stakes are so high, is pathological. In the online system the consequences of double spending (or million spending) are far more benign. At worst one customer is out stolen coins. In a networked offline system those same few coins are a potential loss for every vendor on the net. As Tim May noted, we may not even need to recongize fraud in online cash -- just treat all online double spending as accident. No bonding, secured accounts, investigators, ID badges or cops with guns busting down Janes's door after Iriving has million-spent her coins. Here we both have a simple liability system and much less chance of fraud. Tim May also suggested that most offline protocols are intended for manually used smart cards. This makes sense -- unlike an network environment with automated spending agents, the scope of multi spending for manually used pruchases in small amounts is quite limited. On the network even fraud of a few cents per transaction can quickly add up to big $$$ across thousands of vendors. What are the communications costs of online clearing, anyway? Don't credit card clearings cost about two cents per transaction these days? If clearing costs are less than plausible offline cash fraud and fraud prevention costs, online cash is a winner, both now and increasingly in the future as bandwidth becomes even cheaper. sincerely, -- An Unauthenticated Agent with no credentials: WYSIWYG

3 2

Re: U & Pu is good for U
by jdd＠aiki.demon.co.uk 17 Dec '03

17 Dec '03

In message <199408252138.OAA15395(a)well.sf.ca.us> Brad Dolan writes: > >On the other hand I say that such studies are poor criteria for > >judging the effects of radiation intended to do the maximum possible > >harm. > > Well, these studies are about all we have to go on right now. The > wartime residents of Hiroshima and Nagasaki do provide a large set of > folks exposed to "radiation intended to do the maximum possible harm" > but, darn it, none of them were wearing dosimeters. People do study > these groups, making educated guesses about doses, but it's hard to > draw precise conclusions on that basis. There is a Sufi parable about a guy who loses something on a dark street. His friend finds him searching the ground carefully at the corner under a street light. He asks him what he is doing, and he explains that he dropped something. "Where?" "Down the street." "Then why are you looking here?" "Because there is a light down here." -- Jim Dixon

1 0

Re: (Fwd) Something of Interest (fwd)
by Jim Choate 17 Dec '03

17 Dec '03

Hi, I would like to add one thing, jf_avon(a)ssz.com doesn't exist as a valid user account or alias on any ssz.com system. ____________________________________________________________________ | | | _____ The Armadillo Group | | ,::////;::-. Austin, Tx. USA | | /:'///// ``::>/|/ http:// www.ssz.com/ | | .', |||| `/( e\ | | -====~~mm-'`-```-mm --'- Jim Choate | | ravage(a)ssz.com | | 512-451-7087 | |____________________________________________________________________| Forwarded message: > From owner-cypherpunks(a)ssz.com Sun Jul 20 01:15:32 1997 > Message-Id: <199707200622.XAA18842(a)baker.cnw.com> > From: "Blanc" <blancw(a)cnw.com> > To: <cypherpunks(a)toad.com> > Subject: Re: (Fwd) Something of Interest > Date: Sat, 19 Jul 1997 23:31:08 -0700 > MIME-Version: 1.0 > Content-Type: text/plain; > charset="iso-8859-1" > Content-Transfer-Encoding: 7bit > X-Priority: 3 > X-MSMail-Priority: Normal > X-Mailer: Microsoft Outlook Express 4.71.0913.4 > X-MimeOle: Produced By Microsoft MimeOLE Engine V4.71.0913.6 > Sender: owner-cypherpunks(a)ssz.com > Precedence: bulk > X-Mailing-List: cypherpunks(a)ssz.com > X-List-Admin: list(a)ssz.com > X-Loop: ssz.com > From: jf_avon(a)ssz.com > > |I received this out of the blues. I suppose that you received it > |too. > ........................................................... > > > I didn't receive it, and I set off quite a round of discussion with Jim & the > list, at one point. Guess I'm not considered controversial enough to get it. > :>) > > .. > Blanc > >

1 0

PGP, digicash, and tanks
by dfloyd＠runner.utsa.edu 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- The idea of DigiCash is a good one, and there have been many good ideas on it, but it will be hard to implement it in the US. The IRS will want to stop it cold as it gets around them, some people will fear it "The cash for PEDOPHILES", and Joe Blow will probably have a tough time getting used to it as it is very new to him. Another problem is being able to trust the bank who holds the notes. It will have to be a stable institution which does this, one that the IRS most likely has a grip on, or can get one. The SEC will probably want their way also. As to having PGP on a unix box, and the risks of this, I have a solution to this. What I do is keep my key on my Linux box at home, and have my mail forwarded there. It then is simple to reply and decode messages. pgpdaemon and pgpsendmail also help a lot with the quick encodes and decodes. As to tank rounds, aren't we getting a bit off track here? -----BEGIN PGP SIGNATURE----- Version: 2.6 iQCVAgUBLl3cdHDkimqwdwa5AQEO4wP/ZBX5ecquikmxVHVGDz7Hutg8ryX1taJK l4aVy10uHAv5wE4KptFq3k5enqKsdot3nJsG33GLCfsrcpm2qz1snwAvh+5WmK6y f7AnSJlx671dM9334qoKAuVpLahWFpmmWuoROSXx4rx3zSVIXKjkrWaSJLAHP0Ay cAY0quBcfhw= =r48u -----END PGP SIGNATURE-----

1 0

Re: Fast modular exponentiation
by Pat Farrell 17 Dec '03

17 Dec '03

Phil Karn <karn(a)unix.ka9q.ampr.org> writes: > I.e., if I come up with a list of clock counts for each basic > arithmetic instruction, how can I tell which algorithm is probably > best for my machine? Back in the days of Mix, Knuth worked out the model. But with modern pipelined chips with significant on-chip cache, the model becomes too complex to solve arithmetically. The usual solution is to use Berkeley's Architect's Work Bench (AWB) which allows you to model the chip's instruction set, cache structure, pipeline stall characterists, etc. while using a compiler to generate actual code to execute. You can then execute your algorithm against the chip, and declare a winner. Of course, you have to validate the chip model, and you have to know how the compiler optimizations work, how it interacts with branch prediction logic, etc. While awb is readily available for the usual Unix systems, using it for anything less trivial than a grad school compiler optimization course is a ton of work. It makes sense when you are inventing a new chip architecture, or even a significant revision to an existing chip. I believe that it is far too much work to use awb (or anything of similar capabilities) to evaluate algorithms for real world chips. For algorithm optimization, it makes more sense to study the chip's characteristics, and use a heuristic approach, testing real implementations. I've already measured nearly a four to one difference in execution times using Phil's DES code using different compilers and operating systems on the same hardware (my 486). But it is pretty unsatisfying to say that the best algorithm "depends" on half a dozen variables, and that we can't reliably predict (engineer) a solution. Pat Pat Farrell Grad Student pfarrell(a)cs.gmu.edu Department of Computer Science George Mason University, Fairfax, VA Public key availble via finger #include <standard.disclaimer>

1 0

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

17 Dec '03

In message <199408260422.VAA16628(a)unix.ka9q.ampr.org> Phil Karn writes: > I'm not really an expert on DSPs, but it does seem like they should be > good for modular exponentiation given the number of multiplies required. > But I don't think I'm the first to point that out. DSPs are actually optimized for the operation required in the FFT: integer inner products. A DSP will have hardware for extremely fast summations of expressions like c[i]*x[i] where the c[i] are constants, and new x vectors are introduced at a high rate. This is somewhat different than the kind of fast multiplication you are looking for. -- Jim Dixon

1 0

Re: Fast modular exponentiation
by markh＠wimsey.bc.ca 17 Dec '03

17 Dec '03

> But it is pretty unsatisfying to say that the best algorithm "depends" on > half a dozen variables, and that we can't reliably predict (engineer) a > solution. It does seem to come down to that though. I've spent a bit of time playing with a couple of versions of Montgomery Mult code plus other optimisations for modular exponentiation. What works best depends upon the processor (I was doing C with some inline assembler for the multiply and divide ops). I remember that one particular approach worked very well on an HP 9000/730 and was miserable on anything else I tried (Sparc, 80486, MIPS R3000, 68030). There's a really nice survey paper by Cetin Kaya Koc (then of RSADSI) called _High Speed RSA Implementation_ which describes various optimisations. The references in this are also pretty useful. Mark -- Mark Henderson markh(a)wimsey.bc.ca - RIPEM MD5: F1F5F0C3984CBEAF3889ADAFA2437433 ViaCrypt PGP key fingerprint: 21 F6 AF 2B 6A 8A 0B E1 A1 2A 2A 06 4A D5 92 46 low security key fingerprint: EC E7 C3 A9 2C 30 25 C6 F9 E1 25 F3 F5 AF 92 E3 cryptography archive maintainer -- anon ftp to ftp.wimsey.bc.ca:/pub/crypto

2 1

Re: Nuclear Weapons Material
by L. Todd Masco 17 Dec '03

17 Dec '03

I'd like to point out that some of the people who are most vocal about topics when threads wander off what they consider "cypherpunks topics" are contributing to this "Nuclear Weapons Material" thread in a way that had nothing to do "cypherpunks topics." I'm not saying "cut it out" -- I know where my 'd' key is. I am, however, amused. -- L. Todd Masco | "Large prime numbers imply arrest." - Previously meaningless cactus(a)bb.com | grammatically correct sentence. Now...

1 0

Robot Wars!
by Dr. Charles Rubenstein 17 Dec '03

17 Dec '03

Dear punkers With all the latest government and crime bill and clipper bandwidth being spent I thought you might find this message, posted to PACS-L interesting. -CR Short sig: The Internet does not belong to us. We belong to the Internet. - from Chief Seattle's "Earth" quote ------- Forwarded Message Message-Id: <9408232357.AB16213(a)mail-in.worldlink.com> Date: Tue, 23 Aug 1994 18:42:47 CDT To: Multiple recipients of list PACS-L <PACS-L(a)UHUPVM1.UH.EDU> From: Jack Kessler <kessler(a)well.sf.ca.us> Reply-To: Public-Access Computer Systems Forum <PACS-L(a)UHUPVM1.UH.EDU> Sender: Public-Access Computer Systems Forum <PACS-L(a)UHUPVM1.UH.EDU> Subject: Robot Wars! ("robot wars"?) ----------------------------Original message---------------------------- re: Robot Wars! ("robot wars"?) August 20, 1994 -- San Francisco Where else in the world could you assemble 1000 paying members of the general public for a day to watch little mostly - metal machines rip, tear, shred, ram, saw, and blow each other apart? In California, of course -- the land of the crazies -- and in San Francisco, where all the truly crazy ones are. (I am San Franciscan.) Nearly every combination computer - nerd - machine - geek - homicidal - maniac in the electronic world -- one hopes that there are no more than 1000 of them -- is assembled here in San Francisco's Fort Mason today to watch "The First Annual Robot Wars", a full day of competitive events in which these little creations, 1) "Escort" each other around a trap - filled arena, then, 2) "Face - off", duel with each other one on one, and, finally, 3) "melee", engage in free - for - all group destruction. And they -- all of them including the robots -- are communicating back and forth using the same electronic technologies which I've been using for looking up books in libraries. This is a very live show, featuring home - made robots built by high school students, Industrial Light & Magic wizards (ILM's Marc Thorpe is the event's" Creator and President), and even some elderly (in their 40s) engineers. The crowd is on bleachers, surrounding an arena equipped with great pinball - style paddles, net - like traps which descend upon the unwary contestants, and a great swinging cannon - ball which arcs high over nervous spectators' heads, occasionally slamming into an unwary little competitor. There is a "Madonna Bra" entry: "Zomo" -- made from a suspended stainless steel mixing bowl mounted on something like a little remote control racing car, emblazoned with slogans like "Kiss Me", and "Revenge", scrawled in pink lipstick. There is an entry by the guy who invented SimCity: "Julie - bot", complete with war - painted Barbie Doll head -- "The Barbie from Hell!", the crowd cried. "AndyRoid", a Charlie McCarthy - style ventriloquist's doll mounted on a kid's plastic BigWheel trike -- trailing a lethal Coke can on a string which it/he uses to ensnare and destroy opponents -- screams "child abuse! child abuse!" when it/he is hit, and, after the swinging cannonball strikes it directly in the head, "tylenol! tylenol!". There are contestants with names like "Spiny Norman", "SlowMo", "PainMower", "The Beetle", and "The Master": sort of a cybernetic TV wrestling list. There are some bright people at this thing. A few of them are the folks who brought us films like Star Wars, Indiana Jones, Cobra, Ghost, Terminator 2, Forrest Gump, and Mask. There are some international folks, camcorders and flipphones are everywhere, I see some press luminaries and at least one tv station, and there are plenty of mysteriously - important - looking people. Talk about a 1990s event. Technology, brutality, war, metal. Fitting, I guess, that it takes place on the piers from which the US made war on Japan a half century ago. Somebody should tell me whether this is cruelty or catharsis -- there were plenty of "thumbs down" signals being given, received, and acted upon -- and how far a robot has to be taken before it becomes anthropomorphic? I was interested because there are a lot of Entertainment Industry types involved in this, and I am curious about current predictions that the Entertainment Industry is about to take over information networking. Anyone who thinks this technology is tame either, a) hasn't read William F. Gibson, or, b) has read him but doesn't believe it, or, c) wasn't at "Robot Wars". More can be found out about present and future Robot Wars, I'm told, via e - mail to: robotwars(a)aol.com. Jack Kessler kessler(a)well.sf.ca.us ------- End of Forwarded Message

1 0

PRIVACY 101
by Sandy Sandfort 17 Dec '03

17 Dec '03

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ SANDY SANDFORT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C'punks, Duncan and I are now accepting registrations for our on-line Privacy Seminar. If you would like to participate, you can subscribe by sending a message to: majordomo(a)c2.org In the body of your message, you should have the command: subscribe privacy101 [<address>] Where [<address>] is the e-mail address you wish to use for the Seminar. (If you do not specify an address, the address from which you subscribed will be used.) Send a message to majordomo(a)c2.org with the word "help" in the body of the message to get majordomo help info. Here is some more list info: Majordomo address: Majordomo(a)c2.org Majordomo-Owner address: Majordomo-Owner(a)c2.org List Name: privacy101 List posting address: privacy101(a)c2.org List request address: privacy101-request(a)c2.org The Seminar will be archived. To participate from the beginning, however, you should sign up immediately. The Seminar will begin September 1st. The Seminar will be a series of lectures that alternate with a moderated list for questions and comments. As the Seminar progresses, we may alter or add lectures, but the tentative list of lectures is as follows: Privacy 101 Lectures: 1. Introduction to Privacy Theory and Philosophy 2. Threat Level Management--The Calculus of Risk 3. Identity Information Risks 4. Locational Information Risks 5. Financial Information Risks 6. Health Information Risks 7. Lifestyle Information Risks 8. Political/Philosophical Information Risks 9. Misc. Information Risks 10. Identity Privacy Techniques 11. Locational Privacy Techniques 12. Financial Privacy Techniques 13. Health Privacy Techniques 14. Lifestyle Privacy Techniques 15. Political/Philosophical Privacy Techniques 15. Misc. Privacy Techniques If you have any specific questions or areas of interest which you would like to have addressed during the Seminar, please let us know as soon as possible. We will try to work them into our presentation. Regards, S a n d y ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

1 0

Re: DSPs
by Phil Karn 17 Dec '03

17 Dec '03

>This is somewhat different than the kind of fast multiplication you are >looking for. Yes, but even scalar multiplication is so much faster on a DSP than on most general purpose CPUs that it seems like a definite win. The 486 takes from 13-42 clock cycles to perform a multiply, depending on the operand sizes and number of significant bits in the multiplier. Even if you couldn't keep the pipeline full on a chip like the PowerPC, you'd still be well ahead. But then I hear people say that it's not the multiplication that slows down modular exponentiation, it's the modular reduction. Phil

3 2

MATH: Brands cash, Hal's posts
by Karl Lui Barrus 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Cypherpunks, or maybe that's Atompunks, Earlier, Hal posted several excellent messages concerning Brands' cash, and some introductory material. I always find it useful to work through various protocols by hand (well, with Mathematica), working with real numbers to help understand the protocol and how it works. So like I did a long time ago when Hal posted a description of Chaumian cash, I will give an example of the protocols described. I intend to follow along Hal's posts and work math as it comes up (and try to keep the notation consistent!). I'll not be using numbers large enough to give actual security. For folks with Mathematica, the functions of interest are PowerMod[a,b,c] to calculate a^b mod c, and Mod[a,b] to calculate a mod b. Hal's first post was introductory material on discrete logs: * Generators > Discrete-log based cryptosystems generally work with a modulus n which is > prime, along with a "generator" g < n such that the series g^0, g^1, g^2, > ... , includes all values from 1 to n-1. It is pretty straightforward to > find such n's and g's. It is easy to compute g^x for any x, but > intractable to calculate x given just g^x. Finding a generator g is easy if you know the factorization of n-1. You just need to calculate g^((n-1)/q) mod n for all values of q, the prime factors of n. If any of the results are 1, then g is not a generator. So say you want to see if 5 is a generator mod 2047. The prime factors of n - 1 = 2046 are { 2, 3, 11, 31 }, so you calculate: 5 ^ (2046/2) mod 2047 = 1034 5 ^ (2046/3) mod 2047 = 622 5 ^ (2046/11) mod 2047 = 1435 5 ^ (2046/31) mod 2047 = 622 None of these turned out to equal 1, so 5 is a generator mod 2047. * Diffie-Hellman key exchange > 1. Alice chooses a random x and sends GX = g^x to Bob. Bob chooses a > random y and sends GY = g^y to Alice. Let's use g = 10, and pick p = 17389. 10 is indeed a generator mod 17389. Alice chooses x = 53, and calculates g^x mod p = 10^53 mod 17389 = 9059 Bob chooses y = 4321 and calculates g^y mod p = 10^4321 mod 17389 = 16077 They exchange, so Alice receives GY = 16077 and Bob receives GX = 9059 > 2. Alice calculates GY^x, which is g^(y*x). Bob calculates GX^y, which > is g^(x*y). Alice calculates 16077^53 mod 17389 = 11643 Bob calculates 9059^4321 mod 17389 = 11643 > 3. These are equal, so they use them as their shared secret value. Alice and Bob agree to the shared secret 11643. > An observer sees only GX and GY, and without knowledge of x and y is > unable to calculate g^(x*y). * DH-based identification protocol For this example, suppose we use g = 10, p = 17389 as above. Also, Paul chooses x = 555 to be his private key, therefore 10^555 mod 17389 = 11106 is his public key. > 1. Vicki chooses a random y and sends GY = g^y to Paul. Vicki randomly chooses y = 1994, so she sends 10^1994 mod 17389 = 13848. > 2. Paul calculates GYX = GY^x = g^(y*x) and sends that back to Vicki. Paul calculates 13848^555 mod 17389 = 8324, and sends it back. > 3. Vicki confirms that GYX = GX^y; both should be g^(x*y). Vicki checks 11106^1994 mod 17389 = 8324. This matches what Paul sent back. * Schnorr identification protocol > 1. Paul chooses a random w and sends GW = g^w to Vicki. Paul chooses w = 200, and sends 10^200 mod 17389 = 14097 to Vicki. > 2. Vicki chooses a random c and sends it to Paul. Vicki chooses c = 561 and sends this to Paul. > 3. Paul calculates r = cx+w and sends that to Vicki. Paul calculates r = 561 * 555 + 200 = 311555. > 4. Vicki confirms that g^r = (GX^c)*GW. Both should be g^(cx+w). Vicki checks: 10^315555 mod 17389 = 4594 (11106^561) 14097 mod 17389 = ((11106^561 mod 17389) * 14097) mod 17389 = 4594 * Chaum discrete log interactive signature protocol Here, we'll pick m = 1040. Thus, Paul can calculate MX = 1040^555 mod 17389 = 8608 > 1. Paul chooses a random w and sends GW = g^w and MW = m^w to Vicki. As above, Paul chooses w = 200, so he sends GW = 14097 and MW = m^w mod p = 1040^200 mod 17389 = 472 to Vicki. > 2. Vicki chooses a random c and sends it to Paul. She chooses 561 again. > 3. Paul calculates r = cx+w and sends that to Vicki. He calculates 311555 again. > 4. Vicki confirms that g^r = (GX^c)*GW. Both should be g^(cx+w). She > also confirms that m^r = (MX^c)*MW. Both should be m^(cx+w). Vicki checks g^r as above. Now she also checks: m^r mod p = 1040^311555 mod 17389 = 13723 (MX^c)*MW = (8608^561)*472 mod 17389 = 13723 * Chaum discrete log signature protocol Well, this is similar to the above protocol except a hash function is used. I'll do something similar for Hal's other posts as time permits. Karl Barrus klbarrus(a)owlnet.rice.edu -----BEGIN PGP SIGNATURE----- Version: 2.6 iQCVAgUBLl5uPsSF/V8IjI8hAQE4/AP/VNauuo2nIWvF7xukbh6zNXK/pTnD7vGM 7jQeD9Hk7z9a/GXD2OTjlKUf1HAtFRkPB95X3HS/u5TzO1RdUIoxuiUok38At8vX UUBaRXaF6JJUI8xkvgOt9qCrSnZNKhjh4wZ2JxxOUY/0rB/1TBRzPe/MIIzyy0Ee bKaCRv+gJLA= =esaf -----END PGP SIGNATURE-----

2 1

Spoofing Weapons 2
by John Young 17 Dec '03

17 Dec '03

Forwarding mail by: misra(a)gardener.lanl.gov ("Raymond H. Misra") on Fri, 26 Aug 10:28 AM ------------------- On Aug 26, 2:11am, MEINKING(a)delphi.com wrote: > Subject: > > Each message pounds another nail into my silent coffin. Inside it is dirty, > dank and pathetic. I have received every post. I have read every post, and > each time, I have had what seems like everything to say. But I don't say > it. > > Yet I do know where I want to go, where I want to reach. I want to reach > those that have pounded the nails into my coffin, that have participated in > luring me into the apeiron, trapping me in the coffin, and discarding me > forever. > > To them I can only say this: > > "The fire is burning me. It is erupting from the inside, from the > pit of my gut and bursting forth. The flames it releases want > victims to claim for their own giddy disgust and restoration is no > longer possible." > > >From the depths of the apeiron, at a distance deeper than hell itself a > bright light expands devouring each bit of darkness in its wake. If you > listen, you can hear it speak the sound - the sound of creation. >-- End of excerpt from MEINKING(a)delphi.com You wouldn't be desribing the weapons discussion on "cypherpunks" list for the past few days, would you? -- Raymond H. Misra

2 1

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

17 Dec '03

In message <199408262009.NAA17046(a)unix.ka9q.ampr.org> Phil Karn writes: > > Yes, but even scalar multiplication is so much faster on a DSP than on > most general purpose CPUs that it seems like a definite win. The 486 > takes from 13-42 clock cycles to perform a multiply, depending on the > operand sizes and number of significant bits in the multiplier. The Motorola DSP96002 does an integer multiply in 2 or 3 clocks, so a 33 MHz device does 11 million multiplies (and moves) a second. The chip costs about $50. The newer TI C40 does a 32-bit integer multipy in 1 clock, so a 50 MHz device can output 200 MB/s of results. It can read in a single clock cycle but writes take two cycles (sometimes more). So although it can theoretically read 200 MB/s, it can only write 100 MB/s. However, it has six serial links, each one of which has a 20 MB/s bandwidth, so in theory it can pump out 100+120 = 220 MB/s. However, in practice you would expect the chip to be I/O bound. It costs something like $200 a chip. The real advantage of the C40 is that C40s can be connected together using their serial links. This allows them to be arranged in interesting 3D topologies. In this respect the C40 is intended to be an upgrade on the transputer, which has only four links, and tends to die when connected into large 2D meshes, because the transputers spend too much of their time passing messages. If C40s are connected in pipelines, with three links used as input from the preceding stage and three links used to drive the next stage, you can run them comfortably at 60MB/s. You might choose to do three multiplies on each 32-bit operand at this rate, giving you effectively multiplications at 45 MHz at each stage of the pipeline. > Even > if you couldn't keep the pipeline full on a chip like the PowerPC, you'd > still be well ahead. Ahead of the 486 maybe, but the C40 makes the PowerPC a dog. > But then I hear people say that it's not the multiplication that slows > down modular exponentiation, it's the modular reduction. Can you elaborate? -- Jim Dixon

2 1

FCC Regulation (fwd)
by Al Billings 17 Dec '03

17 Dec '03

---------- Forwarded message ---------- Date: Thu, 25 Aug 94 18:20:01 CDT From: Dave Hurst <hurst(a)vistatech.com> To: nexus-gaia(a)netcom.com, fringeware(a)illuminati.io.com, leri(a)pyramid.com Subject: FCC Regulation (fwd) Forwarded from the com-priv mailing list: (UPI) WASHINGTON, DC. The White House confirmed today that the FCC will become the Federal agency to assume responsibility for regulating the so-called "Information Super Highway." Today this consists of an autonomous network of computers known collectively as the Internet. Usually reliable sources revealed that the government is becoming increasingly apprehensive about the Internet's uncontrolled growth and the potential for damage to national security. A highly placed government source was quoted as saying "...now anyone with a thousand dollars can obtain the computer hardware and software necessary to communicate on the Internet. Irresponsible individuals can easily transmit messages worldwide. Clearly, there is a need for government regulation." In response to these concerns the FCC is rumored to be preparing restrictive regulations to assure "responsible use" of the Internet. The FCC is reportedly cooperating with other national and international agencies to coordinate these regulations. Several former eastern bloc countries and Italy are reportedly coordinating their internal regulation planning with the FCC. Although details are sketchy at this time, these new regulations are likely to take the form of some sort of license examination for Internet users. Despite the fact that a costly new government bureaucracy will be established, it will likely save money in the long run, according to government sources. "A single USENET posting may cost hundreds if not thousands of dollars, therefore, if licensing reduces such postings by only 10% the savings will more than recover these additional costs", said a highly placed government source. Expert government watchers have been able to piece together a fairly comprehensive picture of the soon-to-be-proposed license requirements. Based upon the past history of the FCC, the test will likely consist of three parts: theory, jurisprudence and practice. The theory portion of the examination will include written examination of the principles of digital logic, elements of generic machine language programming, and comprehensive knowledge of TCP/IP and network interfacing hardware. The jurisprudence portion will assess the candidate's basic knowledge of the regulations governing use of the Internet and will cover ethical as well as legal issues. Licensing will likely include an "Internet oath" requirement in which the candidate will swear to uphold certain basic standards of conduct. Users of the Internet will be required to broadcast their license numbers at logon and intermittently after connection to the Internet. The practice portion of the examination is likely to be the most controversial. Reportedly, all candidates must pass a typing skills examination and achieve no less than 40 words per minute to obtain a (temporary) novice license. This must be raised to 80 words per minute before a regular-status license will be issued. Novices will restricted to operating networked computers having speeds of less than 5 Mhz or operation of SLIP or dial-up connections of no greater than 2400 baud. (It is rumored that the FCC will make 5 Mhz replacement crystals available at a nominal charge to temporarily slow computers of novice operators). The FCC also recognizes that there are conditions when terminal emulators are not available. Therefore, an expert class will be established for communication using only numeric keypads and bi-digit numeric displays. Although needing a minimum of equipment, this mode will require sending, receiving and manual translation of raw ASCII codes. Guidelines for minimum communication rates for this mode have yet to be established while the FCC awaits public input. Although felt to be a desirable goal for all users, this class of license will only be required by individuals operating wireless (RF) LANS. Asked what the effect of proposed regulations would have on the Internet, a highly placed official noted that these rules "should not be considered prohibitive, as they simply bring regulation of the Internet in line with other communication modes under FCC governance." However, the source did feel that such regulations should be very helpful in restraining the rapid growth of the Internet.

8 9

Re: (Fwd) Something of Interest
by Blanc 17 Dec '03

17 Dec '03

From: jf_avon |I received this out of the blues. I suppose that you received it |too. ........................................................... I didn't receive it, and I set off quite a round of discussion with Jim & the list, at one point. Guess I'm not considered controversial enough to get it. :>) .. Blanc

2 1

Anon Remailers
by dwomack＠runner.utsa.edu 17 Dec '03

17 Dec '03

Some time back, Xenon maintained a list of anonymous remailers, along with what records were kept, i.e., simple counter, to & from addresses, full text for some time period, etc. I know the list is available via finger (Many compliments to those involved in that!!!), but was wondering if the record- keeping aspect was reported anywhere? And no, I've never written to whitehouse.gov, don't intend to, and wouldn't on a bet!!! Regards, Dave

1 0

Crime Bill
by Jim choate 17 Dec '03

17 Dec '03

Does anyone know if the death penalty has been extended to weapons or arms trafficking? If so this means that simply sending a disk w/ pgp on it now rates a lethal injection.... Anywhere I can get the full text? It does not appear to be up on the white house or other gov. sources yet. Thanks.

1 0

Re: PGP fanatacism
by nobody＠ds1.wu-wien.ac.at 17 Dec '03

17 Dec '03

Earlier, Tim May wrote: > Not only do many of us not do all this stuff (have you seen Eric > Hughes signing his messages? How about John Gilmore?), but some people > have decided to stop reading e-mail altogether. Donald Knuth, for > example. A wise man. > I'm happy that you PGP fans are thoroughly infatuated with using PGP > for everything. Just knock off the clucking and sighing about those > who don't see it as the end-all and be-all of today's communications. > It reeks of fanaticism. Interesting. I wonder what this says though... cypherpunks promote encryption, digital cash, dc nets, data havens... but wouldn't ever be caught actually using any of the above. Hell, that stuff is way too plebian. I'd rather advocate it that actually be in the uncomfortable position of following my own advice.

1 0

Re: PGP fanatacism (Cost-benefit analysis)
by blancw＠pylon.com 17 Dec '03

17 Dec '03

Responding to msg by nobody(a)ds1.wu-wien.ac.at Interesting. I wonder what this says though... cypherpunks promote encryption, digital cash, dc nets, data havens... but wouldn't ever be caught actually using any of the above. .................................................. I think this says is that it is important to apply the appropriate tools when it is apropos and the situation calls for it, but not when there isn't sufficient cause to warrant the time & trouble. Blanc

2 1

Crypto Panel at Rocky Mtn. Inet User's Group
by Richard Johnson 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Just a short announcement culled from the minutes of the last RMIUG meeting. It's of greatest interest to those of us in CO. I suppose the panelists on the list already know about it (but one can never be completely sure). || The next RMIUG meeting is scheduled for Tuesday, September 13th. || We will have a "Crypto-Fest" panel discussion organized by RMIUG || member Duane Thompson (ak351(a)freenet.hsc.colorado.edu) || including Phil DuBois, lawyer for Phil Zimmerman, author of the || encryption program Pretty Good Privacy (PGP), Mike Johnson, || encryption expert, engineer, software programmer, inventor of || the Diamond encryption algorith, and Phil Zimmerman himself, || speaking to us about encryption technology, the benefits and || uses of recent versions of PGP, and issues surrounding || encryption technology. The RMIUG meetings are held at the NCAR mesa facility in Boulder, CO at 7pm on the 2nd Tuesday of the month. To get there, find Table Mesa (yeah, stupid name) or South Boulder Road, and head West on it 'till you reach the end and find the building Woody Allen rapelled out of in Sleeper. The auditorium is just inside the main entrance. Show up at 6:30 for schmoozing. Rich -----BEGIN PGP SIGNATURE----- Version: 2.6 iQCVAgUBLl8EMfobez3wRbTBAQE26gP9GAjrnb/dxCP3XBKtZipjWtFE18AM7C0V t/e45SwqDXRBsn4r/5O4MEuEJUbQ0dmgBK1VvXHgwP+suPf+KbKYHi6ASFG02Ecw Mo9ZiFSUE1KHwwoiK28GrLMRBAYP5lOAKV2jyLckDfeSRmb+4fTgQB7baHH4qa7k emyKs+hlH+I= =8Rk8 -----END PGP SIGNATURE-----

1 0