December 2003 - cypherpunks-legacy

Optimism re NRC Cryptography Report
by tcmay＠got.net 17 Dec '03

17 Dec '03

At 11:04 PM 5/30/96, Hal wrote: >I read the overview of this, and while it is good that the report calls >for maintaining the legality of domestic encryption and some slight >loosening of the export rules, overall I was diappointed. Reading it at the Web site (http://www2.nas.edu/cstbweb/) and looking at some of the comments here, I'm not as disappointed as I expected to be. Sure, there is a lot of language about meeting law enforcement needs (including the disturbing proposal to apply NSA SIGINT capabilities domestically to help the FBI and law enforcement solve the "growing gap" problem in telecommunications intercepts), and the language about "56 bit" systems seems to leave open the door for severe restrictions on stronger systems (as Hal, Bill Frantz, and others note in their posts). But, on balance, I think this NRC report comes down strongly enough in favor of cryptography use for business and individuals that it will effectively *derail* and *stall* current Administration proposals, give support to the Burns Bill, and delay key escrow systems for at least several years. This should be enough to ensure our victory. (Not that I think that even fairly repressive legislation would've been enough to defeat us, but a new breathing spell can only help.) Unless laws are passed very quickly to outlaw the things we are involved with, including such things as superencryption, steganography, anonymous remailers, and digital money, I think we will "win the race to the fork in the road." The "fork in the road" being the point at which the changes are unstoppable. (And I couldn't see much about these technologies....though I haven't read every line of the Web summary, and have certainly not seen the full report.) So, at first reading, I am cautiously optimistic that this NRC report will carry enough weight to delay crypto legislation long enough to ensure our ultimate victory. The "degrees of freedom" will soon be too large as to ever control. --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."

2 1

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

17 Dec '03

At 8:15 5/31/96, Moltar Ramone wrote: >My guess would be that the first of these two points answers the second. >Everything is exportable -- except signed third-party security packages. >My bet would be that the exportable code would not be more than RC4-40 or >perhaps 1DES, but that a signed package would go to RC4-128, 3DES, and >RSA-1024. However, the signature on that package would be on the >condition that the vendor/distributor of that package follow all export >regulations. Where does this leave foreign vendors? Will Sun sign the 3DES package of a foreign vendor? Disclaimer: My opinions are my own, not those of my employer. -- Lucky Green <mailto:shamrock@netcom.com> PGP encrypted mail preferred.

5 4

Re: Something that just crossed my mind. Sorry.
by Sandy Sandfort 17 Dec '03

17 Dec '03

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ SANDY SANDFORT ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ C'punks, At 10:35 PM 5/30/96 -0500, snow wrote: >It is my position (until proven wrong--please) that larger business DON'T >want anonymity. They _want_ to be able to track purchases and use of their >product for several reasons. Two quick answers: 1) What big business wants and what it would be willing to accept in order to make sales, are two different things. While demographic data are nice, an more robust economy full of big spenders is better. 2) Big businesses are made up of individuals. Most individuals would still prefer to have their own privacy preserved even if they would prefer less privacy for others. S a n d y ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

1 0

Re: opinions on book "The Truth Machine"
by Sandy Sandfort 17 Dec '03

17 Dec '03

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ SANDY SANDFORT ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ C'punks, At 03:32 AM 5/31/96 GMT, A.Back(a)exeter.ac.uk wrote: >The book is a possible future world scenario exploring the social >implications of another new potential technology, a 100% reliable >truth test. What would society do with such a device? > >The book explores the direction in which it is no longer possible to >speak untruthfully without detection. A different approach to AP to >ensuring honesty in politicians. If such a device were to exist, you can bet your last e-buck that the politicians would be the LAST to be tested. Today, they ban or highly regulte the PRIVATE use of lie detectors. The excuse is "reliability," but the various levels of government still use them for their own purposes. With a 100% reliable device, they would either claim "national security"--the government needs to lie some times for your own good--or they would rig or evade its application to themselves. Count on it. S a n d y ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

1 0

NRC Report, 0, 1, 2
by jya＠pipeline.com 17 Dec '03

17 Dec '03

The first parts of the full NRC report are filed at our Web site: Preface, Executive Summary and Road Map: http://pwp.usa.pipeline.com/~jya/nrc00.txt (92 kb) Part I -- Framing the Policy Issues Chapter 1 Growing Vulnerability in the Information Age http://pwp.usa.pipeline.com/~jya/nrc01.txt (101 kb) Chapter 2 Cryptography: Roles, Market and Infrastructure http://pwp.usa.pipeline.com/~jya/nrc02.txt (80 kb) --------- Remaining 6 chapters and 14 appendices to be announced as completed. --------- Declan reports that an on-line version is due next week. Note that National Academy Press is accepting orders for the printed version, $45.00 + s/h each. For August. National Academy Press, 2101 Constitution Ave, NW, Lockbox 285, Washington, DC 20055. Tel 1-800-624-6242.

1 0

Re: NRC Cryptography Report: The Text of the Recommendations
by jim bell 17 Dec '03

17 Dec '03

