December 2003 - cypherpunks-legacy

PKP-Lemcom License Agreement
by John Young 17 Dec '03

17 Dec '03

Thanks to John Gilmore we offer the 1992 License Agreement between PKP and Lemcom Systems filed as an exhibit in the RSA v. PGP suit: http://jya.com/pkplem.htm (41K)

1 0

Press Release -- NetFortress Added to GSA Schedule (fwd)
by Declan McCullagh 17 Dec '03

17 Dec '03

---------- Forwarded message ---------- Date: Wed, 21 May 1997 16:41:29 -0400 From: Gretta Bruce <gretta(a)dsnt.com> To: declan(a)well.com Subject: NetFortress Added to GSA Schedule FOR IMMEDIATE RELEASE CONTACT: Gretta Bruce, 813/288-7388 May 21, 1997 or gretta(a)dsnt.com NETFORTRESS ADDED TO GSA SCHEDULE Breakthrough Network Security Solution Now Widely Available to Government Customers Tampa, FL.... Digital Secured Networks (DSN) Technology announced today that its advanced encryption product, the NetFortress, has been listed on the federal procurement schedule of the General Services Administration (GSA). The NetFortress was added to the GSA schedule of one of DSN's federal market VARs, Patriot Technologies Inc. The addition of the NetFortress to the GSA Schedule (#GS-35F-4363D) makes DSN's breakthrough encryption products widely available to customers throughout the federal government. Since the GSA Schedule functions as an approved, "one-stop shop" for federal purchases, it also will shorten the overall procurement process for federal purchasers. "Availability and affordability are the keys for federal buyers," said Raymond L. Weadock, DSN's President and Chief Executive Officer. "Purchasing NetFortress products through the GSA schedule will simplify the overall procurement process, and enable our federal customers to integrate our superior security solutions quickly and efficiently." "The GSA listing for the NetFortress is an important part of our federal sales efforts," Weadock continued. "We have seen a significant increase in federal customers as a result of the recent success of the NetFortress in tests at multiple government testbeds. We anticipate that the GSA listing will enhance the attractiveness of our product in many of these buying decisions." The NetFortress stands out from other network security products because of its unique combination of high-speed data throughput and fully-automated encryption, authentication and key management technologies. Its hardware-based design utilizes algorithm-independent encryption at the network layer (supports IDEA, DES, Triple DES and FEAL), enhanced by dynamic random key exchanges every 24 hours. The NetFortress offers superior security and high-speed performance in an easy-to-deploy, low-cost package. About DSN Technology: Digital Secured Networks (DSN) Technology was founded in 1995 by Dr. Aharon Friedman and Mr. Andrew Savas. Dr. Friedman, DSN's Chairman and Chief Technology Officer, invented the breakthrough encryption technology incorporated into the NetFortress product line. DSN Technology is a privately-held company. For further information, please visit the company website at www.dsnt.com. About Patriot Technologies: Patriot Technologies, Inc., develops integrated, turnkey Internet solutions for business, education and government clients world-wide. With more than 50 years of computer industry experience, Patriot specializes in the design and implementation of Internet applications for enterprise systems, with growing concentration in the area of network security. Key federal clients include the U.S. Department of State, U.S. Department of Justice, and U.S. Department of Energy. Further information may be obtained from the company website at www.patriot-tech.com or by calling 301/417-9899. ######

1 0

Ecash API
by nobody＠huge.cajones.com 17 Dec '03

17 Dec '03

