- cypherpunks-legacy - lists.cpunks.org

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: 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: 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

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

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

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

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

Apologies: mistakes on my statistics... Reality is *worse* than I believed or remembered!
by Jean-Francois Avon 17 Dec '03

17 Dec '03

----------- from CFD V2 #602 ---------------- >From a post by Jean Hogue <jean_hogue(a)sympatico.ca> (Wed, 23 Sep 1998 Subject: a few impressions on the rallye) [snip] - Quebec is waking up and joining in - the ban on "purse-sized" pepper spray -- that says it all. - 60 millions/year forever for gun control bureaucrats, 4 millions/year for 5 years for cancer research 38 women murdered with a firearm last lyear 3900 women died of breast cancer last year if this is not a feminist issue, what is ? - the 60 million/year maintenance cost is almost as high as the "total 7-year cost" of 85 millions promised for the entire program. by 2015, the total tab will be 1 billion dollars. - the gripping testimony of John St-Amour (Marstar) - the brutality of the search for mere _papers_ SWAT with the finger on the trigger of HK MP-5 weapoons and using the weapons to point where to go to - the systematic harrassment of the government pursuing a non- case demanding St-Amour plead guilty to some trivial charges as condition to stop this 3-year long harrassment - over $100,000 in legal fees - the role of Canada Customs, describing St-Amour as "violent" - the government has unlimited funds (taxpayers' money) and can outspend anyone and drag anyone through court forever - trumped-up charges of "unsafe storage" to justify the fiasco. - this can happen to _anyone_. C-68 allows searching for records, unsafe storage charges are routinely fabricated Spin doctoring from McLellan [minister of Justice] - talk of confiscation is paranoid - the registry will be cost-effective - used weeping mothers of Polytechnique killings as prop for C-68 [snip] --------- end of quote ---------------- Ciao jfa Definition: FASCISM: n.: a political and economic movement, strongly nationalistic, magnifying the rights of the state as opposed to those of the individual, in which industry, though remaining largely under private ownership, and all administrative political units, are controlled by a strong central government. ------------------------------------------------- "One of the ordinary modes by which tyrants accomplish their purpose, without resistance, is by disarming the people and making it an offense to keep arms". - Joseph Story, U.S. Supreme Court Justice. ------------------------------------------------- the German gun control laws were enacted by the "liberal" Weimar Republic government that preceded Hitler, and were a strong aid to his coming to power -- because they disarmed Hitler's opponents, and Hitler's adherents ignored them -- as criminals have always ignored gun control laws. Disarming the public is a frequent first step toward dictatorships and genocides. Once the disarming is complete, the public is helpless against those who have the guns. ------------------------------------------------- PGP keys: http://bs.mit.edu:8001/pks-toplev.html PGP ID:C58ADD0D:529645E8205A8A5E F87CC86FAEFEF891 PGP ID:5B51964D:152ACCBCD4A481B0 254011193237822C

1 0

Cypherpunk criminalization
by Michael Wilson 17 Dec '03

17 Dec '03

