December 2003 - cypherpunks-legacy

Re: Fax encryption software
by shamrock＠netcom.com 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- In article <Pine.3.89.9509262116.A7081-0100000@netcom7>, grafolog(a)netcom.com (Jonathan Blake) wrote: > I saw this article in alt.privacy. > > Anybody think the described encryption actually is worth > looking at. [...] >We are talking about a 72 bit engine that is more than >sufficiently strong for time sensitive general business purposes. [...] >>>It is fully licensed, without restriction for export, by the >U.S. >>>Department of Commerce. NO PGP WORRIES. These two statements are mutually exclusive. Snakeoil. - -- - -- Lucky Green <mailto:shamrock@netcom.com> PGP encrypted mail preferred. - --- [This message has been signed by an auto-signing service. A valid signature means only that it has been received at the address corresponding to the signature and forwarded.] -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Gratis auto-signing service iQBFAwUBMGmmZyoZzwIn1bdtAQFrsQF/edmKXMashWa+yP9E4N/M0c/Rgwa4I6rm 0g0K8TzPc8hl4dP01Euiqcm1LAgHqbiL =rRO8 -----END PGP SIGNATURE-----

1 0

Sorry or something
by Marcel van der Peijl 17 Dec '03

17 Dec '03

In case it was not clear: my earlier post really was not a lawsuit threat. It seems it was (mis)interpreted this way by some people. Also, the original author did not post the article but someone he sent it to. I'm sure the author did not intend to post the text as is but first give us a fair chance of defending ourselves. #include <stddisclaimer.h> "My opinions and reactions do NOT represent the official DigiCash standpoint." // Marcel van der Peijl, DigiCash bv, http://www.digicash.com/~bigmac/ // "If you had to tell the Whole Truth, you'd never shut up."

1 0

Re: WSJ on Netscape Hole 3
by cman＠communities.com 17 Dec '03

17 Dec '03

Somebody wrote: >> With Netscape 1.1 the state of the stack is much more dynamic, in >> particular the user can be viewing documents at an arbitary depth in >> the "web tree", each recursion will increase the stack pointer (or >> decrease with some architectures) There is no way of knowing for >> certain where you code will end up and thus no way to reliably alter >> the return address on the stack to execute your arbitary code. > I just tested this under Solaris 2.4 and it "turns out not to be the case." I approached my "bad" URL from a variety of other places, passing through various other pages, and the stack structure was still the same when I clicked on the bad guy. The big problem I'm having on this platform is the windowing register system on the SPARC architecture, which interacts in weird ways with the debugger. The lack of determinacy about where the stack is loaded in global memory _does_ seem to be a much bigger problem on the Mac, which is still not anything approaching a multi-tasking OS. Under Unix, proceses get their own address space to play in, which is always the same; on Macs, with their weird relocatable heaps, you never know where stuff is going to get loaded. I wonder how this is handled in Windows 95.... As for objections about how worthwhile this is, it's pretty clear that a patch will be available for this problem before we can finish and publicize an exploit. This is not, however, the last piece of network software that will contain problems of this sort, and it is a good idea to build up expertise in this area. I'd also suggest going after some of the other browsers... I know, for instance, that AOL's browser dies horribly on these same sort of URLs. Good luck, all. Doug

3 2

Re: [NOISE] Re: Easter Eggs
by Alan Olsen 17 Dec '03

17 Dec '03

At 09:35 AM 9/27/95 -0400, you wrote: > Date: Tue, 26 Sep 1995 12:59:54 -0700 > From: Alan Olsen <alano(a)teleport.com> > > You also need X windows to find the Mozilla animated icon hack on > Jammie Zawinski's page. > ^^^^^^ > >Just for the record, that's Jamie. Hey! I never said I could type at 1am! Yes, I know. #%#$#%ing spelling flames. Grumble. Grumble. (BTW, the compass egg will show up in any page with /jwz/ in the url. The "anim" tag on his page is bogus.) > obNetscapeHack: There is a feature called a "cookie file" in > Netscape that is ripe for exploitation as a security leak. If you > are using a Netscape server (and you may not even need that), you > can feed all sorts of information into it without the user's > knowlege. I have heard of one page that overloads the cookie file > until the machine runs out of drive space. I am sure that there > are other exploitable holes there... Any takers? > >Yikes! That sounds really bad. Do you have any more information on >this? For example, can the server write to anything other than >$HOME/.netscape-cookies? If I write protect that file, but it's still >owned by me, will Netscape still modify it? The url for the spec is: http://home.netscape.com/newsref/std/cookie_spec.html. The cookie overload probibly only worked under 1.1 and before. The spec claims to have limits on the number of cookies you can have. But between this and the server API, I am sure that a hole or two has to exist. This is an area not explored by many. (For good reason. It is usually poorly documented...) OBParanoia: Want something to really make you worried. Imagine this for a web page... A local law enforcement agency decides that it wants to nab a few of those "computer preverts". They create a web site that has a cgi script that looks for providers from a list. It then has a link that shows up only for people at one of those sites to "get hot porn pics". They then collect enough machine names and other info, then use the collected information to obtain a warrent to seize the ISP's logs to match users with machines. (Most browsers to not report e-mail address.) In the current hysteria I do not see this scenerio too far off. Makes you wonder what constitutes entrapment anymore? | Minister of Forced Caffinization in the DNRC | alano(a)teleport.com | |"The moral PGP Diffie taught Zimmerman unites all| Disclaimer: | | mankind free in one-key-steganography-privacy!" | Ignore the man | | -- PGP 2.6.2 key available on request -- | behind the keyboard.| | http://www.teleport.com/~alano | <fnord> |

