December 2003 - cypherpunks-legacy

Re: Internet Security Review
by Doug Hughes 17 Dec '03

17 Dec '03

Several people have asked me about Internet Security Review. As far as I can tell I must have registered for a free copy sometime in the recent past. I think it was on firewalls that I saw it first mentioned. At any rate, there is a little fold out thingy in the back with some questions on it to register for a free copy or pass it on to a friend. This appears to be the introductory issue. Here's what it looks like: _ YES, I want to receive Internet Security Review _____________________________________ (signature is essential) Please answer all of the following questions, sign and mail form to: Internet Security Review, Postoffice Box 2236, Naples, Florida 33939, USA - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 01 Name 02 Company/Agency 03 Dept./mail route 04 Mail address 05 City 06 State 07 Zip code 08 Country 09 Is the address above your business address ? _ Yes _ No 10 What is your current position ? _ Corporate executive _ Management _ Supervision _ Employee _ Student _ Other ________________________________________________ 11 Is information security a part of your day to day responsibility ? _ Yes _ No 12 Does your job include the administration and/or maintenance of an Internet site ? _ Yes _ No 13 Does your job include the supervision of (onre or more ) Internet site(s) ? _ Yes _ No 14 Does your position include advisory on soft- and hardware/peripheral purchases essential for Internet site security ? _ Advisory _ Decisionmaker 15 What is your email address ? 16 Are you using PGP encryption with message interchange, or a different encryption program ? _ PGP _ Other, please complete ____________________________________ 17 Are you in favor of key escrow? _ Yes _ No 18 Is (are) the site(s) within your responsibility using a firewall ? _ Yes _ No 19 Is (are) the site(s) within your responsibility using special access devices (smart cards, tokens, etc.) _ Yes _ No 20 From time to time, we will ask your opinion on various aspects of Internet security. Are you available to cooperate ? _ Yes _ No 21 What particular topics would you like to see covered in Internet Security Review ? ___________________________________________________________________ ___________________________________________________________________ ___________________________________________________________________

1 0

Re: Certificate proposal
by tomw＠orac.engr.sgi.com 17 Dec '03

17 Dec '03

In article <DGxxGM.IHu(a)sgi.sgi.com>, Jiri Baum <jirib(a)sweeney.cs.monash.edu.au> writes: > TW writes: >> I agree. Sending your cc# to a key or an IP address is not what you >> want to do. As a consumer, I want to make sure that I send my cc# to >> the merchant I am buying from. > But how do you know that you want to send to Egghead Software in the > first place? EHS could be a MIMT, maybe you really want to talk to > Eggfoot Software, but every e-mail Eggfoot sends out is intercepted > and changed to read "Egghead" (and vice versa)... > By the time you verify that Egghead is who you want, you could have just > as easily verified that the key is who you want. Thus skipping one step > and avoiding all the attacks applicable to that step. That's true. You really want to make sure that the merchant you are giving your money to is the one who has the goods you are interested in. Perhaps the only way to solve this problem is with some sort of trusted escrow agency. The agency would be well known and its reputation could be verified fairly easily. Of course there's still the existential problem of how do you know your connection to the rest of the world isn't controlled by someone else, but there's really no solution to that. -- Sure we spend a lot of money, but that doesn't mean | Tom Weinstein we *do* anything. -- Washington DC motto | tomw(a)engr.sgi.com

1 0

Netscape Logic Bomb detailed by IETF
by anonymous-remailer＠shell.portal.com 17 Dec '03

17 Dec '03