X-Authentication-Warning: blacklodge.c2.net: majordom set sender to owner-dev-lucre(a)c2.org using -f X-Sender: jeremey(a)descartes.bluemoney.com Date: Wed, 21 May 1997 12:32:09 -0700 To: ecash-dev(a)digicash.com, dev-lucre(a)c2.net From: Jeremey Barrett <jeremey(a)bluemoney.com> Subject: Ecash API Mime-Version: 1.0 Sender: owner-dev-lucre(a)c2.net Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Given the absence of an API from Digicash, we need a high level API so make the task of integrating ecash into products really easy. So here's my stab. This is the current header from my ecash library, which is a wrapper for -lucre. -lucre is great, but it's pretty low-level, hence the wrapper. The documentation in here is pretty incomplete, with just basic descriptions of what functions do what. At some point it will be improved. I welcome comments, suggestions, questions, and feature requests. Currently, this lib handles socket transactions only, but ascii-armor support will be added. This library will be available in some form or another in the future, at the moment I'm just looking for feedback. Regards, Jeremey. /* Copyright (c) 1995, 1996, 1997 * The VeriWeb Internet Corporation. All Rights Reserved. * * Please view the full copyright at the bottom of this file. * * ecash.h $Revision: 1.2 $ (VeriWeb) $Date: 1997/05/21 01:48:50 $ */ /*==========================================================================* * * ecash.h * * Written by: Jeremey Barrett * * $Revision: 1.2 $ */ #ifndef _ECASH_H_ #define _ECASH_H_ #include <Vlib.h> /* utility header */ #include <lucre.h> /* -lucre header */ /*-------------------------------------------------------------------- * Types */ typedef struct _ECSocket ECSocket; typedef struct _ECPayment ECPayment; typedef struct _ECPocket ECPocket; typedef struct _ECConfig ECConfig; typedef struct _ECError ECError; /*-------------------------------------------------------------------- * Errors */ #define ECError_NONE 0 #define ECError_INVALID -1 #define ECError_ECSYS -2 #define ECError_SYS -3 #define ECError_TCP -4 #define ECError_READ -5 #define ECError_WRITE -6 #define ECError_BIGNUM -7 #define ECError_MSGNEW -8 #define ECError_WALLETCREATE -9 #define ECError_NOMEM -10 #define ECError_POCKETOPEN -11 #define ECError_POCKETPASSWD -12 #define ECError_NOBANKACCOUNT -13 #define ECError_WITHDRAWAMOUNTLOW -14 #define ECError_DEPOSITPAYMENT -15 #define ECError_DEPOSITALLPAYMENTS -16 #define ECError_DEPOSITRECDB -17 #define ECError_DEPOSITREJECTED -18 #define ECError_WALLETSTATUS -19 #define ECError_DEPOSIT -20 #define ECError_WITHDRAW -21 #define ECError_NOPOCKETPASSWD -22 #define ECError_ECMSGINVALID -23 #define ECError_SENDMSGCALLBACK -24 #define ECError_MAGIC -25 #define ECError_APPENDMSG -26 #define ECError_PAYMENTACCEPT -27 #define ECError_PAYMENTACCEPTBADAMOUNT -28 #define ECError_PAYMENTREJECTED -29 #define ECError_PAYMENTMAKE -30 #define ECError_PAYREQRECEIVE -31 #define ECError_PAYREQCURRENCYUNKNOWN -32 #define ECError_PAYMENTREQUEST -33 #define ECError_PAYMENTACK -34 #define ECError_PAYDB -35 #define ECError_NOPAYMENTS -36 #define ECError_WALLETCOINS -37 #define ECError_EXCHANGECOINS -38 #define ECError_EXCHANGEREJECTED -39 #define ECError_NOTENOUGHCASH -40 #define ECNoError ((ECError *)NULL) /*-------------------------------------------------------------------- * ECPocket APIs * * Very preliminary documentation (will get enhanced later, I'm just * documenting the less obvious here. * * EC_Pocket_open() - Open an existing pocket, with location and * passphrase set in the ECConfig *. * * EC_Pocket_openAccount() - Create a new pocket with the attributes * in the ECConfig *. This does _not_ open * the pocket. This is for pockets which * have mint accounts only. * * EC_Pocket_openNoAccount() - Create a new pocket with the attributes * in the ECConfig *. This does _not_ open * the pocket. This creates an accountless * pocket, so the mintAddr and mintPort of * the ECConfig * should point to the * moneychanger. Note that mintID is still * required. This will open a connection * to the moneychanger and retrieve currency * keys for the mint. * * EC_Pocket_withdraw() - Withdraw from a mint account. * * EC_Pocket_withdrawProtoCoins() - Complete and withdraw the coins in * the EC_M_Withdraw3 (a -lucre struct). * amt is the value of the coins being * withdrawn. * * EC_Pocket_deposit() - Deposit amount into mint account * * EC_Pocket_depositWithdraw() - Deposit coins and immediately withdraw * the same amount. This allows for exchanges * of coins and altering the stored * denominations. Call this when you don't have * the right coins on hand for a payment. * * EC_Pocket_exchangeCoins() - Exchange coins (via moneychanger), same as * above but w/o mint. * * EC_Pocket_getCoinInfo() - Returns information about the denominations * available for a given amount. max_avail is the * largest amount the pocket can make less than the * amount specified. min_dep is the smallest amount * to exchange which will guarantee the ability to * make amount, provided min_dep is withdrawn in * base units (i.e. 1 cent). * */ ECPocket *EC_Pocket_create( void ); ECPocket *EC_Pocket_copy( ECPocket *this ); ECError *EC_Pocket_destroy( ECPocket *this ); ECError *EC_Pocket_open( ECPocket *this, ECConfig *conf ); ECError *EC_Pocket_openAccount( ECConfig *conf ); ECError *EC_Pocket_openNoAccount( ECConfig *conf ); ECError *EC_Pocket_withdraw( ECPocket *this, Int32 amount, Int32 minPayments ); ECError *EC_Pocket_withdrawProtoCoins( ECPocket *this, ECSocket *sock, EC_M_Withdraw3 wd3, Int32 amt ); ECError *EC_Pocket_deposit( ECPocket *this, Int32 amount ); ECError *EC_Pocket_depositWithdraw( ECPocket *this, Int32 amount, Int32 payments ); ECError *EC_Pocket_exchangeCoins( ECPocket *this, Int32 amount, Int32 payments, char *host, char *port ); ECError *EC_Pocket_getMintID( ECPocket *this, UInt32 *id ); ECError *EC_Pocket_getCurrency( ECPocket *this, UInt32 *cur ); ECError *EC_Pocket_getAccountName( ECPocket *this, char **name ); ECError *EC_Pocket_getCash( ECPocket *this, UInt32 *cash ); ECError *EC_Pocket_getBalance( ECPocket *this, UInt32 *bal ); ECError *EC_Pocket_getCashStr( ECPocket *this, char **cash_str ); ECError *EC_Pocket_getBalanceStr( ECPocket *this, char **bal_str ); ECError *EC_Pocket_getCoinInfo( ECPocket *this, UInt32 amount, UInt32 *max_avail, UInt32 *min_dep ); Int32 EC_Pocket_isAccountless( ECPocket *this ); /*-------------------------------------------------------------------- * ECSocket APIs * * * Simple set of socket APIs. These functions manage the ecash TCP * protocol for you. Documentation later. * * EC_Socket_setCallbacks() - Sets send and receive callbacks for * sending ecash messages. These will be * called _after_ the message is encoded * with the ecash TCP header. */ ECSocket *EC_Socket_create( UInt32 type ); ECError *EC_Socket_setCallbacks( ECSocket *this, UInt32 (*sendcallback)( void *cbInfo, UChar *msg, UInt32 len ), UInt32 (*recvCallback)( void *cbInfo, UChar **msg, UInt32 *len), void *cbInfo ); ECSocket *EC_Socket_createFromFd( char *haddr, char *hport, Int32 fd ); ECError *EC_Socket_open( ECSocket *this, char *haddr, char *hport ); ECError *EC_Socket_accept( ECSocket *this, ECSocket *new ); ECError *EC_Socket_listen( ECSocket *this, char *hport ); ECError *EC_Socket_sendMsg( ECSocket *this, EC_M_Msg msg ); ECError *EC_Socket_recvMsg( ECSocket *this, EC_M_Msg msg ); TCPSocket *EC_Socket_getTCPSocket( ECSocket *this ); /*-------------------------------------------------------------------- * ECConfig APIs */ ECConfig *EC_Config_create( void ); ECConfig *EC_Config_copy( ECConfig *this ); ECError *EC_Config_destroy( ECConfig *this ); ECError *EC_Config_setAccountName( ECConfig *this, char *name ); ECError *EC_Config_setAccountPassword( ECConfig *this, char *passwd ); ECError *EC_Config_setPocketPassword( ECConfig *this, char *passwd ); ECError *EC_Config_setPocketDir( ECConfig *this, char *path ); ECError *EC_Config_setMintID( ECConfig *this, UInt32 mintID ); ECError *EC_Config_setMintAddr( ECConfig *this, char *host ); ECError *EC_Config_setMintPort( ECConfig *this, char *port ); /*-------------------------------------------------------------------- * ECPayment APIs * * The important functions here are accept(), make(), request(), and * variants. Note that this is all socket based, there will be ascii * armor variants soon, but not now. * * EC_Payment_accept() - accept an online payment. The this pointer * points to an ECPayment with the expected * amount set. This amount is checked and an * error will be returned if the incoming payment * does not agree. The ECSocket * is an already * open socket to the payer. This function will * automatically handle accountless pockets, so * explicitly calling the NoAccount variant is * not necessary. * * EC_Payment_accept1() - same as above, but the payment is _not_ acked * to the payer. * * EC_Payment_acceptNoAccount() - same as accept() but for accountless * pockets. Gets called by accept() if * the pocket is accountless. * * EC_Payment_acceptNoAccount1() - same as above, but the payment is _not_ * acked to the payer. * * EC_Payment_handle() - Unconditionally accept a -lucre EC_M_Payment. This * will _not_ check amounts. It will handle NoAccount * automatically. * * EC_Payment_handleNoAccount() - same as above except for accountless * pockets. Called by handle() if the pocket * is accountless. * * EC_Payment_make() - make a payment over the ECSocket passed. This * function _expects_ a payment ack. Use make1() if * none will arrive. * * EC_Payment_make1() - same as above, but does not wait for an ack. * * EC_Payment_receiveRequest() - Receive a payment request on the ECSocket * passed. Returns the information in the * this pointer. * * EC_Payment_request() - Send a payment request over the ECSocket passed. */ ECPayment *EC_Payment_create( ECPocket *pocket ); ECError *EC_Payment_setAmount( ECPayment *this, Int32 amt ); ECError *EC_Payment_setTimestamp( ECPayment *this, UInt32 timestamp ); ECError *EC_Payment_setSeqNo( ECPayment *this, UInt32 timestamp ); ECError *EC_Payment_setDescription( ECPayment *this, char *desc ); ECError *EC_Payment_setRecipientName( ECPayment *this, char *name ); ECError *EC_Payment_setRecipientMint( ECPayment *this, UInt32 id ); ECError *EC_Payment_getAmount( ECPayment *this, UInt32 *amt ); ECError *EC_Payment_getSeqNo( ECPayment *this, UInt32 *seqno ); ECError *EC_Payment_getTimestamp( ECPayment *this, UInt32 *timestamp ); ECError *EC_Payment_getDescription( ECPayment *this, char **desc ); ECError *EC_Payment_getRecipientName( ECPayment *this, char **name ); ECError *EC_Payment_getRecipientMint( ECPayment *this, UInt32 *id ); ECError *EC_Payment_accept( ECPayment *this, ECPocket *pocket, ECSocket *sock ); ECError *EC_Payment_accept1( ECPayment *this, ECPocket *pocket, ECSocket *sock ); ECError *EC_Payment_acceptNoAccount( ECPayment *this, ECPocket *pocket, ECSocket *sock ); ECError *EC_Payment_acceptNoAccount1( ECPayment *this, ECPocket *pocket, ECSocket *sock ); ECError *EC_Payment_handle( ECPayment *this, ECPocket *pocket, EC_M_Payment payment ); ECError *EC_Payment_handleNoAccount( ECPayment *this, ECPocket *pocket, EC_M_Payment payment ); ECError *EC_Payment_make( ECPayment *this, ECPocket *pocket, ECSocket *sock ); ECError *EC_Payment_make1( ECPayment *this, ECPocket *pocket, ECSocket *sock ); ECError *EC_Payment_receiveRequest( ECPayment *this, ECPocket *pocket, ECSocket *sock ); ECError *EC_Payment_request( ECPayment *this, ECPocket *pocket, ECSocket *sock ); /*-------------------------------------------------------------------- * ECError APIs */ ECError *EC_Error_create( void ); ECError *EC_Error_returnValue( Int32 errno ); ECError *EC_Error_returnTCPError( TCPError *err ); ECError *EC_Error_returnLibError( Int32 errno, Int32 libErrno ); #endif /* _ECASH_H_*/ /* <COPYRIGHT_PUB> * * Copyright (c) 1995, 1996, 1997 * The VeriWeb Internet Corporation. All Rights Reserved. * * This is a published work of the VeriWeb Internet Corporation * ("VeriWeb"). Permission to use and/or redistribute may be * obtained upon prior written permission by VeriWeb, and * provided that the following conditions are also met: * * 1. Redistributions of source code, including binary forms, * must retain the above copyright notice, this list of * conditions, and the following disclaimer. * * 2. Documentation and/or other materials provided with any * redistribution must contain the above copyright notice, * this list of conditions, and the following disclaimer. * * 3. All advertising materials mentioning features or use of * this software must display the following acknowledgement: * * This product includes software developed by * the VeriWeb Internet Corporation and its contributors. * * 4. Neither the name of the VeriWeb nor the names of its * contributors may be used to endorse or promote products * derived from this software without specific prior written * permission. * * THIS SOFTWARE IS PROVIDED BY VERIWEB AND CONTRIBUTORS ``AS IS''. * THEREFORE, ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS * FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL VERIWEB * OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED, AND ON * ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY * OF SUCH DAMAGE. * * </COPYRIGHT_PUB> * * ecash.h $Revision: 1.2 $ (VeriWeb) $Date: 1997/05/21 01:48:50 $ */ /*eof*/ -----BEGIN PGP SIGNATURE----- Version: 5.0 beta Charset: noconv iQCVAwUBM4NNuS/fy+vkqMxNAQEzngP7BmDg16Cmnb9uqS30xlhBvA7FaZb4YPRA tulRHA+7FhRZttfBm/jL8gaOEzjdtPR4f7p3gGjB4YC2KvSAI1iTrpR9EYxdzHB7 0qMAjPAZbI0A08ZOPLkGDoOi9Qqs3jCgdimANjdVeTheYNNpcR1Ti4ez1CtdwmUo he0phYP1FBg= =qizj -----END PGP SIGNATURE----- -- Jeremey Barrett VeriWeb Internet Corp. Crypto, Ecash, Commerce Systems http://www.veriweb.com/ PGP key fingerprint = 3B 42 1E D4 4B 17 0D 80 DC 59 6F 59 04 C3 83 64

