December 2003 - cypherpunks-legacy

Re: e$: Geodesic Securities Markets
by gtoal＠an-teallach.com 17 Dec '03

17 Dec '03

> Changes in ownership are reflected by offseting book entries. Ah, the > wonders of double-entry bookeeping. BTW, 1994 is the 500th anniversary of the invention of double entry bookkeeping (by a monk). Made capitalism possible. Ah yes, "Swedish Accounting Techniques" as my Economics lecturer used to call it :) G

1 0

Re: e$: Geodesic Securities Markets
by rah＠shipwright.com 17 Dec '03

17 Dec '03

Forgive me for *ever* doubting you... Perry Metzger says, >Actually, even in the case of securities largely settled by book >entry, DTC still holds physical certificates. That is not, however, >the point. I know It's Not the Point, but I got curious anyway ;-). After all, I haven't been near a brokerage cage in 10 years (NIDS was big stuff back then), and I thought maybe it's time to learn how the world really works these days... So I called DTC, the Depository Trust Corporation, on Water St. in Manhattan, the Mother of all Securities Clearinghouses. After about five transfers, I talked to a very nice lady in underwriting. She said they really *do* have bales of securities in a vault, and that they have a program called FAST, where securities are stored in banks also. However, she said that a growing number of securities are issued book entry only. Issues of up to $150 million can be issued on a *single* certificate. That certificate is held just like the other securities issues, in a vault. She said that like par value, physical delivery is becoming more and more obsolete. That makes sense. Once a certificate is put into the vault at DTC, it usually never leaves. It might as well not be there at all. Changes in ownership are reflected by offseting book entries. Ah, the wonders of double-entry bookeeping. Oddly enough, an e$ certification scheme reverses that paradigm. The book entries disapear, the certificates proliferate, and the clearinghouse becomes a referee, "blessing" the trade. Cheers, Bob ----------------- Robert Hettinga (rah(a)shipwright.com) "There is no difference between someone Shipwright Development Corporation who eats too little and sees Heaven and 44 Farquhar Street someone who drinks too much and sees Boston, MA 02331 USA snakes." -- Bertrand Russell (617) 323-7923

3 2

Re: Hardware generators
by Phil Karn 17 Dec '03

17 Dec '03

Is this trip really necessary? Seems to me you can get strong random numbers without having to build hardware from scratch. Just get a sound interface (widely available for both ISA and parallel interfaces) and run the noise from an FM receiver into the A/D converter. Hash the output with MD5 and you have some pretty strong random numbers. I wouldn't be surprised if with some 16-bit boards you could do away with the FM receiver and just sample the noise from the analog preamp and mixer stages. Many of those boards are rather noisy. It is always better to buy than to build when you can make effective use of some mass-market PC peripheral. Not only do you save a lot of time, but it'll be much easier for others to replicate too. Phil

1 0

Cellular Telephone Experimenter's Kit (2600 article)
by Michael Handler 17 Dec '03

17 Dec '03

