December 2003 - cypherpunks-legacy

Re: Safemail
by droelke＠rdxsunhost.aud.alcatel.com 18 Dec '03

18 Dec '03

> > > SafeMail uses a proprietary Russian algorithm. > > Maybe it is GOST. Schneir covers it, and there is a white paper on > it at the b_crypt site. > I spoke with a fellow there for about 20 minutes today about their program. Sounded like these guys are just front-ends and obviously know nothing about the technology. (Couldn't answer how many bits of the "22 character" key were in use) He did assure me it wasn't GOST, or anything published. Story was that a Russian emigrant (sp?) came over to the US and this is his algorithm. Apparently this person is not willing (at this time) to put the algorithm out for public review. I spent most of my time pushing for some sort of peer review. Supposedly they have talked with Schneier and Denning, about the method but neither has done more than talk with them briefly about the method. (I understood from what he said that they weren't willing to pay Bruce what it would take to do a through review. ;-) I also spent some time educating them about PGP and how it does do compression, ASCII armour, etc. All in all they guy was plesant enough, but no real details on how the system works. What I got was that they "private" key is what you type in. This is then hashed (he even used the word hash) into a 22 character public key that you share with your friends. Even at 8 bits/charcter, 176 bits doesn't sound secure for a public key algorithm, but then again this isn't RSA we are looking at. All in all it still sounds like snake oil to me! Dan ------------------------------------------------------------------ Dan Oelke Alcatel Network Systems droelke(a)aud.alcatel.com Richardson, TX

4 4

Dutch smartcard alert: De Waag, Amsterdam, 6/19 1900 hrs
by tbyfield＠panix.com 18 Dec '03

18 Dec '03

Any C'punks and/or interested parties who happen to be in Amsterdam might want to pay a visit to De Waag this Friday night, ~7pm: AFAIK, the Chipknip--the electronic cash system tested in Arnhem--is making its public debut in the restaurant/cafe "In De Waag." It looks like a bad standard, imo: smartcards storing x<fl50, PIN-card dependent ( -> True Name), transaction records kept (duration unknown) by the implementing company, Interpay. If you're interested in the standard ("VIC"?), get in touch with Interpay: they _have_ released the payment boxes (real cute: an LCD screen, a green "ja" button and a yellow "?" button), and I've seen a Rabobank wallet-reader. For now, the cards stay in De Waag. Full rollout should be about the end of this year. Ted

1 0

Current status of RSA patent...
by Paul S. Penrod 18 Dec '03

18 Dec '03

Can anyone provide additional information on the RSA patent status? If memory serves me, it is due to expire sometime in 1997. Also, what are the ramifications of deploying software based around it, such as PGP 2.62i (from UK)? ...Paul ------------------------------------------------------------------------- "Faced with the choice between changing one's mind and proving that there is no need to do so, almost everybody gets busy on the proof" -- John Kenneth Galbraith "Success is attending a funeral as a spectator" -- E. BonAnno -------------------------------------------------------------------------

5 6

Re: Federal key registration agency
by shamrock＠netcom.com 18 Dec '03

18 Dec '03

At 16:27 6/18/96, TM Peters wrote: >Speaking to the Commonwealth Club of California in San Francisco, Reno said >her plan would require people to register with the new agency the secret >codes -- or "keys" -- they use to encrypt messages online. The cat is out of the bag. Janet Reno is calling for mandatory Government Access to Keys. Not that her statement would surprise anyone on this list. Still, I believe the administration has never before publicly stated that people will be _required_ to deposit their encryption keys with the government. I wonder what the penalties for failure to comply with this requirement will be. [I have requested a transcript of Reno's speech from the Commonwealth Club. I will make the relevant parts available as soon as I get it]. -- Lucky Green <mailto:shamrock@netcom.com> PGP encrypted mail preferred. Disclaimer: My opinions are my own.

3 2

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

18 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 18 Dec '03

18 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 18 Dec '03

18 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 18 Dec '03

18 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 18 Dec '03

18 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 18 Dec '03

18 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