1 0

Re: The USA is the world's biggest terrorist state
by Steve Schear 17 Dec '03

17 Dec '03

>The United States of America sits astride the world, holding the riding >crop and ordering the other nations of the world around in various ways. It >sends troops to distant parts of the world. It even takes on the main >"peacekeeping" (meaning: choosing a faction and suppressing the other >factions) role in Yugoslavia...surely a European problem, if a problem at >all. > The US is in very real danger of reaping the same sort of maelstrom that vanquished the Romans. They were also very powerful, with tentacles reaching almost to the limits of their known world, before a combination of internal decay and dissention and reprisal from those vanquished put them asunder. The government's recent emphasis on terrorism is apt since they have created so many enemies of ethnic, political, religious and social groups. Even paranoids have enemies. The internal threat is not near as great as they portray, but with increased emphasis on suppression and prosecution rather than addressing the ills, it will likely become a self-fulfilling prophesy. However, addressing the complaints of these militias is not under consideration because it would undo the very fabric of Federal jurisdictional excesses which provide the government's power base. Economics and the freedom, or lack, it entails is key. One reason our political system doesn't work is the Fed's right to tax internal economic activity as opposed to the excise taxes it was originally granted. Too much money (power) is concentrated in too few representatives who work in relative isolation (ever try and get a meeting with your rep.) for most of their term. If internal taxes could only be levied by states, who then were free to revenue share what they wished with the Feds (who would submit their requests and budgets to the states), power might be so diffused as to make nationwide lobbying too difficult and expensive and there would be a much closer adherence to local interest. We appear to be heading straight for a Whiskey Rebellion type showdown. In fact, many of the same complaints of retreat from the founding principles, which were ignored in the 1780-90s, are echoing in the writings and speeches of today's militia. In the 1790s it was wealthy and powerful eastern businessmen, mostly former Torries, who supported Hamilton and Washington against the frontiersmen. This time its the military industrial complex. This time I hope the resistance is much bettered prepared. --Steve

1 0

Re: attila the hun (was Re: Wine Politics Again!)
by nobody＠huge.cajones.com 17 Dec '03

17 Dec '03

