December 2003 - cypherpunks-legacy

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

18 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 18 Dec '03

18 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 18 Dec '03

18 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 18 Dec '03

18 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 18 Dec '03

18 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 18 Dec '03

18 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 18 Dec '03

18 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 18 Dec '03

18 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 18 Dec '03

18 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 18 Dec '03

18 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