December 2003 - cypherpunks-legacy

NRC Session Hiss
by jya＠pipeline.com 17 Dec '03

17 Dec '03

During the Q&A of the NRC public session, it was asked why 56-bit DES was selected as the standard of export over other widely distributed programs such as PGP. The panelists seemed to me uneasy in answering this. Primarily their view was that DES was "ubquitious," well- known and tested by use. However, when pressed by later questioners on this topic, they expanded their view: that if another, stronger, program became "ubiquitous" -- in wide use -- they would support it as the standard of export. When it was pointed out that PGP now fit this definition, the panel merely repeated the statement about ubiquity without specifically affirming or denying the PGP claim. Their poker faces seemed uniformly in place to dampen a potential inflammatory topic. Perhaps other attendees will amplify this odd demeanor, but it seems to me that the panel was attempting to avoid commenting one way or the other on PGP's worldwide ubiquity for unstated reasons. I wonder if this was a nudge to the audience that the informal spread of unapproved encryption is the best way to establish its ubiquity and thereby to set a new standard for export, sort of under the noses of the authorities -- as if PGP was exemplary. Recall that this fits the Clinton administration's way of getting around the Croatian arms embargo -- the "no position" position of sidestepping legality. Also, I wonder if the panel wants avoid an open conflict with the administration, the LEAs and the security agencies about PGP. (Or do they know something about PGP that we don't know, or have been led to think they do?) Peter Neumann had pointed out earlier that crypto was going to be ubiquitous, and fairly soon, no matter what. He noted that it is the NRC's recommendation that LEAs take the "long-term, pro-active" view about this and get on with developing other technologies, and training personnel in them, to fight computer crime -- like traffic analysis, packet trace, etc. -- and to accept that prohibiting and cracking crypto is not effective. (This may have been diversionary, but he seemed sincere.) Perhaps the panel is agreeing the crypto genie is out of the bottle, and are advising the authorities to recognize that stronger and stronger crypto is going to become ubiquitous, and it's time to move on to other, presumably less ubiquitious, cyber-crime fighting technolgies. Perhaps the committee was briefed on these technolgies, or maybe some members are even developing them -- Mr. Neumann, for example, in conjunction with Ms. Denning, et al. Those who plan to attend the June 6 session might want to pursue the "no position" position about PGP's ubiquity, and why. Diversionary sop, say, to cover the promotion of non- crypto invasion of privacy. Further, it would be helpful to learn more about what the the committee members were told about "long-term" cyber- surveillance technologies in the pipeline. What bothered me more than anything else about the session was that individual privacy got such short shrift by panelists and by the audience. While there was a bit of discussion on personal privacy protection, government and business, and their mutual back-scratching, seemed to the the primary focus. Pretty Lousy Privacy appears to be in the works, judging from what was not disclosed in the session (and in the report) about two 800-pounders working in concert at citizen data gathering, mining, selling, controlling, dominating -- at the expense of individual privacy, and, shout it, liberty. Peter Neumann got to me when he described the "downside" of anonymity, encryption and security: how can we know who are the criminals if we don't for sure who is who and know for sure who is doing what? Not a single panelist disagreed with his statement about this, but then I heard only a few snorts from the criminal-fraught-fed audience. I kept mum. Jesus, who knows who was recording every titter and hiss -- besides anonymous beside me and me.

3 2

Re: opinions on book "The Truth Machine"
by tcmay＠got.net 17 Dec '03

17 Dec '03

At 12:14 AM 6/3/96, Adam Back wrote: >Well, we don't have curfews yet, but they're getting keen on security >video cameras lately, the university has a few even, on top of >buildings, the steerable variety, and with what I presume are IR spots >mounted on them. Today's newspaper (SJ Mercury News) carried a long article about increasingly ubiquitous video surveillance cameras, and singled out the U.K. as a place that is leading. Apparently even small villages have 50 or more cameras scattered around...men have been arrested for urinating in bushes outside pubs, caught by the infrared pickups (I hadn't thought about the cameras being IR, but this makes sense, as a large fraction of street crimes take place in dark or semidark areas). The article claimed that the cameras and microphones are the latest in surveillance technology, provided by the U.K. defense establishment. Privacy advocates gave comments--they were predictably quite worried. The links with crypto policy are of course apparent. --Winston Smith Boycott "Big Brother Inside" software! We got computers, we're tapping phone lines, we know that that ain't allowed. ---------:---------:---------:---------:---------:---------:---------:---- Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay(a)got.net 408-728-0152 | anonymous networks, digital pseudonyms, zero W.A.S.T.E.: Corralitos, CA | knowledge, reputations, information markets, Licensed Ontologist | black markets, collapse of governments. "National borders aren't even speed bumps on the information superhighway."

1 0

RE: Fate of Ecash if RSA is cracked?
by Matt Thomlinson 17 Dec '03

17 Dec '03

but probably not for decent RSA key lengths -- more probably the hashing algorithm used will fall, with much the same consequences. mattt >---------- >From: dlv@bwalk.dm.com[SMTP:dlv@bwalk.dm.com] >Sent: Sunday, June 02, 1996 6:49 PM >To: cypherpunks(a)toad.com >Subject: Re: Fate of Ecash if RSA is cracked? > >ichudov(a)algebra.com (Igor Chudov @ home) writes: >> scheme gets broken somehow? Suppose, for example, that someone >> discovers an ultra-fast factoring algorithm or something like that. > >This'll happen, probably sooner than later. > >--- > >Dr. Dimitri Vulis >Brighton Beach Boardwalk BBS, Forest Hills, N.Y.: +1-718-261-2013, >14.4Kbps >

