December 2003 - cypherpunks-legacy

Sun's Wallet
by anonymous-remailer＠shell.portal.com 17 Dec '03

17 Dec '03

Sydney, Australia, April 30 -- SunSoft will shortly release a workable cash-on-the-Internet program called Wallet, according to James Gosling, Sun vice president, lead engineer and key architect behind the Java cross-platform language. Gosling, on his first visit to Australia, was discussing the future of electronic commerce at a briefing session in Sydney for Australian information technology journalists. ----- San Jose, Calif., April 30 -- VeriSign, a provider of digital authentication services for Internet access and electronic commerce, has announced the opening of its online Digital ID Center. VeriSign claims the center is capable of issuing millions of personal Digital IDs for World Wide Web and Internet e-mail users. Digital IDs use cryptographic techniques to provide a means of authenticating the identity of each party in an electronic transaction. A Digital ID is issued by VeriSign, after background checks are made on an individual or "entity." Once issued, the Digital ID can be used within any enabled application such as Netscape Navigator Internet client software and Netscape SuiteSpot.

2 1

Best Digital Signature Lib from a WEB server
by Joseph M. Reagle Jr. 17 Dec '03

17 Dec '03

Can anyone recommend a signature implementation for cgi/forms? For instance, someone registers on a WEB site and gets a signed receipt back. (No cookies or such, because the receipt will be show to 3rd party members.) I'm thinking in terms of self-labeling and PICS like work. The PICS Label Syntax and Communication Protocols mentions that Jim Bidzos has agree to allow RSAREF to be available to PICS developers at no cost. Has anyone tried this, or actually implemented a scheme like this? _______________________ Regards, I, man, am regal; a German am I Joseph Reagle http://farnsworth.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

Announce: Windows PGP QuickStart
by Joel McNamara 17 Dec '03

17 Dec '03

Due to a fair amount of demand from Private Idaho users who had novice friends that wanted to use PGP, but were frustrated at the installation and configuration process of the DOS version, I wrote a Windows utility called PGP QuickStart. This is an extremely simple app that handholds the user from downloading PGP with their Web browser to creating their key rings. It automatically unzips the files, creates the appropriate directory, and modifies the AUTOEXEC.BAT file. The user just follows easy to understand dialog boxes and clicks buttons. This is not a full-featured front-end. Its purpose is only to simplify the PGP installation process so a user can later use Private Idaho or any of the other Windows shells that are available. Obviously, most people on the list aren't going to have much personal use for this app. However, it is perfect for recommending to PC users who want to get started with crypto, but may be a little bit intimidated. The beta version is located at: http://www.eskimo.com/~joelm/pi.html Comments to: joelm(a)eskimo.com As with Private Idaho, this utility is free...

1 0

Re: CDT Policy Post 2.15 - Legislation Challenges Clinton's Grip on US Crypto Policy
by jim bell 17 Dec '03

17 Dec '03

> The Center for Democracy and Technology Volume 2, Number 15 >Among other things, the "Pro-CODE" would: >* Allow the export of "generally available" or "public domain" > encryption software such as PGP and popular World Wide Web browsers > without requiring NSA authority. > >* Allow the export of encryption hardware and software not available in > the "mass market" or "public domain" under an export scheme that would > allow up to roughly DES-strength (i.e., 56 bit key-length) security. > if a product of similar strength is commercially available from a > foreign supplier What, exactly, is the point of such a provision that would limit key length? Since the classifications of encryption export software seem to allow any keylength, why should there be an exception for others? I think they should give specific examples of hardware or software whose export would not be allowed, and more particularly an explanation why an exception is needed in those cases. We really need to know what they're thinking about, here. It isn't obvious why, and generally I've found that whenever laws carve out exceptions, there are substantial reasons for those exceptions, although not necessarily "good" reasons. Notice, for example, that there appears to be a distinction between hardware and software. (although, in the bill, it does list both hardware and software.) As we all should understand, the distinction ought to be meaningless, but one of our goals should be to allow the unrestricted export of good-encryption telephones which have their encryption done in hardware. That doesn't appear to be the case, and I think this is a telling limitation. The law will practically guarantee that no factories to build good crypto phones get sited in the US. However, a look at the actual bill shows nothing which specifically limits things to 56-bit keys, although it seems to make an unusual distinction, allowing exports "in any foregin country to which those exports of computers software and computer hardware of similar capability are permitted for use by financial institutions..." The problem, as I see it, is that this is practically an open invitation to foreign countries to pass laws which are specifically intended to restrict encryption. We should not be encouraging them to do this. Some explanation is definitely in order! BTW, that brings us to another issue: The bill should specifically prohibit restrictions on the IMPORTATION of any kind of encryption systems, either hardware and software. >* Prohibit the government from imposing mandatory key-escrow encryption > schemes domestically, or from restricting the sale of commercial > encryption products within the United States Redundant. The 1st amendment should already do this. I have no objection to them re-stating Constitutional protections, but it should label them as such. >* Prohibit the Department of Commerce from imposing government designed > standards for encryption technologies (such as Clipper and Clipper > II). Ditto. But more importantly, I think it ought to be prohibited from even _encouraging_ the use of such systems, which as we all know the government can do by abusing its power. It should be prohibited from spending any money to develop those standards, as well as prohibiting government from encouraging the use of those standards, etc. All in all, a substantial improvement over the Leahy bill, but it could still use a little work. Jim Bell jimbell(a)pacifier.com Jim Bell jimbell(a)pacifier.com

