December 2003 - cypherpunks-legacy

RSA T-shirt
by David K. Merriman 17 Dec '03

17 Dec '03

FWIW, I finally got a chance to see if my barcoded RSA-in-perl t-shirt would actually scan - and it did! It took a bit of fiddling, but it was scannable using one of those hand-held CCD barcode readers. Dave Merriman This is a test (3 UUE lines) of the unconstitutional ITAR - 1/713th of the PGP executable. See below for getting YOUR chunk! ------------------ PGP.ZIP Part [015/713] ------------------- M=$<(&L`#*IPP",(G6(,,S,`P](<2RWU96XCW86/JBYV8A\D8@X'HB_9H#&\X MX'PCUB.,13B"X8`R?^J-:UB.M_`U\>[#)BS&5$0C,Y#^1CS>1`\T1QTXX6!3 M8H,),S$8G>&.WP(8IRA`-M['+`Q%&_C"">5-F%LX@<_Q$;*P'',Q$Z/AA[8M ------------------------------------------------------------- for next chunk to export --> http://dcs.ex.ac.uk/~aba/export/ <><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><> My web page: http://www.geopages.com/CapitolHill/1148

1 0

Re: credit card conventional wisdom
by Rich Salz 17 Dec '03

17 Dec '03

>There is in fact a distinction between "card present" and "card not present" >transactions. AMEX cards for example have an extra group of four digits which >are not part of the embossed card number. They are used as additional >verification to prove that a card is present. So the run-it-through-the-mechanical-device is treated as card not present? /r$

4 5

DCSB: "A Middleware Guy Looks at Issues in Digital Commerce"
by rah＠shipwright.com 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- The Digital Commerce Society of Boston (Formerly The Boston Society for Digital Commerce) Presents Rich Salz Open Software Foundation "A Middleware Guy Looks at Issues in Digital Commerce" Tuesday, December 5, 1995 12 - 2 PM The Downtown Harvard Club of Boston One Federal Street, Boston, MA Rich has been with OSF for nearly four years, where he has been the technical lead of the OSF DCE 1.1 and 1.2 releases. He is also helping write the secure multi-threaded WWW server for the DCE-Web project. He has been active in Usenet, and is the author of INN, one of the most popular Usenet/NNTP implementations. His home page is http://www.osf.org/~rsalz. Rich says: >In the rush to separate lift even more money out of your wallet >-- sorry, to provide consumers with more choice and opportunity >-- the electronic commerce community has largely been ignoring >issues that the distributed systems field has been trying to >address for years. This meeting of the Boston Society for Digital Commerce will be held on Tuesday, December 5, 1995 from 12pm - 2pm at the Downtown Branch of the Harvard Club of Boston, One Federal Street. The price for lunch is $27.50. This price includes lunch, room rental, and the speaker's lunch. ;-). The Harvard Club *does* have a jacket and tie dress code. We need to receive a company check, or money order, (or if we *really* know you, a personal check) payable to "The Harvard Club of Boston", by Saturday, December 2 (that's two weeks from this Saturday), or you won't be on the list for lunch. Checks payable to anyone else but The Harvard Club of Boston will have to be sent back. Checks should be sent to Robert Hettinga, c/o The Shipwright Development Corporation, 44 Farquhar Street, Boston, Massachusetts, 02131. Again, they must be made payable to "The Harvard Club of Boston". If anyone has questions, or has a problem with these arrangements (We've had to work with a few glacial A/P departments ourselves, for instance), please let us know via e-mail, and we'll see if we can work something out. January's speaker will be Art Hutchinson of Northeast Consulting Resources, Inc. We are actively searching for future speakers. If you are in Boston on the first Tuesday of the month, and you would like to make a presentation to the Society, please send e-mail to the BSDC Program Commmittee, care of Robert Hettinga, rah(a)shipwright.com . For more information about the Boston Society for Digital Commerce, send "info bsdc" in the body of a message to majordomo(a)ai.mit.edu . If you want to subscribe to the BSDC e-mail list, send "subscribe bsdc" in the body of a message to majordomo(a)ai.mit.edu . Looking forward to seeing you there! Cheers, Bob Hettinga Moderator, The Digital Commerce Society of Boston -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMKooW/gyLN8bw6ZVAQFMAQP+MQn6wlKxMVHekN1mruUrwILBR0KTcxSK RQo7ELRJAP0aEiEskio3bphrgCpWgxKHJn9KP3YEHuNbwwXZGVzVTlijvzmbVksf ybtAsspMERb/9yWOe4AT69R/hSTAjEkzCwx86iP4FbjBccPiQPQD1eKJ+4C4obW+ WFuq7mpizeU= =J6UH -----END PGP SIGNATURE----- ----------------- Robert Hettinga (rah(a)shipwright.com) e$, 44 Farquhar Street, Boston, MA 02131 USA (617) 958-3971 "Reality is not optional." --Thomas Sowell The e$ Home Page: http://www.webstuff.apple.com/~vinnie/Rah >>>>Phree Phil: Email: zldf(a)clark.net http://www.netresponse.com/zldf <<<<<

1 0

So. FL Cypherpunks Keysigning/Party
by liberty＠gate.net 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Greetings South Florida cypherpunks-- All cypherpunks in or near Dade county who wish to meet will be getting together at 7:30PM on Wednesday, November 29th. In keeping with past South Florida cypherpunks tradition, we are going to meet where the _beer_ is, and (better yet!) this South Florida cypherpunks meeting will coincide with the monthly meeting of the Miami Area Society of Homebrewers ("M.A.S.H.") at the Abbey Brewing Company on Miami Beach. This bar serves a selection of barsnacks, not quite as extensive as the food at The Riverwalk Brewery, but at least they aren't going out of business... Location: The Abbey Brewing Company (305) 538-8110 1115 16th Street, Miami Beach Directions: [From North: Take I-95 South to 195 exit, over to the beach, and go South on Alton Road. Look for a green sign that says "BAR" atop the building.] [From South: Take I-95 North to 395 exit, over to the beach, and go North on Alton Road. Look for a green sign that says "BAR" atop the building.] I will be bringing the videotape of the "Mitchells In The Morning" talkshow featuring PRZ that I mentioned a while ago, but The Abbey has no VCR, and the atmosphere might not be right for a showing. Because the meeting is on Miami Beach, folks from far away are urged to carpool or use Tri-rail to Metrorail and then get a ride from Jim Ray (I will try to stay *somewhat* sober). e-mail <liberty(a)gate.net> for ride or carpool details & I'll try to coordinate the transportation aspect of the meeting for those in need of a ride. Joe Block <jpb(a)miamisci.org> is willing to coordinate the keysigning aspect of the meeting, and he will post in a few days. JMR -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Freedom isn't Freeh iQCVAwUBMKoxZm1lp8bpvW01AQHLywP/YUWrjYBGyhTXVNyJa05WrUZPtZcNx2sK e6Q0Zc4CYm2q3y5Xq2jdOz8pql95y2L/anSNAJS3zdAR4SFpGR45ZxNtLXy1YU6r 6KDCwPpjoJ4+aUdXrfcW/2DR3BMatHIy25I26SqWmwiVSFRvjIBEH9PO73QA9c7Z Yo5nKaDvRu0= =oRZQ -----END PGP SIGNATURE----- Regards, Jim Ray "...the politicians have been arguing over whether to increase the budget enormously or just hugely. The news media refer to this process as 'cutting' the budget." -- Dave Barry Visit my "Pretty Good Homepage" at http://shopmiami.com/prs/jimray/ ----------------------------------------------------------------------- PGP key Fingerprint 51 5D A2 C3 92 2C 56 BE 53 2D 9C A1 B3 50 C9 C8 Key id. # E9BD6D35 (key on page & servers) <liberty(a)gate.net> IANAL ----------------------------------------------------------------------- Help Phil! email zldf(a)clark.net or http://www.netresponse.com/zldf _______________________________________________________________________

1 0

Re: Hardware-random-bits interface
by jimbell＠pacifier.com 17 Dec '03

17 Dec '03

>I've been thinking about physically random bits recently, so >I'd like to offer a simple, easily implementable interface to a >source of such bits, along with a design sketch using a common >radio receiver chip as the noise source. The interface consists >of two bits in the standard PC parallel port, one serving as >the data line and the other the sampling clock. [stuff deleted] > Device probing: the device should somehow identify itself > as a random bit generator. One way to do this is to wire > one of the parallel port data bits to a status line; for > example, data bit 0 (pin 2) could be wired to status bit 5 > (pin 12). Software can then twiddle the data bit and > watch for the response. I'm not a crypto expert, or a mathematician, or anything like that, but I think I have a few suggestions that you should consider. 1. DON'T let the random-number generator "know" that it is being accessed, even with something as simple as a clock. The reason is that if it became important enough, an agency with a BIG BUDGET could make a custom chip that implemented the same apparently-random function, (but might really be a 10**18 state machine with, say, only 10**6 starting positions) but could be "alerted" and reset by a specific pattern of external accesses, possibly activated by a special-purpose virus. The resulting "fake" chip would appear to result in random output, if never reset, but would produce a data stream with a predictable series with a limited number of starting points. 2. Since the main goal of the project is to have this end up being an ECONOMICAL board, you'll probably end up with a data stream which has some sort of slight bias in one direction or another. As far as I can see, that's okay, because it merely means that you're getting somewhat less than one bit of randomness with each accessed bit. But as I understand it, the solution to this is to combine the bits in software so that you end up with fewer bits. While it's been months since I've read Schneier's book, I recall that it talked about extracting more-perfectly-randomized bits from a larger collection of not-quite-so-randomized ones. 3. In addition, for most trustworthy results, I think you should XOR the resulting data with a long-period pseudorandom stream of bits derived and modified from some reasonably random inputs, such as keystroke timings and free-running-system-clock bits. The reason is that (as far as this neophyte knows) a stream of GOOD randomized numbers XOR'ed with a stream of reasonably randomized numbers results in a stream at least as randomized as the better source. More importantly, such a procedure should help deter any attempt to corrupt the physically-random source, because even going to that trouble of subverting it they'd only defeat only one stage in the process. 4. I think the user should be given the option of socketing the IC's. True, that would make it easier for an interloper to replace, but it would also allow the user to quickly swap the critical chips, possibly at intervals of a few days to a few weeks, to partially guard against sabotage. 5. The whole assemblage should be able to be stored in a package sealed with evidence tape.

1 0

Re: Hardware-random-bits interface
by tcmay＠got.net 17 Dec '03

17 Dec '03

At 3:17 PM 11/15/95, David K. Merriman wrote: >At 02:31 PM 11/14/95 -0800, you wrote: >>I've been thinking about physically random bits recently, so >>I'd like to offer a simple, easily implementable interface to a >>source of such bits, along with a design sketch using a common >>radio receiver chip as the noise source. > >It sounds like a fairly decent idea, _as long as you shield the bejeebers >(technical term :-) out of it_. Otherwise, anybody with a signal generator >could skew your numbers however they saw fit: any component lead can act as >an antenna, no matter now small that lead is. But if you "shield the bejeebers out of it," then all the radio receiver generates is whatever signal manages to sneak through--which, ironically, would make it _easier_ for an outside attacker to drive--and some amount of internal receiver/amplifier noise, such as the Johnson noise talked about here. (Every receiver has an "equivalent noise temperature," recall.) And if one is left with only internal noise, why not simply use a nice clean source like a Zener diode? --Tim May Views here are not the views of my Internet Service Provider or Government. ---------:---------:---------:---------:---------:---------:---------:---- Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay(a)got.net 408-728-0152 | anonymous networks, digital pseudonyms, zero Corralitos, CA | knowledge, reputations, information markets, Higher Power: 2^756839 | black markets, collapse of governments. "National borders are just speed bumps on the information superhighway."

3 2

Re: Hardware-random-bits interface
by David K. Merriman 17 Dec '03

17 Dec '03

At 02:31 PM 11/14/95 -0800, you wrote: >I've been thinking about physically random bits recently, so >I'd like to offer a simple, easily implementable interface to a >source of such bits, along with a design sketch using a common >radio receiver chip as the noise source. It sounds like a fairly decent idea, _as long as you shield the bejeebers (technical term :-) out of it_. Otherwise, anybody with a signal generator could skew your numbers however they saw fit: any component lead can act as an antenna, no matter now small that lead is. One way to handle it would be to lay it out as a multi-layer PCB, with the signal & power traces inside, and ground plane on the outer layers. Then enclose the circuit components inside a shielding enclosure (mu-metal would be good) mounted to the PCB, then tuck the entire assembly inside another enclosure (small aluminum box for example, also connected to ground). Of course, there would be easier ways to fabricate it, but they would just make the shielding that much more difficult to implement. Dave Merriman This is a test (3 UUE lines) of the unconstitutional ITAR - 1/713th of the PGP executable. See below for getting YOUR chunk! ------------------ PGP.ZIP Part [015/713] ------------------- M=$<(&L`#*IPP",(G6(,,S,`P](<2RWU96XCW86/JBYV8A\D8@X'HB_9H#&\X MX'PCUB.,13B"X8`R?^J-:UB.M_`U\>[#)BS&5$0C,Y#^1CS>1`\T1QTXX6!3 M8H,),S$8G>&.WP(8IRA`-M['+`Q%&_C"">5-F%LX@<_Q$;*P'',Q$Z/AA[8M ------------------------------------------------------------- for next chunk to export --> http://dcs.ex.ac.uk/~aba/export/ <><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><> My web page: http://www.geopages.com/CapitolHill/1148

1 0

Re: MED_vac
by Thomas M. Swiss 17 Dec '03

17 Dec '03

John Young <jya(a)pipeline.com> writes: > > 11-15-95. NYPaper Page One: > > "When Patients' Records Are Commodities for Sale." > > Individual medical records, carrying more sensitive > personal information than ever before, are increasingly > being gathered and stored by the tens of thousands in > commercial databanks maintained by institutions like > hospital networks, health maintenance organizations and > drug companies. And although there is a Federal law that > protects the privacy of video rental lists, private > medical information is being bought and sold freely. A (possibly stupid) thought: could commercial key escrow help here? I very much want hospitals to have fast access to my medical data if my broken and bleeding body should come through their door, even if I am unconscious and my personal physician cannot be reached. On the other hand, I don't want anyone to be snooping through them right now. One solution is for me to carry my records around with me on a smartcard or some such device. But there are problem with that approach; for example, do I want that personal information to be in my wallet if it's stolen? Do I want to add another item to the list of physical items I have to keep secure? So, what if my records were available on the net, but encrypted with a an key known to my physician and an escrow agency? (Equivalently, they could be on that smartcard, but encrypted.) If an emergency occurs, the hospital fetches my encrypted records from my physician's server, then sends a message (signed with the hospital's key) to Keys R Us, the escrow agent, saying "This is Dr. McCoy at Frobnitz Memorial Hospital, we need the key for FooBar Medix, Inc., patient number 147258369." (My FooBar Medix, Inc., insurance card lists my physician's server, the escrow agency, and my patient number.) Keys R Us verifies the message and sends the key. Perhaps there's also an alias to notify of the release, one that reports to but is not traceable to my physician or me. Keys R Us only has a number and a key; they don't know who my physician is and therefore don't know where to find the actual records. Anyone who gets my insurance card can find the records, but has to convince Keys R Us to release they key; and if I've done my homework in picking the agency, they won't. Does this give an advantage over just having a copy of my records kept by a trusted third party? Maybe so; I think maybe less trust of the escrow agency is necessary. No snooper can slip someone at the escrow agency a couple of cyberbucks to get a copy of my records, unless they've managed to match "FooBar Medix, Inc. patient number 147258369" with "Tom Swiss" and the location of my physician's server. (What if FooBar Medix, Inc., lets this information out? I dunno. I guess I visit their office with a shotgun. Better idea: FMI doesn't know what escrow agency I use. I fill in Keys R Us on the card myself.) No minimum wage slave can just casually browse my records for fun. Thoughts? [Since TIS is in the CKE field, I should note that this is my own boneheaded idea, not affiliated with the company in any way.] -Tom Swiss / tms(a)tis.com

3 3

encryption in BeOS kernel
by cpunk＠remail.ecafe.org 17 Dec '03

17 Dec '03

This also corresponds to IBM's development of its "IPC" "network appliance" (also due out 1Q '96) to challenge the desktop PC for Internet use. It parallels as well IBM's reported work on a "Microkernal" which may feature encryption, authentication and security hooks. IBM's IPC will probably use an Intel chip (WSJ today). Which leads to speculation: Would chip-fabbers covertly Fortezza chips to get export ok? Motorola, HP, IBM, others long-linked to USG are ever ready to gobble international market share in the national interest. Intel, sure, world-class fab plants planting chip-secrets. Wonder if that key escrow protest to Gore is a cover for economic actions authorized by National Security D&D?

1 0

Re: NSA, ITAR, NCSA and plug-in hooks.
by jimbell＠pacifier.com 17 Dec '03

17 Dec '03

>jim bell writes: >>>I think it's 121.1, Category XIII paragraph (b) item (5): >>>"Ancillary equipment specifically designed or modified for paragraphs (b) >>>(1), (2), (3), (4) and (5) of this category;" >> >>Question: What makes computers in general NOT describable by such a >>paragraph?!? > >The referenced paragraphsdescribe cryptographic hardware, software and >technical data. Computers in general are not "specifically designed" >as cryptographic equipment. Great! Then you must merely ensure that there is at least one (non-encryption) program around that can use the same hooks.

4 3