- cypherpunks-legacy - lists.cpunks.org

Re: RC4
by rross＠sci.dixie.edu 17 Dec '03

17 Dec '03

>From: Alex Tang <altitude(a)umich.edu> >> I talked with RSA yesterday specifically about free servers and RC4. >> They just said that they would need a business plan for the >> server product. When i said that the product would be free, they started >> talking in circles about how everyone who uses RC4 needed a license (but i >> was asking about the licenses...) I asked flat out "how much would a >> license for RC4 cost for a free server product". They only reponded with >> "Very Expensive", and then went on about a business plan. > >Ask them about the free version of RC4 which is circulating. If they say >it is patented ask them for the patent number. Ask them why you should >pay them big bucks if you can get it for free. Here's their reply to a similar correspondence: >The RC4 algorithm is copyrighted by and intellectual property of RSA Data >Security. For use of this algorithm in a product or service you plan to >sell, you may use the RC4 software implementation from our BSAFE toolkit. >Licenses are not available for other commercial software implementations of >this algorithm other than what is included in our BSAFE toolkit. I wasn't aware that you could copyright an algorithm. Patent, yes, but not copyright. Intellectual property meens secret, right? Aren't there any precendence cases involving propriety schemes that are reverse engineered? I know there have been, I just can't remember what they are. In any case, RSADSI is likely to sue anyone who attempts to use the RC4 code openly, and even if they lose there are considerable legal fees involved for whoever tries it. What if a bunch of people put secure HTTPd servers online at the same time, without any clear trail pointing to the first one? If the RC4 code really is legal to use, this would make it hard for RSADSI to pinpoint anyone to sue, thus eliminating the intimidation factor. By the way, since RSA is such a vocal opponent of the Clipper chip on the grounds of its secret Skipjack algorithm, why does it market secret algorithms like RC4 and RC2? Does this seen like a double face to anyone else? ----------------------------------------------------------- Russell Ross email: rross(a)sci.dixie.edu 1260 N 1280 W voice: (801)628-8146 St. George, UT 84770-4953

5 4

Re: patented vs secret (was Re: RC4)
by rross＠sci.dixie.edu 17 Dec '03

17 Dec '03

>> >> By the way, since RSA is such a vocal opponent of the Clipper chip on the >> grounds of its secret Skipjack algorithm, why does it market secret >> algorithms like RC4 and RC2? Does this seen like a double face to anyone >> else? >> >> ----------------------------------------------------------- >> Russell Ross email: rross(a)sci.dixie.edu >> 1260 N 1280 W voice: (801)628-8146 >> St. George, UT 84770-4953 > >Patented does not equal secret. The argument against Clipper (at least one >of them ;-), is that it has not been subjected to review outside of the NSA. > >I believe the code for RC4 and RC2 is accessible and has been subjected to >review by many in the crypto field - you just can't use it legally without >a license. > >Noam Source code for them is available for $25,000, but only binaries are available otherwise. The source code for RC4 was leaked or reverse-engineered, so it is widely known now, but RSA has never released the algorithm officially. I have found no documentation on the algorithm behind RC2. They are in fact secret, proprietary algorithms, with the exception of the unofficial RC4 code. ----------------------------------------------------------- Russell Ross email: rross(a)sci.dixie.edu 1260 N 1280 W voice: (801)628-8146 St. George, UT 84770-4953

1 0

cost of attacking cards (fwd)
by fc＠all.net 17 Dec '03

17 Dec '03

Forwarded message: >From fc Thu Jul 27 19:16:26 1995 Subject: cost of attacking cards To: pgf(a)tyrell.net (Phil Fraering) Date: Thu, 27 Jul 1995 19:16:26 -0400 (EDT) In-Reply-To: <199507272242.AA05163(a)tyrell.net> from "Phil Fraering" at Jul 27, 95 05:42:57 pm X-Mailer: ELM [version 2.4 PL22] Content-Type: text Content-Length: 608 > Just wondering, but do you have a cost breakdown for the > figure of $ 500.00 for a "cash card?" I published this stuf about 4 years ago and calculated $5,000, but a few months ago I spent some time with one of the top people in this field and he claimed that $500 was the right figure and backed it up with some experiments. > Would this be a single-unit manufactured-in-one-piece card > or something else? This is based on a volume business where we are breaking cards full time. -- -> See: Info-Sec Heaven at URL http://all.net Management Analytics - 216-686-0090 - PO Box 1480, Hudson, OH 44236 -- -> See: Info-Sec Heaven at URL http://all.net Management Analytics - 216-686-0090 - PO Box 1480, Hudson, OH 44236