At 04:04 PM 5/30/96 -0700, Hal wrote: >This is then followed with a couple of pages of justification for why >this relaxation of the export policies should be allowed. Much is made >of the fact that people will be more likely to use 56 bit encryption than >the 40 bit which is currently allowed. (This is an example of the >perspective issue I mentioned above.) However, nowhere is it stated why >more than 56 bits is not OK, and why it is necessary to forbid repeated >use to increase confidentiality. There is not one word of discussion of >this proviso. A very curious omission! It seems to me that if they're trying to explain any sort of limits on encryption, they should focus carefully on WHY those limits should exist, and why, exactly, those limits should be selected at any particular level. >Third, although in broad terms the report is supportive of the use of >cryptography, the specific recommendations do very little to liberalize >current policies. Free domestic access to cryptography is already the >law. Raising the export size limit from 40 to 56 bits is a step >forward, but a small one. Beyond 56 bits they recommend the >requirement of escrowed encryption. Given current moves to standardize >on triple DES, this is a retrenching action. They recommend >criminalizing the use of cryptography in committing crimes, admitting >that this may be used in some cases (as comparable mail fraud statues >have been) to bring prosecutions against people who cannot be proven to >have committed any other crime. "[T]he committee understands that it >is largely the integrity of the judicial and criminal justice process >that will be the ultimate check on preventing its use for such >purposes." I can think of a much better "ultimate check on preventing its use for such purposes." Jim Bell jimbell(a)pacifier.com

2 1

Re: Backdoor in RSA Discovered
by Gary Howland 17 Dec '03

17 Dec '03

> In this paper we present a mechanism that can quite easily be > added to PGP that allows the person who modifies PGP to learn > the private keys of those who use it to generate keys. Furthermore > the keys are leaked securely and subliminally, i.e. even if you > analyze the source code you cannot determine previously generated > keys or future keys, only the attacker can. The only way to detect the > presence of the mechanism itself is by looking over the source code, or > the compiled code. The attack has the effect of turning a database of > public keys into a database of public/private key pairs with respect to > the attacker *exclusively*. Sounds like they are doing something like this: Generate a prime P of 500 bits (say) Encrypt with Mallets public key Generate start_q using (E(P) << 524)/P Keep incrementing start_q until prime, and call this Q Generate N by multiplying P and Q to get a 1024 bit key Top 500 bits of N will be E(P) It could also be done like this: Generate a random H of, say, 290 bits Keep incrementing H until (H << 300) + 1 is prime and call this Q Encrypt H for Mallet H <<= 10 Keep incrementing H until prime Generate N by multiplying P by Q, to get a 900 bit key Bottom 300 (but 10) bits of N will E(P) I'm sure there are few mistakes, and there need to be a few other trivial tests in there somewhere, but I think this should work. The first method should produce "better" keys than the first (as if Mallet cares) I'll try and knock some code up to demonstrate this over the next few days. Gary -- pub 1024/C001D00D 1996/01/22 Gary Howland <gary(a)systemics.com> Key fingerprint = 0C FB 60 61 4D 3B 24 7D 1C 89 1D BE 1F EE 09 06

1 0

Privacy (was Re: Something that just crossed my mind. Sorry.)
by John Pettitt 17 Dec '03

17 Dec '03

At 10:01 AM 5/31/96 -0700, Sandy Sandfort wrote: >~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > SANDY SANDFORT >~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > >>Two quick answers: > >1) What big business wants and what it would be > willing to accept in order to make sales, are > two different things. While demographic data > are nice, an more robust economy full of big > spenders is better. > >2) Big businesses are made up of individuals. > Most individuals would still prefer to have > their own privacy preserved even if they would > prefer less privacy for others. > > I think what most people want is no surprises, by that I mean that peoples perceptions of privacy should match reality. In many cases that will mean no demographics. However there are a lot of situations where people will trade information for something they perceive as having value. I see nothing wrong with this *if* there is informed consent. John Pettitt, jpp(a)software.net EVP, CyberSource Corporation, 415 473 3065 PGP Key available at: http://www-swiss.ai.mit.edu/htbin/pks-extract-key.pl?op=get&search=0xB7AA37…

1 0

I told you so
by Perry E. Metzger 17 Dec '03

17 Dec '03

Reposted from the firewalls mailing list. Date: Thu, 30 May 1996 16:39:33 -0700 From: Bill Stout <bill.stout(a)hidata.com> Subject: DES-3 Story retraction I retract the following story, it was told to me by a contractor who attended a MBONE group meeting on the MBONE, where the story originated: Story: 'A person working on the MBONE project did an unannounced experiment across the internet using Triple-DES for MBONE, and the very next day, 'ATF' agents knocked on his door and warned him against exporting munitions. The experimentor was shaken by the fact that agents approached him so quickly after the experiment.' The MBONE experimentor referred to in the story was Van Jacobson at the Lawrence Berkeley Labs. I followed this up since receiving much interested mail responses. I called Van Jacobson himself at the Lab (the web is a wonderful thing!), and found that the story was embellished. The real event as told by Van Jacobson was: 'MBONE software was at one time accidentally compiled with links into libraries which contained DES, and someone (I don't remember who) noticed the DES capability in our MBONE binaries, and informed the group about the encryption export problem. The problem was promptly fixed.' Sorry for the mis-information. Bill <=======10========20====Ruler for Eudora users==50========60========70========80 William B. Stout | "Stop socialism in America!" Senior Systems Admin | "Dilbert for President." Hitachi Data Systems | "Police power today=police state tomorrow." Open Systems Center | "The secret of life - being part of the process of Santa Clara, California | creation." 408-970-4822 | #include <sanity_disclaimer.h> <=======10========20========30========40========50========60========70========80

2 3

NRC Report, 3
by jya＠pipeline.com 17 Dec '03

17 Dec '03

Chapter 3 Needs for Access to Encrypted Information http://pwp.usa.pipeline.com/~jya/nrc03.txt (88 kb)

1 0