The occasion of Jim Bell's arrest provides an opportunity to consider a number of points: Are Federal Agents Evil? Why is there an attempt to persecute Jim Bell, one that has many similarities to the Olympic Park Bombing rush-to-judgment, Ruby Ridge, Waco, OK City, etc.? Are we to believe that government agents are 'evil,' or True Believers that _we_ (those who are _not_ true believers) are evil? I personally think not. I think we are seeing a phenomenon that is rather simple--government agents will tend to pursue cases that may get them recognition or promotion. People like Jim Bell pass some mobile threshold where their case is media 'hot' or sexy enough to make it worth pursuing--the Feds get a collar and media attention, a prosecutor gets similar benefits, judges are notoriously easy to inflame for the proper paperwork to be obtained, etc. Are the rest of the cypherpunks at risk? Looking at it with my game theorist hat on, I suspect not--while Tim May has been pushing the envelope recently, I don't think he's crossed any line would allow the appearance of a 'good bust,' nor has anyone else on the list (to my direct knowledge). I think we're witnessing a bit of the same mentality that literally did allow the operation of the Nazis--they're just doing their job, just following orders, just being part of their bureaucracy, with perhaps a few True Believers to leaven the mix. Technology vs. Public Relations/Propaganda Cypherpunks write code, we hear it often enough as the credo of the 'movement.' On the other hand, as valuable a social service as it actually has been, the war is being fought on other terms. Crypto has been characterized as 'offensive' technology, in two senses of the term--a regulated weapons technology, and a socially unacceptable act. This manifests in the 'what have you got to hide' mentality, coupled with the trotting out of the Four+ Horsemen. We're losing this part of the war, and the cutting of more code isn't going to help us one bit. We need to turn the public perception around. What we're seeing in this case is a rather rapid erosion of the legal principles of an expectation of privacy (I won't engage in the rather lengthy discussion of this, but I recommend the interested parties do take the time to read in a good law library, or hunt down the materials on the Bork nomination to the Supreme Court). We've become a society that is expected to publicly air our dirty laundry, to march onto a television talk-show and expose our faults, foibles, and felonies. We need to fight back in ways that communicate to Joe Sixpack, also known as the Common Man--we all have secrets, we all have things we don't want people to know. Build the database! Get the testimonials! Let me briefly mention some of the sorts of need for privacy, secrecy, anonymity that are socially acceptable, and which we need to use to reinforce our own message: --AIDS testing; --Illness diagnosis, such as cancer; --Financial information: credit card numbers, bank balances, net worth; --Dropping the dime on crime: mob witnesses, corporations, your noisy neighbor who abuses their kids but owns a shotgun; --Donations to needy causes, but not wanting everyone to have their hand out; --Personal habits: alcoholism, drug use, gambling addiction, sexual preferences; --Common law privileges: confessional, physician or attorney relation to their client. In short, we all have things we want to remain secret, and we certainly don't want them to be 'exposed,' or to fall into the wrong hands. We need to take the issue back from the criminalization of having secrets to a place where crypto is viewed as a defensive technology--we're entitled to it, and our privacy. Crypto vs. the Government This is the biggest area of contention. The cypherpunk case is that strong, unescrowed cryptography is essential--we have no reason to assume that government is our friend (pull out the file of long-term government abuses here, from using the IRS to pursue political targets to the mail-opening programs of the FBI/CIA), and more to the point, this isn't a 'local' issue that is categorized by a singular stance on the part of the U.S. government. The cryptosystems we build and promote are used in places where they protect human rights workers, economic security and competitiveness, privacy, etc. The Internet and the tools are global, so we're on a battlefield that also includes: -Europe, including the Former Soviet Republics and Bosnia, where strong crypto is critical for freedom-loving movements; -Asia, where users of strong crypto use it to prevent competitive intelligence or organized espionage programs from impacting on their business, in particular, from actions of those U.S. 'allies' Japan, Korea, China; -the Middle East, where strong crypto protects human rights workers, businesses, and individuals who have an un-Islamic taste for things like pornography, or news; see 'rogue' States like Iran, but also U.S. 'allies' like Saudi Arabia, Egypt, Israel, Kuwait, etc. And the global battle means that we have to set an example, allow access, and fight those efforts on our own turf (does anyone really think that Asian or European competitive intelligence or espionage efforts don't also take place on American soil?). The U.S. government has made good use of the insinuation that if we have things to hide, then in a free and open democracy, we must be actively engaged in criminal activity. Certainly, strong cryptography of many sorts is being used to protect criminal activity. It is also a principle upon which the American system is based that you don't deprive the rights and freedom of the majority, those who have not committed any crime, merely in an effort to pursue the felonious. This is why you still need a properly executed warrant to search an area which has an expectation of privacy (which _is_ being slowly eroded as a legal principle, which we need to point out as a trend). As Tim May likes to point out, there are an increasing number of laws that individuals can be pursued under, with ever more general levels of interpretation. Convictions make convicts. Bureaucracies tend to grow, seeking more power for themselves, until 'that which is not compulsory is illegal, and that which is not illegal is compulsory.' Students of history are well aware of what comes next in the cycle-- revolution. My only observation on this is that America has always been willing to speed through trend curves, and it looks like she is flooring the accelerator in this case--from growing State, to global Power, to dying Empire. Think of it like an organic system, and like any entity, it reacts poorly to what it rightly views as being a threat to its own survival--cypherpunks among many. Sign me: A Man With Many Secrets and Much to Hide Michael Wilson 5514706(a)mcimail.com

6 9

Re: encryption laws
by Steffen Zahn 17 Dec '03

17 Dec '03

On Thu, 15 Jul 1993, Allan Thompson wrote: > Would it be possible for a court to subpeona a encrypted file or key, > and order you to tell them the key ? > If you didn't would you be held in 'contempt of court' ? How about claiming that you used a OTP and then revealing the key? Or should I say a key? Regards Steffen -- home email: domain: berlin.snafu.de, user: zahn To send email to me combine user@domain above to construct my address. Use of my address for unsolicited commercial advertising is forbidden.

4 3