December 2003 - cypherpunks-legacy

Re: .PWL spin
by Duncan Frissell 17 Dec '03

17 Dec '03

At 05:12 PM 12/9/95 -0500, Joseph M. Reagle Jr. wrote: > So now, I don't even bother with that, I'm just hoping securdrv, >sfs, or something makes it to W95 one of these days... (I doubt either of >those will make it...) SecureDrive works under Windows 95 if you disable all 32-bit disk drivers. Control Panel System Performance File System Troubleshooting Disable all 32 bit protected mode disk drivers You have to run SECTSR before starting Win95. A pain but it does work. I will be working on figuring out how to force Windows 95 to disable 32 bit access for just my SecureDrive disk alone. Should be possible. DCF "Windows 95 beats having a personal life."

1 0

Timing Attacks
by Rev. Ben 17 Dec '03

17 Dec '03

I'm not so sure I see the great usefulness of this attack. I've taken a cursory glance at Mr. Kocher's paper on-line and what it comes down to essentially, if I undestand it correctly, is that you need to be as sure of the timing as you can be. Now, on a distributed system, you can't measure those timings, because any latency could come from the originating computer, the links in the middle or any combination of them. Also precise timings can be limited by fluctuating load averages amongst other things in a time-sharing computing environment. While this might work in a lab, with the current advances in computing speed, the differences between a fast and a slow calculation can easily be opaqued by network lag. Am I missing something, or does this attack only work in a lab? Ben. ____ Ben Samman..............................................samman(a)cs.yale.edu "If what Proust says is true, that happiness is the absence of fever, then I will never know happiness. For I am possessed by a fever for knowledge, experience, and creation." -Anais Nin PGP Encrypted Mail Welcomed Finger samman(a)powered.cs.yale.edu for key

2 1

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, which is available at: ftp://ftp.csua.berkeley.edu/pub/cypherpunks/premail/premail-0.33a.tar.gz 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)extropia.wimsey.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{"bsu-cs"} = "<nowhere(a)bsu-cs.bsu.edu> cpunk hash ksub"; $remailer{"c2"} = "<remail(a)c2.org> eric pgp hash reord"; $remailer{"penet"} = "<anon(a)anon.penet.fi> penet post"; $remailer{"ideath"} = "<remailer(a)ideath.goldenbear.com> cpunk hash ksub reord"; $remailer{"hacktic"} = "<remailer(a)utopia.hacktic.nl> cpunk mix pgp hash latent cut post ek"; $remailer{"flame"} = "<remailer(a)flame.alias.net> cpunk mix pgp. hash latent cut post ek reord"; $remailer{"rahul"} = "<homer(a)rahul.net> cpunk pgp hash filter"; $remailer{"mix"} = "<mixmaster(a)remail.obscura.com> cpunk mix pgp hash latent cut ek ksub reord ?"; $remailer{"syrinx"} = "<syrinx(a)c2.org> cpunk pgp hash cut reord mix post"; $remailer{"ford"} = "<remailer(a)bi-node.zerberus.de> cpunk pgp hash ksub"; $remailer{"hroller"} = "<hroller(a)c2.org> cpunk pgp hash latent ek"; $remailer{"vishnu"} = "<mixmaster(a)vishnu.alias.net> cpunk mix pgp. hash latent cut ek ksub reord"; $remailer{"robo"} = "<robo(a)c2.org> cpunk hash mix"; $remailer{"replay"} = "<remailer(a)replay.com> cpunk mix pgp hash latent cut post ek"; $remailer{"spook"} = "<remailer(a)valhalla.phoenix.net> cpunk mix pgp hash latent cut ek reord"; $remailer{"rmadillo"} = "<remailer(a)armadillo.com> mix cpunk pgp hash latent cut"; $remailer{"ecafe"} = "<cpunk(a)remail.ecafe.org> cpunk mix"; $remailer{"wmono"} = "<wmono(a)valhalla.phoenix.net> cpunk mix pgp. hash latent cut ek"; $remailer{"shinobi"} = "<remailer(a)shinobi.alias.net> cpunk mix hash latent cut ek reorder"; $remailer{"amnesia"} = "<amnesia(a)chardos.connix.com> cpunk mix pgp hash latent cut ek ksub"; $remailer{"gondolin"} = "<mix(a)remail.gondolin.org> cpunk mix pgp hash latent cut ek reord"; 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: (robo hroller c2) (flame hacktic replay) (wmono spook) (alumni portal) Use "premail -getkeys pgpkeys(a)kiwi.cs.berkeley.edu" to get PGP keys for the remailers. Fingering this address works too. Last update: Mon 11 Dec 95 6:49:36 PST remailer email address history latency uptime ----------------------------------------------------------------------- portal hfinney(a)shell.portal.com #+*########* :44 99.85% hacktic remailer(a)utopia.hacktic.nl ******* **** 7:17 99.72% c2 remail(a)c2.org *++-.-++ +++ 47:37 99.65% rmadillo remailer(a)armadillo.com ++++++++ +++ 38:51 99.38% amnesia amnesia(a)chardos.connix.com -+- -+ +--+ 1:55:48 99.36% flame remailer(a)flame.alias.net * *** * **** 19:31 99.30% spook remailer(a)valhalla.phoenix.net ..-* ****** 53:58 99.08% extropia remail(a)extropia.wimsey.com ---.- -.--- 6:49:13 98.44% shinobi remailer(a)shinobi.alias.net + --- -- - + 53:31 98.38% ecafe cpunk(a)remail.ecafe.org ### ##-## 2:18 98.11% wmono wmono(a)valhalla.phoenix.net * ** ** 12:36 98.07% mix mixmaster(a)remail.obscura.com .-__ _-__. 27:56:43 97.91% replay remailer(a)replay.com * + +** ** 5:41 97.69% gondolin mix(a)remail.gondolin.org - --_.- 10:47:46 97.00% vishnu mixmaster(a)vishnu.alias.net *#** # 5:26 96.37% alumni hal(a)alumni.caltech.edu *# # # 1:20 96.28% bsu-cs nowhere(a)bsu-cs.bsu.edu ## # # # :15 95.56% ford remailer(a)bi-node.zerberus.de ---._...-- 15:06:29 94.28% hroller hroller(a)c2.org ####*+### -# 5:21 94.25% rahul homer(a)rahul.net ** +* *+**+* 4:32 99.67% penet anon(a)anon.penet.fi - . -- 13:10:01 83.74% robo robo(a)c2.org #-## 5:59 52.62% 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: Timing Cryptanalysis Attack
by David E. Smith 17 Dec '03