1 0

VTW: Senate attacks Clinton encryption export policy
by Shabbir J. Safdar 17 Dec '03

17 Dec '03

======================================================================== __ _________ __ \ \ / /_ _\ \ / / Voters Telecommunications Watch \ \ / / | | \ \ /\ / / (vtw(a)vtw.org) \ V / | | \ V V / May 2, 1996 \_/ |_| \_/\_/ Redistribute only until 5/28/96 SENATORS FIRE BROADSIDE SALVO AT CLINTON ADMINISTRATION'S HEINOUS AND ANTIQUATED ENCRYPTION EXPORT POLICIES Please widely redistribute this document with this banner intact until May 28, 1996 ________________________________________________________________________ CONTENTS The Latest News Chronology of the 1996 Crypto Bills For More Information ________________________________________________________________________ THE LATEST NEWS Today, a core contingent of the US Senate proposed legislation that would free public domain software such as Phil Zimmerman's PGP (Pretty Good Privacy), allow for the export of products that have competitive encryption abroad, and limit the government's ability to propose another Clipper-style standard. The latest proposal, sponsored by Sen. Burns (R-MT) is the third in a series of bills this year that blatantly attack the Clinton Administration's policies of restricting the export of encryption that is already found outside the United States. Text of the legislation is now available on http://www.crypto.com/ and http://www.vtw.org/ as soon as we get it. In another bold move, Senators Conrad Burns (R-MT) and Patrick Leahy (D-VT) have scheduled online chats to discuss this legislation with the people who understand the issue the best: the net community. As a part of the Whistlestop96 campaign by VTW and CDT (Center for Democracy and Technology) to bring members of Congress in touch with the net community during the 1996 campaigns, Senators Burns and Leahy will be attending live online chat sessions on HotWired and America Online. The schedule as currently available is: Sen. Burns America Online, News Room auditorium: Monday May 6, 9pm EST Hotwired: Monday May 13, 9pm EST Sen. Leahy America Online: date not yet available Hotwired: date not yet available In addition, volunteers have begun maintaining a resource page at http://www.crypto.com/ with a corresponding mailing list for encryption policy news. You can subscribe to it from the WWW page http://www.crypto.com/ or by sending mail to majordomo(a)panix.com. ________________________________________________________________________ CHRONOLOGY OF THE 1996 ENCRYPTION BILLS May 2, '96 Bi-partisan group of Senators introduce PRO-CODE Act, which would free public-domain encryption software (such as PGP) for export, free much commercial encryption for export, and reduce the government's ability to push Clipper proposals down the throats of an unwilling public. Original sponsors include: Senators Burns (R-MT), Dole (R-KS), Faircloth (R-NC), Leahy (D-VT), Murray (D-WA), Nickles (R-OK), Pressler (R-SD), and Wyden (D-OR). Mar 5, '96 Sen. Leahy (D-VT) and Rep. Goodlatte (R-VA) introduce bills to liberalize cryptography exports. Cosponsoring this legislation on the Senate side at Sen. Burns (R-MT) and Sen. Murray (D-WA). On the House side are the following cosponsors: DeLay, Campbell, Eshoo, Moorhead, Doolittle, Barr, Ewing, Mica, Everett, Bono, Lofgren, and McKeon. ________________________________________________________________________ FOR MORE INFORMATION ABOUT ENCRYPTION Encryption Policy Resource Page: http://www.crypto.com/ Voters Telecommunications Watch: http://www.vtw.org/ Internet Privacy Coalition: http://www.privacy.org/ ========================================================================

1 0

Re: proposed anti-pseudospoofing law in Georgia
by Rich Burroughs 17 Dec '03

17 Dec '03

At 12:52 PM 5/2/96 -0700, "Vladimir Z. Nuri" <vznuri(a)netcom.com> wrote: [snip] >this proposed law in Georgia >would make it illegal to have a login name other than >your legal name, as I understand it. [snip] More than proposed. It was signed by Gov. Zell Miller on April 18, and is now the law in GA. see http://www.clark.net/pub/rothman/ga.htm and http://www.gahouse.com/docs/whatsnew/parsons.htm Rich ______________________________________________________________________ Rich Burroughs richieb(a)teleport.com http://www.teleport.com/~richieb See my Blue Ribbon Page at http://www.teleport.com/~richieb/blueribbon New EF zine "cause for alarm" - http://www.teleport.com/~richieb/cause

1 0

Re: [Fwd: Cylink can export 128-bit DH?]
by frantz＠netcom.com 17 Dec '03

17 Dec '03

