December 2003 - cypherpunks-legacy

On-Line Security Eyed For Florida St. ID Tool
by se7en 17 Dec '03

17 Dec '03

V-One Corp. said it will be supplying a key security component to the smart card identification and transaction system that Florida State University is developing. When the system, SmartWorld, is deployed later this year, students will gain access through the Internet to a host of applications touching on many aspects of campus life. Electronic financial transactions over the network will be secured through mutial authentication and encryption aided by the smart card. V-One said it will provide its SmartGate "middleware," which allows virtually any application to run securely on public networks like the Internet. The agreement also provides for cross-training between V-One and Florida State personnel, and V-One technology will be incorporated in demonstrations that Florida State's Card Application Technology Center makes in marketing its system to other universities and colleges, government agencies, and other organizations. se7en

1 0

Re: Digital Cash application
by jim bell 17 Dec '03

17 Dec '03

At 02:20 PM 6/19/96 -0500, Declan McCullagh wrote: >Whether it's a good idea or not - Don't bury your head in the sand too early. >- and I'm told that it could violate FEC >rules - _ANYTHING_ could "violate FEC rules." The issue is, "could this be done in a way that would NOT violate any such rules. Or, more generally, could this be done in a way that would challenge or even obliterate FEC rules. If you ask a lawyer for the course of action to take that will, guaranteed, not raise any eyebrows, he'll give you one speech. If, on the other, you ask him if a tactic violates black-letter law, for certain, he'll give you another. >- it's not going to happen. >A campaign spokesperson told me that "Harry refuses" to take the cash, period. (How certain are you that they understand the ramifications of this?) This year, maybe not. However that doesn't mean that there shouldn't be a debate on the subject. Technology may allow a rip-roaring debate among the public, not just the Libertarian Party, and e-cash may implement this stolen-property return in a way designed to cause the most consternation and embarrassment among those in power. Remember, if it has been decided, a year ago, that doing this was "okay", chances are good that Harry Browne WOULD be willing to do so now. Trying to ignore the issue won't make it go away. Jim Bell jimbell(a)pacifier.com

1 0

Re:Oil Change software snoops through hard drive
by mccoy＠communities.com 17 Dec '03

17 Dec '03

Declan writes: > Alan forwarded this to me. Thought it might be interesting. -Declan [...auto updating software...] > Unanswered Qs: [...intersting questions which are raised by such a service...] I saw no mention of authentication between the Oil Change client and server, so the first question that I had was "how do you know if you are actually connecting to the legitimate Oil Change server?" Since the updates are via dialup a few bridge clips in the right location would be all it takes to have the call re-routed to someone else's server (and if the update is done over the net hijacking the system is not much harder...) Once you have people getting your server instead of the Oil Change server you _own_ their machine. You can install whatever trojan horses or backdoors you want under the guise of an update or direct the user to pull a hacked update from a server you designate (and it wouldly not be hard to set up a dummy software package so that even if you later lose your override of the system or remove it to cover your tracks the system continues to keep your backdoors installed.) This is some very bad mojo. A little social engineering or midnight wiring and there will be a lot of people in a world of pain. Nothing like designing a system which takes your weak spot and makes it a security problem for every one of your customers... jim

1 0

No Subject
by mixmaster＠remail.obscura.com 17 Dec '03

17 Dec '03

FYI: "Cash Crunch" _Wall Street Journal_ by Neal Templin 6/17/96 "Companies are coming up with ways to deal with one of the biggest obstacles to on-line purchases: how to pay for what you buy"

1 0