17 Dec '03

At 04:45 AM 12/12/95 -0500, Black Unicorn wrote: >> | PS - I think Paul was a bit surprised when Jim Barksdale pulled >> | out his wallet and handed him 10 crisp $100 bills. :-) >> Great. mention it where the IRS is sure to be listening. :) >Why would the IRS listen? Everyone knows the tax system is voluntary. Do you know something I don't? :) Would you mind sharing? :) Dave ----- David E. Smith, c/o Southeast Missouri State University 1210 Towers South, Cape Girardeau MO USA 63701-4745, +1(573)339-3814 PGP ID 0x92732139, homepage http://www.midwest.net/scribers/dsmith/ Quote: "And if we change, well, I'll love you anyway" - Alice In Chains Dec15-Jan15: (618)244-3340/2209 Perkins, Mt Vernon IL 62864

3 2

Today's Baltimore Sun on the NSA...
by pcw＠access.digex.net 17 Dec '03

17 Dec '03

As I mentioned on Sunday, the Baltimore Sun is running a long series on the NSA. Today, the published an article that described how the NSA routinely listens into the phone calls of Americans. This happens in two ways. First, if the conversation leaves the country then the NSA can intercept it. Second, the NSA is also allowed to grab local phone calls for "training" purposes. The funniest part of the article mentioned that Henry Kissenger got both ends of the stick. He relied on NSA to pass him sensitive information about his rivals. But the head of the Department of Defense, who got to appoint the head of the NSA, made sure that the NSA told him what Kissenger was up to. The strangest anecdote involved a Baltimore Sun reporter who called Cuban diplomats from overseas. This was picked up by NSA and the evesdropper openly chatted about it a civilian cocktail party. The details got back to the reporter. The parties in the Baltimore suburbs are from the pages of Fleming not from the pages of Cheever. There is some debate about the whole issue of snooping on American citizens. Everyone quoted on the record says it's all pretty upstanding and good. The paper also gives a fair amount of ink to the argument that American citizens could be involved in terrorism too. This seems to be logical to me. The deepest point made was that NSA could never really assume greater law enforcement practices because this would involve disseminating their information to a much larger audience. Since using secret information often reveals that you can get it, there is little doubt that people would stop using the phone system and the other information sponges. So much for absolute power. -Peter Wayner -=-=-= On Friday, the last article in the series is promised to report, "The next war will be fought with computers. NSA is getting ready." You will be able to buy a reprint of the NSA stories from SunSource. $3.95. Call 410-332-6962.

1 0