Adam Back wrote: > Bill Stewart <stewarts(a)ix.netcom.com> writes: > > At 11:13 PM 5/20/97 -0700, Kent Crispin wrote: > > >On Tue, May 20, 1997 at 04:23:10PM +0000, Attila T. Hun wrote: > > [rant deleted - bill] > > >Speaking of power corrupting, notice how the power to speak > > >anonymously has destroyed this poor souls brain. When Attila T. Hun posts to the list, I can tell you how many hours, days and minutes it has been since his last post. I know when I see his name on a post that he has something to say. Perhaps the most telling comment I have heard about him was when a fellow cypherpunk said about Attila, "When he replies to one of my posts I never know if he's going to kiss me or rip me a new asshole. He doesn't respond to my _reputation capital_ or my perceived net persona--he responds to what I express in my posting." I don't have a problem with the opinions or points of view that Kent expresses on the cypherpunks list, but I do have a problem with the fact that his posts seem to reflect a pre-programmed world-view, with little thought given to the actual content and concepts expressed by those he is replying to. I find Kent's posts to be much like the ASCII art that is posted to the list--each post is slightly different, but predictable. The aspersions that Kent casts on those such as Attila and Tim serve no purpose other than to accentuate the fact that he is envious of their propensity for dealing on a real-world level with the concepts he addresses from an intellectual ivory tower. > > Attila's not anonymous - he's a regular poster, and has been > > for long enough to build up some reputation around his penname. There are people I have known for years--their _real_ name, where they live, went to school, the annual average rainfall in their hometown, etc.--but I know very little about who they really are-- how they think, what they believe, etc. I know a lot more about Attila T. Hun. His posts reflect who he is, where he's been, what he's done, and his perceptions about himself and the world around him. His posts reflect his persona. Kent's posts reflect, in my opinion, what he has "learned to believe." When I read Kent's posts, I don't feel like I learn who he is, but rather, I learn the "position" that he is taking on this or that point. Real name/anonymity aside, I see Attila as real and Kent as a shadowy figure. My advice to Kent would be, "If you're going to be an asshole, at least be a _real_ asshole." I enjoy the exchange of differing viewpoints (and genuine conflicts) on the cypherpunks list, because it gives me food for thought about positions and viewpoints that I have dichotimous feelings about, but I have little use for lukewarm, passive-aggressive exchanges. (I prefer the pissing contests between raving maniacs.) > In short I believe you picked on the wrong guy if you considered > Attila an example of someone with lots to say when hiding behind > strong anonymity. I have used a variety of "names" as a writer, musician and as a fugitive from injustice. Whenever I looked in the mirror, however, I always saw the same face. And no matter what "persona" I am using, I find that I feel most like "myself" when I speak and act honestly, no matter whether my stance is homeostatic or dichotymous. I have done traffic/personality/pseudonym analysis on the list for years and have uncovered a plethora of anonymous personas. Some use anonymity to "step out of" their regular list persona. Some use it to address issues that could not deal with under their regular persona because of a need to protect their perceived public/social image. Some use anonymity because of personal or business conflicts that could be used against them by those who feel threatened by honesty. Others use anonymity because it is fun to play "hide and seek" with list members who know them well enough to suspect who they _really_ are. I first encountered the "TruthMonger" persona in 1989 and have followed its evolution since that time. The better I got at tracking the various entities assuming the TruthMonger persona, the more I realized that those who claim to "know" or "expose" who a particular TruthMonger _really_ is are wrong about 90% of the time. The reason for this is simple. Once we form an "opinion" of _who_ somebody is and _what_they_ believe_, and _who_they_are_, then we "interpret" what they have to say in their posts in accordance with our learned perception of them. Accordingly, we fail to see the naturally occuring dichotomys and inconsistencies that are inherent in living, learning and adapting to the evolution of thought which comes with an expanding mental and emotional paridigm. When the same person posts anonymously, then those who know them and have an "opinion" of who they are and what they think can no longer categorize their post automatically and interpret it in the "usual" manner. Anonymity forces the reader to consider the content that is contained in the post, rather than automatically consigning it to the proper "box" according to the established persona of a regular poster. Many people are not comfortable with not being able to "assign" an anonymous persona with the author's appropriate mental "box" so they attribute this or that post with this or that list member and respond accordingly. I am posting this anonymously. Who am I? I am the person who believes what I have written here and who doesn't want what I am expressing to be classified according to what I wrote yesterday. I am: TruthMonger # -96

3 2

Report: The Risks of Key Recovery
by Alan Davidson 17 Dec '03

17 Dec '03

An experts' study of the risks presented by key escrow and key recovery was released this morning and is now available on the Web at http://www.crypto.com/key_study/ Thought some of you folks might find this interesting. Regards, Alan ----------------- THE RISKS OF KEY RECOVERY, KEY ESCROW, AND TRUSTED THIRD PARTY ENCRYPTION Report By Leading Cryptographers and Computer Scientists Says Government Encryption Plan Is Risky and Impractical On Wednesday May 21, a group of leading cryptographers and computer scientists released a report examining the risks and implications of government-driven key-recovery systems. The report cautions that, "The deployment of a general key-recovery-based encryption infrastructure to meet law enforcement's stated requirements will result in substantial sacrifices in security and cost to the end user. Building a secure infrastructure of the breathtaking scale and complexity demanded by these requirements is far beyond the experience and current competency of the field." The report's authors, recognized leaders in the fields of cryptography and computer science, include Hal Abelson, Ross Anderson, Steven M. Bellovin, Josh Benaloh, Matt Blaze, Whitfield Diffie, John Gilmore, Peter G. Neumann, Ronald L. Rivest, Jeffery I. Schiller, and Bruce Schneier. HOW TO OBTAIN A COPY OF THE REPORT The report is available online at http://www.crypto.com/key_study/ and printed copies will also be available through the Center for Democracy and Technology. FOR MORE INFORMATION If you have any questions or would like additional information, please contact Alan Davidson at CDT, 202.637.9800 <abd(a)cdt.org>.

1 0

Re: Anonymous remailers: A call to arms wanted
by Cyberdog 17 Dec '03

17 Dec '03

>Anonymous remailers protect speakers from retaliation. The Founders used >anonymity, as the pseudonymous writings in the Federalist Papers show. > >Granted, some anonymous posts are drivel, some are even illegal. > >So? > The Antifederalist writers used pen-names too, and recent events make thier arguments interesting. http://colossus.net/wepinsto/rot/afp/index.html Index to the Antifederalist Papers Antifederalist No. 1 GENERAL INTRODUCTION: A DANGEROUS PLAN OF BENEFIT ONLY TO THE "ARISTOCRATICK COMBINATION" Antifederalist No. 2 "WE HAVE BEEN TOLD OF PHANTOMS" Antifederalist No. 3 NEW CONSTITUTION CREATES A NATIONAL GOVERNMENT; WILL NOT ABATE FOREIGN INFLUENCE; DANGERS OF CIVIL WAR AND DESPOTISM Antifederalist No. 4 FOREIGN WARS, CIVIL WARS, AND INDIAN WARS - THREE BUGBEARS Antifederalist No. 5 SCOTLAND AND ENGLAND - A CASE IN POINT Antifederalist No. 6 THE HOBGOBLINS OF ANARCHY AND DISSENSIONS AMONG THE STATES Antifederalist No. 7 ADOPTION OF THE CONSTITUTION WILL LEAD TO CIVIL WAR Antifederalist No. 8 "THE POWER VESTED IN CONGRESS OF SENDING TROOPS FOR SUPPRESSING INSURRECTIONS WILL ALWAYS ENABLE THEM TO STIFLE THE FIRST STRUGGLES OF FREEDOM" ....

1 0

One-time pads
by nobody＠huge.cajones.com 17 Dec '03

17 Dec '03

Timothy C[reep] May sits at his terminal dressed in five-inch stiletto heels, fishnet stockings, a gold-lame mini-skirt, a purple halter with girdle underneath to keep in his flabby gut, a Fredericks of Hollywood padded bra also underneath the halter, a cheap Naomi Sims pink afro wig, waiting to yank his crank whenever a black man responds to one of his inane rants. ^. .^ ( @ ) c