[ Apologies about posting to the list, but my mail directory got scragged by Net Access admins, and I lost the list of people who wanted this. Interesting stuff regardless.] ----- BEGIN ARTICLE ----- >From _2600_ Magazine, Spring 1994 (Volume 11, Number 1), pp 20-21 ***** Product Review ***** Cellular Telephone Experimenters Kit $125, Available for OKI 900 Network Wizards PO Box 343 Menlo Park, CA 94026 Voice: (415) 326-2060 Fax: (415) 326-4672 Email: info(a)nw.com OKI Telecom (404) 955-9800 (800) 554-3112 Review by Mr. Upsetter Any technology that combines radio, telephones, and computers is sure to interest hackers. It's no wonder cellular telephony has received so much attention. Now exploring the system is a little easier for us. A company called Network Wizards has introduced an interface that allows control of an OKI 900 cellular telephone from a DOS PC via the RS-232 port. Their Cellular Telephone Experimenters Kit (CTEK) consists of an interface, four DOS executables for controlling the phone, and a C function library so you can write your own programs. Also included on disk are a user's manual, function library, and a short cellular tutorial. The interface itself is contained in a small black box with a DB25 connector on one end. A cable with a specialized plug for connecting to the OKI is on the other end. Inside is a PIC16C54 microcontroller which converts data from the OKI to standard RS-232 data. The interface also has a mini stereo jack for connecting a microphone and earphone. The DOS executables included with the CTEK allow you to perform numerous functions. The MENU.EXE program allows you to change any of the phone's five NAMs. (A NAM, or Number Assignment Module, consists of a telephone number, system ID, initial paging channel, access overload class, and group ID mark. This information, along with your ESN, identifies your phone in the cellular system.) This program also allows you to read, write, and edit the phone's 200 alphanumeric memories. The TEST.EXE program, allows you to manually control the transmit and audio functions of the phone. You can turn the transmitted on or off and set the channel, SAT, and transmit power. You can also set the volume, mute the transmit, or recieve audio as well as set the audio source to the earpiece, sounder, or external jack on the CTEK interface. The TEL.EXE program allows you to monitor the paging channel and displays all the forward control channel messages. It also allows you to place and receive a phone call while displaying the voice channel messages. The KEYCON.EXE program simply allows you to press keys on the OKI from the computer keyboard. The programs provided with the CTEK certainly expand on the functionality of the phone. But to do the really fun stuff, you need to write your own programs. Source code to TEL.EXE and KEYCON.EXE are provided to get your started with the CTEK function library. Although my C programming skills were a little rusty, I found it easy enough to write programs with the library. I wrote a cellular scanning program which had the following capabilities: * Scan for a paging channel and display the messages. If a voice channel is assigned, go to that channel and listen to the call. * Scan voice channels and listen to active channels. * Scan OMNICELL channels and listen to active channels. * While listening to a call, display the voice channel messages. * Automatically follow handoffs. * Decode DTMF, change the volume or audio source. * Automatically mute the audio and stop monitoring when the call is released. Other functions in the library allow you to send reverse channel messages, get the received signal strength, control transmitter and audio functions, and read the phone's memory. Overall the function library is quite versatile. I had several other ideas for programs, for instance: * Log all messages and call information for certain cellular phone numbers. You could log paging channel messages, calls placed and received, call durations, DMTF digits dialed, cell channels used, etc. * Create a "spectrum" display of the cellular band by scanning all channels and recording the signal strength. * With a map of cell cites in your area, physically track a phone as it moves from cell to cell. I had great fun exploring the cellular network while playing with the CTEK. But this kit isn't for everyone. To get the most out of CTEK, you need to write your own programs. The executables provided in the kit really don't use the phone to its highest potential. Also, the OKI 900 isn't the cheapest phone in the world. It goes for about $400 to $450 new, perhaps $300 used if you can find one. Still, you could put together a great cellular monitoring system comparable to the ones designed for law enforcement for a few hundred dollars as opposed to a few thousand dollars. The CTEK is best suited for monitoring the cellular network rather than as a tool for fraud. You cannot change the phone's ESN with the CTEK. In fact, the library function which lets you send reverse control messages won't even let you send a bogus ESN. Overall, the CTEK is a well-designed product, both in hardward and in software. While it's currently only available for the OKI 900, Network Wizards promises a version for the OKI 1150 soon. ***** Sample output of my cellular monitoring program ***** (phone numbers have been masked) Monitor system A or B? Monitoring system B Scanning for control channel Monitoring Control Channel: 0337 System: B Received Signal Strength: 46 (408) 482-01XX page scc=3, dcc=2 (415) 264-06XX page scc=3, dcc=2 (408) 671-19XX page scc=3, dcc=2 (310) 701-23XX non-autonomous reg: on scc=3, dcc=3 (805) 680-11XX reserved (13,6) scc=3, dcc=2 (415) 517-32XX page scc=3, dcc=2 (408) 499-03XX page scc=3, dcc=2 (805) 893-22XX reserved (13,6) scc=3, dcc=2 (510) 914-46XX page scc=3, dcc=2 (213) 500-44XX chan=526, vmac=0, scc=1, dcc=2 monitoring channel 256 audio on hit any key to stop monitoring Decoding DTMF. Press any key to resume. 3447555#706 audio off (415) 971-86XX page scc=3, dcc=2 (707) 312-21XX page scc=3, dcc=2 OMNICELL Scan: Press any key to resume. channel: 0358 RSSI: 10 channel: 0379 RSSI: 53 activity on channel 0379 RSSI 53 audio on hit any key to stop monitoring handoff msg: chan=465, vmac=0, scc=2, pscc=1 tuning to channel 465 handoff msg: chan=505, vmac=0, scc=1, pscc=2 tuning to channel 505 audio off channel: 0400 RSSI: 11 channel: 0421 RSSI: 08 ----- END ARTICLE ----- Transcribed 22 June 1994 by Michael Handler <grendel(a)netaxs.com> Support 2600! If you like the article, please buy the magazine -- there is immense amounts of useful information in there. -------------------------------------------------------------------------- Michael Brandt Handler <grendel(a)netaxs.com> Philadelphia, PA PGP v2.6 public key on request Boycott PSI, Inc. & Canter & Siegel <<NSA>> 1984: We're Behind Schedule