1 0

Reminder on PBS Show
by MELODYJAMES＠delphi.com 17 Dec '03

17 Dec '03

CYBER SECRETS (This week on Life on the Internet) Law enforcement agencies say that in the wrong hands, email encryption software called PGP (Pretty Good Privacy) threatens the public good. Check out the online transcript, hyperlinks and live video stream of this week's feature "Cyber Secrets" on the Life on the Internet web site. <http://www.pbs.org/internet/> The program *Life on the Internet* is broadcast on Saturday mornings in some areas. Check your listings.

1 0

"Insider Non-Trading" (Re: Insider Trading and Inside Information)
by tcmay＠got.net 17 Dec '03

17 Dec '03

At 7:15 PM 6/2/96, Mike Duvos wrote: >The SEC, in cooperation with the courts, has been gradually >shifting the definitions of "insider" and "inside information" to >more all-encompassing ones. ... >Nowdays "inside information" has been expanded to include >anything that the general public is not privy to, and "insiders" >can be almost anyone as well. ... Indeed, the recent changes to U.S. Code 18503-666, have been dubbed the "Insider Non-Trading Law." What, you may ask, is "insider non-trading"? Just as inside information may affect decisions to engage in a stock trade, so too can insider information cause a decision _not_ to engage in a stock trade! Imagine that Trader Joe was planning to sell Security Dynamics short. Perhaps with a direct short sale, or purchase of puts, or other variants. However, he learns from his golfing partner, Jim Bidzos, that RSA Data is about to be sold to SD for $250 million. Returning from his golf game, he cancels his short plans. Voila, "insider non-trading." The SEC tumbled to this some time ago, and now demands that all those who are insiders, or who are married to insiders, or who are golfing buddies of insiders register their trading intentions 90 days in advance of any transaction. (This will increase to 120 days in 1997, and 180 days the following year.) This form of "intention escrow" ensures that insider information cannot be used to cancel trades which were planned and then not pursued. Key escrow, signature escrow, identity escrow, position escrow, and, now, intention escrow. Welcome to the Escrow Society. --Tim May (P.S. Stu Brownstein, a Bay Area friend of mine, came up with this "insider non-trading" joke several years ago. He once thought about writing a letter to the "NYT" pointing out how insider trading laws must also imply insider non-trading laws, but a Washington friend of his, he claims, told him not to. "It may give the SEC ideas," he said.) Boycott "Big Brother Inside" software! We got computers, we're tapping phone lines, we know that that ain't allowed. ---------:---------:---------:---------:---------:---------:---------:---- Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay(a)got.net 408-728-0152 | anonymous networks, digital pseudonyms, zero W.A.S.T.E.: Corralitos, CA | knowledge, reputations, information markets, Licensed Ontologist | black markets, collapse of governments. "National borders aren't even speed bumps on the information superhighway."

2 1

Surveillance Cameras
by anonymous-remailer＠shell.portal.com 17 Dec '03

17 Dec '03

Tim May wrote: >Today's newspaper (SJ Mercury News) carried a long article about >increasingly ubiquitous video surveillance cameras, and singled out the >U.K. as a place that is leading. There was a news report on this a couple of months ago. In addition to the government surveillance cameras, when there's a major crime in the U.K. the cops have started collecting all the security tapes from offices, gas stations, railway stations, etc, etc in the surrounding area and scanning them to try to find the culprits. The interesting things that they said were : 1. The cameras only reduce crime rates locally, as the criminals simply move to areas without cameras. 2. The real criminals (e.g. IRA bombers) know how to disguise themselves well enough that the cameras cannot easily be used to identify them. 3. The cameras are often pointed in the wrong direction, not switched on or aren't recording. A good example is the London club which was bombed a year or so back. The bomber walked up to the entrance and placed the bomb directly in view of the security camera. It was switched off at the time ... 4. Even when people are recorded, the resolution is often too poor to identify them. So it appears that the cameras are great for arresting people who urinate in bushes, but useless for catching real criminals. Alice de 'nonymous ... ...just another one of those... P.S. This post is in the public domain. C. S. U. M. O. C. L. U. N. E.

1 0

Re: opinions on book "The Truth Machine"
by tcmay＠got.net 17 Dec '03

17 Dec '03