1 0

Re: JCrypt (was: getting netscape to support the remailers)
by cman＠communities.com 17 Dec '03

17 Dec '03

> That was what I was thinking as well. I am confused by >Netscape's java support though.. I haven't seen very many details. Is >netscape going to only support applets or can you add stuff to the >runtime as well? In order to use jcrypt one needs access to add stuff >to the runtime I beleive. Currently jcrypt is implemented as a glue layer on top of RSAREF. This means it has to be accessed through native methods. Also, in general, one doesn't want to be downloading trusted security code every time one uses it, even if it has strong authentication (and this hasn't been built into Java yet.) So there are two questions: o Will netscape allow local trusted Java code to be invoked by downloaded applets? o Will netscape support native methods in such code? I would _greatly_ prefer to implement the jcrypt code in 100% java, but there are legal barriers to doing this where RSA is patented. JCrypt, however, is designed to allow the native methods to be replaced with Java should someone desire to do that. Also, there are other architectural concerns involving the direct or indirect invocation of local trusted encryption code by untrusted, downloaded software, which will be addressed somewhat in the next release of JCrypt. > >> >> > I started thinking about what it would take to get Netscape >> > to support sending mail through the remailers, after having >> > read the S/MIME specs which Netscape 2.0 is apparently going to >> > support. Perhaps with enough browbeating Netscape 3.0 will support >> > the remailers. >> >> Netscape doesn't need to support remailers explicitly since Netscape >>will be >> supporting Java. I think a remailer client is within Java's >>capabilities... >> Anyone disagree? >> >> andrew >> > > >-- >sameer Voice: 510-601-9777 >Community ConneXion FAX: 510-601-9734 >An Internet Privacy Provider Dialin: 510-658-6376 >http://www.c2.org (or login as "guest") sameer(a)c2.org

1 0

Schnorr patent
by peace＠BIX.com 17 Dec '03

17 Dec '03

Now that PKP is dead, does anyone know how to contact C. Schnorr about his patent? Peace ..Tom

1 0

[Q] Checkfree Wallet
by Harry S. Hawk 17 Dec '03

17 Dec '03

I'm writing about security and the Internet and in particular about the Netscape bugs. I'm interested if anyone know technical details about the Checkfree Wallet system. Have they made code publically available, etc. BTW. THe Wallet system is supposed to be using ~768 bit public key system and it is reported to exportable. All decyption is done at Checkfree Corp. Users encode only the credit info, the WWW server signs the file and forwards it to Checkfree who will decrypt and process the credit card data. I've been told no credit card info is kept on any servers except for machines inside of Checkfree's network and that keep credit card numbers on file there. Please let me know if you know anything. Unless other indicate any information will be assume for publication. Background information is welcome as well. /hawk habs(a)panix.com writing for NetGuide Mag. --

1 0

Re: alpha.c2.org nymserver
by Bill Stewart 17 Dec '03

17 Dec '03

>> Also, I am having a LOT of grief trying to get the alpha.c2.org remailer to >> work for me... (yes, I have the help files) >> Could someone walk me through it? > >You mean the nym server at alpha.c2.org? It seems to have about a 1 week >delay on it... > >Be sure the reply block that you give it is your own, and that you tell >alpha which remailer the reply block goes to. If you get a copy of the latest Private Idaho beta, it's got a convenient set of user interfaces for using the nymservers, as well as for PGP, remailers, etc. (Runs on Windows, so some of you may not find it all _that_ convenient :-) PI works with either vanilla PGP or ViaCrypt. The first step is to get the PGP key for alias(a)alpha.c2.org installed in your key ring, and update PI's key tables (a menu item). Then choose the "Create a nym" menu item and follow all the dialog boxes. I found it a little confusing at first, since I didn't realize the nymserver just uses secret-key encryption and not public-key, so you don't need to create a public-key-pair to do it - the only PGP involved is encrypting the message sent to the nymserver. So you can now send mail to the _highly_ anonymous wcs(a)alpha.c2.org :-) #--- # Bill Stewart, Freelance Information Architect, stewarts(a)ix.netcom.com # Phone +1-510-247-0664 Pager/Voicemail 1-408-787-1281 #---

1 0

