- cypherpunks-legacy - lists.cpunks.org

Crypto Punch
by John Young 17 Dec '03

17 Dec '03

Punch in "cryptography" at the IBM patent site and ogle: you won't believe your oozing orbs. http://patent.womplex.ibm.com/ Then try other bell-ringers of this punch-drunk ring.

1 0

IMPORTANT: Additional information about UDCM.
by DataETRsch＠aol.com 17 Dec '03

17 Dec '03

{Please read this *entire* e-mail message.} Hi, A detailed description of the IMDMP encryption algorithm will be posted to this mailing list within a few days. An end-user application will be released within a few weeks. I would appreciate it if all you cypherpunks out there review the description and the software, and tell me what you think of IMDMP. Also: The AOL web site address my company has may not always work out when the server is having problems or user overloads. Please try again later. Again, the web site address for UDCM, Universal Data Cryptography Module, is: http://members.aol.com/DataETRsch/udcm.html. IN RESPONSE TO THE FLAME MAIL DATA RESEARCH HAS BEEN RECEIVING: Note: The 18 "sub-algorithms" of IMDMP are basically algorithm "modes", and, yes, many algorithms do *not* have multiple encryption layers, although, obviously, the more advanced ones do. Also, 256 bytes is equal to 2048 bits. I realize that most of you out there know that, but some of you don't. "Bits" are referenced more often than "bytes". And, the "industry standard" that IMDMP is obviously well above is DES, etc. Also, DES 128, PGP 1024, RSA 128, IDEA 128, and IMDMP 2048 were applied at their maximum settings on a file full of about 64 *million* repeating "A" ASCII character bytes. The mutation levels the algorithms rendered on their individual trash test files were compared. Subtle patterns where searched for. Binary character tallys where taken. IMDMP did *not* leave *any* repeating patterns in the test file that was used. In IMDMP, each of the 256 possible binary character combinations had an approximate count of 0.390625% of all of the 64 million bytes. 0.390625% is the best possible percentage. Are all of you out there satisfied? Jeremy K. Yu-Ramos President DataET Research Data Engineering Technologies

7 7

No Subject
by Bovine Remailer 17 Dec '03

17 Dec '03