2 1

Re: Poison Pill Defense (fwd)
by Igor Chudov ＠ home 17 Dec '03

17 Dec '03

----- Forwarded message from Peter Trei ----- >From cpunks(a)manifold.algebra.com Wed May 21 09:12:25 1997 Message-Id: <199705211410.KAA03539(a)www.video-collage.com> Comments: Authenticated sender is <trei@popserver> From: "Peter Trei" <trei(a)process.com> Organization: Process Software To: cypherpunks(a)algebra.com Date: Wed, 21 May 1997 10:21:43 -6 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: Poison Pill Defense Reply-to: trei(a)process.com CC: trei(a)www.video-collage.com Priority: normal X-mailer: Pegasus Mail for Win32 (v2.42) nobody(a)huge.cajones.com (Huge Cajones Remailer) writes: > > I hear from anonymous correspondents that the following > technique has been successfully deployed among some militia > members and cypherpunks who fear raids on their private > property. Apparently the technique was originally invented > by a biotech lab that the FDA was planning to shut down in an > uncivil manner when Kessler first came to power. The > lab was never raided. > Preliminary: choose a suitable viral agent. [...] > Step one: immunize household members against this agent. Several things come to mind in reading this. 1. This has *no* crypto-related content. 2. This guy has been watching too many re-runs of 'Mission Impossible'. The scheme is Rube-Goldberg and full of potential failure modes, ranging up to and including the accidental death of the implementor and his/her household. The techniques involved are complex, difficult, dangerous, and expensive. 3. This is not a 'defense'. * It won't stop a raid; if it's deployment is kept secret, it's deterrence value is zero. If it's deployment is publicized, then it is ineffective, since the raiders will take appropriate countermeasures (and announcement of it's deployment is *very* good grounds for a raid). * It won't work to conceal whatever you had that was worth concealing, in the event of a raid. All it is a scheme for getting petty vengence, and even if works perfectly, will get you murder or attempted murder charges tacked onto whatever you were raided for. Only an idiot (such as our anonymous poster) would even think of deploying such a scheme. 4. If I were an agent provocateur, attempting to make the members of this list look dangerous, I'd encourage them to discuss topics like this. Jim Bell's advocacy of AP may have been legal, but it sure didn't endear him to LEAs. I seriously suspect that this thread may have been planted by someone with the intent of discrediting the list. Peter Trei Disclaimer: I speak only for myself. ----- End of forwarded message from Peter Trei -----

1 0

Re: Hacked, Trashed and Out of Beer (fwd)
by Igor Chudov ＠ home 17 Dec '03

17 Dec '03

----- Forwarded message from Peter Trei ----- >From cpunks(a)manifold.algebra.com Wed May 21 09:20:15 1997 Message-Id: <199705211417.KAA03928(a)www.video-collage.com> Comments: Authenticated sender is <trei@popserver> From: "Peter Trei" <trei(a)process.com> Organization: Process Software To: cypherpunks(a)manifold.algebra.com Date: Wed, 21 May 1997 10:28:32 -6 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: Hacked, Trashed and Out of Beer Reply-to: trei(a)process.com CC: trei(a)www.video-collage.com Priority: normal X-mailer: Pegasus Mail for Win32 (v2.42) Bill Frantz wrote: > At 6:21 PM -0700 5/20/97, se7en <se7en(a)dis.org> wrote: > >Well, I finally managed to catch up on all the email from this list, and > >managed to also get all of the hacked web sites thus far up on my web > >page at http://www.dis.org/se7en > > > >w-h-i-c-h includes: > > > >Amnesty International > >Central Intelligence Agency > >East Timor, Indonesia > >Kriegsman Fur > >NASA > >U.K. Labour Party > >U.S. Air Force > >U.S. Department of Justice > > Gee, your server sure wants to send a lot of cookies. I consider receiving > a cookie before getting a statement, or being able to guess (e.g. WEB > shopping), about their use to be an unfriendly act. > Bill Frantz Netscape 4.x (I'm using beta3, beta4 is now out) includes an option to silently refuse all cookies. That alone is enough to make me put up with it's instabilities. Peter Trei ----- End of forwarded message from Peter Trei -----

1 0

Re: encryption laws (fwd)
by Jim Choate 17 Dec '03

17 Dec '03

Forwarded message: > Date: Wed, 21 May 1997 15:03:32 -0400 > From: tzeruch(a)ceddec.com > > If they had reasonable cause to believe you had knowledge of the key and > > were refusing to divulge it under direct order of the court you would be > > held in contempt until you were very old and gray. > > IANAL, but > > You could claim 5th ammendment priviledge - they would have to give > immunity from any prosecution relating to the contents. > The 5th ONLY applies if you are being accussed AND immunity is not granted. Jim Choate CyberTects ravage(a)ssz.com

1 0

Re: encryption laws (fwd)
by Jim Choate 17 Dec '03

17 Dec '03

Forwarded message: > From: frissell(a)panix.com > Date: Wed, 21 May 1997 07:45:35 -0400 > >If they had reasonable cause to believe you had knowledge of the key and > >were refusing to divulge it under direct order of the court you would be > >held in contempt until you were very old and gray. > Two years max. A lot less time if you followed my strategy of spamming the > court with daily (hourly?) screeds in which you assert in your finest Usenet > flame language the fact that you will never follow the judge's order. Your contention is that the longest a judge can hold you on contempt charges is two years? I would love to see a reference on this one. Jim Choate CyberTects ravage(a)ssz.com

1 0

pgMedia, Inc. vs. Network Solutions, Inc. PARTY!
by mf＠mediafilter.org 17 Dec '03

17 Dec '03

name.space hits network solutions with antitrust suit zero.tolerance.org - mediafilter.org - and name.space invite you to our web party and legal fundraiser at 11 East 4th Street 2F Buzzer #1 New York, NY 10003 Friday, 5-9-97, 7pm (EDT) till... register a name in name.space create a virtual home page bring images to scan if you're not live in NYC you can still see the event on our webcam and register from wherever you are! check out the party at http://namespace.party.cam switch your PC or Mac to name.space with one click http://ns.autono.net./ns./download.html see.you.in.name.space Paul Garrin http://name.space http://namespace.xs2.net apologies if you got this twice or if you do not support the freeing of the internet. for more information on the Anti-Trust action pgMedia, Inc. d/b/a/ name.space vs. Network Solutions, Inc. please go to http://namespace.xs2.net/ns./legal.html

1 0

Business needs over citizen rights
by Tim May 17 Dec '03

17 Dec '03

It's interesting that in the various recent developments over crypto, the needs of business are taking priority over the basic rights of citizens. In fact, the debate is being driven by issues of "competitiveness." * In the latest round of crypto export policy, relayed to us by Will Rodger of "Interactive Week," it is relaxation of export for financial and banking software that is being pushed. (Possibly connected to the next item, though.) * Meanwhile, the Administration's "Crypto Import Restrictions" (officially entitled "The Safe Streets, Child Protection, and Public Safety Act") are about to be introduced, as reported to us by Brock Meeks (on this list by Bill Stewart). It is possible that this is also related to corporate interests, as this would stop certain offshore developers--unhindered by U.S. laws--from competing in the U.S. against U.S. companies (this is mere speculation on my part, but it may be part of the big picture). * And SAFE has special provisions for financial cryptography (read: Banking interests), while also putting the screws to any citizen-units who step out of bounds with crypto. ...and so on. What these trends add up to is an almost complete disregard for basic, fundamental issues of civil liberties and freedom in favor of various craftings of laws to advantage some American companies, disadvantage other American companies, and manipulate the international competitive scene. This is what politics has always been, of course. Pork barrels and pigs at the trough, to mix some porcine metaphors. It shows how far we have degenerated as a nation. Exactly which parts of the First, Second, etc. Amendments do these porkers not understand? May they all be vaporized. --Tim May There's something wrong when I'm a felon under an increasing number of laws. ---------:---------:---------:---------:---------:---------:---------:---- Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay(a)got.net 408-728-0152 | anonymous networks, digital pseudonyms, zero W.A.S.T.E.: Corralitos, CA | knowledge, reputations, information markets, Higher Power: 2^1398269 | black markets, collapse of governments. "National borders aren't even speed bumps on the information superhighway."

2 1

Re: Since when is supporting unrestricted crypto unreasonable?
by lucifer＠dhp.com 17 Dec '03

17 Dec '03

At 10:46 PM 5/6/97 -0500, Omegaman wrote: >I'm starting to think that until someone actually gets arrested and >jailed for using strong, unbreakable encryption that is "suspected" of >supporting a crime, little will change. In the meantime, the >administration, Congress, and the TLA's will keep getting closer to >achieving their goals. Ahh, but the government is far too clever to haul up Phil Cypherpunk and charge him with "Encryption with intent to hide". Instead, they'll wait until they get a Tim McVeigh-esque case, show that he "conspired" using encryption, and say "See how tough on crime we are? We must convict and fry this evil militia member. And give him an extra 230 volts for using encryption, according to the SAFE law." There isn't an American politician alive who would dare publically ask to have a McVeigh-level-case's sentence reduced or any stupid charges dropped. "Sorry, I can't appear soft on this kind of criminal!" Then, there is *legal precedent* for all kinds of criminals to get the extra 5 years (or 230 volts). Then, when they DO come around and pound down the doors of Jim Cypherpunk for having evil thoughts about FBI agents and find an encrypted copy of Penthouse; well, hey, that law's been tested on the books before. Lock him up. When charges are brought up against a suspect, the suspect is truly spammed with all manner of accusations. It's how the legal game is played. Find someone you want to lock up, then throw enough turds and some will eventually stick. Tim May's new signature nicely reflects this. Therefore, citizens won't ever "win" if ProCODE or SAFE or whatever is enacted. It'll just be another turd thrown at suspects.

1 0

Re: Banking Secrecy and Nazi Gold
by Tim May 17 Dec '03

17 Dec '03

Someone sent me private mail about my post, and suggested that Swiss bankers have historically had close ties to the Swiss government, e.g, most are reserve officers in the Swiss military. He also suggested that Switzerland is more of a police state than many realize. Here is my reply: I don't argue otherwise. Likewise, Monaco is a video surveillance state, with hundreds of cameras scattered in hidden locations throughout that tiny place. Neither are places I'd want to live. But the deposits of the 1930s-40s are ancient history. As I said, I see the current foofaw as being political. (Just as the Kurt Waldheim thing was political, in that Israel, the U.S., and many other states knew of Waldheim's war record and chose to exploit the knowledge rather than reveal it.) If the U.S. forces the illegal gains to be "given back," mightn't the fortune Joe Kennedy amasses as a rum runner be seized? The Kennedy clan made its considerable fortune through outlaw activities, even to the (probable) point of buying the '60 election (Illinois, as I'm sure you know). (Not suggesting rum running = extermination of Jews. Far from it. But the notion of going back to events of 50-60 years ago, when ignored in the intervening decades, must always be scrutinized for real intentions.) Lastly, I really wish you'd make more of your comments in a public way, so that my responses can be public. --Tim There's something wrong when I'm a felon under an increasing number of laws. ---------:---------:---------:---------:---------:---------:---------:---- Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay(a)got.net 408-728-0152 | anonymous networks, digital pseudonyms, zero W.A.S.T.E.: Corralitos, CA | knowledge, reputations, information markets, Higher Power: 2^1398269 | black markets, collapse of governments. "National borders aren't even speed bumps on the information superhighway."

1 0

Re: (fwd) Cell Phone Cancer Study
by John Young 17 Dec '03

17 Dec '03

As follow up to the Stewart Fist report on new findings of cell-phone hazards, the Jerusalem Post says that the report is causing alarm in Israel -- where cell-phones are heavily used -- and that the government intends to investigate. Motorola et al are hunkered. The scientific study is in the journal "Radiation Research," Volume 147, Number 5, May 1997: http://www.cjp.com/radres/html/may97toc.htm Michael H. Repacholi, Antony Basten, Val Gebski, Denise Noonan, John Finnie and Alan W. Harris "Lymphomas in Emu-Pim1 Transgenic Mice Exposed to Pulsed 900 MHz Electromagnetic Fields" (p. 631) However, there is not an on-line version, unless someone knows of it elsewhere. What say the cellular folks here to this story?

2 1

Re: (fwd) Cell Phone Cancer Study
by John Young 17 Dec '03

17 Dec '03

Thanks for critiquing this sensitive topic. The 11-page paper was published by Radiation Research, as noted here, whose editor is at Oak Ridge National Lab, if that offers credibility. Radiation Research's Web site shows an impressive range of credentials of scientists in the field, perhaps superior, if more specialized, to that of Science and Nature, both which oft times suffers the chancres of promiscuous sci-populuxitis. Best is to see the report for oneself. A copy is available for US$30.00 by fax. Request by calling the publisher at (423) 574-5874. Or E-mail to: Radiation Research Biology Division Oak Ridge National Laboratory <radres(a)aol.com> We've had a layman's look and cite the authors' final cautionary paragraph: "This is not to imply that any humans at all are necessarily at increased risk of cancer as a consequence of exposure to RF fields. No single experiment on animals can allow such a conclusion. Rather, we believe the study reported here indicates a need for further research. Tumorigenesis in genetically predisposed mice may provide a useful assay for interactions between RF fields and biological systems. With the current rapid expansion in the use of RF fields for telecommunications, a reliable assay is required to enable a better assessment of limits to safe levels of human exposure." Send more money or die, sucker, the "responsible" scientist's clanging alarm, eh?

1 0

Re: Controversial Commercial ISP for Remailer?
by Dave Hayes 17 Dec '03

17 Dec '03

> Dave Hayes wrote: > > Igor Chudov writes: > > > I am interested in your view, Dave. > > > > There are only two reasons that I can see your interest serving. > > You either wish to support my views or oppose them. Neither case > > serves your potential enlightement, therefore I shall choose to > > not answer. > Dave, you are a very insightful man, but in this case you were > mistaken: I am interested to hear your views for my enlightenment. I responded that way for a reason. I offered my view on spamming spammers. You replaced "spamming spammers" with "hacking spammers". I do not see the relevance, hence my answer. ------ Dave Hayes - Altadena CA, USA - dave(a)jetcafe.org Freedom Knight of Usenet - http://www.jetcafe.org/~dave/usenet Who are the learned? Those who put into practice what they know.

1 0

(fwd) Elctronic Funds Transfer Expansion Act
by Damaged Justice 17 Dec '03

17 Dec '03

>From Post Office Credit Union' _Credit Union Post_, Spring 1997: Congress recently passed a law making it mandatory to receive government payments by direct deposit to a financial institution. It's called "Electronic Funds Transfer Expansion Act," and it requires all federal payments, except an IRS refund check to be issued by electronic funds transfer (Direct Deposit). It will affect anyone who receives veteran's benefits, Social Security, federal government and military pensions and salaries, or any government payment. Members who have their payments sent to Post Office Credit Union will have _immediate access_ to their money. So what are you waiting for? If you don't already have direct deposit, consider signing up for it. It's not only easy, convenient, and safe, it will soon be mandatory for all! Give us a call at 244-3518 to take advantage of direct deposit today! -- [The] "Electronic Funds Transfer Expansion Act".. requires all federal payments except an IRS refund check to be issued by electronic funds transfer. So what are you waiting for? If you don't already have direct deposit, consider signing up for it. It's not only easy, convenient, and safe, it will soon be mandatory for all! [Post Office Credit Union' Credit Union Post_, Spring 1997]

