December 2003 - cypherpunks-legacy

Re: Why I think Jim Bell is getting railroaded
by Hal Finney 17 Dec '03

17 Dec '03

>From what I have read, the elements of the conspiracy offence are a plan to commit a crime involving multiple individuals, and at least one overt act taken in furtherance of the plan. For example, if people get together and plan a kidnapping, then one member goes out and buys some rope, that could be enough to represent conspiracy to commit kidnapping. You don't actually have to do the kidnapping to be convicted on conspiracy. If Bell got together with his friend and talked about disabling government computers with "carbon fibers" (whatever those are), and he then goes out and buys a source of carbon fibers, a case could be made that this would represent the crime of conspiracy. (We don't know yet whether either of these thing actually happened, of course.) Now his lawyer can argue that the conversation was purely hypothetical speculation of the type which technically minded people commonly engage in, and the carbon fiber source (if it exists) was acquired out of curiosity based on the discussion. Then it would be up to the jury to decide whether Bell's actions actually were part of a planned crime or not. In this context his writings and hostile relations with government agencies could conceivably be used against him, if his lawyer did try to argue that his conversations were just innocent speculation. Hal

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

RFC 2144 on CAST-128 Encryption Algorithms (fwd)
by cpunks＠algebra.com 17 Dec '03

17 Dec '03

plz do not use bcc igor ----- Forwarded message from Adam Shostack ----- >From cpunks(a)manifold.algebra.com Thu May 22 13:12:32 1997 From: Adam Shostack <adam(a)homeport.org> Message-Id: <199705221736.NAA17266(a)homeport.org> Subject: RFC 2144 on CAST-128 Encryption Algorithms (fwd) To: coderpunks(a)toad.com (The Coderpunks list) Date: Thu, 22 May 1997 13:36:16 -0400 (EDT) X-Mailer: ELM [version 2.4ME+ PL27 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-cypherpunks(a)toad.com Precedence: bulk I hadn't seen this mentioned. This is to coderpunks, bcc'd to cypherpunks & cryptography. Adam ------ A new Request for Comments is now available in online RFC libraries. RFC 2144: Title: The CAST-128 Encryption Algorithm Author: C. Adams Date: May 1997 Mailbox: cadams(a)entrust.com Pages: 15 Characters: 37532 Updates/Obsoletes: None URL: ftp://ds.internic.net/rfc/rfc2144.txt There is a need in the Internet community for an unencumbered encryption algorithm with a range of key sizes that can provide security for a variety of cryptographic applications and protocols. This document describes an existing algorithm that can be used to satisfy this requirement. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited. ----- End of forwarded message from Adam Shostack -----

3 4

News from the Front II
by news＠WEBSTER2.ffg.com 17 Dec '03

17 Dec '03

An update to our customers and friends on happenings at ----------------------------------------------------------------------- F O R E F R O N T - Taking the Chaos out of the 'Net http://www.ffg.com Newsletter 5/13/97 ----------------------------------------------------------------------- Contents: I. News from the 'Front II. Hot Tip III. Special Offer ----------------------------------------------------------------------- I. News from the 'Front WebSeeker 3.2 stops information overload! - http://www.ffg.com/seeker/ WebSeeker 3.2 should be your weapon of choice when faced with information overload. The latest version of WebSeeker is even faster than what C|Net already called "blazingly fast!" and you have more control over your search than ever before! Newsflash! Top Publishers Promote WebPrinter - http://www.ffg.com/press/printtheweb.html WebPrinter has become the de facto standard for printing from the Internet. Millions of Internet users will receive WebPrinter, ForeFront's leading Internet printing technology, by year-end. ForeFront begins marketing BMC Software's NetTune Pro - http://www.ffg.com/press/nettune.html Just when you thought they had it all, ForeFront Direct now offers another quality PC/Networking tool. ForeFront Reports First Quarter Earnings. Sales are up 51% over first quarter 1996 - http://www.ffg.com/press/Q1_97Release.html "The sky's the limit!" says Tron Black, Online Sales Director as sales continue to rise at ForeFront. ----------------------------------------------------------------------- II. Tip o' the Day Tired of Task Switching? If you are tired of switching from WebSeeker to your web browser and back, then your day of deliverance has arrived. WebSeeker 3.x detects whether you have Microsoft Internet Explorer installed and embeds Internet Explorer within WebSeeker if you do. To activate this embedded browser, click View/Abstract. Check out this screen shot! - http://www.ffg.com/seeker/images/browser.gif You'll never have to leave WebSeeker again If you don't have WebSeeker 3.2 then buy it now! - http://www.ffg.com/seeker/ If you have an earlier version of WebSeeker then upgrade now! - http://www.ffg.com/seeker/wsupgrade.html Netscape Users - You can use Netscape as your default browser and still take advantage of this feature with IE. Also new in 3.2: Highlight words in any application, hit the FindNow! icon in your tray and WebSeeker will start your search. ----------------------------------------------------------------------- III. Special Offer ForeFront would like to offer you, our V.I.P.'s, a chance to get ALL of our Web products (WebSeeker, WebWhacker, and WebPrinter) at a discount. Get the Web Bundle for only $89.50 for a limited time. - http://store.ffg.com/webbundle/ ----------------------------------------------------------------------- If you wish to unsubscribe from the ForeFront mailing list, please send mail to nonews(a)sldc.ffg.com or go to http://www.ffg.com/press/

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

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