December 2003 - cypherpunks-legacy

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