December 2003 - cypherpunks-legacy

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

DEMOGRAPHICS v. ANONYMITY
by Sandy Sandfort 17 Dec '03

17 Dec '03

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ SANDY SANDFORT ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ C'punks, At 07:19 AM 6/3/96 +0200, "Senator Exon" wrote: >... demographic data on big spenders is worth more than >anonymous cash from people who buy packages of gum. Much >more. A true, but irrelevant. The correct dichotomy is between demographic data on big spenders and anonymous big spenders. Yes, it would be nice to have demographics on everyone, but demographics are secondary to sales. >An economy of big spenders is worthless unless they're in >your store. The cards give evidence of who spends in your >store, so you target your advertisements accordingly. Of course, there are other ways to get demographics and other ways to target advertising and other ways to get big spenders into your store. >I also shop only with cash, here and elsewhere. >Double-blinded e-cash will be the only way to go, if it >ever is the way to go. And I bet they don't turn down your cash just because it contains no demographic data. Thus demonstrating the pragmatism of the market with regard to anonymity. S a n d y ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

2 1

Re: Java Crypto API questions
by br＠doppio.Eng.Sun.COM 17 Dec '03

17 Dec '03

Martin Minow (minow(a)apple.com) writes: [...] |-- Policies = Assertions + Capabilities. That's what my notes Policies are statements like: "code endorsed by any one of the following signatures (say three of my friends) can access the public part of my file system" This is hard. It's probably not going to make it in the first release. The simple first pass is to say "code signed by x, y, and z" can do whatever it wants. |-- Feedback to security-api(a)java.sun.com. The alias had some trouble over the week-end. It should be working fine now. -- Benjamin

3 2

PGP's ubiquity (was Re: NRC Session Hiss)
by Bruce Baugh 17 Dec '03

17 Dec '03

At 09:15 PM 6/2/96 -0700, 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? Much, much less than that. I get about five hundred messages a day. On the average day, none of them are PGP-encrypted. On the average _week_, none of them are PGP-encrypted. And by virtue of having a PGP key signed and on the servers, I'm better prepared to send and receive such mail than at least 99.9% of the net.population. >PGP was a failure in the mass market, regardless how popular it may be >with some subscribers of this list. True, and important. In one sense it doesn't matter how good a security system is if a manageable set of people are the only ones using it. There are only a few thousand IDs in the key servers, and vast majority of those, I'd guess, are like me in not using PGP routinely. But even if we were, the institutions of the State have experience in the long-term surveillance of groups quite a bit larger than us. This is where I think some forms of cyber-elitism fail. So I've got access to darned good tools. The State has numbers and resources, and memes about how the masses do right when they acquiesce, on its side. We are not, I think, particularly secure in an environment where the very fact of using secure tools stands out from the herd. But what the herd needs are good tools with good simple front ends, and a) those who design the tools generally don't care about the herd and so do nothing to get outside the crypto ghetto and b) those in a position to design the front ends generally have more immediately rewarding things to do or don't know about the tools themselves. Five years ago I was quite optimistic about strong security as an important element in bringing about the post-statist society I desire. Now I'm pessimistic. I just don't see signs of the stuff spreading sufficiently. And while S/MIME has interesting features (based on what I've read so far), the default 40-bit setup is basically no protection at all. And I know just how hard it is to get people comfortable using non-default features. -- Bruce Baugh bruce(a)aracnet.com http://www.aracnet.com/~bruce

1 0

Crypto APIs Considered Harmful
by tcmay＠got.net 17 Dec '03

17 Dec '03

A typo when I wrote: 2. Eliminates a reason for controlling the distribution and export of browsers, mailers, newsreaders, etc. Imagine the glum reaction of the NSA when they realize that they can't control these programs, because the "crypto hooks" are only the hooks to basic message payloads...and they control these. ^ *can't* I meant to include the "can't." A Web browser with no hooks for crypto absolutely will not be export-controlled. But if users in Slovakia and Beninia can _see_ the messages, as they of course can, then crypto programs they supply themselves can of course see and act on the messages. (Copying to a clipboard, for example, and lots of other ways.) No way the NSA can control that. Concentrating on integrating crypto tightly into commercial programs is playing the NSA's game. --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

Re: Java Crypto API questions
by br＠doppio.Eng.Sun.COM 17 Dec '03

17 Dec '03

|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. In the actual talk, I said "will be public and open", that is when we actually announce the policy it will be public and open. The things that are certain about it is that it will be constrained only by export considerations, and that we'll sign competitors' packages. I am hoping that I can get a spec document for the API ready by the end of the month. By then we will have more details regarding the export stuff. In the meantime, I'll see if we can get an interim FAQ together. The security-api(a)java.sun.com address should be working now. -- Benjamin

1 0