X.509, S/MIME, and evolution of PGP
by Bill Stewart 17 Dec '03

17 Dec '03

I'd always heard X.509 public key certificates were a hierarchical, evil, anti-WebOfTrust ISOism. But Netscape is now doing them, and talking S/MIME, so I sat down to read the specs, and they're really not all that bad. (Technically, I've only read PKCS#6 and RFC 1422, and not the real ISOisms...) Yeah, they've got lots of clunky ASN.1 Ambiguous Encoding Rules and X.500 Silly Name Format, but those can be lived with, and the X.500 may be possible to simply ignore in most cases. Steve Kent, author of RFC1422, envisions that a hierarchical world with government certification authorities would be the most convenient implementation, and with the X.500 directory service serving certificates, but that's primarily editorial and not required by the technology. Since a zillion and a half people are about to acquire Netscape 2.0, which supports non-Verisign-signed X.509 certificates and DES, we can definitely extend the Web of Trust concept to that world; can we also extend secure user-to-user messaging? It's time for PGP to mutate and take over the world... An X.509 certificate has the following components 1. version 2. serial number 3. signature (algorithm ID and parameters) 4. issuer name 5. validity period 6. subject name 7. subject public key (and associated algorithm ID) expressed as ASN.1 and signed with the issuer's public key. The issuer and subject names are expressed as X.500 addresses (big deal). The CA's public key is expected to be obtained out of band, or as a chain of signatures from some other CA that you got a signature for out of band; there's no policy implementation that says who can be one. The primary requirements on CAs are to never issue the same serial number twice, maintain uniqueness on signatures for subjects, and maintain a Certificate Revocation List which is accessible somehow. Unfortunately, the data format doesn't support multiple signatures, but the documentation _does_ explicitly indicate that you can _have_ multiple certifications; you just have to drag around a bunch of separate certificates, leading to some obvious implementation opportunities. CRLs are less well-specified, though the PEM RFCs suggest a PEM format; the main requirement is that they be keyed off the serial number, which is why that has to be unique. RFC 1422 proposes a rooted hierarchy of CAs - a root called the Internet Policy Registration Authority, which would certify a bunch of Policy Certification Authorities, which would each have different requirements on what their CAs require from people who want to be certified, ranging from anonymous personas to heavily identified Official People, and would do a certain amount of coordination to preserve uniqueness. Becoming a PCA would require paying money to the IPRA. However, there's no requirement that a _specific_ organization become the _one_ _official_ IPRA; if somebody were to volunteer and announce themselves as the IPRA, there's no particular conflict-resolution mechanism. [ maybe it's time for a Cypherpunks Press Release? No - I didn't say it. Not me! ] But rootedness only really matters to software that cares... and as long as your software accommodates N levels of certification, you can have a Web of Trust getting back to a key you signed yourself, and either get an official personna certificate or plug your public key into your software as the IPRA (and sign the real IPRA's certificate yourself :-) Problems: 1) ITAR - shouldn't be a big deal, because all of this is building a signature/authentication mechanism, it's not doing any encryption. The encryption, if any, is a user agent issue, and that's Netscape's problem; the Web of Trust tool is an add-on. 2) RSA patent - can this be built with RSAREF? Or RSAREF with permission for a couple extra activities? Or built out of RIPEM or RIPEM-SIG? The latter has the benefit of already being exportable. 3) Netscape compliance - the Netscape folks have been real friendly, and I hope they'll leave their format for getting certificates open. 4) Other software and CA policy-makers - getting out first is worth something; then you're the standard that they have to follow instead of the other way around. For some issues, like X.500 name vs. DNS name, there are probably people in the IETF or community in general working on it, or alternatively you can do an ugly hack abusing the organization and address fields. 5) S/MIME - real S/MIME compliance requires support for RC2 as well as publicly available algorithms, though this is really just an X.509 handler. 6) It's a lot of work - well, yeah, it is. And I'm lazy. Is there enough related code in SSLeay to steal to help implement it? #--- # Bill Stewart, Freelance Information Architect, stewarts(a)ix.netcom.com # Phone +1-510-247-0664 Pager/Voicemail 1-408-787-1281 #---

2 1

Re: Time Keys, Some Secure Ideas (by Alias: Jay Hyden)
by Bill Stewart 17 Dec '03

17 Dec '03

Jay - you wrote: > >> Time Keys, Some Secure Ideas << > The weakest attack on a time key based system is to spoof the >computer that keeps track of time into releasing encryption >keys i.e. change the clock. No, the weakest link is that you have to trust the person _running_ the time key system. Spoofing the clock only matters to a system you trust. Even a system running on a satellite isn't trustable unless you're running it yourself; your good friend and business partner who launched it may have put in a backdoor because the KGB threatened to kill his grandmother if he didn't. #--- # Bill Stewart, Freelance Information Architect, stewarts(a)ix.netcom.com # Phone +1-510-247-0664 Pager/Voicemail 1-408-787-1281 #---

1 0