At 12:14 AM 6/3/96, Adam Back wrote: >Tim May <tcmay(a)got.net> wrote: >> At 11:53 AM 6/1/96, Adam Back wrote: >> >Tim May <tcmay(a)got.net> wrote: >> [...] Maybe the "make.money.fast" description was a poor one...what I meant >> to imply is that the book is being advertised widely (I've seen half a >> dozen announcements of it), > >Ah .. I misunderstood, the ad is being spammed. We have a truly awful >news feed which gets around 2 weeks of lag, at time of posting that >was the only one I'd seen. And I thought my newsfeed was bad! Do an Alta Vista (or DejaNews, etc.) search of "The Truth Machine" and you'll find about 300 articles on Usenet about it. However, about 95% of them are from jhalpe(a)ix.netcom.com, the author of this media event novel or from ivypress(a)ix.netcom.com, his vanity publisher. (Actually, maybe Ivy Press is not a vanity publisher. Maybe Ivy Press is what might me dubbed a "Cantwell and Siegel publisher.") And the groups this was posted to....mama mia! This is why I was irked that this spam was leaking into the Cypherpunks group as well. But no harm done, and it demonstrates another example of how the Net is being used for such advertising. Imminent death of the Net predicted--news at 11. --Tim May Boycott "Big Brother Inside" software! We got computers, we're tapping phone lines, we know that that ain't allowed. ---------:---------:---------:---------:---------:---------:---------:---- Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay(a)got.net 408-728-0152 | anonymous networks, digital pseudonyms, zero W.A.S.T.E.: Corralitos, CA | knowledge, reputations, information markets, Licensed Ontologist | black markets, collapse of governments. "National borders aren't even speed bumps on the information superhighway."

1 0

The Elevator Problem
by Deranged Mutant 17 Dec '03

17 Dec '03

This may be old hat, but an earlier post (around the time the Kocher RSA-timing attack came out) to the list asked about the "Elevator Problem", where two parties who think they share the same secret want to confirm it on an open channel. I came up with an idea for a protocol but never got around to posting it, and dropped off the list briefly... so pardon me if this is already touched upon. Alice and Bob are in a crowded place and want to confirm they share a secret. Each picks a couple of random numbers, b and i. The secret P is hashed i times, something like: H_0(P) = H(P,0) [H can be something like SHA-1...] H_i(P) = H(H_i-1(P), i) They then tell each other bit b of H_i(P). This is repeated a number of times to make random guessing very unlikely. If all bits match, they agree that they share the secret (we assume neither wants to lie but discover if the other knows the secret). Since this is a mutual protocol, an eavesdropper who listens in shouldn't be able to spoof Alice or Bob. Or maybe Alice and Bob can agree never to reuse combinations of b and i anyway (or they can append a counter to the secret, so that combinations of b and i never give the same values). Could be useful for implementing as a remote login? Comments? Rob. --- No-frills sig. Befriend my mail filter by sending a message with the subject "send help" Key-ID: 5D3F2E99 1996/04/22 wlkngowl(a)unix.asb.com (root@magneto) AB1F4831 1993/05/10 Deranged Mutant <wlkngowl(a)unix.asb.com> Send a message with the subject "send pgp-key" for a copy of my key.

1 0

IR Cameras
by Jim Choate 17 Dec '03

17 Dec '03

Forwarded message: > Date: Sun, 2 Jun 1996 20:19:34 -0700 > From: tcmay(a)got.net (Timothy C. May) > Subject: Re: opinions on book "The Truth Machine" > > Today's newspaper (SJ Mercury News) carried a long article about > increasingly ubiquitous video surveillance cameras, and singled out the > U.K. as a place that is leading. Apparently even small villages have 50 or > more cameras scattered around...men have been arrested for urinating in > bushes outside pubs, caught by the infrared pickups (I hadn't thought about > the cameras being IR, but this makes sense, as a large fraction of street > crimes take place in dark or semidark areas). Here in Austin, TX there is at least 1 IR camera located at the top of the police building downtown (8th & IH-35). Many intersections have stoplight synchronized cameras for getting license plates of red light runners (eg N. Lamar & 51st). I know the output of the cameras is cabled off-pole (can see the cables) to a NEMA style box. Don't know the format from there. It would be no technological leap to buy cable channels and mux the pictures back to a centralized site. This city is lousy with cable and fiber and the city bought in from the get-go with a project called I-Net in the mid-80's. Jim Choate

2 1

Re: The Elevator Problem
by Tim Dierks 17 Dec '03

17 Dec '03

At 7:50 PM 6/2/96, Deranged Mutant wrote: >Alice and Bob are in a crowded place and want to confirm they share a >secret. > >Each picks a couple of random numbers, b and i. The secret P is >hashed i times, something like: > > H_0(P) = H(P,0) [H can be something like SHA-1...] > H_i(P) = H(H_i-1(P), i) > >They then tell each other bit b of H_i(P). > >This is repeated a number of times to make random guessing very >unlikely. > >If all bits match, they agree that they share the secret (we assume >neither wants to lie but discover if the other knows the secret). It doesn't seem to me like it needs to be this complex. Here's a couple of protocols I can think of: For a secret S: Alice and Bob generate and exchange random nonces. Then they calculate the HMAC of S using the other's nonce as the MAC secret. They exchange HMACs and each verify that their peer has correctly calculated the HMAC given the secret and the nonce. - or - Each of Alice and Bob hash S and use the result as a symmetric encryption key; they then attempt to exchange messages. If they can exchange messages, they must have arrived at the same key, and thus be using the same S. To avoid replay attacks, exchange nonces and use them as a part of the key calculation. Note that neither of these reveals that you know S unless your peer knows S; noone who doesn't know S can determine if Alice or Bob actually know S or if they're using some other faked value (except for analysis of the repercussions of the exchange). - Tim Tim Dierks -- timd(a)consensus.com -- www.consensus.com Head of Thing-u-ma-jig Engineering, Consensus Development

1 0