With all of the Noise on this list, and all of the opinion that has been expressed, opinion which would seek to slander, misrepresent or opinion which would like to represent itself as fact, it has increasingly become difficult to separate the wheat from the chaff. Clearly, someone has a vested interest which they are expending a great deal of effort to protect. My email to Netscape detailing their logic bomb has gone unanswered, and unacknowledged for ten days now. Ten days is a long time for no "official" comment. Just as ten days is a long time not to answer email. Rather than attacking individual posters, rather than questioning credentials, rather than scaring journalists, rather than intimidating and wilfully spreading misinformation to create confusion, rather than doing any of this, I will simply quote the official minutes of the Internet Engineering Task Force (IETF) which is the protocol engineering, development and standardization arm of the Internet Architecture Board (IAB). The IETF is a large open international community of network designers, operators, vendors, and researchers concerned with the evolution of the Internet protocol architecture and the smooth operation of the Internet. Request-For-Comments are a series of memorandums which act as official minutes of the IETF. Request-For-Comments No. 1521 (RFC-1521) Subsection 7.4.2 is authoritative and has been reviewed and has received international approval. To avoid the accusation, of misquoting, I will simply quote Section 7.4.2 of RFC1521 in its entirety. This memorandum has unlimited distribution and is available by FTP from DS.INTERNIC.NET, NIS.NSF.NET, NISC.JVNC.NET, FTP.ISI.EDU, WUARCHIVE.WUSTL.EDU, FTP.CONCERT.NET, or FTP.SESQUI.NET. European readers might be advised to use the United Kingdom repository at SRC.DOC.IC.AC.UK. Asian & Pacific Users should probably use the local mirror for WUARCHIVE.WUSTL.EDU, or alternatively, their local National RFC repository. >7.4.2. The Application/PostScript subtype > > A Content-Type of "application/postscript" indicates a PostScript > program. Currently two variants of the PostScript language are > allowed; the original level 1 variant is described in [POSTSCRIPT] > and the more recent level 2 variant is described in [POSTSCRIPT2]. > > PostScript is a registered trademark of Adobe Systems, Inc. Use of > the MIME content-type "application/postscript" implies recognition of > that trademark and all the rights it entails. > > The PostScript language definition provides facilities for internal > labeling of the specific language features a given program uses. This > labeling, called the PostScript document structuring conventions, is > very general and provides substantially more information than just > the language level. > > The use of document structuring conventions, while not required, is > strongly recommended as an aid to interoperability. Documents which > lack proper structuring conventions cannot be tested to see whether > or not they will work in a given environment. As such, some systems > may assume the worst and refuse to process unstructured documents. > > The execution of general-purpose PostScript interpreters entails > serious security risks, and implementors are discouraged from simply > sending PostScript email bodies to "off-the-shelf" interpreters. > While it is usually safe to send PostScript to a printer, where the > potential for harm is greatly constrained, implementors should > consider all of the following before they add interactive display of > PostScript bodies to their mail readers. > > The remainder of this section outlines some, though probably not all, > of the possible problems with sending PostScript through the mail. > > Dangerous operations in the PostScript language include, but may not > be limited to, the PostScript operators deletefile, renamefile, > filenameforall, and file. File is only dangerous when applied to > something other than standard input or output. Implementations may > also define additional nonstandard file operators; these may also > pose a threat to security. Filenameforall, the wildcard file search > operator, may appear at first glance to be harmless. Note, however, > that this operator has the potential to reveal information about what > files the recipient has access to, and this information may itself be > sensitive. Message senders should avoid the use of potentially > dangerous file operators, since these operators are quite likely to > be unavailable in secure PostScript implementations. Message- > receiving and -displaying software should either completely disable > all potentially dangerous file operators or take special care not to > delegate any special authority to their operation. These operators > should be viewed as being done by an outside agency when interpreting > PostScript documents. Such disabling and/or checking should be done > completely outside of the reach of the PostScript language itself; > care should be taken to insure that no method exists for re-enabling > full-function versions of these operators. > > The PostScript language provides facilities for exiting the normal > interpreter, or server, loop. Changes made in this "outer" > environment are customarily retained across documents, and may in > some cases be retained semipermanently in nonvolatile memory. The > operators associated with exiting the interpreter loop have the > potential to interfere with subsequent document processing. As such, > their unrestrained use constitutes a threat of service denial. > PostScript operators that exit the interpreter loop include, but may > not be limited to, the exitserver and startjob operators. Message- > sending software should not generate PostScript that depends on > exiting the interpreter loop to operate. The ability to exit will > probably be unavailable in secure PostScript implementations. > Message-receiving and -displaying software should, if possible, > disable the ability to make retained changes to the PostScript > environment, and eliminate the startjob and exitserver commands. If > these commands cannot be eliminated, the password associated with > them should at least be set to a hard-to-guess value. > > PostScript provides operators for setting system-wide and device- > specific parameters. These parameter settings may be retained across > jobs and may potentially pose a threat to the correct operation of > the interpreter. The PostScript operators that set system and device > parameters include, but may not be limited to, the setsystemparams > and setdevparams operators. Message-sending software should not > generate PostScript that depends on the setting of system or device > parameters to operate correctly. The ability to set these parameters > will probably be unavailable in secure PostScript implementations. > Message-receiving and -displaying software should, if possible, > disable the ability to change system and device parameters. If these > operators cannot be disabled, the password associated with them > should at least be set to a hard-to-guess value. > > Some PostScript implementations provide nonstandard facilities for > the direct loading and execution of machine code. Such facilities > are quite obviously open to substantial abuse. Message-sending > software should not make use of such features. Besides being totally > hardware- specific, they are also likely to be unavailable in secure > implementations of PostScript. Message-receiving and -displaying > software should not allow such operators to be used if they exist. > > PostScript is an extensible language, and many, if not most, > implementations of it provide a number of their own extensions. This > document does not deal with such extensions explicitly since they > constitute an unknown factor. Message-sending software should not > make use of nonstandard extensions; they are likely to be missing > from some implementations. Message-receiving and -displaying software > should make sure that any nonstandard PostScript operators are secure > and don't present any kind of threat. > > It is possible to write PostScript that consumes huge amounts of > various system resources. It is also possible to write PostScript > programs that loop infinitely. Both types of programs have the > potential to cause damage if sent to unsuspecting recipients. > Message-sending software should avoid the construction and > dissemination of such programs, which is antisocial. Message- > receiving and -displaying software should provide appropriate > mechanisms to abort processing of a document after a reasonable > amount of time has elapsed. In addition, PostScript interpreters > should be limited to the consumption of only a reasonable amount of > any given system resource. > > Finally, bugs may exist in some PostScript interpreters which could > possibly be exploited to gain unauthorized access to a recipient's > system. Apart from noting this possibility, there is no specific > action to take to prevent this, apart from the timely correction of > such bugs if any are found. Hopefully this sets the record clear, once and for all with authority whose credentials cannot be questioned nor attacked. I wonder though, did Netscape not know about RFC1521?? You'd expect them to, wouldn't you?? Alice de 'nonymous ... ...just another one of those... P.S. This post is in the public domain. C. S. U. M. O. C. L. U. N. E.