[NOISE] Re: Pornographic stories
by pjm＠ionia.engr.sgi.com 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Scott Binkley writes: > Stop posting this type of crap on the Internet. I'd be pleased if people would refrain from posting to inappropriate groups. There a number of acceptable venues for pornography on the Net. > People like you are the ones to get everyone censored. If we censor ourselves, the bluenoses win. > Hopefully everyone else will flame you a thousand times over A polite note suggesting that one remember to log out when leaving one's terminal unattended should suffice. Regards, Patrick May -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMMy/qu5Yg08fDKehAQG8nAQAlJZjWwGPfkCgM3+umOFlfNd0wYZBCKiw M3JktEPpBpviMmiiH6WgKI0BHpvWhLmEcwVQ7Bs56pRtLma/gp66ljOC+eP2m78f KxN8Ao9o/MDDdX7LHUHC7IeliMikBcdkCBttrHdKXpY6xTFAygwVH2qC+rmam0Xp Gz0USqvzDc0= =2V4I -----END PGP SIGNATURE-----

1 0

Re: Time-based cryptanalysis: How to defeat it?
by Bill Stewart 17 Dec '03

17 Dec '03

At 10:56 PM 12/10/95 -0800, anonymous-remailer wrote: >Assuming Alice is decrypting a secret message sent to her >by Bob (on her very slow C64 ;), and Mallet is watching >with a stopwatch in hand, hoping to determine Alice's secret >key... The modern equivalent of that very slow C64 is the smartcard/ electronic wallet. Sounds like we'll have to implement them very carefully.... >It would be good to place inside the decryption routines >a timer (WELL PLACED!) that waits a random-number of cycles >(based on key-strokes, mouse position, etc.) to defeat this >type of cryptanalysis? The most interesting detail in the paper, to me, was: PK> Computing optional Ri+1 calculations regardless of whether the exponent PK> bit is set does not work and can actually make the attack easier; PK> the computations still diverge but attackers no longer have to identify PK> the lack of a correlation for adjacent zero exponent bits. My immediate reaction to the description of the timing attack on Diffie-Hellman had, of course, been to do precisely that :-) #-- # Thanks; Bill # Bill Stewart, Freelance Information Architect, stewarts(a)ix.netcom.com # Phone +1-510-247-0663 Pager/Voicemail 1-408-787-1281

2 1

MD4 weaknesses (Was: Windows .PWL cracker implemented as a Word Basic virus)
by Bill Stewart 17 Dec '03

17 Dec '03

At 06:20 PM 12/10/95 -0500, daw(a)quito.CS.Berkeley.EDU (David A Wagner) wrote: >-----BEGIN PGP SIGNED MESSAGE----- > >In article <95Dec10.175318edt.1732(a)cannon.ecf.toronto.edu>, >SINCLAIR DOUGLAS N <sinclai(a)ecf.toronto.edu> wrote: >> My understanding was that MD4 had been broken once, at the cost of >> much computer time. >Not *that* much computer time... >In my copy of Hans Dobbertin's paper, the abstract says > >``An implementation of our >attack allows to find collisions for MD4 in less than a minute on a PC.'' > >As far as I know, the difficulty of inverting MD4 is still an open >problem -- but why would you want to use a broken algorithm like MD4 >when you can use MD2, MD5, or SHA? Do you have a reference to Dobbertin's paper? Schneier's discussion of MD4 says that DeBoor and Bosselaers cryptanalyzed the last two of the three rounds of MD4 in 1991, Merkle did the first two, and Biham discussed a differential attack on the first two, but nobody had done the whole thing. Does Dobbertin's attack take one of these and use it to feed an otherwise-brute-force search? #-- # Thanks; Bill # Bill Stewart, Freelance Information Architect, stewarts(a)ix.netcom.com # Phone +1-510-247-0663 Pager/Voicemail 1-408-787-1281

1 0

Re: Timing Cryptanalysis Attack
by Peter Trei 17 Dec '03

17 Dec '03

