December 2003 - cypherpunks-legacy

re: voice encryption
by wcs＠anchor.ho.att.com 17 Dec '03

17 Dec '03

> [IBM ISDN board with TI DSP, COM1 interface, 64kbps] The big problem with ISDN is still getting connectivity to the people you want to talk to and getting service at reasonable prices (prices vary widely depending on your phone monopoly's interactions with the regulatory bureaucracy, and/or your distance from long-distance service providers if you want PRI connections.) Do you know if the TI DSP is user-programmable, or if it's just performing most of the ISDN functions? The difficulty with COM1 interfaces, when you're using DOS, is that DOS basically gives you a single character per interrupt, which means a system doing 8000 char/second on COM1 is taking a *lot* of interrupts. There are generally other interfaces that let you handle more characters at once, but they're not transparent to software that's expecting simple COM1, and they're often vendor-specific. (The FOSSIL drivers for 16550 UARTs are addressing the same problem; maybe somebody's got FOSSIL support for ISDN?) On the other hand, if you're doing software to support voice over ISDN, it's probably worth doing some board-specific hacking, especially if you're going to use the on-board DSP anyway. Bill

1 0

re: voice encryption/isdn
by Mark Hittinger 17 Dec '03

17 Dec '03

>> [IBM ISDN board with TI DSP, COM1 interface, 64kbps] >The big problem with ISDN is still getting connectivity to the >people you want to talk to and getting service at reasonable prices Yep. But it may be there some day. Ken Olson called ISDN a joke. I remember seeing somebody in Computer World saying ISDN stood for "I Still Don't kNow". >Do you know if the TI DSP is user-programmable, or if it's just >performing most of the ISDN functions? Hah! We are talking about an IBM board here!! :-) There was some kind of ROM on the board, it may be an 8051 with EPROM? Or possibly a 68701. We will figure it out at some point. Speaking of DSP the new AT&T 3700 modem (from paradyne actually) has a DSP and it seems to be driven by an easily modifyable rom. Just another possibility. While we are blue skying about this - what about the idea of using two cellular connections in parallel? Aside from cost it might create some interesting interception problems. --------- I'd like a 250 Mhz 128 bit hybrid processor with 64 meg of 8 way interleaved memory, a 10 megabyte per second i/o channel, two 3 gig hard disks, two dat drives with compression, and a large diet coke. -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.3a mQCNAiz4FWMAAAEEALBCb7HZS7V4gbsp9yJ7Yty49jQ9wcgRhkLjNNgdyJbrJZCq 5/sv4Ljy/4AhVhjlJyZS8L3owS8l0ClZVzWw4/kO3KN7MPz4YPPR7+qIlPQVM0yv gWpJ43EZZ8b8cvAkE9HATCKWktY2ReRSX5DLnScDH/n5jivw+MD/UO8fURCVAAUR tCBNYXJrIEhpdHRpbmdlciA8YnVnc0BuZXRzeXMuY29tPg== =VbKi -----END PGP PUBLIC KEY BLOCK-----

1 0

re: voice encryption
by Mark Hittinger 17 Dec '03

17 Dec '03

Hey guys last week we got ahold of a new board made by IBM that is an actual ISDN board. It is accessible as com1, is hayes compatible, and has the texas instruments DSP chip on it. The claim is 64kb. We will test it and see how it goes. This would be better than the 28.8 stuff but I think that still needs to be done for cellular. --------- I'd like a 250 Mhz 128 bit hybrid processor with 64 meg of 8 way interleaved memory, a 10 megabyte per second i/o channel, two 3 gig hard disks, two dat drives with compression, and a large diet coke. -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.3a mQCNAiz4FWMAAAEEALBCb7HZS7V4gbsp9yJ7Yty49jQ9wcgRhkLjNNgdyJbrJZCq 5/sv4Ljy/4AhVhjlJyZS8L3owS8l0ClZVzWw4/kO3KN7MPz4YPPR7+qIlPQVM0yv gWpJ43EZZ8b8cvAkE9HATCKWktY2ReRSX5DLnScDH/n5jivw+MD/UO8fURCVAAUR tCBNYXJrIEhpdHRpbmdlciA8YnVnc0BuZXRzeXMuY29tPg== =VbKi -----END PGP PUBLIC KEY BLOCK-----

2 1

hal@alumni.caltech.edu up
by Hal 17 Dec '03

17 Dec '03

The Caltech system had some problems with break-ins so apparently some disk reorganization was done in the clean-up which stopped my remailer for a while. I touched up a bit of the code tonight, nothing too significant, and it seems to be working OK now. Note that this remailer always forwards via the one at shell.portal.com. It does have its own decryption key, but all outgoing mail goes via that address. This makes the mailer more politically acceptable to TPTB. But it does mean that when you "ping" the remailer you won't see the alumni address in the From line, but portal instead. Hal

1 0

Cypherpunk meetings. The next step.
by GRABOW_GEOFFREY＠tandem.com 17 Dec '03

17 Dec '03

------------ TEXT ATTACHMENT -------- SENT 03-13-94 FROM GRABOW_GEOFFREY @LONGIS -----BEGIN PGP SIGNED MESSAGE----- Greetings all, Yesterdays meetings brought up some interesting ideas. Through the fault of no one, the sound quality of the other locations was somewhat less than exceptional. If any of you who attended the other meetings can send out a summary of what was discussed, I would appreciate it. We at the Wash. location were discussing what the next step should be in the "Clipper vs. Privacy" battle. Several ideas were brought up: - Create our own in-line secure phone encryption device to compete with Clipper-designed machines. - Increase public awareness of Clipper and what it may bring by using methods such as: . Anti-clipper t-shirts, buttons & pins . Anti-clipper memos on any and all BBSs and networks . Anti-clipper letters to the editor of every newspaper . et al - Continued polotical wrestling. Washington attandees: If I've left out anything, please write it down and send it out. G.C.G. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | Geoffrey C. Grabow | "What we demand are rigidly defined | | Oyster Bay, New York | areas of doubt and uncertainty!" | | | -------------------- | | grabow_geoffrey(a)tandem.com | Clipper, SkipJack & Digital Telephony | | | JUST SAY NO!!! | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.3a mQCNAiz/qhsAAAEEAN4QxTfSBoeP/FCiaX0/KmCkl6BcKRa1PeoP6ZlPWydg1nOx yZAk8pIdgiGxxgiMBMsqD+SrU+Sl1Fx1AdJ14HJsBp1V6G4rBTZqvFpbNPCfrQfz K/Apg+7bBpi5Qv+sQ0TWIy38zp/laArgcdUOpE4oE2UOUBVEtYvm47K2P+i5AAUR tC9HZW9mZnJleSBDLiBHcmFib3cgPGdyYWJvd19nZW9mZnJleUB0YW5kZW0uY29t Pg== =2NWi - -----END PGP PUBLIC KEY BLOCK----- -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLYNIXIvm47K2P+i5AQF1YwP+LDdw2OZyQCQe+S4FsnYW6GcbLlLShxn+ VS2UNihMtFqMwDjIK48lT17y2dyZ8UBPGx2Gdhr+hWOQGg7URxvCW8RHTMV+0kql m1fyTuuvD6njA7Q2Y5CSHmhuoECnqOJF6QpdVi6tti/QyY266h83kAexIzXa5+Un ViY5zW+zJyY= =0TKT -----END PGP SIGNATURE-----

1 0

Magic Money gripes
by Hal 17 Dec '03

17 Dec '03

I hate to complain. Magic Money is something that people have been asking for for a long time, and it's a very nice implementation. A lot of aspects have been really well thought out, particularly the money aging and replace- ment. But I've been playing with it off and on lately and there are some improvements needed IMO. I'll just assume interested readers know how the program works and jump right into it. - The program handles encryption of messages to and from the bank auto- matically, but makes the user have to handle encryption of messages to other people. I can see some justification for this - maybe the message (that is, a coins.dat file) will be sent via secure means like a direct or IR connection, so encryption is not needed. But most of the time it is needed, in which case the user has to use PGP or something as a sep- arate step. - The program distinguishes between bank messages, which are signed blinded coins, and user messages, which are raw coins, by whether they are in ASCII text or not. This is not the significant distinction between these two kinds of messages. - Bank messages look just like other PGP messages. But the user has to know not to try to run them through PGP and instead give them directly to the MM program un-decrypted. The only way he can tell is to notice that the sender address is the bank. If the bank ever sends him a real coin file (which it may to prime the pump) then the user just has to know to treat these messages differently. - There is no way to know which bank an incoming coin file is for. I think this is one of the biggest weaknesses of the system. If more than one bank is competing I have to know which bank a given coin file is associated with and go to that directory to process that coin file. - There is no way to put coin files directly into your allcoins.dat file. There are a couple of cases in which you might want to do this. First, you might pay out some coins and then change your mind before sending them, and want to put them back. Or second, you might receive some coins from a trustworthy person (your mum, say) and just want to add them without going through the bank. - More generally, it is difficult to use the program in a safe way which deals robustly with errors of various types. When I was first building the program I had some bugs which caused coins to appear to be double- spent, to not signature-check properly, to not be found in the proto file, etc. The program did not appear to handle all of these errors safely, sometimes aborting in the middle of a file. In addition, the program always calls its output files coins.dat and output.asc. If you run it twice without renaming these files you can lose data and lose money. Then, when you send the files, you need to manually keep backups in case the email fails. Again, otherwise you will lose money. - The money data structures do not allow for expansion. I'd like to see a way of adding new fields in the future which will be ignored by older versions of the program. For example, in regard to the above, I'd like to see a "bank email address" and possibly a bank key added to the coins.dat file. Then you could mail the coins to someone without including a lot of out-of-band data about the bank they were for. It would be nice if this could be done without totally breaking the current program. At a minimum a version number could be stuck at the front so that old programs would recommend that users upgrade. - The program uses PGP algorithms and data structures, but not its files. The bank's key and user's keys are kept in separate files. There might be advantages in putting these keys into PGP's regular files. Also, the random number generation in PGP looks stronger than MM, since it keeps much more state from run to run. MM seeds based on a very, very elementary hash on a file called rand.dat, which will tend to be fixed, and the time of day. - None of the MM files are encrypted on the disk. The money files could be stolen by someone with access to your computer, and your secret key used for communications with the bank could be stolen as well. This would be a major security flaw in some situations. Having made these complaints, let me reiterate that I am very pleased with this program overall. I also appreciate mpd(a)netcom.com's efforts in running a server. I have built a Mac client for MM which is not too mac-like but lets you drag-n-drop incoming files onto the MM icon and it handles them right. I'll tweak that a little more then upload it with the other clients. Hal

1 0

I hate to nitpick, but...
by Matt Thomlinson 17 Dec '03

17 Dec '03

I really hate to pick stuff like this out, but people in washington STATE are sensitive to this stuff, and talking like this might create some confusion, so.. ---- From: GRABOW_GEOFFREY(a)tandem.com [...] We at the Wash. location were discussing what the next step should be [...] Washington attandees: If I've left out anything, please write it down and ---- NOTE: Above, WASHINGTON == Washington DC, not Washington State. The Washington meeting in _Seattle_ went well -- we had 11 attendees for our first meeting ever. Hopefully, with better planning :) we'll have even more at our next meeting. Since it was our first meeting, much of it was spent introducing ourselves and planning logistics of our monthly meetings. We've decided to pursue MBONE connections in anticipation of the next broadcast Bay Area meeting. We're setting up a local group mailing list to service our local needs. In the event we can't get MBONE, our meetings will be held one week after the Bay Area meetings, in hopes that some kind soul will be able to provide us with rough minutes or the like. I know that this has been done before, although I know it is a thankless job... matt Matt Thomlinson Say no to the Wiretap Chip! University of Washington, Seattle, Washington. Internet: phantom(a)u.washington.edu phone: (206) 548-9804 PGP 2.2 key available via email or finger phantom(a)hardy.u.washington.edu

1 0

No Subject
by rishab＠dxm.ernet.in 17 Dec '03

17 Dec '03

Matt Thomlinson <vikram!phantom(a)u.washington.edu>: > I was wondering what people were thinking about putting together a > page for WWW? Would it be useful? Would people browsing around look at > it and would it be a medium to disseminate info? Maybe divide it up... I've been working on this for a while, as I mentioned in an earlier post. At the moment, you can use Gopher as an interface to browse articles on policy (Clipper, DT ...) at EFF or CPSR, and at chaos.bsu.edu for digicash and more cpunk stuff. I'm really more interested in WWW because the articles can be hypertextified with cross-references. Right now, you can use Gopher as an index of articles themselves, so there is no point making a WWW html that's just a 'contents' page. In about 3-4 weeks from now, I'll be ready to release fully hypertext WWW html. This will still be quite limited, to policy on Clipper, Digital Telephony, ITAR; FAQs; Cypherpunk stuff -- Digicash, Blacknet(?), anon/remailers; RSA, other patents and papers; Kerberos and other security, maybe. All this will be as cross-referenced as I can manage by next month. There are over 4 megs in (uncompressed) articles, that I've downloaded so far. -------------------------------------------------------------------------------- Rishab Aiyer Ghosh "What is civilisation rishab(a)doe.ernet.in, rishab(a)dxm.ernet.in but a ribonucleic Voicemail +91 11 3760335; Vox/Fax/Data 6853410 hangover?" H-34C Saket New Delhi 110017 INDIA --------------------------------------------------------------------------------

1 0

re: voice encryption
by elbert2＠darmstadt.gmd.de 17 Dec '03

17 Dec '03

>> [IBM ISDN board with TI DSP, COM1 interface, 64kbps] last november, on a trade show, i saw AVM presenting a PCMCIA card for ISDN. it ran BTX alias Datex-J alias Minitel, so there *is* a "application for the masses". They said to have production running till CeBit-time. sorry, no further info.

1 0

Yet another assault
by bart＠netcom.com 17 Dec '03

17 Dec '03

Seen in the Edupage mailing list: ELECTRONIC EAVESDROPPING A measure soon to be introduced on Capitol Hill would require that all network providers, including the Internet and commercial on-line services, build in the capability to record any person's e-mail and deliver it to federal law-enforcement authorities. Government agents will need only to show a person merits investigation, rather than obtain a court order as is the case for telephone eavesdropping. (Business Week 3/14/94 p.55)

1 0