A warning label ought to be tattooed on Tim C. May's head, saying `Warning: shit content under pressure'. o-:^>___? Tim C. May `~~c--^c'

1 0

Trade secrets / moderator liability
by Greg Broiles 17 Dec '03

17 Dec '03

As reported by Michael Froomkin's correspondent, the Uniform Trade Secrets Act <http://www.execpc.com/~mhallign/usta.html> (enacted with local modifications in, as I understand it, 40 states, among them California) says that third parties may be held liable for misappropriation of a trade secret where the third party knows or has reason to know that they are doing so. For example, California Civil Code section 3426.3 says: 3426.3.(a) A complainant may recover damages for the actual loss caused by misappropriation. A complainant also may recover for the unjust enrichment caused by misappropriation that is not taken into account in computing damages for actual loss. (b) If neither damages nor unjust enrichment caused by misappropriation are provable, the court may order payment of a reasonable royalty for no longer than the period of time the use could have been prohibited. (c) If willful and malicious misappropriation exists, the court may award exemplary damages in an amount not exceeding twice any award made under subdivision (a) or (b). And misappropriation is defined in California Civil Code section 3426(1)(b) as: (1) Acquisition of a trade secret of another by a person who knows or has reason to know that the trade secret was acquired by improper means; or (2) Disclosure or use of a trade secret of another without express or implied consent by a person who: (A) Used improper means to acquire knowledge of the trade secret; or (B) At the time of disclosure or use, knew or had reason to know that his or her knowledge of the trade secret was: (i) Derived from or through a person who had utilized improper means to acquire it; (ii) Acquired under circumstances giving rise to a duty to maintain its secrecy or limit its use; or (iii) Derived from or through a person who owed a duty to the person seeking relief to maintain its secrecy or limit its use; or (C) Before a material change of his or her position, knew or had reason to know that it was a trade secret and that knowledge of it had been acquired by accident or mistake. My other concern about moderator liability for approving/distributing trade secret material is in the criminal context. For example, the Economic Espionage Act of 1996 (HR 3723, now found at 18 USC 1831 et seq, <ftp://ftp.loc.gov/pub/thomas/c104/h3723.enr.txt> ) says that some trade secret violations are now a federal crime; and California Penal Code section 499c(b) also criminalizes some wrongful acts relating to trade secrets. Specifically, I think it's feasible to find aiding & abetting (and, more remotely, conspiracy) liability where a moderator knowingly and substantially contributes to public disclosure of a trade secret. It seems to me that there's a murky middle period, where the trade secret is known to some wrong people, but is still substantially a secret, where third party liability is present. But once a wide distribution of the secret is made, I don't think it's meaningful to talk about further distribution as misappropriation. If there's no common-sense "it's no longer a secret" safety valve, trade secret would provide time-unlimited protection to publically available information, which I think would be preempted by (or frustrate the purpose of) Congress' limited grants of protection to information via patent and copyright. But this is only my conjecture about how things ought to work, given the responsibilities created for third parties by statutes like the UTSA; I don't know of cases on this issue and given my work/bar review schedule, won't have time to find them any time soon. Also, as I mentioned in my previous message, I think there are good arguments that neither of the prominent trade secret disclosures I'm familiar with that have occurred (in part) via the list would create moderator liability. I'm mentioning moderator liability (and writing what's turning into a long message about it) not because I think it's an especially big danger but because I think it's an interesting public policy issue. I don't have the teeniest clue how other nations' laws might treat third parties who assist or enable the wide dissemination of trade secret materials. Perhaps other list members can offer a local perspective. -- Greg Broiles gbroiles(a)c2.net 510-986-8779 voice 510-986-8777 fax

2 1

Re: [IDEA] Cypherpunks Super Computer (was Re: The Upcoming DES Challenge)
by Hal Finney 17 Dec '03

17 Dec '03

[Sorry if this is a re-post...] From: "Frank O'Dwyer" <fod(a)brd.ie> > However, what if there was a safe scripting language with bignum > arithmetic and other cryptographic primitives, and what if > lots of people ran a service that would accept scripts in > that language and respond with the answer? Say, a Safe-TCL > interface to Peter Gutmann's cryptlib, running at idle > priority? Sort of like a distributed batch queue, and also > a bit like the way jobs are (were?) submitted to Crays. The > Cypherpunks Super Computer. It need not be significantly slower > than raw code if the primitives are high level enough. A few years ago I coded up a TCL interface to Pr0duct Cypher's PGPTOOLS library. It did bignum arithmetic from the command line, and also let you use MD5 and IDEA on files and buffers. Unfortunately I had a major disk crash and was never able to recover my last version, and I never got back to it. Safe-TCL has never gotten the scrutiny of Java, but IMO if it ever does it will be found to suffer from its own flaws. At this point I think Java is farther along the path to safety. I do like the idea of a widely available, installed, crypto-capable scripting language. This would be an ideal basis for trying out new crypto protocols and algorithms, without having to write a whole program from scratch. We have been talking about setting up DC nets for years, for example. The concept is so simple as to be almost trivial. But the infrastructure is the hard part - dealing with the I/O issues, the multiple architectures, all the configuration issues. I suspect that Java, when it gets its security API, may be a good candidate for this kind of system. It's already got high level socket I/O, and with a bignum package and some basic crypto primitives like one way functions, you could do a lot with it. You still have the problem of trading off safety for utility, though. Hal

3 2

No Subject
by Bovine Remailer 17 Dec '03

17 Dec '03

> >The Path To Revolution > >You Don't Have To Be There To Experience It > >By Linton Weeks >Washington Post Staff Writer >Thursday, January 9 1997; Page C5 >The Washington Post > >The computer is a revolutionary tool. > >It really is. Revolutionaries, counterrevolutionaries, >extremist groups, radical wings, separatist movements, >cults, and their critics and sympathizers are aswarm on >the Net. Never before have so many people had direct access >to information from every angle. It's like a teeming >hive of Gutenbergs. > >For instance, the Tupac Amaru Revolutionary Movement, >the Peruvian guerrillas who took hostages in the Japanese >embassy in Lima just before Christmas, has a Web presence. Its >"Solidarity Page," with a link to the official Spanish-language >Tupac Amaru site in Europe, is nursed by a Toronto-based group >called Arm the Spirit. > >The solidarity page is touted on a more elaborate site >sponsored by the U.S. Committee to Support the Revolution in >Peru. Based in Berkeley, this committee sings the song of the >Communist Party of Peru, also known as Shining Path. > >"Welcome to a real revolution in cyberspace!" reads the >Shining Path page. "We expose the lies about the >revolution put forward by the U.S.-backed Fujimori regime and >its apologists, while opposing U.S. and other foreign >intervention. We organize against the repression and >terror directed at the revolution and the Peruvian people." > >Sinn Fein, the radical political wing of the Irish Republican >Army, the armed and rebellious Sri Lankan Liberation Tigers >of Tamil Eelam and a multitude of U.S.-based "Aryan" >revolutionaries also have carefully designed Web sites. (Such >sites are so devoid of humor that it seems likely these people >really are who they say they are.) > >These are prime spots for unfiltered propaganda. Here in the >home of the free and the frenetic, the Net is protected by >the First Amendment and the wholesale distribution of >political information -- the good, the bad, the ugly -- is as >old as Thanksgiving. Thomas Paine would have had an amazing home page. > >The Shining Path pages are elaborate. Various links highlight >"the crimes of the U.S.-backed Fujimori regime," list the >political prisoners in Peru, reprint the press releases of Shining >Path and Tupac Amaru and offer a gallery of incendiary souvenirs >you can buy -- leaflets, buttons, T-shirts and cassettes of >revolutionary music. > >The site also gives users a way to "hook up with, support >and/or join us." But it warns those interested not to use >e-mail, because U.S. government officials might be monitoring >it. "We encourage you to contact us by postal mail, phone or fax." > >"Terrorist fund-raising is illegal in this country," said one >U.S. State Department staffer who was reluctant to talk about >the government's monitoring of any Web pages. Speaking only on >background, the staffer said that extremist Web sites are mostly >posted by U.S. citizens and are viewed as domestic material, >which is under the jurisdiction of the FBI and the Justice >Department, both of which have Web sites. > >"There is genuine international concern that this information >is freely available -- and that it's legal," the staffer said. > >John Russell of the Justice Department said, "There are First >Amendment considerations and there are legitimate law enforcement >concerns." The Justice Department, he said, would like >"to find a legal and acceptable procedure" to discover who >is posting the information. He said several law enforcement >agencies, including the FBI, ATF and DEA, are planning a joint >meeting soon to discuss the proliferation of such rabble-rousing pages. > >The Internet brings the far-flung complexities and dangers of the >world a little closer to home. The bright side is that most >people savvy enough to use the Internet may also be sophisticated >enough to sort out the truth in the information supplied by >various groups such as Tupac Amaru, Sinn Fein and the Department of Justice. > >GETTING THERE: >Tupac Amaru at http://burn.ucsd.edu/~ats/mrta.htm >Shining Path at http://www.calyx.com/~peruweb/csrp.htm >Sinn Fein at http://www.irlnet.com/sinnfein >Liberation Tigers of Tamil Eelam at http://www.eelam.com >State Department at http://www.state.gov >FBI at http://www.fbi.gov >Department of Justice at http://www.usdoj.gov. > >(Source: The Washington Post, http://www.washingtonpost.com) > >---- > >

1 0

Key Escrow Good, GAK Bad
by Ken Kirksey 17 Dec '03

17 Dec '03

> To me, Key Recovery cryptography is like using a condom with a >hole in it. No thanks. I agree in principle, and I doubt I would ever use a key recovery system if I had a choice. But, speaking as a network manager, I know that private key recovery (not GAK) can be an enhancement to security. I'll give an example. About a year ago, my boss wanted to protect his file of annual financial projections for the company from prying eyes on our Macintosh network. I installed CurveEncrypt on his machine, showed him how to use it, and gave him the standard lecture on choosing a good passphrase. I stressed that he needed to chose a passphrase easy to remember, because if he forgot it, there was no way to get his file back. Well, he forgot his passphrase. He spent an hour trying every combination he could think of, interjecting a curse here and there for color. He is now totally off using encryption to protect sensitive information. He refuses to use it, and he discourages anyone in the office from using it. I know that his position is unfair, but he _is_ the boss, so he makes the rules. And he is a typical computer user. If your average joe forgets his passphrase and loses two days worth of work, he's not likely to encrypt his work again. (Or he's likely to write down his passphrase in the future). If we were using a Key Escrow system, this situation could have been avoided. Yes, using a key escrow system is less secure that using a non-key escrow system, but I'd argue that using a strong key escrow system is better than using no encryption at all in situations like this. Our network is less secure that it could be because of one user's bad experience. Ken

5 4

Thanks.
by DataETRsch＠aol.com 17 Dec '03

17 Dec '03

Hi, Thanks for clearing up that file size query for me. You are right about that 258 (it's actually 256) header attribute. In that header is where the IMDMP special security option settings are stored (if they are indeed enabled). But the options are rarely ever used by most developers. For more information, download UDCM V2.0 from: http://members.aol.com/DataETRsch/udcm.html and view the help documentation. Also, the 256 byte header itself is encrypted with a 128-bit encryption code. Thanks again! :-) Jeremy... President DataET Research Data Engineering Technologies

1 0

Install UDCM properly before using it...
by DataETRsch＠aol.com 17 Dec '03

17 Dec '03

Hi again, The shareware version of UDCM *must* be installed before use. Run "install.exe" after decompression of the archive. JUST INCASE YOU DON'T KNOW WHAT THE HELL I AM TALKING ABOUT: Greetings! I am Jeremy K. Yu-Ramos, president of DataET Research, Data Engineering Technologies. I am sending you this message to let you know that DataET Research has recently initiated the distribution of UDCM, Universal Data Cryptography Module. UDCM implements a revolutionarily new, extremely advanced and sophisticated, digital data encryption algorithm named IMDMP, Integrated Mathematical Data Manipulation and Positioning. Extensive research shows that IMDMP is more advanced than DES, RSA, IDEA, and PGP. UDCM (the IMDMP algorithm)... o Is a royalty-free Windows DLL module featuring advanced cryptography. o Contains more than 140 procedures and functions. o Is a very cost-effective size of only 57 kilobytes. o Implements the IMDMP encryption algorithm. o Is more advanced than all of the industry standard encryption algorithms. o Allows encryption keys as large as 256 bytes (2048 bits). o Includes 18 sub-algorithms. o Processes all forms of binary and ASCII files. o Allows multiple encryption layer levels. o Has absolutely no back-doors or magical keys. o Does not store encryption keys in files. o Processes files as large as 2,147,483,390 bytes. o Has a 100% data preservation rating. o Includes Y2K compliant time and date locking features. o Has NCSC compliant data cleaning and wiping capabilities. o Includes file specific unique encryption features. o Includes file authentication guard features. o Includes unique encryption signaturing features. o Includes data importance and sensitivity stamping features. UDCM can be accessed through programs developed with popular application and database programming languages and environments such as: C, C++, Visual Basic, PowerBuilder, Delphi, OOP Pascal, Turbo Pascal, SmallTalk, dBase, Paradox, Access, Sybase, Oracle, etc. DataET Research has released a shareware version of UDCM named UDCM V2.0. To download UDCM V2.0 for free, please go to: http://members.aol.com/dataetrsch/udcm.html. I hope you will consider applying UDCM in the software you develop. Thank-you very much for your time. Jeremy... President DataET Research Data Engineering Technologies

1 0

Re: Key Escrow Good, GAK Bad
by Douglas Barnes 17 Dec '03

17 Dec '03

This whole line of reasoning is exactly what the government is preying on -- and it's working with a lot of people. However, it's a red herring. By and large, the government doesn't care about file-level encryption, the sort where the Key Escrow systems you're outlining would be useful. Furthermore, this kind of encryption can be done pretty much in isolation -- it's not a communication medium, so it's less susceptible to attacks on standardization. What the government is mostly concerned with is encryption that's used for communicating, where there is no similar feeling on the part of individuals or industry that something like key escrow is needed. It is a classic bait-and-switch maneuver. Furthermore, if people really wanted Key Escrow, the government wouldn't have to be putting the thumbscrews to software companies to get them to adopt it -- the market would perform this function quite nicely. FWIW, Doug At 04:31 PM 1/9/97 -0500, you wrote: >> To me, Key Recovery cryptography is like using a condom with a >>hole in it. No thanks. > >I agree in principle, and I doubt I would ever use a key recovery system >if I had a choice. But, speaking as a network manager, I know that >private key recovery (not GAK) can be an enhancement to security. > >I'll give an example. About a year ago, my boss wanted to protect his >file of annual financial projections for the company from prying eyes on >our Macintosh network. I installed CurveEncrypt on his machine, showed >him how to use it, and gave him the standard lecture on choosing a good >passphrase. I stressed that he needed to chose a passphrase easy to >remember, because if he forgot it, there was no way to get his file back. > >Well, he forgot his passphrase. He spent an hour trying every >combination he could think of, interjecting a curse here and there for >color. He is now totally off using encryption to protect sensitive >information. He refuses to use it, and he discourages anyone in the >office from using it. I know that his position is unfair, but he _is_ >the boss, so he makes the rules. > >And he is a typical computer user. If your average joe forgets his >passphrase and loses two days worth of work, he's not likely to encrypt >his work again. (Or he's likely to write down his passphrase in the >future). If we were using a Key Escrow system, this situation could have >been avoided. Yes, using a key escrow system is less secure that using a >non-key escrow system, but I'd argue that using a strong key escrow >system is better than using no encryption at all in situations like this. > Our network is less secure that it could be because of one user's bad >experience. > >Ken >

1 0