> > People employing systems like PGP are already advised to use them > > on private machines, with only one user, and untampered-with > > binaries. > > Timings like the ones listed are trivial to take in establishing > things like SSL sessions, or Photuris sessions. The danger is to > online protocols, not to PGP. > Perry Loathe as I am to disagree with Perry :-), is it really 'trivial' to take these timings in an online protocol? Paul writes on the DH example: ------------------------- A preliminary implementation of the attack using the RSAREF toolkit[8] has been written. RSAREF scans across the exponent from MSB to LSB and does two exponent bits at a time, so corresponding adjustments to the attack were made. Using a 120-MHz PentiumTM computer running MSDOSTM, a 512-bit modulus, and a 256-bit secret exponent, processing times ranged from 392411 microseconds to 393612 microseconds and closely approximated a normal distribution with a mean of 393017 microseconds and a standard deviation of 188 microseconds. -------------------------- Note that the range is 1201 microseconds and for RSA: -------------------------- RSAREF's modular reduction function with a 512-bit modulus on the same 120-MHz PentiumTM computer takes an average of approximately 17 microseconds less time if c is slightly smaller than p, as opposed to slightly larger than p. Timing measurements of many ciphertexts can be combined to detect whether the chosen ciphertexts are larger or smaller than p. ------------------------- The range here is 17 microseconds. Paul notes: --------------------------- Random delays added to the processing time may increase the number of ciphertexts required, but do not completely solve the problem since attackers can compensate for the delay by collecting more measurements. (If enough random noise is added, the attack can become infeasible.) -------------------------- In a 'real' system, there is a lot of unpredictable variation in the timing of the signal. Sources of such noise include routers, and other sessions on the server (any decent server these days is multi-tasking, and can handle multiple connections simultaneously). On top of that, real protocols have a lot of processing overhead, looking up certificates and keys, generating MAC hash values, etc, many of which are difficult to predict. I tried pinging some machines to look at the slop in the roundtrip times. I have not checked traceroute, but for what it's worth, I'm in central Massachusetts. elnath (local to my lan) <10 ms rtfm.mit.edu (20 miles) 10-21 ms iii1.iii.net (FreeBSD on a 120MHz P5, 35 miles) 100-200 ms utopia.hacktic.nl (Netherlands) 190-781 ms Maybe Paul can give us some figures as to how *much* random noise is enough to make his (very elegant!) attack unfeasible. Note that the range of the random slop I'm getting is hundreds to thousands of times the range of the signal he needs to detect. Statistical techniques, averaging the return times for the same text over many trials may be useful, but the number required to detect a less than 1% variation is going to be high. The attack might be feasible of it can be mounted on a quiet server from a point 'close' (in network terms) to the timing system, and the intervening network segments are also fairly quiet. I don't think random users are going to crack the Dilbert Store, however. Speaking for myself.... Peter Trei Senior Software Engineer Purveyor Development Team Process Software Corporation http://www.process.com trei(a)process.com

1 0

Re: Timing Attacks
by Bill Stewart 17 Dec '03

17 Dec '03

At 02:15 PM 12/11/95 -0500, "Rev. Ben" <samman-ben(a)CS.YALE.EDU> wrote: >I'm not so sure I see the great usefulness of this attack. > >I've taken a cursory glance at Mr. Kocher's paper on-line and what it >comes down to essentially, if I undestand it correctly, is that you need >to be as sure of the timing as you can be. > >Now, on a distributed system, you can't measure those timings, because >any latency could come from the originating computer, the links in the >middle or any combination of them. ... >Am I missing something, or does this attack only work in a lab? It works much better in relatively controlled environments - smart cards, for example, are usually both slow and not busy doing other things, plus you can get a bunch of them and analyze the variance in performance across cards. The Usual Suspects say this does appear to affect Fortezza, plus things like digital wallets are obvious targets. If you're clever, you can design smart-card readers that do the measurements for you, and convince people to use them. The attack also works better if you can try it multiple times with the same numbers to work around random latency; the lowest number is closest to real. Running on time-shared machines increases randomness a lot (though if the Bad Guys have an account there, they can watch the machine's performance more closely.) On the other hand, running on shared machines has its own set of security risks, though they're better places for Diffie-Hellman systems than secret keys - but Diffie-Hellman needs authentication to be safe against MITM, and therefore there's still a secret key for that. Interesting times.... We've all been discussing whether there'd be some major theoretical-mathematics breakthrough, and along comes an engineering attack. #-- # Thanks; Bill # Bill Stewart, Freelance Information Architect, stewarts(a)ix.netcom.com # Phone +1-510-247-0663 Pager/Voicemail 1-408-787-1281

2 1

Voluntary Key Escrow is Freedom, Surveillance is Privacy
by tcmay＠got.net 17 Dec '03

17 Dec '03