Security of PGP if Secret Key Available?
by Robert A. Hayden 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- About once a week we get some lame-o flame bait posted to alt.security.pgp or this mailing list or somewhere abotu some hole in PGP. We further say with fairly good reliability that they are bogus, get a light chuckle, and then go back to dealing with the real issues. However, I got to wondering about the security of PGP assuming somebody trying to read my PGPed stuff has my 1024-bit secret key. ie, if I have it on my personal computer, and somebody gets my secret key, how much less robust has PGP just become, and what are appropriate and reasonable steps to take to protect this weakness? Thanks -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: PGP Signed with PineSign 2.2 iQCVAwUBMbJ5xTokqlyVGmCFAQGcAgQAvjFdZ+YLdQGxDHcT+GOwP82BSwiTYlaQ F9RV8L+radCK/SyeLnEtoodkKVqpcsItIQ/JJ44FOAmnsBLljuWqbhZMl8G8+uCB pcpkXpre83CwoM6qDKkCEyqCiMxq857ioCoqb+WRNJYbb++muVBDHADVzGoGOjLg cvIMxnnXF3c= =tnTb -----END PGP SIGNATURE----- ____ Robert A. Hayden <=> hayden(a)krypton.mankato.msus.edu \ /__ Finger for Geek Code Info <=> Finger for PGP Public Key \/ / -=-=-=-=-=- -=-=-=-=-=- \/ http://krypton.mankato.msus.edu/~hayden/Welcome.html -----BEGIN GEEK CODE BLOCK----- Version: 3.12 GED/J d-- s:++>: a- C++(++++)$ ULUO++ P+>+++ L++ !E---- W+(---) N+++ o+ K+++ w+(---) O- M+$>++ V-- PS++(+++)>$ PE++(+)>$ Y++ PGP++ t- 5+++ X++ R+++>$ tv+ b+ DI+++ D+++ G+++++>$ e++$>++++ h r-- y+** ------END GEEK CODE BLOCK------

2 1

Why PGP isn't so ubiquitous (was NRC Session Hiss)
by Deranged Mutant 17 Dec '03

17 Dec '03

On 2 Jun 96 at 21:15, Lucky Green wrote: > That PGP is ubiquitous is subject to discussion. PGP is widely available, > but that doesn't mean that it is widely used. What percentage of email is > PGP encrypted? Less than half a percent? In part because it's not well integrated with mailers. That could change with a PGP3 DLL. PGP isn't only used for email: o files distributed over the net that are PGP-signed o signed email o non-emailed file distributions (over BBS, or physical transfer of disks) o personal storage (though other utilities are better-suited for that than PGP) o related utilities that make use of PGP-keys (HPack archiver) The reasons PGP hasn't become widely used are because of it's lack of user-friendliness and poor integration into other tools, irregardless of S/MIME. Rob. --- No-frills sig. Befriend my mail filter by sending a message with the subject "send help" Key-ID: 5D3F2E99 1996/04/22 wlkngowl(a)unix.asb.com (root@magneto) AB1F4831 1993/05/10 Deranged Mutant <wlkngowl(a)unix.asb.com> Send a message with the subject "send pgp-key" for a copy of my key.

2 2

PRY_ing
by jya＠pipeline.com 17 Dec '03

17 Dec '03

6-3-96. NYP: "As privacy grows scarcer on the Internet, people finally start to take notice." Denise Caruso column. Tomorrow, the Federal Trade Commission's Bureau of Consumer Protection is sponsoring a public workshop in Washington called "Consumer Privacy on the Global Information Infrastructure." The F.T.C.'s intention is to find out how much consumers and the industry really know about critical privacy issues created by what it calls "the emerging on-line marketplace," and to look at various ways to protect personal data. Privacy on data networks is a complex issue. It includes thorny questions about anonymity -- who should be allowed to be anonymous in network interactions, and under what circumstances -- and the red-hot debate over digital encryption, which can protect private communication and transactions from all prying eyes, including the Government's. PRY_ing

1 0

Re: The Elevator Problem
by Blake Wehlage 17 Dec '03

17 Dec '03

At 02:50 AM 6/3/96 +0000, Deranged Mutant wrote: > >This may be old hat, but an earlier post (around the time the Kocher >RSA-timing attack came out) to the list asked about the "Elevator >Problem", where two parties who think they share the same secret want >to confirm it on an open channel. I came up with an idea for a >protocol but never got around to posting it, and dropped off the list >briefly... so pardon me if this is already touched upon. > >Alice and Bob are in a crowded place and want to confirm they share a >secret. > >Each picks a couple of random numbers, b and i. The secret P is >hashed i times, something like: > > H_0(P) = H(P,0) [H can be something like SHA-1...] > H_i(P) = H(H_i-1(P), i) > >They then tell each other bit b of H_i(P). > >This is repeated a number of times to make random guessing very >unlikely. > >If all bits match, they agree that they share the secret (we assume >neither wants to lie but discover if the other knows the secret). > >Since this is a mutual protocol, an eavesdropper who listens in >shouldn't be able to spoof Alice or Bob. Or maybe Alice and Bob can >agree never to reuse combinations of b and i anyway (or they can >append a counter to the secret, so that combinations of b and i never >give the same values). > >Could be useful for implementing as a remote login? > > >Comments? > > > >Rob. > >--- >No-frills sig. >Befriend my mail filter by sending a message with the subject "send help" >Key-ID: 5D3F2E99 1996/04/22 wlkngowl(a)unix.asb.com (root@magneto) > AB1F4831 1993/05/10 Deranged Mutant <wlkngowl(a)unix.asb.com> >Send a message with the subject "send pgp-key" for a copy of my key. > > Its a good thought, I never even thought about it, but it should work. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Blake "Pokey" Wehlage Gaa- 3.69 <jwilk(a)iglou.com> Record- 2-4-4 Age- 13 Final Standings- 2nd Place (Beat in Championship) President & Founder: Revolution Software "I have the fastest glove in the east!" Profanity Software "Hackers never stop hacking they just get caught" VSoft My life- Rarely eat or sleep, Hack til' 7:00a, goto school, play goalie til' 5:00p, hack til' 7:00a Hank Aaron- d:-)!-< Pope- +<:-) Santa Claus- *<:-) The Unabrower |:-) Current Girlfriend(s)- Lindsey Wilcox, Laura Schubring ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

1 0