2 1

Re: Controversial Commercial ISP for Remailer?
by Dave Hayes 17 Dec '03

17 Dec '03

Ray Arachalian writes: > On Tue, 6 May 1997, Dave Hayes wrote: > > Igor Chudov writes: > > > I am interested in your view, Dave. > > There are only two reasons that I can see your interest serving. > > You either wish to support my views or oppose them. Neither case > > serves your potential enlightement, therefore I shall choose to > > not answer. > A very Zen answer (and quite a slippery one at that.) Thank you. > What if Igor was simply curious as to your views? Curiosity does not generally have zero attachment to other goals. If it did in this case, the information is not useful. > If not what difference does it make whether he supports or opposes > your view? Moo. > Why do you care whether or not a person is enlightened by your > response? I don't. > If you truly are following Zen, then it is not for you to decide > what will or won't enlighten others since this would mean taking > responsability for another person's karma. I neither follow nor lead Zen, but it is interesting to note your conjugation of "truth" and it's implications. > IMHO, your response isn't one of potentially enlightening others, but rather > fear of sharing your opinion. Since it is clear you cannot understand the former, the latter is all that is open to you to understand. Perhaps that is good enough, for your purposes. > This is two fold. If you fear he will oppose it, you are seeking > the approval of others. If you fear he will agree to it, you fear > that those who oppose his views will oppose yours. There are many more folds that you have overlooked. I may desire him to oppose it, thus seeking negative approval. I may desire him to agree to it, thus seeking positive approval. I may desire him to neither agree nor oppose it, thus seeking his enlightenment by my words, which is really seeking positive approval. I may fear he will neither agree nor oppose it, thus seeking his lack of enlightenment by my words, which is really seeking negative approval. > You could take the hidden third option and claim privacy, however it > is too late to do so since you have already shared some commentary - > and thus this path is closed to you. No path is closed to me, except by my choice. > Your responses so far were to the ethical and moral standards of spamming the > spammers. I wasn't interested in such. I am comfortable with my own morals > and take responsability for my actions. However, the point of this paragraph > is that you have tried to share with us your morals, and thus thrust them > upon us, later, here, you say you lack the will to share your views with us, > and thus back out of passing judgement on our hypothetical actions. > And at this point I am no longer interested in your oppinion on this > matter for it is jaded by fear, so please, don't even bother to reply. :) Notice the way you respond to my sharing: You pass judgement on my views, thus preventing your own enlightenment. Then you say you lack the will to be interested in my response, thus becoming guilty of what you claim I am guilty of. This was truly a mirrored interchange. I thank you for the opportunity to witness my self in you. ;-) ------ Dave Hayes - Altadena CA, USA - dave(a)jetcafe.org Freedom Knight of Usenet - http://www.jetcafe.org/~dave/usenet A passerby caught Nasrudin prying open the window of his own bedroom from the outside in the depths of night. "What are you doing? Locked out?" "Hush!" came the reply. "They say I walk in my sleep. I am trying to surprise myself and find out."