Citizen-unit jim bell wrote: >Pardon me, but since this "key escrow" system was always claimed to be >"voluntary," then how can there be any kind of legal penalties associated >with "failure to release" those keys? > > >Which raises another question: Let's suppose I owned a product based on >CKE, and I went to the escrow agent and said, "This escrow is voluntary, >right? If so, erase my key in your possession." > >Not that I'd trust them to do so, but how "voluntary" can a system be if >people can't volunteer out of it? In much the same sense the income tax system is "voluntary." For further details, consult the definition of "newspeak" in Orwell's novel. Remember, saying that Voluntary Key Escrow is neither "voluntary" nor "escrow" is thoughtcrime. Freedom is Slavery, Surveillance is Privacy, Censorship is Decency --Citizen-Unit May227-80-5992 Views here are not the views of my Internet Service Provider or Government. ---------:---------:---------:---------:---------:---------:---------:---- Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay(a)got.net 408-728-0152 | anonymous networks, digital pseudonyms, zero Corralitos, CA | knowledge, reputations, information markets, Higher Power: 2^756839 | black markets, collapse of governments. "National borders are just speed bumps on the information superhighway."

1 0

ViaCrypt supports CKE in PGP
by Robichaux, Paul E 17 Dec '03

17 Dec '03

In today's mailbox I got a pack of marketing slicks from ViaCrypt. They're about to release ViaCrypt PGP 4.0 in two editions: Personal and Business. The 4.0 release adds some nice new features: - recipient groups for sending to several addresses at once - a Search dialog for finding keys - encryption-only & decryption-only keys - signature-only keys - key expiration dates - a Windows DLL that third-party developers can use (!!) The biggie, though, are these: "Encryption automatically includes Corporate Access Key as additional recipient (option)" and "Key selection/display dialogs show only keys certified by Corporate Access Key (option)" So, real CKE will soon be available from an unexpected source. I'm not sure whether to be excited or dismayed. On the one hand, any movement towards CKE seems dangerously close to the slippery slope of GAK. On the other hand, I know a large corp like Intergraph is much more likely to license PGP for internal use if it has CKE features-- especially since they can hold the keys internally. The DLL is an awfully nice feature, too. -Paul -- Paul Robichaux, KD4JZG | perobich(a)ingr.com Intergraph Corporation | http://www.intergraph.com Be a cryptography user. | Not speaking for Intergraph Co-author, "Building Internet Appls With Visual C++", Que Books (0-7897-0213-4)

1 0

Re: NIST GAK meeting writeup, LONG part 3 of 3
by Andrew Loewenstern 17 Dec '03

17 Dec '03

Pat Farrell writes in his report on thi NIST GAK meeting: >>Geoff said that they may want legislation support for >>protecting against illegal release of keys, failure to release, etc. Jim Bell Responds: > Pardon me, but since this "key escrow" system was always claimed > to be "voluntary," then how can there be any kind of legal penalties > associated with "failure to release" those keys? well, since the subject at hand is Escrow Agent Criteria, "Geoff" is probably talking about the failure of an escrow agent to release a key upon production of "lawful authorization" .... andrew

1 0

Re: NIST GAK meeting writeup, LONG part 3 of 3
by jim bell 17 Dec '03

17 Dec '03

At 11:04 AM 12/10/95 -0800, you wrote: > >NIST Key Export meeting, December 5, 1995 Long version >Part 3 of 3. > >This covers the notes on agent criteria, and the >industry presentations. > [stuff deleted] > >Geoff said that they may want legislation support for >protecting against illegal release of keys, failure to release, etc. Pardon me, but since this "key escrow" system was always claimed to be "voluntary," then how can there be any kind of legal penalties associated with "failure to release" those keys? Which raises another question: Let's suppose I owned a product based on CKE, and I went to the escrow agent and said, "This escrow is voluntary, right? If so, erase my key in your possession." Not that I'd trust them to do so, but how "voluntary" can a system be if people can't volunteer out of it?

1 0

Re: Timing Attacks
by eli+＠GS160.SP.CS.CMU.EDU 17 Dec '03

17 Dec '03

samman-ben(a)CS.YALE.EDU writes: >I'm not so sure I see the great usefulness of this attack. It appears to be more practical than 99 percent of the "weaknesses" that get published. Not bad, I'd say. It's also a very cute attack; I'd never have guessed a priori that you could get that many key bits from timing data. >work in a lab, with the current advances in computing speed, the >differences between a fast and a slow calculation can easily be opaqued >by network lag. "Random delays added to the processing time may increase the number of ciphertexts required, but do not completely solve the problem since attackers can compensate for the delay by collecting more measurements. (If enough random noise is added, the attack can become infeasible.)" [extended abstract, p. 5] Sufficient network noise *might* make the problem go away, in some cases, but that's a weak sort of claim to make about a cryptosystem. (What if the attacker tries at six in the morning, or cracks a machine local to you, or just gets lucky?) You might put your server behind a time-quantizing firewall... Also, it's not just networked machines. Smart cards may have a hard time defending themselves against hostile card readers. They're slow already; the user may not appreciate the extra time spent for obfuscation. (This depends critically on the numbers, of course.) -- Eli Brandt eli+(a)cs.cmu.edu