-lucre 0.8.1: ecash library for Unix available (with source, no blinding)
by lucre＠alpha.c2.org 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- We are pleased to announce the 0.8.1 ALPHA release of -lucre, a C library which implements the protocols of ecash(tm). This library was developed for research purposes, so source is available, but to avoid patent issues, blinding of coins is not currently supported. Please read the README (appended below) for more detailed information. You can currently get -lucre by anonymous ftp to csclub.uwaterloo.ca, in the directory /pub/-lucre. If you need to reach us, the development team for -lucre, you can try <lucre(a)alpha.c2.org>. Our public key is in the README, below. There is also a mailing list set up for discussing the library. To subscribe, send email to <majordomo(a)c2.org> with a message (_not subject_) of "subscribe dev-lucre". We are providing this library so that people can study how ecash works, and possibly come up with innovative ways of incorporating ecash into existing systems. Paying for remailers, for example, is a topic that seems to come up again and again on some mailing lists. Hopefully, it will also encourage more people to open an account with Mark Twain Bank; the more people who are using ecash, and the more shops that accept ecash, the better the system will be. We believe in open systems, not "security through obscurity", or the "trust me" model of security, and so we saw a full-source release to be important. The distribution comes with the library itself, as well as a very simple ecash client. The client should be usable to accept or pay ecash (or, if you discover it doesn't fit your needs, you can change it yourself), but, of course, you don't get the anonymity offered by the patented blinding feature of ecash. The README is attached below; please read it, as it contains more useful information about the use of this library. - -lucre version 0.8.1 README - --------------------------- This is version 0.8.1 of -lucre (We pronounce it ``dash lucre''; you can pronounce it however you like), the Unofficial Cypherpunks Release of Ecash (or ``Coderpunks'', if you want). As the ``-l'' indicates, this is a C library that implements the protocols of DigiCash's ecash (version 1.8.5, the kind used by Mark Twain Bank, not EUnet). This is an ALPHA release. That is, future release may not even adhere to the same API. This library was developed for, and is provided for, research purposes; adjust your expectations of support accordingly. As far as we know, - -lucre will only work on Unix-style machines; it is unlikely that we will release a Windows or Mac version. - -lucre provides all of the basic things you would like (payment requests, payments, deposits, withdrawals, opening accounts). The format of the wallet is somewhat different from that of DigiCash's standard client, so it would probably be tough to use both that and -lucre with the same MT bank account (maybe not, though; we haven't tried). Most of the information used to produce this program came from information published on the Web, Usenet, and various mailing lists, and from analysis of the output of a logging packet forwarder. The rest was obtained from talking to various people, and from simple experimentation. Because these are not ``official'' sources, some things may be incorrect. Use at your own risk; there is always the possibility, when using ecash, that your money will vanish into the bowels of the network. To use this code, you will need the SSLeay package, which you can get from ftp://ftp.psy.uq.oz.au/pub/Crypto/SSL/SSLeay-0.5.2a.tar.gz, and the Berkeley db package, which you can get from ftp://ftp.cs.berkeley.edu/pub/4bsd/db.1.85.tar.gz. Note especially that the use of SSLeay is subject to restrictions in some countries, including the US. Also, as distributed, this package does _not_ do blinding of withdrawn coins, as that process is patented by Dr. David Chaum. If you manage to license the patent, or if you fall under the ``Experimental Use Exception'' (in the US, and possibly other places), it's up to you to add in the blinding code yourself. In any case, and especially if you plan to use ecash for commercial purposes, we would recommend that you contact competent legal counsel. Note that DigiCash publishes an ``official'' library for ecash, though (at time of writing) it is much higher-level, and without source available. If that library would suit your needs, you are probably better off using it instead of -lucre. This library is _not_ in the public domain. Currently, you may not modify it, redistribute it, or distribute any program linked to it (dynamically or staticly), without our explicit permission (signed by the public key below). This restriction is a reflection of the ALPHA version of the library; it is likely that future versions will have more lenient licensing agreements. Some things we would like to put in future versions: o Resending aborted withdrawals: the code to do this is in there, but the bank seems to think the repeated withdrawal message is a new withdrawal [We lost $0.23 learning this... :-( ]. We'll look into this further. o An interface into resending and cancelling payments: all of the right info is currently being stored in the databases; only convenient functions to actually do the work are needed. o Make the function names more parallel: currently, some are like ``wallet_open'' and some are like ``free_msg'' (we're talking about verb-object order, here). This isn't a big deal, especially if you have lucre.h in front of you. o Put in better differentiation of error conditions, and more logging. o More complete client-to-client communications. Right now it is limited to payment requests and payments. We are, of course, open to suggestions [and ecash donations! :-) ]. You can reach us, the development team for -lucre, at either of the addresses below (in fact, use both, as the nym servers seem to be flaky). Better yet, there is a mailing list to discuss the library; send mail to majordomo(a)c2.org with body "subscribe dev-lucre" to subscribe. Type bits/keyID Date User ID pub 1024/E9E2AC75 1996/06/13 Development team for -lucre <lucre(a)alpha.c2.org> Key fingerprint = 63 94 0D F7 D9 6F 2D E5 08 0F EE 19 CB 6B A9 17 sig E9E2AC75 Development team for -lucre <lucre(a)alpha.c2.org> Development team for -lucre <lucre(a)nym.jpunix.com> sig E9E2AC75 Development team for -lucre <lucre(a)alpha.c2.org> - -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.2 mQCNAzHANI0AAAEEANYAvtkmYoH/Mav1A8fuwm+ZsDD4t3NY7nYd6zBKkepLLHWd Ue1Wnyr3mFHcrQBbJshwOJOCCUvYwDHST1TOqssaK/vAVavvubD8kRam+SET04b/ 477krJbCycnbBJ5FSugR4kKKs3S3BkrFWIJaBVTSzsocp+eGrrpcpsjp4qx1AAUR tDBEZXZlbG9wbWVudCB0ZWFtIGZvciAtbHVjcmUgPGx1Y3JlQGFscGhhLmMyLm9y Zz6JAJUDBRAxwDTfulymyOnirHUBAeqmBACfy2V57n/kAWMaUT5cFjW/C9ErL9JD 2ej5xr2vXNsYqXVIGGAc1ZNWIRKdxIp5fs+eBwf6mPRcwHe62a50hp9nTmhNnNCr HLLr6g4KkIgNslYtIma+U7ojysAWrcU0Ng8dse8bheO6OiXPoBVI+stp9Uijl60f tTOCPEP9ldY34LQyRGV2ZWxvcG1lbnQgdGVhbSBmb3IgLWx1Y3JlIDxsdWNyZUBu eW0uanB1bml4LmNvbT6JAJUDBRAxxegrulymyOnirHUBAb+MBADErPAtQdo4X8UU 8uGrFsDvSIfzRVgaz+HarEB1PNW5gsEiw9xhHizT6cKM0L9F7BCJWye2jHDm8DSP a5GdQNEmg+siFOw7+97hELqOzJsOjTBrF+mZ5flEeGQJHKub1D5hRChIqI/bwa5A 6e8AKbLB+mfaO2hfXJtnlroUx9foTg== =GvP2 - -----END PGP PUBLIC KEY BLOCK----- -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMchcGbpcpsjp4qx1AQEVrQQArRPfJgQQq7rRgIl5mBoS5Ju2Hq4aR7u3 mV90yLTHpQq8mC59O2NCxtJzRqfnA9sASVWDZWFudwmzwj6V6f6Kwxb8i8PO4EZ0 28A+BBf+jtpDNG2bsTYxEbIxQM1eE+GuUjSatbW0sYW3J3df7YeYyQAVU/7b2dni +BLOnD4tqvw= =Jozg -----END PGP SIGNATURE-----

1 0

Re: Gov. archives - NSA (fwd)
by Black Unicorn 17 Dec '03

17 Dec '03

New ideas about where the "totally new russian crypto" proffered by "mailsafe" might come from: ---------- Forwarded message ---------- Date: Tue, 04 Jun 1996 12:13:22 -0500 From: Brian Durham <bdurham(a)metronet.com> To: cypherpunks(a)toad.com Subject: Re: Gov. archives - NSA http://www.nsa.gov:8080/ Interesting information about Soviet one-time pad ciphers and about crypto-related documents from the WW2 era that are being declassified.

1 0

Re: MasterCard Seeks Revision in On-Line Bill
by jim bell 17 Dec '03

17 Dec '03

This kind of testimony shows exactly why we (individual citizens) can't trust corporations to guard our interests in the crypto arena: At 12:25 PM 6/19/96 -0700, se7en wrote: >Joel Lisker, MasterCard International senior vice president for security >and risk management, testified in support of the "Promotion of Commerce >On-Line an the Digital Era Act" bill. > >But he urged that the legislation be amended to address security concerns >arising from the resale and reexportation of encryption technology. > [..] >But Mr. Lisker urged that the bill be amended to increase the penalties >for the rexportation and resale of this technology to questionable >buyers, including criminals. "Modernizing the federal regulatory approach >to encryption technology must be accomplished without weakening the >ability of law enforcement agencies to pursue criminal activity," he >testified. Look at this closely, and Mastercard's position, and you'll notice that Lisker has no obvious professional interest in encouraging the _increasing_ of penalities for the "reexportation and resale of this technology to questionable buyers, including criminals." (In a contest between Mastercard armed with good encryption, and criminals armed with similar tools, Mastercard will win, because winning simply involves keeping the crooks away from its money.) Lisker is also presumably smart enough to know that few people are going to go into an "Encryption Store" and say, "I'm a criminal! Could I buy your best encryption, please?" Yet, despite no obvious reason for Lisker's interest, he's pushing the "no crypto to bad guys" buttons, so he's obviously sucking up to the politicians in an area he has no reason to. It sounds to me like a deal is being struck, and I'm certain the public will be on the short end of that deal. Why can these thugs just accept the fact that crypto will get into the hands of people that governments don't want it to? Jim Bell jimbell(a)pacifier.com

1 0

Re: Current status of RSA patent...
by vin＠shore.net 17 Dec '03

17 Dec '03

"Paul S. Penrod" <furballs(a)netcom.com> suggested: >PGP 2.6.2i is not US codebase, and RSA is not patented outside the US >according to Bruce Schneiner. Therefore, if a product was deployed into >the US using a non-US codebase, it is unclear to me what legal >jurisdiction (if any) RSA may have in these circumstances. The relevant issue is not the code-base. Copyright "protects" the code. A patent is a proprietary claim on a design for a device, in this case RSA's PKC. A nation issues a patent as an acknowledgement and validation of a proprietary claim on a specific design, for a non-obvious device, for a limited period, enforcable within the boundries of its jurisdiction. Nice try. 2.6.X-ui doesn't use Rivest's RASREF cryptographic toolkit like the US version does, but it does impliment the patented RSA "device." You can bring it into the US, but if you try to sell it in the US and make money from the design --without giving RSA its due -- they're gonna get ya! RSA has no "legal jurisdiction," in the US or elsewhere. (Few companies do;-) But I can understand how, hanging around a Libertarian cabal like C'punks, you might forget that sovereignty rests in the State. Wishful thinking, lad. Suerte, _Vin Vin McLellan +The Privacy Guild+ <vin(a)shore.net> 53 Nichols St., Chelsea, Ma. 02150 USA Tel: (617) 884-5548 <*><*><*><*><*><*><*><*><*>

1 0

Re: Current status of RSA patent...
by Deranged Mutant 17 Dec '03

17 Dec '03

On 19 Jun 96 at 13:25, Paul S. Penrod wrote: > PGP 2.6.2i is not US codebase, and RSA is not patented outside the US > according to Bruce Schneiner. Therefore, if a product was deployed into Note that Bruce's expertise is in cryptography, not patent law. > the US using a non-US codebase, it is unclear to me what legal > jurisdiction (if any) RSA may have in these circumstances. It's a violation of RSA's patent wherever RSA is patented (in the US only, I believe). Doesn't matter who wrote the code, or where. Oh yeah: PGP 2.6ui or 2.6.3i is based on US versions. I believe they still use some of PRZ's code. And don't forget that IDEA is patented by Ascom Tech AG. Rob. --- No-frills sig. Befriend my mail filter by sending a message with the subject "send help" Key-ID: 5D3F2E99 1996/04/22 wlkngowl(a)unix.asb.com (root@magneto) AB1F4831 1993/05/10 Deranged Mutant <wlkngowl(a)unix.asb.com> Send a message with the subject "send pgp-key" for a copy of my key.

1 0

Re: Digital Cash application
by jim bell 17 Dec '03

17 Dec '03

At 10:53 PM 6/19/96 -0400, Declan B. McCullagh wrote: >Excerpts from internet.cypherpunks: 19-Jun-96 Re: Digital Cash >application by jim bell(a)pacifier.com >> It seems to me that since paying people funds that were stolen from them >> would produce good publicity, which by definition could be argued to be >> spending it on the campaign. Sure, it's a non-traditional tactic, but that >> doesn't mean it's in violation of the campaign law. They could also email >> along a set of libertarian literature, and the recipient would certify that >> he would promote the libertarian cause and work for the election of the >> candidate, etc, etc. > >Jim: I've worked on a presidential campaign before and can tell you that >if the FEC is likely to consider something a violation, the campaign is >not going to skirt the line. > >That said, perhaps the law is outdated and needs to be changed. The following two paragraphs were sent to me by a person familiar with Oregon Libertarian politics over the last 15 years: "Good idea. Something like this was done in the early '80's in Oregon. There was a $1 checkoff to the political party of one's choice on the Oregon income tax form, and the LPO was the recipient of a grand or so of money stolen from taxpayers. Gary Chipman came up with the idea of sending $1 bills to LPO members and registered Oregon libertarians with a fundraising letter touting us as the only party that would really give them their money back." "Interestingly, the mailing raised more in donations than it cost in stolen money and postage, and got us good press too. The legislature promptly abolished the checkoff during their next session." [end of quote] There may be a CLUE here: Laws and regulations tend to be written based on what the writer can imagine, and are updated based on what has happened. We can probably agree that "standard" (non-libertarian) politics would not have anticipated such an idea, and moreover you can also suppose that 20+ years of D's and R's politics would not have resulted in an example of such a tactic being used. Thus, there is no obvious reason to believe that this kind of tactic would have already been prohibited. We can agree that D's and R's won't like it, as is obvious from what the Oregon legislature did, but rather than merely presume that it is illegal, why not take the position that unless it is clearly outlawed, then it must be considered a legal tactic? It would be a valid goal to eliminate the system, as it apparently did in Oregon. Don't give up before the race. Jim Bell jimbell(a)pacifier.com

1 0