Newsweek on Crypto
by jya＠pipeline.com 17 Dec '03

17 Dec '03

Newsweek, June 10, 1996, pp. 49-55. Scared Bitless The arcane world of cryptography used to be the exclusive realm of spies. Now it's everybody's business -- to the chagrin of the government. By Steven Levy [Photo] Loosen up: Sen. Conrad Burns says the United States should ease the export rules on crypto software On the face of it, the issue of cryptography -- the technology that employs secret codes to protect information -- seems more suited to math class than "The McLaughlin Group." Yet this once esoteric subject has wound up in the center of a Beltway controversy, complete with congressional infighting, lobbyists, entrenched government agencies, blue-ribbon reports and even a bit of presidential politics. This sudden spotlight on what was previously the domain of deep-black spy stuff turns out to be a good thing, because in the Information Age crypto policy is more than an abstraction: it could provide the difference between security and vulnerability, or even between life and death. Unfortunately, choosing the right policy is not a given, and there the controversy lies. Here's the problem: we're increasingly entrusting information to computers -- everything from confidential medical records to business plans to money itself. But how can we provide security so that these data will be protected from eavesdroppers, thieves and saboteurs? The answer hinges on cryptography. By scrambling the information into digital codes, it allows only those entrusted with the keys to decipher those files to see them. Some hot-shot cryptographers have developed systems that can provide all of us with unprecedented security, automatically coding and decoding in such a way that we won't have to know it's there. (We can even have our phone calls encoded something Prince Charles might have appreciated.) Silicon Valley would love to set such a system in motion. It not only would generate revenues, but would also address the main problem that's keeping the Internet from fulfilling its potential as a center of commerce: security. Problem solved? Not quite. Law-enforcement and national-security agencies view this prospect with dread. Legal eavesdroppers, like FBI wiretappers and National Security Agency snoopers, couldn't make sense of intercepted transmissions. They warn that we could miss indications of a terrorist act, like a nuke smuggled into Manhattan. In addition, drug dealers, child pornographers and garden-variety thugs could mask their activities with a mere mouse click. Even before the Clinton administration took office, the NSA and FBI presented those nightmare scenarios to the transition team. The Clintonites were scared bitless. They vowed to make sure that the worst didn't happen. They understood that cryptography should be put to general use -- but only if it were altered in such a way that the government could, if necessary, get access to secret messages, using a new technology known as "key escrow." The best-known of those schemes was the ill-fated Clipper Chip, and subsequent systems haven't caught on. (Yet another was presented two weeks ago.) Until then they would maintain the strict export controls that treat crypto software as powerful munitions. That's right -- Uncle Sam regards that copy of Netscape you downloaded as sort of a Stinger missile. But now the government position of slowing down the flow of crypto is under increasing attack. Software companies complain that regulations cost them money and hold down innovation. Privacy groups complain that the controls reek of Orwell's "1984." Congress is demanding changes. Bob Dole wants to make it an issue. And on Thursday came what Sen. Conrad Burns, a Montana Republican, called "the nail in the coffin" of the Clinton crypto policy: a report by the National Research Council that clearly rebukes the administration's position. Despite the Clinton-Gore attempt to protect us against the abuse of cryptography, says the Congress-commissioned report, our safety is at risk -- because the lack of cryptography has weakened our security. Under particular attack are the regulations that limit the strength of exported software like IBM's Lotus Notes, mostly by mandating that the keys that encode and decipher the information not exceed 40 bits (the longer the key, the stronger the protection). Often, domestic users have to settle for this crippled crypto: since software companies are loath to release two versions of their products, they simply choose to offer the weaker, approved-for-export version. Meanwhile, foreign companies have no such restrictions, and U.S. companies maintain they are losing sales. Congress has taken up their case; bills introduced by Sen. Patrick Leahy, Rep. Bob Goodlatte and Burns all would relax the export rules. "These bills are pro-privacy, pro-jobs and pro-business," says Leahy. While prospects for passage are slim, the fact that a sizable number of legislators are defying intelligence and law-enforcement agencies is itself significant. Crypto policy is even finding its way into the presidential campaign. On a visit to Silicon Valley, Bob Dole was alerted to the problem by Netscape CEO Jim Barksdale. He also saw a chance to chip away at Clinton's support in the high-tech world. Dole not only cosponsored the Senate bills but issued a neo-cypherpunk statement charging that "the administration's big brother proposal will literally destroy America's computer industry." The NRC report, entitled "Cryptography's Role in Securing the Information Society," stands as the most serious challenge to current policy. It is drenched in credibility: its 16 authors include former attorney general Benjamin Civiletti, onetime NSA deputy director Ann Caracristi, privacy expert Willis Ware and cryptographer Martin Hellman. The panel was briefed by all sides of the issue, including some classified sessions with government officials. Despite the group's diversity, it reached consensus: "Widespread commercial and private use of cryptography is inevitable in the long run and ... its advantages, on balance, outweigh its disadvantages." The NRC made some specific recommendations. The government should stop building a system around the umproven Clipper-style technology. The export regulations should be relaxed, specifically permitting free export of the well-tested Data Encryption Standard, which uses a 56-bit key. (While some argue for even bigger keys, this is a significant jump. The increase in key size alone means that theoretically it will be more than 65,000 times harder to crack a code.) Perhaps the strongest rebuke came with the rejection of the "if you only knew" defense. The committee concluded that informed decisions on crypto could be made without access to classified material. If the NRC advice was followed, would criminals hide nefarious activities behind a digital wall of gibberish? Quite possibly, admits the committee -- but without action to promote crypto, we are increasingly dependent on a computer-controlled world with insufficient protection. "We're encouraging a world that supports greater confidentiality -- but we think it's worth the risk," says panelist Ray Ozzie, creator of IBM's Lotus Notes. The committee cited security breaches like the recent raid on Citicorp by Russian hackers, and warned that without crypto, we are more vulnerable to "information warfare" threats -- endangering operations like the air-traffic-control system. The government's response? "We do care about the security of information, but we need to do it in a way that does not diminish law enforcement," says an administration official. "People writing academic reports can take chances. But when you are the policeman, you have to err on the side of protecting people." The question is, which approach provides the most protection? The NRC report undercuts the government's position at a time when many were already beginning to question it. On May 21, 11 senators sat down in a bugproof room for a classified briefing, presumably designed to make them rethink their proposals. But, said Leahy, "no one seemed to change their mind." Looks like they've cracked the code. [Two photos] 'Pro-privacy, pro-jobs, pro-business': Sen. Patrick Leahy (right) and Lotus Notes creator Ray Ozzie think strong codes will make a stronger economy _________________________________________________________ [Box] Sending Messages In Private Cryptography makes it possible to turn intelligible words into a hodgepodge of letters, numbers and symbols, keeping them out of the hands of cybersnoops. [Illustration: computer > key > encrypted message > key > computer.] To send a private message through a network, a cryptography program is used to "lock" the message -- making it unreadable to anyone who intercepts it. The program generates a secret, digital key when it scrambles the message. The receiver then uses the key to translate the message back into plain text. _________________________________________________________ [End] Thanks to SL and Newsweek.