2 1

The origin of some heavy legal terms
by tcmay＠got.net 17 Dec '03

17 Dec '03

At 12:10 PM 12/11/95, Black Unicorn wrote: >The term 'pressing a defendant for a plea' came from the practice of >piling heavy weights on a defendant and 'pressing' him into the very >floor of the court. (As defendants who did not admit a plea would save >their family from being held accountable to judgment, the incentive to >remain silent was high). Often weight was piled atop the hapless >defendant until he or she expired, having refused to enter a plea. Modern courts have replaced the rocks used in earlier days with law books, of course. The need for heavy law books to press the accused is one of the main reasons electronic versions are not being adopted. This practice also gave us the term "the full weight of the law" as well as the symbol of the law as being a blind woman carrying a scale filled with rocks to place upon the guilty to convince them to confess. (This was originally done in the court's torture chamber, from which we get the term "judge's chamber.") Sometimes the "scales of justice" can be "tipped," which derives from the practice of tipping the judge to get favorable rulings. --Tim "Not a Lawyer" May

1 0

Re: [NOISE] GAK and self-incrimination?
by Ed Carp (ecarp＠netcom.com) 17 Dec '03

17 Dec '03

> Date: Mon, 11 Dec 1995 09:01:40 -0500 > To: Bill Stewart <stewarts(a)ix.netcom.com> > Subject: Re: [NOISE] GAK and self-incrimination? > From: tallpaul(a)pipeline.com (tallpaul) > Cc: cypherpunks(a)toad.com > If I'm not guilty why do I want strong crypto? Sometimes for the same > reason I want a shredder. And why do I want a shredder? Sometimes just to > keep the local gossip from going through my papers after I throw them out. Another, not-so-obvious reason to encrypt stuff, especially stuff that goes out over the net, is that folks can suck your email off the net and gather all sorts of useful information. This has all kinds of annoying implications, especially for people who gather demographics and other data for constructing email lists for sale. -- short ed

1 0

Third generation privacy
by tallpaul＠pipeline.com 17 Dec '03

17 Dec '03

On Dec 11, 1995 13:07:22, '"Ed Carp (ecarp(a)netcom.com)" <khijol!netcom.com!ecarp>' wrote: > >Another, not-so-obvious reason to encrypt stuff, especially stuff >that goes out over the net, is that folks can suck your email off the >net and gather all sorts of useful information. This has all kinds >of annoying implications, especially for people who gather >demographics and other data for constructing email lists for sale. > >-- short ed > Another related issue is what I'll call "third generation" privacy. This exists when I want privacy not for myself or even the person with whom I'm communicating but to protect the privacy of innocent third parties. E.g.: Grandpa is getting senile and I'm communicating with a second family member on how we should handle the problem; My friend Jane was just raped and I'm communicating with a mutual friend about how we can help her. The anti-freedom forces have tried to define the parameters of the debate inside the boundaries of the "four horsemen." We need to understand that we do not have to remain within those false boundaries and, in fact, it is very good not to. --tallpaul

1 0

Re: NIST GAK meeting writeup, part 3 of 3
by Pat Farrell 17 Dec '03

17 Dec '03

I appologise to the list for the character mangling in the original posting. I wrote it in Word so I could spellcheck it, and I couldn't turn OFF the idiotic smartquotes. I've placed a cleaned up, fewer typo, and hyperlinked version out on my NIST page, http://www.isse.gmu.edu/~pfarrell/nist/pdf.nist2.html jim bell <jimbell(a)pacifier.com> writes: >> Geoff said that they may want legislation support for >> protecting against illegal release of keys, failure to release, etc. > Pardon me, but since this "key escrow" system was always claimed to be > "voluntary," then how can there be any kind of legal penalties associated > with "failure to release" those keys? It was Geoff G. talking, not Mike Nelson or Ed Appel. The difference is critical. Mike and Ed have some political savvy. My best friend Geoff does not. I believe that Geoff has never bought into "voluntary" as a concept. EPIC successfully FOIA'd papers from the FBI saying that they will change their tune when/if there isn't sufficient compliance. Mike and Ed are political enough to know that they can't sell this if they push too hard. Geoff isn't. The podium had a light that showed green/yellow/red lights. These let the speakers know how much time was left. For the morning, since only NIST/NSA/FBI/... folks talked, they didn't bother to reset the light. It was red all the time, altho it blinked occasionally. Ed took the mike, and asked "what is the red light for? Does it glow red whenever someone from the Government is lying?" It got a good chuckle. It was probably also close to being true. Ed and Mike understand the audience, Geoff never will. > Which raises another question: Let's suppose I owned a product based on > CKE, and I went to the escrow agent and said, "This escrow is voluntary, > right? If so, erase my key in your possession." > > Not that I'd trust them to do so, but how "voluntary" can a system be if > people can't volunteer out of it? It isn't voluntary for export approved software. The word voluntary is not in the criteria. It is only voluntary if domestic users foolishly choose to buy GAK'd products. So don't! Criteria #2 says "...cryptographic functions shall be inoperable until the key(s) is escrowed in accordance with #3." Worse, IMHO, is criteria #9, which states " ... cryptographic functions shall interoperate only with key escrow cryptographic functions in products that meet these criteria..." The interoperability issues stayed muddy. The government didn't spend much effort making it clearer. The karma seemed to be that if you had two products, say Webscape 128 and Webscape 64/Gak, selling 128 domestically and 64/GAK exported, that you can't make Webscape128 interoperate with 64/GAK unless the Webscape128 keys are GAKed. Part of this is burried in agent criteria #6, "6. Escrow agent entities that are certified by the U.S. government shall work with developers of key escrow encryption products to develop and support a feature that allows the product to verify to one another that the product's keys have been escrowed with a U.S.-certified agent." Looks to me like the software has to chase up the chain of certification authorities (or escrow authorities if you prefer) before it can work. Pat Pat Farrell Grad Student http://www.isse.gmu.edu/students/pfarrell Info. Systems & Software Engineering, George Mason University, Fairfax, VA PGP key available on homepage #include <standard.disclaimer>

1 0

Re: Re[2]: Timing Cryptanalysis Attack
by David E. Smith 17 Dec '03

17 Dec '03

At 10:30 PM 12/11/95 CST, Martin Diehl wrote: > OTOH, maybe we _should_ try for constant computation time and then try > for *random* delay time. Remember that _we_ will spend a lot of real > time arguing whether the *random* delay is really _random_ Does it necessarily matter whether the random delay time is true-random? The idea is to obfuscate the time of the whole computation. As long as you don't base your random numbers on the system clock, it should serve its purpose. (I omit the system clock because timing seems to be the nexus of the whole attack, so we can safely assume that the clock's data, and thus its source of "randomness," can be predicted. ----- David E. Smith, c/o Southeast Missouri State University 1210 Towers South, Cape Girardeau MO USA 63701-4745, +1(573)339-3814 PGP ID 0x92732139, homepage http://www.midwest.net/scribers/dsmith/ Quote: "And if we change, well, I'll love you anyway" - Alice In Chains Dec15-Jan15: (618)244-3340/2209 Perkins, Mt Vernon IL 62864

1 0

Re: More FUD from First Virtual [NOISE]
by Bill Stewart 17 Dec '03

17 Dec '03

At 09:19 PM 12/11/95 -0800, sameer wrote: >> Maybe Sameer will create a Hack FV page :-) > > FV isn't worth it. > Actually, Hack FV seems pretty pointless. Someone hacks FV, >and a chargeback is issued on the credit card. Big deal. Same old >outdated credit-card based payment systems. > No more secure than credit cards. Besides, if you hack FV you've got the money :-) #-- # Thanks; Bill # Bill Stewart, Freelance Information Architect, stewarts(a)ix.netcom.com # Phone +1-510-247-0663 Pager/Voicemail 1-408-787-1281

