December 2003 - cypherpunks-legacy

Re: Word lists for passphrases
by Erle Greer 17 Dec '03

17 Dec '03

At 12:09 AM 7/6/96 -0500, snow(a)smoke.suba.com wrote: >On Fri, 5 Jul 1996, Erle Greer wrote: > >> Word-List Builder (this is not an ad) >> I have a small(5k) program(WordList.EXE) that will extract <words> from any >> file and append the new words to a textfile(MainList.TXT). It is in early >> beta, but does the job nicely. I simply drag-n-drop multiple files onto the >> icon and let it do its dirty work. It prints new words to the screen and >> echos "." when it encounters old words again. It will, of course, accept >> parameters from DOS. > > Is the source code available for porting to other platforms? Sure, I'm not a Unix guru, but if you can port Turbo Pascal, more power to you! I will send the source if someone specifically asks. >> This is totally free to anyone who wants it. Just email and I will send the >> latest version. Suggestions are certainly considered. > > Unixi, recursively scanning directories. Unix, you can do, but the recursive subdirs aren't a prob for me. A final dream would be to convert it to VB4, use MS's WWW custom control, and unleash it as a spider. >> Imagine building a word-list just from your /Netscape/Cache subdirectory! > > Imagine building a word list from /usr/spool/news/* > >Petro, Christopher C. >petro(a)suba.com <prefered for any non-list stuff> >snow(a)crash.suba.com

1 0

Re: Word lists for passphrases
by Erle Greer 17 Dec '03

17 Dec '03

Word-List Builder (this is not an ad) I have a small(5k) program(WordList.EXE) that will extract <words> from any file and append the new words to a textfile(MainList.TXT). It is in early beta, but does the job nicely. I simply drag-n-drop multiple files onto the icon and let it do its dirty work. It prints new words to the screen and echos "." when it encounters old words again. It will, of course, accept parameters from DOS. This is totally free to anyone who wants it. Just email and I will send the latest version. Suggestions are certainly considered. Imagine building a word-list just from your /Netscape/Cache subdirectory! Future versions will include: Larger multiple file handling, *.* in same directory support, better binary file support, and list sorting.

2 1

Re: What remains to be done.
by Anthony Daniel 17 Dec '03

17 Dec '03

Hi there Should try SECURE DESK-TOP as well (PC only), it can encrypt (DES and IDEA) any: - file - directory - groups of directories - Hard Disk - Floppy - Removable drive And it can add PEM capabilities to most e-mail clients and it's WIN95 and user friendly. Try it at: http://www.systems.it/secure There are NO export restrictions on it as well because it's Italian made. ciao Anthony ------------------------------------------- >At 12:58 PM 7/4/96 +0000, Deranged Mutant wrote: >>Another need is for file/disk-encryption utilities. I'm not familiar >>with what's out there for Macs, but for PCs there's SFS and ASPICRYP >>for SCSI drives (with no source!) and SFS, SecureDrive and SecureDevice >>for HD (or FD). The latter won't work on Win95. AFAIK, SFS and >>SecureDrive aren't 100% friendly with Win95 either, though they'll work. > > I'll just add that Jetico puts out BCrypt, which works perfectly >with Win95. Of course it costs, but one can try out the software only >version, then upgrage to hardware encryption! >_______________________ >Regards, He who knows others is wise. > He who knows himself is enlightened. >Joseph Reagle http://rpcp.mit.edu/~reagle/home.html >reagle(a)mit.edu E0 D5 B2 05 B6 12 DA 65 BE 4D E3 C1 6A 66 25 4E >

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

ratings
by bryce＠digicash.com 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Of course a real rating would be signed by my ratings private key and not by my e-mail private key. I might start a service where I will pay you for your ratings and then distribute them for a fee. (Note that you get paid for generating ratings, as long as your ratings get good meta-ratings. You have to pay to use other people's ratings. This is how it should be.) Regards, Bryce -----BEGIN PGP SIGNATURE----- Version: 2.6.2i Comment: Auto-signed under Unix with 'BAP' Easy-PGP v1.1b2 iQB1AwUBMd7iRkjbHy8sKZitAQGTEQL+IchRcLv9r7/WpDQb8tmJ0QJD7tN8KUNG AEX/UtzApwffH2kS90ThHVnsVt/8WKgI+WfsZ0Z0PtYoE5uLwBUJDzXydbZ8zHEx B5Ti4pfF0wuXwWD6kA/ISYyhZHRewcol =Dwsd -----END PGP SIGNATURE-----

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: Shrink-Wrap Lic. uphelo by courts. From Edupage, 4 July 1996
by Hallam-Baker 17 Dec '03

17 Dec '03

Deranged Mutant wrote: > >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) Perhaps Prof Froomkin could provide an opinion. It sounds to me however as if the defendants were simply ripping off the copyright of the plaintif and attempting to get arround it by claiming to have "bought" rights to resell along with the software by wrangling over the shrink wrap agreement. Or were the defendants reselling the software unopened to foreign customers via the Internet? Seems to me that that might well be open to further challenge. If a "contract" clause is expressed in a manner that means that it would not be encountered by a party which it attempts to bind there might be argument as to whether acceptance was possible. I suspect that the claims the plaintifs were making lay very definitely within the range of what people in the trade would usually expect to be the licensing terms for software purchased off the shelf. Just as there is an expectation when purchasing a book that one has purchased an instance and not the rights to the copyright. Consider the analogy with purchasing a book that is wrapped in shrink wrap film and that consequently one was unable to read the "all rights reserved" legend. The question that I am interested in is whether someone could claim that a shrink wrap license can bind a user to terms that are less widely expected in the industry. For example clauses which prohibit reverse engineering, transfer to other users etc. Might be interesting to know the precise rulling made and its terms. Phill

3 2

Re: Net and Terrorism
by vinnie moscaritolo 17 Dec '03

17 Dec '03

>On Fri, 5 Jul 1996, vinnie moscaritolo wrote: > As for a solution to governement problems, I have always and still belive > in the ballot box first. And the only way to win votes is to appeal to the > morons out there who do vote.. Maybe there is hope in the next generation > of internet literate kids.. or maybe I am just a dreamer. > >snow(a)crash.suba.com wrote > You are a dreamer. Netscape, TV for the internet. BS. I am not being that idealistic. look all I am saying is that maybe the net just offers kids the ability to see a variety of views instead of the mainstream liberal (or whatever it will be next week) controlled media. For now anyways any entity that has something to say and can write his way out of a paper bag has pretty much the same ability to influence on the net (at least newsgroups) as say Ted Copulate does. Maybe freedom we have here wont last for long, maybe the Pointcast of the future will just create another MTV generation...but at least for now we have a voice. Vinnie Moscaritolo ------------------ "friends come and friends go..but enemies accumulate." http://www.vmeng.com/vinnie/ Fingerprint: 4FA3298150E404F2782501876EA2146A

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