1 0

Re: Floating Point and Financial Software
by Joseph L. Moll 17 Dec '03

17 Dec '03

I have seen monetary items represented as integers, with the software assuming that the last two digits are actually the "cents" part of the float. There are still round off problems with this scheme, but the calculations are much faster since they are integers. --- Joseph L. (Joe) Moll -- Network and Communications Engineering mailto:jmoll@acquion.com http://www.acquion.com phone:864-281-4108 ACQUION, Inc. Greenville, SC USA -- Specialists in Electronic Commerce disclaimer: This email is not to be considered official correspondence ---

1 0

List of reliable remailers
by Raph Levien 17 Dec '03

17 Dec '03

I operate a remailer pinging service which collects detailed information about remailer features and reliability. To use it, just finger remailer-list(a)kiwi.cs.berkeley.edu There is also a Web version of the same information, plus lots of interesting links to remailer-related resources, at: http://www.cs.berkeley.edu/~raph/remailer-list.html This information is used by premail, a remailer chaining and PGP encrypting client for outgoing mail. For more information, see: http://www.c2.org/~raph/premail.html For the PGP public keys of the remailers, finger pgpkeys(a)kiwi.cs.berkeley.edu This is the current info: REMAILER LIST This is an automatically generated listing of remailers. The first part of the listing shows the remailers along with configuration options and special features for each of the remailers. The second part shows the 12-day history, and average latency and uptime for each remailer. You can also get this list by fingering remailer-list(a)kiwi.cs.berkeley.edu. $remailer{"extropia"} = "<remail(a)miron.vip.best.com> cpunk pgp special"; $remailer{"portal"} = "<hfinney(a)shell.portal.com> cpunk pgp hash"; $remailer{"alumni"} = "<hal(a)alumni.caltech.edu> cpunk pgp hash"; $remailer{"c2"} = "<remail(a)c2.org> eric pgp hash reord"; $remailer{"penet"} = "<anon(a)anon.penet.fi> penet post"; $remailer{"flame"} = "<remailer(a)flame.alias.net> cpunk mix pgp. hash latent cut post reord"; $remailer{"mix"} = "<mixmaster(a)remail.obscura.com> cpunk mix pgp hash latent cut ek ksub reord ?"; $remailer{"replay"} = "<remailer(a)replay.com> cpunk mix pgp hash latent cut post ek"; $remailer{"ecafe"} = "<cpunk(a)remail.ecafe.org> cpunk mix"; $remailer{"amnesia"} = "<amnesia(a)chardos.connix.com> cpunk mix pgp hash latent cut ksub"; $remailer{'alpha'} = '<alias(a)alpha.c2.org> alpha pgp'; $remailer{"lead"} = "<mix(a)zifi.genetics.utah.edu> cpunk pgp hash latent cut ek"; $remailer{"treehole"} = "<remailer(a)mockingbird.alias.net> cpunk pgp hash latent cut ek"; $remailer{"exon"} = "<remailer(a)remailer.nl.com> cpunk pgp hash latent cut ek"; $remailer{"vegas"} = "<remailer(a)vegas.gateway.com> cpunk pgp hash latent cut"; $remailer{"haystack"} = "<haystack(a)holy.cow.net> cpunk mix pgp hash latent cut ek"; catalyst(a)netcom.com is _not_ a remailer. lmccarth(a)ducie.cs.umass.edu is _not_ a remailer. usura(a)replay.com is _not_ a remailer. Groups of remailers sharing a machine or operator: (c2 alpha) (flame replay) (alumni portal) Use "premail -getkeys pgpkeys(a)kiwi.cs.berkeley.edu" to get PGP keys for the remailers. Fingering this address works too. Note: The remailer list now includes information for the alpha nymserver. Last update: Mon 3 Jun 96 6:47:19 PDT remailer email address history latency uptime ----------------------------------------------------------------------- replay remailer(a)replay.com ********+*** 6:17 99.89% vegas remailer(a)vegas.gateway.com ** * *--**** 37:04 99.82% amnesia amnesia(a)chardos.connix.com ------------ 3:52:31 99.74% flame remailer(a)flame.alias.net -----++---++ 1:25:32 99.74% exon remailer(a)remailer.nl.com +***#- * *+* 5:48 99.33% ecafe cpunk(a)remail.ecafe.org ####+**##*#* 1:17 99.31% alpha alias(a)alpha.c2.org *+ +++-++**+ 45:57 99.26% c2 remail(a)c2.org +- ++.-+++++ 57:37 99.24% haystack haystack(a)holy.cow.net +*-***#+# ## 10:00 98.62% penet anon(a)anon.penet.fi _-. .___ -- 40:43:38 97.37% extropia remail(a)miron.vip.best.com ----------- 9:35:17 97.17% alumni hal(a)alumni.caltech.edu *#-+##* -## 15:58 95.46% mix mixmaster(a)remail.obscura.com .--++--+++- 2:29:31 94.30% portal hfinney(a)shell.portal.com *#-+##*# ## 17:14 93.19% lead mix(a)zifi.genetics.utah.edu +++++++++++ 36:51 92.05% treehole remailer(a)mockingbird.alias.net - .--.-.- 8:47:35 90.83% History key * # response in less than 5 minutes. * * response in less than 1 hour. * + response in less than 4 hours. * - response in less than 24 hours. * . response in more than 1 day. * _ response came back too late (more than 2 days). cpunk A major class of remailers. Supports Request-Remailing-To: field. eric A variant of the cpunk style. Uses Anon-Send-To: instead. penet The third class of remailers (at least for right now). Uses X-Anon-To: in the header. pgp Remailer supports encryption with PGP. A period after the keyword means that the short name, rather than the full email address, should be used as the encryption key ID. hash Supports ## pasting, so anything can be put into the headers of outgoing messages. ksub Remailer always kills subject header, even in non-pgp mode. nsub Remailer always preserves subject header, even in pgp mode. latent Supports Matt Ghio's Latent-Time: option. cut Supports Matt Ghio's Cutmarks: option. post Post to Usenet using Post-To: or Anon-Post-To: header. ek Encrypt responses in reply blocks using Encrypt-Key: header. special Accepts only pgp encrypted messages. mix Can accept messages in Mixmaster format. reord Attempts to foil traffic analysis by reordering messages. Note: I'm relying on the word of the remailer operator here, and haven't verified the reord info myself. mon Remailer has been known to monitor contents of private email. filter Remailer has been known to filter messages based on content. If not listed in conjunction with mon, then only messages destined for public forums are subject to filtering. Raph Levien

