December 2003 - cypherpunks-legacy

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