3 2

PAY-OFF TIME FOR BUG-BUSTERS, NETSCAPE PLEDGES "DOGFIGHT"
by OpsAn＠gnn.com 17 Dec '03

17 Dec '03

PAY-OFF TIME FOR BUG-BUSTERS, NETSCAPE PLEDGES "DOGFIGHT" Netscape Communications has awarded two software sleuths $1,000 each for finding security gaps in its Netscape Navigator 2.0 software. The company also awarded gifts to 50 other contestants in its "Bugs Bounty" program for identifying non-security problems. (Wall Street Journal 11 Dec 95 B7) Meanwhile, Netscape has vowed to wage a "dogfight" with Microsoft in setting standards for Internet software. CEO James Barksdale says his company will continue to develop products that operate independently of any particular computer operating system, noting that, "We offer freedom to the masses. It's a tough fight -- I'll grant you that -- but we're brave. We're well financed. We believe that God is on our side." (Investor's Business Daily 11 Dec 95 A7)

1 0

Timing RSA and Certificates worth ??
by lyalc＠mail.mpx.com.au 17 Dec '03

17 Dec '03

My limited mind induces me to think that a certificate become subject to timing attacks on the RSA private signing key. This appears to meet the main critieria of fixed data (for instance, a bank's certificate in/on ecash), processed widely by a small group of machines (eg a subset of customers) on inherently untrusted machines (home PC's) which may or may not have the right software/operating system parts. Certificates in general, do not appear to lend themselves to "blinding". In this case, certificate verification processes seem flawed and highly unreliable. eg a merchant gets lots of data containing a bank(s) certificate, and probably encrypted data. Is this the death knell for STT/SEPP and ecash/echeque systems ??? Some ramblings and thoughts. lyal

1 0

Re: Timing Attack Paper
by Bill Stewart 17 Dec '03

17 Dec '03

At 09:39 PM 12/11/95 CST, gibo wrote: >I went to > >http://www.cryptography.com/timingattack.html > >and found the whole thing to be totally incomprehensible from >a layman's point of view. I apologize for having not read >"Applied Cryptography", which might have made the abstract a >simpler read - but even if I had I'd have been baffled by a >lot of the terminology and equations in this paper. > >Can anyone post a brief summary which explains the essential >workings of the attack? I'd be very grateful. Briefly, most public-key calculations are _slow_, and use 512-2048-bit numbers which get represented as arrays of machine integers. The amount of time they take depends on the values you're multiplying together, especially because the algorithms used to do the arithmetic less slowly take shortcuts whenever possible to avoid unnecessary work. If you watch the time that it takes for a machine to do calculations using its private keys, for some algorithms you can guess a bit or two of the key. If you're clever, and have the ability to feed the victim different numbers for it to calculate on (e.g. make a bunch of connections using Diffie-Hellman), you can guess different bits each time, and gradually get the whole thing. It helps to watch this a number of times to get better statistics, so you can tell what's real calculation and what's just speed-randomness. Obviously, it also helps if you're running a program on the same machine as the target you're trying to hit, but you can still gain some information if you're running across a network and having to estimate random network delays. In these cases, you just have to watch longer to get stats. A common algorithm for doing modular exponentiation (the core of the Diffie-Hellman and RSA algorithms) looks like this: To calculate y**x mod m (all this arithmetic is multiple-precision) (and maybe there's an off-by-one error or two in this :-) This uses successive squaring to do the calculation in log2(x) time instead of just doing x multiplies by y, which would be very slow since x is typically 500-1000 bits long... Remember that multiplying two 1024-bit numbers typically involves multiplying two arrays of 32 numbers 32 bits long, which takes 32*32 or 1024 multiply steps. And modulo calculations are also slow. prod = 1 square = y log2x = number of bits in x for i = 1 to log2x+1 { if (x odd) then { prod = prod * square if ( prod > m ) then prod = prod mod m } # else if (x even), don't bother square = square * square if (square > m) square = square mod m x = x / 2 } You can figure out the timing for the squaring calculations yourself. Since you get to pick y, you can manipulate it to guess a bit about how long x is, and notice from the different timings how many times there was a prod*square calculation (which tells you how many bits were odd), as well as how many prod mod m calculations. You can get a certain amount of defense by keeping around prod1 and prod2, and calculating prod1 = prod1 * square (the real value) for odd and prod2 = prod2 * square (a dummy you'll discard later) for even, and doing something useful to obscure the mod m calculations, like keeping a dummy around to divide if prod1 or prod2 is less than m. Aside from slowing things down by 50%, if you're not careful, there's still information that leaks from the timing. For other algorithms, sometimes the calculations you've got to do timings on are more subtle, like DES, but you can still often guess things, and Paul gives a bunch of calculations for these. They're more statistical, since the effects you're chasing are subtler, but you still get information. #-- # Thanks; Bill # Bill Stewart, Freelance Information Architect, stewarts(a)ix.netcom.com # Phone +1-510-247-0663 Pager/Voicemail 1-408-787-1281

1 0

Plaintiff's Opposition in Karn vs State Dept
by Phil Karn 17 Dec '03

17 Dec '03

On Monday, December 11, my attorneys filed a Plaintiff's Opposition to Defendants' Motion to Dismiss in the case of Karn vs US Dept of State et al. I have HTMLized our filings and added them to my web page. Please feel free to peruse them. Also, let me know if you spot any obvious typos; I had to do quite a bit of manual editing, particularly in the footnotes, to make the result look good in HTML. The government now gets the chance to answer our opposition. They were originally scheduled to do by December 13, but since our own filing was delayed over the weekend by the judge's concurrence the government will probably get a few extra days to respond. Note that we have asked to make oral arguments on the motion. I'll let everyone know if or when this will happen. The web page is: http://www.qualcomm.com/people/pkarn/export Phil

1 0