- cypherpunks-legacy - lists.cpunks.org

Re:What remains to be done: keeping info free
by Sherry Mayo 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Hal Finney writes.. > From: Black Unicorn <unicorn(a)schloss.li> > > A. Methods to run secure websites on insecure servers. > > [...] > > A software solution which permits local decryption makes traffic analysis > > less useful, presents the opportunity to use front end and disposable www > > pages on domestic ISPs while imposing no liability on the ISP itself, and > > opens several more effective traffic analysis deterants. > I don't quite understand what is being proposed here. If the > information on the web site is encrypted, who is supposed to be able to > decrypt it? Just one person, or some select group of people? My If the objective is to keep information available then check out Ross Andersons "eternity service" proposal (http://www.cl.cam.ac.uk:80/users/rja14/#Lib) which outlines a "highly distributed, resilient and anonymous file store. Once a document is published on it, the courts will simply not be able to find and delete all the copies" Sherry -----BEGIN PGP SIGNATURE----- Version: 2.6 iQCVAgUBMdyPeOFu4n6w1qeBAQF4igP/bhD22woqB8W2kglF6r6Z4rdUVDzGrXk4 N9Iav/KnUtAlmWb/yItHg9+uwAPRtomkTeOZye5UcmJzYI8WERyBYi5Y4OghA48a vo9C/Qo4znljc2J3+J1nWuuDp1khSVB/b+B1/r2zqN/Uv7YvwkF9cext/bf8XV/G uxPJz0DvSLE= =jiix -----END PGP SIGNATURE-----

1 0

Re: ecash thoughts
by jim bell 17 Dec '03

17 Dec '03

At 02:18 PM 7/4/96 -0700, Steve Reid wrote: >The person wanders around the web, acting as though he's perfectly willing >to pay, and participating in the fair coin tosses. Except, he really has >no intention of paying. He will gain free access to 9 out of 10 sites, and >on the ones that he loses the 1/10 gamble, he just backs out of the deal >and doesn't pay anything. The end result is that instead of seeing all of >the web at 0.1 cents per page, he sees 90% of the web completely for >free. If everyone does this, the sites will go broke. > >It's the equivalent of welshing on a bet. > >The obvious solution would be to require that the person pay the 1 cent, >then if he wins the 9/10 bet, he gets the 1 cent back. But that will just >move the problem from the user to the server- the site can welsh on the >bet and refuse to pay back the one cent. They will get ten times the >payment that they are supposed to get. If you're a store and I want to buy something that costs, say, $4.50, and we want to eliminate the need for change (for whatever reason) then I would pay $4.00 up front and we'll flip the electronic coin for the rest. At that point, you already have $4 so I'd have no reason to welsh on the remaining 50 cents. It obviously doesn't work this way if the minimum coin is larger than the current purchase... Jim Bell jimbell(a)pacifier.com

1 0

Re: Lack of PGP signatures
by Clay Olbon II 17 Dec '03

17 Dec '03

>It is not possible to clear-sign binaries with PGP. The point of clear- >signing >is to have signed text that is readable to people who don't have the >software >necessary to process the text. It would make sense to clearsign a file that >is base64'ed or uuencoded, which wouldn't alter the contents of the file. I >can't see how such an option would be harmful, except that it might lose >some >characters that are important to the context of the message. > Mark, Of course you can use pgp to sign binaries. How else did the pgp binary itself get signed? You can either sign it in a separate file, or in the same file. PGP sorts it out for you. What do you use it for? Same reasons you sign text. "I signed this file" means that you vouch for it in some undefined way (maybe I wrote and compiled it, or somesuch). Clay *************************************************************************** Clay Olbon II * Clay.Olbon(a)dynetics.com Systems Engineer * PGP262 public key on web page Dynetics, Inc. * http://www.msen.com/~olbon/olbon.html ***************************************************************** TANSTAAFL

2 1

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