1 0

The Value of "Attachments" on this List
by tcmay＠sensemedia.net 17 Dec '03

17 Dec '03

See attached file: F:\MYFILES\MAY.MSG The attached file: "MAY.MSG" has been attached in HyperMIME format. It may be read by any Exidy Sorcerer computer, using Electric Pencil 1.2 (release date 7-81).

1 0

"Encryption" IRC script?
by wmono＠Direct.CA 17 Dec '03

17 Dec '03

C'punks.. I was just DCC'ed this rather cryptic IRCII script. The author, nickname george.. /whois george 311 George ~root original.netwest.com * :000-System Admin-000 312 George irc.escape.com :[198.6.71.13] Escape - New York City (I highly doubt he's really the root there - no identd running?) claims that it's an encryption routine in IRC. I don't know how to read that script language, and I'm most certainly not a crypto expert, so I've attached the script in hopes that someone can tell me if this guy is a whacko and whatnot. (Sorry for those not interested - the file was small, so I figured that not too many people will mind. It is ASCII with some nonprintables contained within.) I warn that I haven't tested the script, and as with all untrusted scripts, DO NOT RUN IT until it's confirmed by someone that it's safe! I-CODE.IRC -- William Ono <wmono(a)direct.ca> PGP 2902B621 fingerprint = 51 6B BC 81 57 D8 FF 6A 5A A1 A4 6B 9A E3 E5 EE = fingerprint PGP-encrypted mail welcome! Witty Quote Goes Here

1 0

New release (v1.3) of CFS Unix encrypting file system now available
by Matt Blaze 17 Dec '03

17 Dec '03

Source code for the latest version (release 1.3) of CFS, the Cryptographic File System, is now available upon request for research and experimental use in the US and Canada. CFS pushes encryption services into the Unix(tm) file system. It supports secure storage at the system level through a standard Unix file system interface to encrypted files. Users associate a cryptographic key with the directories they wish to protect. Files in these directories (as well as their pathname components) are transparently encrypted and decrypted with the specified key without further user intervention; cleartext is never stored on a disk or sent to a remote file server. CFS employs a novel combination of DES stream and codebook cipher modes to provide high security with good performance on a modern workstation. CFS can use any available file system for its underlying storage without modification, including remote file servers such as NFS. System management functions, such as file backup, work in a normal manner and without knowledge of the key. CFS runs under SunOS and several other BSD-derived systems with NFS. It is implemented entirely at user level, as a local NFS server running on the client machine's "loopback" interface. It consists of about 5000 lines of code and supporting documentation. You must have "root" access to install CFS. CFS was first mentioned at the work-in-progress session at the Winter '93 USENIX Conference and was more fully detailed in: Matt Blaze. "A Cryptographic File System for Unix", Proc. 1st ACM Conference on Computer and Communications Security, Fairfax, VA, November 1993. (PostScript available by anonymous ftp from research.att.com in the file dist/mab/cfs.ps.) and in Matt Blaze. "Key Management in an Encrypting File System", Proc. Summer '94 USENIX Tech. Conference, Boston, MA, June 1994. (PostScript available by anonymous ftp from research.att.com in the file dist/mab/cfskey.ps.) Version 1.3 of CFS also includes ESM, the Encrypting Session Manager. ESM provides shell-to-shell encrypted sessions across insecure links and requires no OS or network support. It is useful for typing cfs passphrases when logged in over the network. ESM needs RSAREF 2.0 to compile and is tested only on SunOS and BSDI. ESM is the first released part of a suite of session encryption tools that are described in Matt Blaze and Steve Bellovin. "Session-layer Encryption." Proc. 1995 USENIX Security Workshop, Salt Lake City, June 1995. (PostScript is available from ftp://research.att.com/dist/mab/sesscrypt.ps) The new version of CFS differs from the version described in the papers in a few ways: * The DES-based encryption scheme has been strengthened, and now provides greater security but with the online latency of only single-DES. * Support for the smartcard-based key management system is not included and a few of the tools are not included. * An impoved key management scheme now allows chaning the passphrase associated with a directory. * The performance has been improved. * The security of the system against certain non-cryptanalytic attacks has been improved somewhat. * User-contributed ports to a number of additional platforms. * Hooks for adding new ciphers. * 3-DES and MacGuffin encryption options. * Timeout options allow automatic detach of encrypted directories after a set time or period of inactivity. CFS is distributed as a research prototype; it is COMPLETELY UNSUPPORTED software. No warranty of any kind is provided. We will not be responsible if the system deletes all your files and emails the cleartext directly to the NSA or your mother. Also, we do not have the resources to port the software to other platforms, although you are welcome to do this yourself. The software was developed under SunOS and BSDI, and there are also unsupported user-contributed ports available for AIX, HP/UX, Irix, Linux, Solaris and Ultrix. We really can't promise to provide any technical support at all, beyond the source code itself. We also maintain a mailing list for CFS users and developers; subscription information is included with the source code. Because of export restrictions on cryptographic software, we are only able to make the software available within the US and Canada to US and Canadian citizens and permanent residents. Unfortunately, we cannot make it available for general anonymous ftp or other uncontrolled access, nor can we allow others to do so. Sorry. Legal stuff from the README file: * Copyright (c) 1992, 1993, 1994 by AT&T. * Permission to use, copy, and modify this software without fee * is hereby granted, provided that this entire notice is included in * all copies of any software which is or includes a copy or * modification of this software and in all copies of the supporting * documentation for such software. * * This software is subject to United States export controls. You may * not export it, in whole or in part, or cause or allow such export, * through act or omission, without prior authorization from the United * States government and written permission from AT&T. In particular, * you may not make any part of this software available for general or * unrestricted distribution to others, nor may you disclose this software * to persons other than citizens and permanent residents of the United * States and Canada. * * THIS SOFTWARE IS BEING PROVIDED "AS IS", WITHOUT ANY EXPRESS OR IMPLIED * WARRANTY. IN PARTICULAR, NEITHER THE AUTHORS NOR AT&T MAKE ANY * REPRESENTATION OR WARRANTY OF ANY KIND CONCERNING THE MERCHANTABILITY * OF THIS SOFTWARE OR ITS FITNESS FOR ANY PARTICULAR PURPOSE. If you would like a copy of the CFS source code, please read to the end of this message and then send email to: cfs(a)research.att.com DO NOT REPLY DIRECTLY TO THIS MESSAGE. You must include a statement that you are in the US or Canada, are a citizen or legal permanent resident of the US or Canada, and have read and understand the license conditions stated above. Be sure to include an email address in a US- or Canada-registered domain. The code will be sent to you via email in a "shar" shell archive (a little over 300K bytes long).

1 0

Re: Banks and Crypto - Again
by Andrew Loewenstern 17 Dec '03

17 Dec '03

> Critics say that the longer DES is used, the more likely its code > could be broken. While realizing this could limit its life span > as a government certified standard, ABA warned that requiring banks > to convert to a new standard by 1998 (the year DES's certification > expires) could be prohibitively costly due to the high level of > electronic funds transfers secured by DES. ABA therefore encouraged > the National Institute for Standards and Technology (NIST) to > continue to endorse DES as a Federal Information Processing Standard > (FIPS) for use by the financial community. "Breaking DES keys in a reasonable amount of time could be prohibitively costly for Banks due to the high level of electronic funds transfers secured by DES." andrew

1 0

Military Prisons for Citizen-Units
by tcmay＠sensemedia.net 17 Dec '03

17 Dec '03

At 5:42 PM 7/28/95, Brian Davis wrote: >The military is not authorized to listen in to any phone calls they want >to hear. Otherwise, everyone on the list, including me, would probably >be in some hidden military prison. > >:-) for the humor-impaired. This is not so. The military _did_ put me in one of their hidden military prisons, but decided I would be more useful on the Cypherpunks list. I recognize several other names here from my work brigade. --Citizen-Unit Tim "The Zek" May .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay(a)sensemedia.net | anonymous networks, digital pseudonyms, zero 408-728-0152 | knowledge, reputations, information markets, Corralitos, CA | black markets, collapse of governments. Higher Power: 2^756839 | Public Key: PGP and MailSafe available. "National borders are just speed bumps on the information superhighway."

2 1

Re: Java, Netscape, OpenDoc, and Babel
by david d `zoo' zuhn 17 Dec '03

17 Dec '03

[ Web Mall, OSF, Java, ports, etc] // See http://www.osf.org/comm/press/950276-ato.html for mroe details. Actually, try http http://www.osf.org/comm/press/950726-ato.html instead.

1 0

Re: Java, Netscape, OpenDoc, and Babel (NewsClip)
by Rich Salz 17 Dec '03

17 Dec '03

>On the other hand, a Java object brokerage service sponsored by OSF OSF has no current plans to do this.

1 0