2 1

GAK Spreads, FRB Smirks
by John Young 17 Dec '03

17 Dec '03

A news report today that 22 new members have joined the Key Recovery Alliance, now 61 total. A meeting in Toronto on April 24-25 reviewed committee reports on key recovery prospects for "facilitating the wordlwide use of strong cryptography." And, two Federal Reserve economists claim that smart cards and E-cash have a ways to go to compete with well-tested and trusted paper bucks. No, they smirk, these views do not protect the FRB's central bank hegemony. Both reports at: http://jya.com/krafrb.txt

1 0

No Subject
by Secret Squirrel 17 Dec '03

17 Dec '03

Date: Wed, 7 May 1997 From: Graham-John Bullers <real(a)freenet.edmonton.ab.ca> To: lucifer Anonymous Remailer <lucifer(a)dhp.com> Cc: cypherpunks(a)toad.com Subject: Re: PGP I think Vulis needs each of us to send ten copies of this back to him. On Tue, 6 May 1997, lucifer Anonymous Remailer wrote: > Tim C[retin] Mayflower styles his facial hair to look more > like Graham-John Bullers. > > ,,, > -ooO(o o)Ooo- Tim C[retin] Mayflower > (_) > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Graham-John Bullers Modulator of alt.2600.modulated ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ email : real(a)freenet.edmonton.ab.ca : ab756(a)freenet.toronto.on.ca ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ http://www.freenet.edmonton.ab.ca/~real/index.html ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

3 2

Re: [NTSEC] 64-bit En/Decryption speed (fwd)
by Ray Arachelian 17 Dec '03

17 Dec '03

---------- Forwarded message ---------- Date: Wed, 7 May 1997 14:17:55 -0400 From: Craig Nulan <Craig.Nulan(a)ccmail.irs.gov> To: Bill Stout <stoutb(a)pios.com>, ntsecurity(a)iss.net Subject: Re: [NTSEC] 64-bit En/Decryption speed 577 Mghz No hardware abstraction layer The native platform on which NT was developed No need to validate beyond this. 10 times or faster. The DEC marketing rhetoric re: Alphas, is fairly reliable, unlike Microsoft's representations re: NT security. Has anyone else on this list examined the apparent demise of TCSEC product evaluations? Anyone else questioned why MS failed to keep NT in the RAMP process subsequent to getting version 3.5 C2 certified in a workstation configuration? Does it strike anyone else as odd that the U.K.'s ITSEC product evaluations are vendor sponsored, vendor scheduled, and conducted in private test environments? Does anyone believe that NT can ever be restructured into a general purpose operating system? A secure, general purpose O/S? Two URL's you'll want to remember. csrc.nist.gov - here you'll want to look at the the `94 and `95 annual reports (and meeting minutes) of the Computer Security and Privacy Advisory Board www.ecma.ch - where you can read first hand how security evaluation criteria are evolving Could it be that it's time to consider NT security from the perspective of the forest rather than from the perspective of endless little leaves on endless expanses of trees?

1 0

Igor's Diabolical Mind
by nobody＠huge.cajones.com 17 Dec '03

17 Dec '03