2 2

Re: Unofficial Release
by rah＠shipwright.com 17 Dec '03

17 Dec '03

jamiel(a)sybase.com (Jamie Lawrence) says, >At 3:27 PM 06/22/94 -0400, Perry E. Metzger wrote: > >>Fine. However, you are, you realize, a fool. There is no point in > >I was wondering if you had recently lost an appendage, or maybe had bad >hemorrhoids or something. Like a lot of bright people on this list, Perry doesn't like to repeat himself too much. Like a lot of other people on this list, he gets grouchy when the ritalin wears off... (Damn, I can't find it *anywhere*. Excuse me, there's a tongue around here somewhere... ah. There it is. It's now in my cheek, see? A joke. Levity, even...) Cheers, Bob ----------------- Robert Hettinga (rah(a)shipwright.com) "There is no difference between someone Shipwright Development Corporation who eats too little and sees Heaven and 44 Farquhar Street someone who drinks too much and sees Boston, MA 02331 USA snakes." -- Bertrand Russell (617) 323-7923

1 0

Re: e$: Geodesic Securities Markets
by rah＠shipwright.com 17 Dec '03

17 Dec '03

Sandy Sandfort says Me>> |>> Oddly enough, an e$ certification scheme reverses that paradigm. The book |>> entries disapear, the certificates proliferate, and the clearinghouse |>> becomes a referee, "blessing" the trade. > >I don't think so. The book entries still exist. The book is the only >place securities ever really exist. E$ certificates--and even physical >certificates--are nothing more than receipts evidencing ownership as >defined by the book entry. Remember, securities are "intangible" assets >by definition. (Ditto for dollars, yen, pounds and francs, by the way.) > Well, yes. You're right. In a sense. However, in this scenario, it is possible for the clearing house to operate more like a, since "referee" didn't work before, how about "notary", with an official cc: to the security's issuer. The issuer could keep books, if it was important (as Perry said a while back, the Feds would have to have a "confirm", so someone would keep records of the transaction). Of course, the parties to the trade could keep their books, too. On the other hand, if, like those famous asian anonymous equity markets we heard about (from Eric?) there's no recording requirement (assume a frictionless waterbed <g>), very interesting things can happen. All the new owners of the security care about is the ability to sell it later, or collect interest from the payer of any interest, etc. All the sellers want is cash. My contention is that the sellers can get cash in a market by presenting the e$-based certificate. Cashing out interest "coupons" from the issuer happens in the same fashion. Perry had a point a while back. This is cryptography based, but not cryptography, and most c-punks are probably skipping this thread. I'm *really* interested in this stuff, and will talk to all comers about it, off-line. A couple of people have already sent me e-mail to start the ball rolling... Thanks, Bob Hettinga ----------------- Robert Hettinga (rah(a)shipwright.com) "There is no difference between someone Shipwright Development Corporation who eats too little and sees Heaven and 44 Farquhar Street someone who drinks too much and sees Boston, MA 02331 USA snakes." -- Bertrand Russell (617) 323-7923

