- cypherpunks-legacy - lists.cpunks.org

I confess [Was: Who was that Masked Cypherpunk?]
by liberty＠gate.net 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Duncan Frissell <frissell(a)panix.com> wrote: >OK, fess up. Who was it who amended the anti-key-escrow language of the >Libertarian Party Platform live on CSPAN? Specific reference to >cypherpunks. 'Twas me, the guardian of the *original* definition of the fine old term "escrow" against the slick denizens of Newspeak. I have found this Libertarian convention to be a super-fun experience, and I will be demonstrating PGP, Private Idaho, and lots of other fun stuff on Saturday at 3PM. All are invited to attend. Watch for "Pennies for Perot" this afternoon! ;) JMR -- Dade Chairman and Florida Delegate. Regards, Jim Ray -- DNRC Minister of Encryption Advocacy "It is long past time to end the laughable presumption that voters who can easily cope with the choices offered at Burger King are somehow 'confused' by more than two choices at the voting booth." -- me [From my Miami Herald article.] "Truth is stranger than fiction, especially when 'truth' is being defined by the O.J. Simpson Defense Team." -- Dave Barry 6/16/96 ___________________________________________________________________ PGP id.E9BD6D35 51 5D A2 C3 92 2C 56 BE 53 2D 9C A1 B3 50 C9 C8 <mailto:liberty@gate.net> http://www.shopmiami.com/prs/jimray Coming soon, "Pennies For Perot" page! CYA with http://www.anonymizer.com ___________________________________________________________________ -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Freedom isn't Freeh. iQCVAwUBMd1Ii21lp8bpvW01AQEBWAQAoWqyLNe921Dx9HXbMFVoW2ReNGp0Qo6r mZd3FvNcJDw4bOeI434sekDwAEg9G2SiCCnBMBFrilZnKscMZpZp0XdNV6+b52FN MtyYW9yYQSRRgixjf3+j6O6jecPynztdugnnWY7Y8jWcb3ukipYYt4cQAVL13sX4 Aknxd4DXtzc= =lvW8 -----END PGP SIGNATURE-----

1 0

Shrink-Wrap Lic. uphelo by courts. From Edupage, 4 July 1996
by Deranged Mutant 17 Dec '03

17 Dec '03

------- Forwarded Message Follows ------- Date: Thu, 4 Jul 1996 17:27:43 -0400 (EDT) From: Edupage Editors <educom(a)elanor.oit.unc.edu> Subject: Edupage, 4 July 1996 ***************************************************************** Edupage, 4 July 1996. Edupage, a summary of news items on information technology, is provided three times each week as a service by Educom, a Washington, D.C.-based consortium of leading colleges and universities seeking to transform education through the use of information technology. ***************************************************************** [..] "SHRINK-WRAP" LICENSES OKAYED BY COURT The validity of the "shrink-wrap" licenses that many software publishers rely on for copyright protection was bolstered by a recent appellate court ruling in Chicago. Last month, the Seventh Circuit Court of Appeals reversed a lower court's finding that shrink-wrap agreements were unenforceable. Plaintiffs in the case, ProCD vs. Zeidenberg et al., charged the defendants with distributing the software program via the Internet. The defendants had argued that they couldn't be held to the license terms because they'd had no chance to negotiate or object to parts of the agreement. They also said the license agreement should be printed on the outside of the box, where it could be read before purchasing. The latest ruling found this suggestion to be an onerous burden, but did say the box must have a notice saying there's a licensing agreement inside, and that buyers should be able to return the software if they don't agree to the license once they read it. (Investor's Business Daily 3 Jul 96 A5)

1 0

Re: rsync and md4
by jamesd＠echeque.com 17 Dec '03

17 Dec '03