1 0

Re: Java Crypto API questions
by Kevin Jessup 17 Dec '03

17 Dec '03

Jeff Weinstein <jsw(a)netscape.com> wrote... > Not likely. Sun will probably be required to agree not to do this >as a condition of exporting software with "pluggable crypto". Software >with hooks for crypto functions is treated the same as the actual crypto >as far as the ITAR is concerned. > > --Jeff Just WHAT is a "hook" for crypto?? ;-) I've read about the Microsoft crypto API, other such hooks and the "ban on hooks", but who says a "hook" must be so "generic". With things such as the "component object model" stuff Microsoft is pushing and similar technologies in the UNIX world, I can still see "hooking" to crypto. Though perhaps more on an application-specific basis and not so "generically". I acknowledge that crypto which is nearly "invisible" to the end-user will make it more widespread, and thus the need for a generic API. Politicians and technology: like oil and water. -- "Rest enough for the individual man - [but] too Kevin Jessup much or too soon and we call it Death. But for software engineer MAN, no rest and no ending. He must go on, Marquette Medical Systems conquest beyond conquest...and when he has http://www.mei.com conquered all the depths of space and all the PGP Email preferred mysteries of time, still he will be beginning." kevin.jessup(a)meipws.mis.mei.com -- H.G. Wells, Things To Come

1 0

Re: Why PGP isn't so ubiquitous (was NRC Session Hiss)
by Bruce Baugh 17 Dec '03

17 Dec '03

At 04:33 AM 6/3/96 +0000, Deranged Mutant wrote: >In part because it's not well integrated with mailers. That could >change with a PGP3 DLL. I have a growing feeling that PGP 3 is never going to happen. Or that if it does, it will happen only after the passage of more draconian anti-privacy laws, and the guys working on it will be forced to include sundry backdoor stuff or drop it altogether. I suspect someone could do quite nicely by going ahead and developing a 2.6.2 or 2.6.3 DLL. -- Bruce Baugh bruce(a)aracnet.com http://www.aracnet.com/~bruce

1 0

Re: Java Crypto API questions
by jim bell 17 Dec '03

17 Dec '03

At 02:17 AM 6/3/96 -0700, Jeff Weinstein wrote: >Andrew Loewenstern wrote: >> >> Moltar Ramone writes: >> > Probably. But they won't be able to export the signed 3DES >> > package :) It leaves foreign vendors in trouble, is where. >> >> Sun can export the signature though. The vendor already has the package, >> they just need the sig/cert... > > Not likely. Sun will probably be required to agree not to do this >as a condition of exporting software with "pluggable crypto". Software >with hooks for crypto functions is treated the same as the actual crypto >as far as the ITAR is concerned. But you haven't explained why somebody can't export JUST the signature. You know, import the software, have Sun sign it domestically, strip off everything that isn't a signature, and export the signature. Append it to the un-imported code outside the country. Jim Bell jimbell(a)pacifier.com

2 1

Re: Java Crypto API questions
by jim bell 17 Dec '03