20 36

Re: Remailer-in-a-Box, Everyone a Remailer
by Jay Campbell 17 Dec '03

17 Dec '03

>Rather, a single physical machine site can and should be able to run many >remailers, out of user accounts. (Accounts on systems like Sameer's C2. Or >Hal's remailer running on Portal. Or maybe some of the Mixmaster clients.) This also brings up the idea of 'opportunistic remailers' again (somebody gimme a snazzy name for that) - a PC/Mac-based SMTPish server that isn't always online. Shell accounts are becoming a piece of history for most users; part-time dialup IP (ppp/slip) is the predominant connectivity layer. A user could run an opportunistic remailer, and compile a list of other opp remailers his server would poll in addition to the standard shell-based 'always up' remailers. Given a large enough list (ie, everyone on this list ran this app in the background) there should be plenty of opp remailers online and ready to relay at any given time to make this an effective model. -- Jay Campbell Regional Operations Manager -=-=-=-=-=-=- Sense Networking (Santa Cruz Node) edge(a)got.net MIT PGP KeyID 0xACAE1A89 "On the Information Superhighway, I'm the guy behind you in this morning's traffic jam leaning on his horn."

1 0

Re: Verification of Registration
by patrick＠Verity.COM 17 Dec '03

17 Dec '03

> > Curious. Did anyone else receive this unsolicitated *invitation*? > > At 11:31 PM 10/23/95 -0700, verify(a)cnet.com wrote: > >Your membership registration has been processed. To become a full member > >of c|net online, please return the text of this message (to verify(a)cnet.com) Someone signed the mailing list up. I'm sure that they'll tell us about it when they get done. Patrick _______________________________________________________________________ / These opinions are mine, and not Verity's (except by coincidence;). \ | (\ | | Patrick J. Horgan Verity Inc. \\ Have | | patrick(a)verity.com 1550 Plymouth Street \\ _ Sword | | Phone : (415)960-7600 Mountain View \\/ Will | | FAX : (415)960-7750 California 94303 _/\\ Travel | \___________________________________________________________\)__________/

1 0

encryption products
by privsoft＠ix.netcom.com 17 Dec '03

17 Dec '03

I am presently evaluating / testing / researching three encryption products and I was wondering if any of ya'll are familliar with them. 1. TECSEC'c VEIL product ( so far only available through mailorder) 2. K. Briggs's Puffer, ( available for demo download off the web) 3. P. Glen's THE CRYPT , ( also available off the web) I am looking for comments about their respective crypto strengths, verstility, and capability. Thanks in advance for any assistance. Steve O ************************************************* PrivaSoft TM * 1877 Springfield Ave PO BOX 600 * Maplewood NJ 07040-0600 * Tel. 201-378-8865 Fax. 201-762-3742 * Http://www.privasoft.com/privasoft * E-mail: privsoft(a)ix.netcom.com * *************************************************

1 0

Re: [reformatted] how secure can privasoft be?
by patrick＠Verity.COM 17 Dec '03

17 Dec '03

> > > This can at most buy you a constant factor - useful, but not very. > ... > > Someone else on this list mentioned that an edge detection algorithm > ... > > It could give you a quick go/no go. > > Don't forget that in most cases it'll be obvious that it's the wrong > key - only when it isn't would you submit the thing to a second-level > analyzer to check for edges/characters etc. I'm confused here. How will it be obvious? Unless you mean that you're going to sit there and watch it while it goes through the, (on average), 999999999/2 keys it would have to try before finding it. That could take awhile and really slow things down if it took user intervention for each test. You can't beat the human eye on visual discrimination though. Patrick _______________________________________________________________________ / These opinions are mine, and not Verity's (except by coincidence;). \ | (\ | | Patrick J. Horgan Verity Inc. \\ Have | | patrick(a)verity.com 1550 Plymouth Street \\ _ Sword | | Phone : (415)960-7600 Mountain View \\/ Will | | FAX : (415)960-7750 California 94303 _/\\ Travel | \___________________________________________________________\)__________/