At 02:05 AM 7/1/96 -0400, David F. Ogren wrote: > I stand by my statements. When you are deep in a hole, it is time to quit digging. > The problems that you bring up have to do with situations > where an active attacker develops a slightly different > pair of documents with the same hash. > > Although this is highly undesirable characteristic for a > hash function, [...] No kidding. Current state of the art is that MD4 is broken for signing documents prepared by other people, and MD5 may be broken soon, but MD4 is not broken as proof of authorship. So if everyone was using MD4 for PGP signing, which they are not, it would still not be a problem for most people. But it would be a problem for authors of software, who should know that a security bug that sinks only *some* people is still a security bug. Therefore no author of software should employ MD5 or MD4 in new software, but existing users of software that employs MD5 and MD4 should not panic. --------------------------------------------------------------------- | We have the right to defend ourselves | http://www.jim.com/jamesd/ and our property, because of the kind | of animals that we are. True law | James A. Donald derives from this right, not from the | arbitrary power of the state. | jamesd(a)echeque.com

1 0

Re: SAFE Forum--some comments
by frantz＠netcom.com 17 Dec '03

17 Dec '03

At 08:44 PM 7/2/96 -0700, Martin Minow wrote: >It's not quite that bad. Here are a few (more or less strong) crypto >products you might not know you have: > >1. Every Macintosh made since at least 1988 has a secure authentication > client module in the AppleShare Chooser dialog. When you use it to > connect to a remote server, it notes that the user information > is "two-way scrambled." (The server sends a random number challenge > that the client uses to encrypt the username and password. The > encrypted information is sent to the server.) All Macintosh systems > running System 7 or later have the corresponding server software. > What is interesting about this is that the encryption is completely > invisible to the user. I hear this as the server sends out a key which the client uses to encrypt the username/password. This algorithm makes less sense than the one I thought I heard at the SAFE forum on Monday which was: (1) The server sends out a challenge/salt (different each time) (2) The client uses a secure hash to compute hash(salt||password) and returns the username and the hash. (3) The server computes hash(salt||password) and compares the hashes. Given that there is still some interest in algorithms and protocols on this list, can you describe what is really happening? Thanks - Bill ------------------------------------------------------------------------- Bill Frantz | The Internet may fairly be | Periwinkle -- Consulting (408)356-8506 | regarded as a never-ending | 16345 Englewood Ave. frantz(a)netcom.com | worldwide conversation. | Los Gatos, CA 95032, USA

2 1

C2's Anonymizer in Reuters
by E. ALLEN SMITH 17 Dec '03

17 Dec '03

Not the most friendly of articles... but still pretty good. As usual, edited to stay within fair use. -Allen > Reuters New Media > _ Friday July 5 12:28 PM EDT _ >Web Surfing Incognito > HOLLYWOOD - Ever felt like browsing without leaving those footprints > that site designers, your school and your employer are increasingly > inclined to harvest? > A service being offered at http://www.anonymizer.com purports to give > Web surfers the freedom to travel at will without leaving tell-tale > signs that they've been where they've been. [...] > The visited site's layout and design can be altered, so you are > probably not seeing it in all its glory -- and it is displayed within > a field with hot buttons to take you back to the anonymizer site, a > FAQ or to make a bug report (like, for example, you've reached a site > which isn't preceded by the anonymizer URL). > Privacy is one of those issues veteran Netizens take very seriously -- > it used to be called "anonymous" FTP after all. But many > sites now depend on demographics passively collected, rather than just > the number of hits, to attract advertisers. > Copyright, Reuters Ltd. All rights reserved

1 0

CCC Crypto Lock
by anonymous-remailer＠shell.portal.com 17 Dec '03

17 Dec '03