At 10:55 AM 5/2/96 -0700, Ian Goldberg wrote: >Bill Frantz <frantz(a)netcom.com> wrote: >>As far as I know, DES is DES, domestic or export. If your DES >>interoperates with domestic DES (or popular implementations available on >>non-US servers), then you have DES. > >Not quite. CDMF key shortening was designed by IBM to shrink a 56-bit DES >key to 40 bits, suitable for export. See AC2, page 366. I heard a rumour >that CDMF is in SET, but I'm not sure how much that makes sense. I can find no evidence in Draft 2/23/96 of SET for 40bit DES keys. (BTW, I would not call CDMF DES, but this may be merely quibbling.) On page 31, it says, "The DES key format follows FIPS 46: it contains 56 bits of keying material and eight optional check bits." Since SET is very careful to not deal with anything but the financial aspects of online commerce, they can probably get a license for export under the current rules. (SET only includes a SHA hash of the "contract", calculated by both the cardholder and the merchant in its encrypted content. Both versions must match for the transaction to be authorized.) Regards - Bill ------------------------------------------------------------------------ Bill Frantz | The CDA means | Periwinkle -- Computer Consulting (408)356-8506 | lost jobs and | 16345 Englewood Ave. frantz(a)netcom.com | dead teenagers | Los Gatos, CA 95032, USA

1 0

Re: [Linux] Unix plugins for Netscape (Was: Calling other code in Java applications and applets)
by Alan Olsen 17 Dec '03

17 Dec '03

At 10:45 AM 5/2/96 -0700, Ian Goldberg wrote: >I'd venture a guess that most people who have a Linux box sufficiently cool >to run netscape at all, have the ability to run ELF. In fact, there are >probably a lot of people (like everyone who bought Slackware 3.0 or a recent >RedHat) for which netscape is the _only_ a.out binary on their system. In order to run any of the recient kernels you HAVE to be running ELF. (Or have your copy of GCC upgraded to 2.7.0 or higher.) The docs make no mention of it, but it barfs on the make if you do not have it. (There are three flags that are not supported under the old versions of GCC.) > - Ian "Add me to the 'Make an ELF Linux binary!!!' list..." Are they keeping a list? As for Linux, last I heard it was still on the semi-supported list. (The dropping of BSD on the fasttrack server pisses me off as well, but that is another matter...) I would like to get a version of the Linux binary that supports 128 bit SSL. (As well as the ELF binaries.) --- 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

3 2

Sen. Patrick Leahy's PGP key now avail.
by rodger＠interramp.com 17 Dec '03

17 Dec '03

Wanna write the good Senator on the occasion of his newest bill? His pub key's out there. (URL is http://bs.mit.edu:8001/pks-commands.html#submit/ ) Will Rodger

2 1

Re: no-cost DH?
by Ted Garrett 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit To: perry(a)piermont.com, cypherpunks(a)toad.com Date: Wed May 01 02:16:17 1996 Sorry, Perry. This time you are wrong. Cylink is giving away their Passport Gold SDK (Security Development Kit). Period. I've just recieved the documentation on the SDK itself, and am expecting shipment of the SDK itself about the middle of May. I was skeptical myself when I read the first post regarding this SDK being released to the public for free, so I called up Cylink. They promptly connected me with Peter Bolton <mailto:pbolton@cylink.com>, who has been very helpful in getting this SDK into my hot little hands. Included is, and I quote: "We hold the world-renowned Diffie-Hellman patent used in public key encryption. While developing our industry-leading encryption acceleration engines, we also developed a full suite of services for Diffie-Hellman-based key exchange, government-sanctioned Data Encryption Standard (DES) encryption algorithms, Digital Signature Standard (DSS) document signatures, and the complementary functions you need to incorporate data security into your product. And it's available to you for free: a no-cost toolkit and royalty free license." This is the second paragraph of the fax I received from Cylink after my following up on the free SDK offer. From the rest of the fax, it seems that provisions are included in the SDK for DH, DES, DSS, and SHA. X.509 appears to be in the works. The SDK is purported to interoperate with the Cylink products based on the Secure Enterprise Architecture Stack. I'm pretty dad-blamed excited about this one, boys. I was trying to wait till I was sure to say anything on the list. I'm sure. -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQEVAwUBMYcBs81+l8EKBK5FAQEfhQf+LJAytjAhEOoD0ai6K0liuyDQkWuMmAxq z5H5KzNXBQn0F+r2ukVEPsX0Ocgfbqp5fo5lRp+hDegM9KRz+MulSmVXEQSdbUPi 6cfq7c0/HhHNkuaJK8xeTOvDlquYLmnDPJJ6KxAcTQvh3ssRJMo9YYWXIF/YlX/J fVZunnwMY9xmIggOfoXIV6ZZvkAUsumA6EgGbKggm2HMh5X4ukWDb3qW2RkKDTlr 8pM8SPRs4IEJFzoXA1FAXafePm1tA2PXhLeOKmwjjZ4R58L6Y4l+eRRsNXIkUGrD 8iY7QUbozhTyTyzRMGzv21g2cOHmfmLblKfJsNQYWFX5yKctla7qyA== =TklH -----END PGP SIGNATURE-----

3 2