Igor Chudov @ home wrote: > some of the best hacks that I heard was to install a trojan > instead of, say, cat, that would randomly change one byte in > a randomly chosen file. Igor, I am currently monitoring a friend's system in order to analyze the source and methodologies of various attacks on it and I spend my spare time reading his email, databases, private diaries, etc. (I am blessed with breasts which allow me to set a man's car on fire and know he will just smile, and say, "That's OK, I'll get another one.") His comments regarding "Igor" imply that you have a diabolical mind and a good nose for nasty business. I can tell from your comments above that he judged you fairly well. Most hackers tend to be one-time Charlie's who pop into a low security system to mark their territory by pissing on a directory tree, so to speak, or adding their own personal form of graffiti and then returning home to pat themselves on the back for their great genius. In many cases the admin of a good system will have everything back to normal before the hacker has finished congratulating himself. The system intruder I am currently dealing with has a long history of success in his nefarious activities and one of the main reasons for this is his patience and his subtlety. Once he gains entry to a system he generally sets up an obscure back door for himself, pulls a directory tree, finds out the backup schedule, and then exits. He then lays out a plan of attack which is geared toward allowing him to roam the system at will without being observed. Usually, he will start by replacing such things as the system 'ps' command with one that keeps certain processes hidden from the prying eyes of sysadmins. He also substitutes his own programs for system files which are rarely installed and/or used. He is one of a rare breed of pure hackers whose main focus is system penetration and information access, with control issues being secondary. This requires a level of patience that allows him to observe the system for months, if necessary, before moving to secure his long-term ability to penetrate the system and roam at will. Once an intruder has his handiwork on the previous few months of system backups, then you might say that he has become a "tenured" member of your organization. I have had previous experience with the individual involved in the compromise of my friend's system (and ISP) and I am well aware of the fact that much of his power comes from the fact that he tends not to interfere with the functioning of one's system unless he is attacked. (In which case he generally fires a shot over the sysadmin's bow, indicating that the choices are "peaceful coexistence" or "explaining to management that their system is 'toast' because you chose to cop an attitude.") The only way, to my knowledge, that anyone has ever forced his exit from a system he has penetrated has been by ferreting out enough of the substructure of his intrusion that he fears his latest methodologies being discovered and exposed to scrutiny. {In which case he quietly packs up and leaves. {In my case, he sent me flowers, as well.}) On rare occasions he will intervene to fix system problems that are beyond the resident sysadmin, perhaps because the problems are affecting his own activities. When macro capabilities were added to spreadsheet programs, he had a trojan written for them before the shrink-wrap on the new release hit the floor. (He recognized macros as a close cousin to the Unix daemons, which he considers God's gift to pure hackers.) He was lurking on my friend's system in Austin, at the time, and he dropped my friend a polite note that advised him it would be unwise to mess with the files until the hacker had debugged them sufficiently that they would not cause inadvertant problems. His current work-in-progress is a Trojan which is frightening in its scope if it turns out to operate in the manner that I and others now suspect. It may represent a quantum leap in Trojan Horse technology (kind of an Equestrian Trojan Horse). {Its existence was "discovered" by a cypherpunk, by the way.} While I am not at liberty to reveal the as yet sketchy details of how the Trojan operates, I can give you a small glimpse into the the mind of its creator by providing an example of another Trojan that was previously discovered with his signature on it. The Trojan works through a word processor's spell checking and automatic correction system. Nonsensical character sequences are added to the spell checker, in the form of 'xytrz-->delete', 'xribpt-->format', etc. A .doc file is placed on the system which, when spell-corrected, will then become "format c:" or whatever its creator desires. A variety of triggers were discovered for the Trojan, and they encompassed a variety of approaches. (The triggers were indicative of a benign series of probing experiments designed to lead to a finished product versatile enough to bypass any attempt to guard against the Trojan's execution.) A simple trigger would run a .bat file which loaded the file into the word processor, auto-corrected the spelling, saved the file as a .exe file of the creator's choosing, then exited. More complicated triggers involved such things as (in Win 95) giving the file a unique extension (such as .xyz), using the "open with" option to point to a hidden copy of a word processor executable which has no macro-virus protection, etc., and which will run the macros in place in the file when it is opened. (A variation on this trigger takes advantage of the fact that many systems keep outdated versions of word processing software on the system in order to be able to work with older files {which often turn to crap when loaded into the latest-greatest version, despite manufacturer's claims of compatability}. Users and admins generally don't stop to realize that the "protection" they install is often applied only to the newest version of their software.) As you pointed out, Igor, the more subtle a program's operation and effects, the longer it can work undiscovered and the greater the range of the time/space continuim it can encompass. Virus/Trojan checkers generally guard only against system damage and/or loss of data. It is infinitely more difficult to guard against a system intruder who has other goals in mind and has the patience to remain unobtrusive. Even most security conscious system administrators don't take much note of minor glitches as long as they appear to be benign problems inherent in the implementation of the software. The Trojan that I and others are currently working with was only perceived as a potential problem after the person who discovered it had spent months cursing the software manufacturer for not including an obviously needed capability in the product. It was a very minor but frustrating problem, leading the user to make inquiries as to how to "work around" the product's lack of providing this function. Upon discovery that the product was supposed to provide the function, his research quickly indicated that there was a "fly in the ointment." Most users probably would have just shrugged and lived with the problem, since it was relatively minor. Instead, he brought the small anomalie he discovered to the attention of myself and others and it has opened up a Pandora's box that appears to have the potential for a new breed of Trojan Horses. > basically, install lots of backdoors and then play with their minds. Actually, Igor, I'm beginning to wonder if perhaps you are the hacker I've been trying to ferret out? I think I'll keep an eye on you. > some ppl would steal CC# of their customers and publish them, but I would > not do it. The hacker I've been discussing has infiltrated a variety of Pac Bell sites, and the like, over the years. A regional administrator, upon being informed of the presence of an intruder on the system, immediately called in a team of Bay Area security consultants to deal with the problem. By the time they arrived the hacker had sent a small mountain of email to various management personnel which contained precious company secrets and had Pac Bell's competition listed as a cc: (in the body of the message, as a warning). When the group from Berkeley arrived they consulted with the admin about the potential seriousness of the veiled threat, did a quick check of the system, realized who the hacker was that they were dealing with, shrugged, and said, "He's on our system too. We'd advise just leaving him alone." When the administrator questioned the wisdom of their suggestion the consultants advised him that they would be more than happy to proceed as long as the overuling of their opinion was put in writing. The admin agreed, whereupon he was presented with the consultants' standard "reality check" authorization form, whose letterhead reads: AUTHORIZATION TO PROCEED CONTRARY TO ADVISED COURSE OF PROCEDURE "Last One Seen Fixing It Gets The Blame" The administrator decided in favor of job-security, and the security consultants were paid generously to provide a generic report for his superiors which indicated that the admin's prompt action resulted in the problem coming to a quick resolution. Personally, I've seen more than a few sysadmins who declare war on a minor hacker instead of just fixing the problem so that it won't occur again and moving on. (Much like some of the hilarious posts in the cypherpunks archives in which a list member responds to a Vulis post by saying, "Just ignore him and he'll go away." and then proceed to take two or three pot-shots at him.) (.)(.)Monger

3 2