1 0

Re: Verification of Registration
by Lynne L. Harrison 17 Dec '03

17 Dec '03

Curious. Did anyone else receive this unsolicitated *invitation*? At 11:31 PM 10/23/95 -0700, verify(a)cnet.com wrote: >Your membership registration has been processed. To become a full member >of c|net online, please return the text of this message (to verify(a)cnet.com) > >The following magic token in this message [cypherpunks::752400770] will be automatically >processed to verify you. Please note: The number included in the token is >*not* your password; the one to use on the site is the one you entered on >the registration form. > >Please include the complete token appearing above, including the brackets. >The best way to return it to us is to include this entire message in your >reply. If you mailer does not allow you to do this, retype or cut and >paste the magic token (including the square brackets) into a new message to >verify(a)cnet.com. If you are having difficulty completing this process, >please direct your questions to support(a)cnet.com. > >Once you are verified you will be able to take advantage of the full >range of c|net online's services. > > ******************************************************************** Lynne L. Harrison, Esq. Poughkeepsie, New York lharrison(a)mhv.net "Say not, 'I have found the truth', but rather, 'I have found a truth.'" - Kahlil Gibran from "The Prophet" ********************************************************************

3 2

Attacks on Products and Companies
by tcmay＠got.net 17 Dec '03

17 Dec '03

At 12:02 AM 10/24/95, Ian Goldberg wrote: >We should be keeping in mind that the goal here is to end up, in one way >or another, with a _secure_ way of transacting on the net. To that end, >it may be necessary to demonstrate that some current products don't >provide that way. We certainly don't want people to be scared away >from using one insecure product, only to use another, especially >if the latter is less secure than the former. ... >Everything would be _so_ much easier to check, though, if these >people would stop this "security through obscurity" garbage and >publish their protocols, if not their source. > > - Ian "Mr. Worf, activate targetting scanners." I don't wish to beat a dead horse, but my main point is not that we (the list members, and others) should not be scrutinizing and trying to break systems, but that it should be done with less general nastiness. What do I mean by "nastiness"? (And let me first hasten to add that neither Ian Goldberg nor his partner were nasty in their attacks on Netscape.) The problem I see is that people often _personalize_ the attacks, or treat members of companies who show up on the list as _adversaries_. I can't know for sure if the various folks from Netscape, First Virtual, Digicash, Intuit, etc., who hang out on this list feel besieged, but I know I sure would. If everything I said, even with disclaimers that I don't speak officially, were to be torn apart and the ulterior motives speculated upon, I'd either shut up on this list or get off it completely. (Recall that we had Marc Andreessen on this list last December--for whatever reasons, and there are likely several, he left. I recall many attacks on his company. He perhaps figured "What the hell do I need this for?") Legitimate, scientific analysis is commendable. The brute force attack on Netscape was great, and even better was the random seed attack. But many of the attacks are less solid: "How can you people at Digital Datawhack produce such crap? The assumptions you make in the Flogisticon module are disgusting, another example of security through obscenity." (What I think this piling on is likely to accomplish is to push company list subscribers here to just shut up. They see that the more is said by folks from Netscape, as the best current example, the more fireworks and insults ensue. The less that is said the better. This is not a good situation.) I'm not arguing for "niceness," just that some of the edge be taken off the attacks. The "bounties" that are being offered in press releases have the danger of inviting premature announcement of results. And of discouraging companies from actively participating in this list and discussing what might be done to improve security. Just my views. No doubt some will think I'm a shill for some company. --Tim May Views here are not the views of my Internet Service Provider or Government. ---------:---------:---------:---------:---------:---------:---------:---- Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay(a)got.net 408-728-0152 | anonymous networks, digital pseudonyms, zero Corralitos, CA | knowledge, reputations, information markets, Higher Power: 2^756839 | black markets, collapse of governments. "National borders are just speed bumps on the information superhighway."

1 0

Hacking commercial systems.
by hallam＠w3.org 17 Dec '03

17 Dec '03

Hi, A number of people have been proposing hacks on commercial payment systems. Could I point out that this is not necessarily a good idea? One vendor I spoke to has a contract clause with sublicensees which requires a legal response in such situations. His opinion was that attempting such a crack on a "live" system consitituted conspiracy to commit fraud and organisation of the same could involve RICO penalties. It would seem prudent to approach such projects with a little caution. If a request were made for a sample of material to work on most companies would oblige and a refusal would provide protection against legal tactics. Most sensible companies would see the advantage of offering a reward. Phill

2 1