17 Dec '03

At 01:13 PM 6/3/96 -0400, Simon Spero wrote: >On Mon, 3 Jun 1996, jim bell wrote: >> >> But you haven't explained why somebody can't export JUST the signature. You >> know, import the software, have Sun sign it domestically, strip off everything that isn't a >> signature, and export the signature. Append it to the un-imported code >> outside the country. > >Ancillary device... It's pretty clear cut. Sure about that? Is a microprocessor an "ancillary device"? A DRAM module? A hard disk? How about an operating system, which stores and retrieves data for an encryption program? How about a BIOS? What about a keyboard? A video display? I think that any definition of "ancillary device" which is so broad as to include signatures just about has to include any any of these things too, but it won't be considered such because the government has already lost the battle on hardware exports. A signature is just that: A signature. It doesn't encrypt or decrypt. It doesn't even ALLOW the system it's in to encrypt or decrypt, because there are numerous encryption programs written that have no need for such a signature. If no program existed which _used_ that signature, nobody would think twice about exporting it. The fact is, it is LEGAL to import encryption code into the US. It is LEGAL to generate an hash of that code, and it is LEGAL to export that hash. To believe otherwise is to broadly expand the scope of export laws far beyond what they were intended to mean. Jim Bell jimbell(a)pacifier.com

1 0

[Noisy] More curfews (was Re: opinions on book "The Truth Machine")
by Rev. Mark Grant, ULC 17 Dec '03

17 Dec '03

On Sat, 1 Jun 1996, Adam Back wrote: > political climate. Having just read your post on curfews my response > was what the fuck, are you serious? It totally amazes me that public > opinion has got to the stage that something like this would be > accepted. Interesting that the day after you posted this the front-page of the UK's major newspapers carried a story about the Labour party proposing precisely the same thing in the UK. Of course the cops already have surveillance cameras all over the place. > I'm not sure where I would stand on this legally, but I have so far > resisted the temptation to tell them it's none of their business. I tried it a few weeks ago when they stopped me for a random breath test (illegal as far as I know) after following me for three miles while I scrupulously obeyed the law. They originally claimed that they had stopped me randomly, because "that's what I pay them for", but when I questioned the legality they decided that I'd crossed the centerline while passing a parked car and therefore must be drunk (even though my car was too wide to not cross the line). In other words, I don't think they care about the legal issues. Still, I suppose it's better than being stopped for "driving at 2:30 in the morning" again. Hmm, who said the UK didn't have a curfew already? > They are I think > talking about making it law that all target pistols must be kept at > the gun club (whereas currently you can take them home to clean (but > not shoot)). Gun-thieves will love that one. Why steal them one at a time when you can steal twenty or thirty in one go? Mark "Out of Europe in a few more days" Grant

1 0

Re: Security of PGP if Secret Key Available?
by Henry Huang 17 Dec '03

17 Dec '03

On Jun 3, 2:36, "Robert A. Hayden" wrote: > However, I got to wondering about the security of PGP assuming somebody > trying to read my PGPed stuff has my 1024-bit secret key. ie, if I have > it on my personal computer, and somebody gets my secret key, how much > less robust has PGP just become, and what are appropriate and reasonable > steps to take to protect this weakness? If someone else has your secret key, it's safe to assume you're toast. ;) Better a new key and revocation certificate before the forgeries start (or before someone ELSE does before you ... <shudder>). More specifically, if you've failed to assign a passphrase to your secret key, you ARE toast, because anyone can just pick it up and use it. If you did use a passphrase, it becomes a question of breaking either the passphrase, or the IDEA algorithm used to encrypt your secret key. It's usually a lot easier to break the passphrase than it is to brute force IDEA. See the PGP Passphrase FAQ (http://www.stack.urc.tue.nl/~galactus/remailers/passphrase-faq.html) and Arnold Reinhold's page (http://world.std.com/~reinhold/papers.html) for more details. -H

1 0

Re: Java Crypto API questions
by shamrock＠netcom.com 17 Dec '03

17 Dec '03

At 2:17 6/3/96, Jeff Weinstein wrote: >> Sun can export the signature though. The vendor already has the package, >> they just need the sig/cert... > > Not likely. Sun will probably be required to agree not to do this >as a condition of exporting software with "pluggable crypto". Software >with hooks for crypto functions is treated the same as the actual crypto >as far as the ITAR is concerned. Then how can Sun claim that their system is 1. Exportable 2. Does RC-4 and DES? The Java Crypto AIP presentation slides that are available on Sun's website clearly make both claims. Unfortunately, the feedback address that Sun provides in the slides is unknow to their mailserver (at least it was last week) and no further information seem to be avaiable about their "public and open" policy. Confused, Disclaimer: My opinions are my own, not those of my employer. -- Lucky Green <mailto:shamrock@netcom.com> PGP encrypted mail preferred.

1 0

Re: Why PGP isn't so ubiquitous (was NRC Session Hiss)
by shamrock＠netcom.com 17 Dec '03

17 Dec '03

At 21:33 6/2/96, Deranged Mutant wrote: >The reasons PGP hasn't become widely used are because of it's lack of >user-friendliness and poor integration into other tools, irregardless >of S/MIME. I concur. It is that lack of integration that gave S/MIME the space to grow in. Now it is too late to achieve the market dominance that PGP should have achieved long ago. S/MIME *will* be the email encryption standard used by Joe Sixpack. Disclaimer: My opinions are my own, not those of my employer. -- Lucky Green <mailto:shamrock@netcom.com> PGP encrypted mail preferred.

1 0