MicroPatent, 4 July 96 Systems and methods for protecting software from unlicensed copying and use (Assignee -- Convex Computer Corporation) Abstract: Disclosed systems and methods for protecting a software program from unauthorized use and copying through the removal at least one of a plurality of instructions comprising a software program, and encrypting the removed instruction utilizing an encryption algorithm to produce an encrypted instruction, the encryption algorithm responsive to a randomly generated key. Ex Claim Text: A processing system for protecting a software program from unauthorized use, said software program including one or more unencrypted instructions stored in memory associated with said software program, said processing system comprising: a processing unit operable to: remove at least one selected said unencrypted instruction from an executable area in said memory associated with executable portions of said program; encrypt said at least one selected unencrypted instruction removed from said software program utilizing an encryption algorithm to produce an encrypted instruction; store said encrypted instruction within a first non-executable data area in said memory associated with said software program; and insert at least one trappable instruction in place of said encrypted instruction within said executable area in memory allowing said software program to be linked with one or more other programs. Assignee: Convex Computer Corporation Patent Number: 5530752 Issue Date: 1996 06 25 Inventor(s): Rubin, Robert J. If you would like to purchase a copy of this patent, please call MicroPatent at 800-984-9800. Copyright 1996, MicroPatent

1 0

Transforming variable- to fixed-length keys
by pgut001＠cs.auckland.ac.nz 17 Dec '03

17 Dec '03

In preparing the next version of cryptlib (which is going to have some cool features when it's ready, which should be before the end of the millenium), I've run into a problem in writing a general-purpose n-byte input to m-byte output transformation function. What this does is take an arbitrary-length user key and transform it to a fixed-length encryption key (for example an entered passphrase into a 112-bit triple-DES key). The constraints on memory usage are: - The input (user) key can't be altered (you can't change data passed in by the caller) - The user key can't be copied to an internal buffer (it can be of arbitrary length, and is sensitive material so shouldn't be copied elsewhere) In other words there's no temporary storage available apart from what's provided in the output key. This is almost always a different length from the input key. Some other constraints are: - The transformation must be algorithm-independant (it shouldn't, for example, rely on SHA1 to transform an input string into a fixed output of 160 bits and assume you'll never need a key longer than 160 bits). This means you can't just use a single pass of a hash function to generate the output key, since the output can be smaller or larger than the hash function output. - The transformation must be able to be iterated to make a password-guessing attack harder to perform. This one is tricky, since the lack of temporary buffer space means you can't just feed the output back to the input and iterate. Here's my initial approach, if anyone has any comments to make on this or knows of a better way to do it, please let me know. Peter. -- Snip -- Initially, the user key is passed in as a byte string: +-------------------------------------------------------+ | User Key | +-------------------------------------------------------+ The first stage in the key hashing prepends the length of the string as a big-endian 16-bit count to the user key: +------+-------------------------------------------------------+ |Length| User Key | +------+-------------------------------------------------------+ The aim of the hashing is to reduce this variable-length input string to a fixed-length key appropriate to the encryption algorithm being used. This is done by treating the user encryption keys as circular buffers and repeatedly hashing chunks of the user key and xoring the result into the output buffer. Thus the first chunk of the encryption key would be obtained with: +------+-------------------------------------------------------+ |Length| User Key | +------+-------------------------------------------------------+ | | | _ / | Hash _ / | _ / | / | | +-----------------------+ | Encryption Key | +-----------------------+ The second chunk of the enryption key would be obtained with: +------+-------------------------------------------------------+ |Length| User Key | +------+-------------------------------------------------------+ | | | _ / | Hash _ / | _ / | / | | +-----------------------+ | Encryption Key | +-----------------------+ Since the input to the hash function is much larger than its output, a significant amount of the user key affects each chunk of the encryption key. The size of each "chunk" is determined by the hash function being used. For example with the MD4 hash function, 64 bytes of user key affect each 16 bytes of encryption key. Once the end of the user key or encryption key buffer is reached, the hash function wraps around to the start of the buffer and takes its data from there. A pass over the user key is considered complete when the hash function input has wrapped around completely and is back at the start of the buffer. The amount of wraparound depends on the length of the user and encryption keys. For example with 8-byte (strictly speaking 56-bit) DES keys even a single application of MD4 will wrap around the encryption key buffer twice, shrinking up to 64 bytes down to 8 bytes in a single operation. On the other hand a 4-byte user key will wrap the user key buffer around twice, expanding it to fill 8 bytes of the encryption key buffer (without, however, actually giving 8 bytes of effective key space). In order to avoid repeatedly hashing the same data (which results in the output key cancelling out every second round), the input data is varied by adding the iteration count mod 256 to each byte before it is hashed. Therefore for five rounds of key hashing the user key "This is a key" would give the following effective input to the hash function: \x00\x0DThis is a user key \x01\x0EUijt!jt!b!vtfs!lfz \x02\x0FVjku"ku"c"wugt"mg{ \x03\x10Wklv#lv#d#xvhu#nh| \x04\x11Xlmw$mw$e$ywiv$oi} [Is this nice? Problems are that you might be able to perform some sort of related-key attack, and that if you know the input value to round n you can get the input value to round n+m without having to go through all m rounds. However I can't see how this would aid an attacker].