1 0

Combined DSP Technology
by NetSurfer 17 Dec '03

17 Dec '03

The following is cut from EDUPAGE: ---------- Forwarded message ---------- Date: Wed, 22 Jun 1994 02:15:36 -0400 From: E-D-U-P-A-G-E <info(a)ivory.educom.edu> MOTOROLA UNVEILS 3-WAY CHIP, SNAGS HONG KONG CONTRACT Motorola's new MC68356 chip combines a microprocessor, a digital-signal processor, and a special communications processor, all on a single sliver of silicon. The three-way chip will be used in credit-card-sized high-speed modems, cellular telephone equipment and automobile guidance systems. (Wall Street Journal 6/20/94 B8) Meanwhile, Motorola's been hired to build a $40 million high-speed wireless computing network in Hong Kong. A trial run of the network, operating at 19.2 K bits per second, is planned for later this year. (Investor's Business Daily 6/20/94 A14) This would be a nice little package to include PGP... -NetSurfer #include standard.disclaimer >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> == = = |James D. Wilson |V.PGP 2.4: 512/E12FCD 1994/03/17 > " " " |P. O. Box 15432 | finger for full PGP key > " " /\ " |Honolulu, HI 96830 |====================================> \" "/ \" |Serendipitous Solutions| Also NetSurfer(a)sersol.com > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

1 0

Re: Thoughts on the NSA's correction to SHA
by jktaber＠netcom.com 17 Dec '03

17 Dec '03

Forwarded message: > > > >The very fact that this correction had to made offers some > >insights into the National Security Agency. > > > >I believe that releasing DES to the public was the biggest > >cryptography mistake that NSA ever made. Consider the state of > >research in cryptology before DES. It was simplistic. It was > >haphazard. There was little interest. If any results of value > >were ever discovered, the NSA could squash them with a secrecy > >order. No one cared. > > > > There is one problem with this analysis: > > IBM created DES. Not the NSA. Sure the NSA could have asked them to keep > it hidden, but the NSA was also going to IBM and warning them > about Russians evesdropping on IBMs networks. Everyone realized it > was time for public cryptography. Especially IBM. It is not clear > that a secrecy order would have worked. > > This is not to say that your analysis is wrong. They classified the > design procedures which was their attempt at a compromise. IBM couldn't > publish the details of how to make a good algorithm, but they could > release the details of the standard. > > > Well, yes, IBM did create DES. But the NSA against its better judgment blessed the effort, and by my guessing helped tremendously. I have heard rumors that NSA *does* say it was their biggest mistake, and never again. There is no way I can prove a rumor, but I put a lot of credence in these particular rumors. I speculate that it was Bobby Inman who ordered NSA to facilitate IBM.

1 0

Unofficial Release
by dcosenza＠netcom.com 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- I'm pleased to announce the release of an unofficial version of PGP v2.6ui that allows for key generation up to 8176 bits, thanks are due to Tom Rollins for his diligence compiling the code and also to Mathew at Mantis Consultants in the UK for bringing us all up to 2.6ui. Said material, including source codes and an associated signature, can be found on ftp.netcom.com look in /pub/dcosenza for the following: pgp26ui.zip --> DOS release pgp26uisrc.zip --> source codes pgp26uisrc.sig --> sigfile for pgp26uisrc.zip tom.asc --> Tom's public key, you'll need this to check the sig This patch level is not endorsed or supported in any way shape or form by MIT, so usage of this program might put you in violation. A couple of notes: keys that are larger than 1264 bits will not be readable by previous versions of the software, so users who are interested in larger key lengths are encouraged to move up. Also, considering the enormous amount of time it takes to generate a 4096 bit key on a 486 (10 1/2 hours), an upper limit of 2048 or thereabouts is strongly recommended. Enjoy everybody and Ever forward, David - -- - --------------------------------------------------------------------------- David Cosenza dcosenza(a)netcom.com PGP 2.3a Public Key available by finger _or_ ftp.netcom.com:/pub/dcosenza PGP 2.3a Key fingerprint = BF 6C AA 44 C6 CA 13 3F 4A EC 0A 90 AE F3 74 6D "When encryption is outlawed, only outlaws will have encryption." -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCzAgUBLgevPSjdpAfJZzihAQFipATwk1jlksS571wBq3p2KySjjpj0PHOY8QJy yc5/S2BYn5ynY4XSp98skAUgWTblU0cT1uFu2JrukpdCqec5pCzCFVuErN2fn9zY MWUhqZKG74v1nTfNrlA+JjfiXd9LWjJJO8bBRfEyZ5ZBMsxALvU/N1j1rCV+KovI OjxtLDdbe5znloT/2GVwlPo2TQUi//cpfT9XNbVDUVCLG934nlw= =BQtC -----END PGP SIGNATURE-----

5 4

Using "nobody" to camouflage encryption/remailers/commerce
by Vincent.Cate＠FURMINT.NECTAR.CS.CMU.EDU 17 Dec '03

17 Dec '03

If we use "nobody" as an email address we can hide remailers or make it seem like there were remailers where there are not, etc. The convention on the Internet is for mail to "nobody" to go to "/dev/null". This is used as a return address when you don't want bounced mail. Now remailer operators are clearly more interested in privacy than in following conventions. Imagine remailers also had addresses like "nobody(a)vox.hacktic.nl", and "nobody(a)jpunix.com". Now if someone doing an internet wire-tap sees mail to "nobody(a)furmint.nectar.cs.cmu.edu" it is hard for him to tell if this means: a) It will just end up in /dev/null like it does on 99% of the machines b) furmint is another remailer c) someone on furmint gets mail as "nobody" d) furmint acts as a remailer for those with money e) furmint is being used for some email based business f) etc So now assume that there was a lot of encrypted mail going to "nobody(a)alex.sp.cs.cmu.edu". That might be because I am also doing something funny there, or it might be because someone is just sending a lot of encrypted mail to /dev/null. By the way, anyone is welcome to send encrypted mail to this address (via a remailer or not). Even if there is no email going out of that machine, it could just be that with my remailer I collect the mail some period into a file, encrypt the file, move it off to some other machine (using FTP, NFS, uucp, rcp, http, telnet, etc.), and mail it from there. Could be hard to tell. Remailers named "nobody" will be harder to stop. So it would be nice if sites with remailers would set the "nobody" alias to point to their remailer to start this convention. Assuming that the remailer will drop non-encrypted mail (or at least mail that does not have a good format) this should not cause any problems. On "furmint" I did the following: Changed the "nobody:/dev/null" in /usr/misc/.mmdf/table/aliases to "nobody:vac+pgp@furmint.nectar.cs.cmu.edu". Ran "dbmbuild" to rebuild the "mmdf" database. I don't know how different this will be on other Unixes. It may only take editing "/usr/lib/aliases" on other systems. So I did give away the puzzle in the second paragraph, if you send mail to "nobody(a)furmint.nectar.cs.cmu.edu" it is the same as sending mail to "vac+pgp(a)cs.cmu.edu". So far. :-) I doubt that "nobody" was getting a lot of mail, but if so I will modify my "pgp-receive" script to drop any mail not encrypted for it. If they ever outlaw sending mail to "nobody" there will be millions of people who are breaking the law. If some country outlaws encryption, people (or programs) in other countries could send encrypted mail to "nobody" at random machines in that country to act as a cover for the legitimate encrypted mail. -- Vince

2 1