1 0

Re: Net and Terrorism.
by Arun Mehta 17 Dec '03

17 Dec '03

At 00:37 05/07/96 -0700, Rich Graves wrote: >Since the two muslims who used to give a shit about this list seem to have >left in disgust, I suppose I should register my "That ain't representative >of Islam... Not so long ago, when Moslems were fighting the Soviet Union in Afghanistan, they were heroes to the western world, supplied arms and money enough to destabilise the whole region. Once the Soviet menace faded, the same fighters were branded terrorists. Mixed signals like this are responsible for much of the animosity that one finds in the Islamic world (possibly even in other parts of the world) against the US. Arun Arun Mehta Phone +91-11-6841172, 6849103 amehta(a)cpsr.org http://mahavir.doe.ernet.in/~pinaward/arun.htm

1 0

Re: I confess [Was: Who was that Masked Cypherpunk?]
by Duncan Frissell 17 Dec '03

17 Dec '03

At 12:56 PM 7/5/96 -0400, Jim Ray wrote: >'Twas me, the guardian of the *original* definition of the fine old >term "escrow" against the slick denizens of Newspeak. I have found >this Libertarian convention to be a super-fun experience, and I will >be demonstrating PGP, Private Idaho, and lots of other fun stuff on >Saturday at 3PM. All are invited to attend. Since no one has mentioned exactly what happened at the LP Convention, I will relate it from memory and JR can correct me. They were going to vote on adopting a platform plank that upheld the right of everybody to use any crypto they wanted and export it an everything and also opposing the proposal for a requirement that people use a key escrow system set up by the government. JR offered an amendment which changed the language to refer to "so-called Key Escrow (actually government access to keys GAK)" and he also explained that "escrow" is where you place something with a trusted third party and the government is neither trusted nor a third party. He mentioned cypherpunks live on CSPAN. Maybe when JR finished the Con he can post the original proposed language of the LPs plank and the final language as amended. DCF

2 1

Re: CWD -- Jacking in from the "Keys to the Kingdom" Port
by Alan Olsen 17 Dec '03

17 Dec '03

At 06:27 AM 7/6/96 +0000, you wrote: >On Fri, 5 Jul 1996, CyberEyes wrote: > >> NOT talking about Lynx, what DOS-based Web browser is there? > > Net-Tamer. > > Requires a PPP connection, and precious little else. The problem is getting PPP to work under DOS. If your kid can do that, then he will have no problem in disabling any sort of filtering, as well as wiping the hard drive and installing Linux with X11R6. DOS stacks are a pain to get functioning, usually have little to no useful instructions, and tend to be harder than hell to find. (Or as Homer Simpson once said: "Mmmmmm! Packet drivers!") I expect to see a case where some kid gets in trouble for filtering out what his parents can see, read, or hear. Or sets the school filter to only allow going to porno sites. I find it humorous how many people think that they can use technology to babysit their kids when the kids understand the technology much better than they do in most cases... --- Alan Olsen -- alano(a)teleport.com -- Contract Web Design & Instruction `finger -l alano(a)teleport.com` for PGP 2.6.2 key http://www.teleport.com/~alano/ "We had to destroy the Internet in order to save it." - Sen. Exon "Microsoft -- Nothing but NT promises."

1 0