December 2003 - cypherpunks-legacy

Hardware-random-bits interface
by Peter Monta 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. The parallel port, while a bit less universal than RS-232, eliminates the complexity of UARTs and clock generation and offers higher speed and friendlier local power. For an ISA bus running at 8 MHz, bits can be sampled at about 2.5 Mb/s, i.e., about 300 kB/s. (The bandwidth of the noise source should of course be consistent with this.) Another advantage of a simple device is that it can be thoroughly inspected: there is no PLD or microcontroller code to vet/trust. Not all parallel ports have bidirectional data registers, so the most general path is to assign a status bit to the input and use a control bit for the clock output. I'm using bit 4 of the status register (pin 13 on the PC's DB-25) as the input and bit 0 of the control register (pin 1) as the clock. Specifically, the rising edge of pin 1 should sample the noise waveform and present the result on pin 13. (Pin 1 is inverted, so bit 0 should transition from 1 to 0.) I'd also like to suggest a device name for the Unix environment, /dev/prandom, for "physically random". The intention is that the bits returned be as raw as possible, as close to the physics as possible, leaving any debiasing/hashing to other software (for example, the /dev/random implementation in recent Linux kernels). (I have a Linux device driver that implements this interface; it is very simple, needing only to sample the bits, pack them into bytes, and manage mutual exclusion, filesystem housekeeping, and probing.) Here are the particulars of the "dongle" board I'm in the process of making. Noise source: an FM/IF radio receiver chip, with no input supplied, so that the IF amplifier chain produces wideband noise at its output. I'm looking at the Motorola MC13158 and the Philips SA626. Each provides about 20 MHz of IF bandwidth, and the Motorola part has an on-chip comparator, reducing the entire device to two chips: the receiver chip and an HCMOS flip-flop. Power: from the port data lines; >=3.5V at about 20 mA is available. 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. Cost: around $10 in parts, I guess. A rate of 300 kB/s will make a 600 MB one-time pad in an hour (assuming software is similarly fast). I'm wondering if any of the mail systems have convenient hooks to use pads (though it would not be difficult to write up). Suggestions welcome. I'll put the design on the Web once it's finished; replicating it should be pretty easy. People can also grab the device driver if they wish. Cheers, Peter Monta pmonta(a)qualcomm.com Qualcomm, Inc./Globalstar

1 0

world smartcards..
by John Young 17 Dec '03

17 Dec '03

Responding to msg by msew+(a)andrew.cmu.edu (Martin C Sweitzer) on Tue, 14 Nov 3:51 PM >Anyone know what kind of encryption they will be >using... HP's web site at <http://www.hp.com> has more info on the cards and the related "international cryptographic platform" being crippled and begged and groveled to USG for export. Try the site's search feature for "encryption" to poke around HP's various products, where some of the crypto to be employed is cited, if hypocryptically.

1 0

Re: NSA, ITAR, NCSA and plug-in hooks.
by Rev. Mark Grant 17 Dec '03

17 Dec '03

On Tue, 14 Nov 1995, Raph Levien wrote: > I move we file a CJR on some suitable software with crypto hooks. If you want to get really warped, feel free to file a CJR for Privtool, it's a mail program with crypto hooks but no crypto, and has the added advantage of being written outside the US but still illegal to export, as far as I can tell (certainly it's now on the export-controlled section of c2.org) In fact, maybe I should file one myself, as it's a real pain to have to tell non-US users to get it from a non-US site rather than the 'official' distribution site at c2.org. Can non-US citizens do these things ? Mark

1 0

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

17 Dec '03

Scott Brickner <sjb(a)universe.digex.net> writes: >Jeff Barber writes: >>Does anyone know the ostensible justification for this? What section of >>the ITARs do they point to when they say "this is illegal"? I've perused >>an online copy of ITAR (no, I haven't read all of it -- I have other >>things I want to do this year :-), but I can't find a section that could >>be construed to support this contention. > >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?!?

2 1

Cypherpunk FAQ
by cassiel＠alpha.c2.org 17 Dec '03

17 Dec '03

Hi, I'm new to the list, so please don't flame me too badly if this is a dumb question. At least restrict the flames to private email where no one else can hear me scream. :> I downloaded the Cypherpunk FAQ from the Cypherpunk Website. When I decompressed it, all it contained were the words "Yoo hoo, anybody home?" Has the FAQ been corrupted or is this an in-joke? Also, the Privacy FAQ states it was written by L. Detweiler. Is this THE L. Detweiler? If so, why is it in the archives? Thanks for helping me out. Cassiel

1 0

Get your own ITAR
by Rich Salz 17 Dec '03

17 Dec '03

1 703 875 6644. The kindly administrative assistant there will take your name and address and send you a hardcopy of the ITAR regulations. I don't know about overseas mailings. I also imagine you will have to wait until the current US budget stale-mate is resolved. (Thanks to digest-reader walt(a)osf.org for the phone number.) /r$

1 0

Re: credit card conventional wisdom
by Greg Broiles 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Detweiler writes: > the argument goes like this: secure credit card number uploading > schemes (such as in Netscape) are not important on the internet because > credit card numbers are already insecure. you give them to low-wage > workers all the time who might steal the number from you anyway. > there are a lot of fallacies with this. I find this to be a key > cypherpunk issue, and I hope others will agree to the point of > trying to attack this fallacy through letters to the editor, > debates, etc., because it seems to rationalize weak security. You're only reproducing half of the debate, which goes like this: Businesses/customers won't trust the Internet for commerce, because it's not perfectly secure. And then others go on to point out that businesses and consumers do business every day using commerce tools whose security features are weak to nonexistent. So, no, we don't have to "get the Internet ready for business" because it's already at least as secure as ordinary consumer transactions. This doesn't mean that it's not important to work on security, just that it's a useful direction for improvement, not a baseline requirement. Most consumer-level transactions are based on a general sort of trust-in-human-nature sort of policy, backed up by the knowledge that a single failed transaction (or even a constant low level of failed transactions, where failed == "didn't get paid but gave the stuff away") isn't likely to kill off a business or even make it unprofitable. Loss by theft or fraud can be thought of like any other sort of overhead - and it doesn't make sense (financially) to spend more to eliminate it than you'll recover by that elimination. Pursuing criminal or civil charges against a non-performing party is expensive - most people do it out of a sense of moral outrage, or because they want to maintain a public perception of unforgiveness, not because they really think they'll get back what they've expended in time, money, and opportunities lost for other (more profitable) pursuits. (see Axelrod on the Prisoner's Dilemma tournaments for the arguable game-theory C-punks cryptoanarchy relevance.) -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMKlcz33YhjZY3fMNAQEAlwP7B+cP/IB1wZ0TeWwwoL5j9z4m5irIO9yV O5599i6fiJ2X3+HbJKGY0/aENs1Zq6kNPHo1I/HcjBhN3fazwelv5BV1dFfmnfUp lPA8DOTraM7qGse6JEpG+tyJa7bL4wadjDAlFVe4uPSxokw1gppBMkZa6pcwd3cX zQ7ammmgeQI= =ZZi9 -----END PGP SIGNATURE-----

1 0

Applied Cryptography MPLS Book Release Party
by Karen E Cooper 17 Dec '03

17 Dec '03

APPLIED CRYPTOGRAPHY 2nd Ed. BOOK RELEASE PARTY Please come out and meet author Bruce Schneier at a drinks and hors d'oeuvre reception to celebrate the publication of Applied Cryptography, 2nd Ed. The reception is in Minneapolis, Minnesota on Wednesday, 29 November, 1995, from 5:00 to 8 pm. RSVP for directions and specifics. Karen Cooper (612) 823-1098 kecooper(a)maroon.tc.umn.edu

1 0

Re: encryption in BeOS kernel
by tcmay＠got.net 17 Dec '03

17 Dec '03

Either John Young or someone imitating his style wrote: >Would chip-fabbers covertly Fortezza chips to get export ok? > I have no idea what "Fortezza" means as a verb, but I'll Moscow a guess: Intel might, according to this guesser, insert NSA-approved back doors in "information appliance" chips. Unlikely in the extreme, for a variety of reasons. First, designers cannot keep secrets. Second, examination of the chips would reveal such meddling. Third, Intel is only one of several likely providers of such chips (e.g., Oracle is said to have plans to use Acorn ARM chips, and DEC may also provide low-end Alpha chips, and of course Motorola-IBM has variants of the PPC to provide). >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? Too much Pynchon? --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."

1 0

Re: credit card conventional wisdom
by anonymous-remailer＠shell.portal.com 17 Dec '03

17 Dec '03

On Tue, 14 Nov 1995, Greg Broiles wrote: > Detweiler writes: > > > the argument goes like this: secure credit card number uploading > > schemes (such as in Netscape) are not important on the internet because > > credit card numbers are already insecure. you give them to low-wage > > workers all the time who might steal the number from you anyway. > > > there are a lot of fallacies with this. I find this to be a key > > cypherpunk issue, and I hope others will agree to the point of > > trying to attack this fallacy through letters to the editor, > > debates, etc., because it seems to rationalize weak security. > > You're only reproducing half of the debate, which goes like this: Actually, this is not quite correct. There is a difference if I give a credit card to *one* person, or if I give the message containing that number to a chain of twenty or thirty strangers to get my information to the one person I want to have that information. We're back to handing your card to the neighbour, who gives it to the doorman, who flags the cab and gives it to a cabbie, who then drives cross town and gives it to another doorman, who then etc, etc. Something completely different than the long bomb from the quarterback. Our potential interception points have increased substantially ... and we have absolutely no audit trail to figure out who *might* have scarfed the card. I guess the average customer won't care. His loss is limited to $50. But some of us who try to live in the real world wonder how long that'll last. Can we measure the life of it in a matter of weeks?? Or months? > Businesses/customers won't trust the Internet for commerce, because it's > not perfectly secure. > > And then others go on to point out that businesses and consumers do > business every day using commerce tools whose security features are weak > to nonexistent. Hmmm ... maybe we'll even get a whole whole new industry going ... don't ya think?? Maybe we can create a whole new set of risks which are additive to those we already have. Maybe every petty grifter might trade in his very own credit card number and simply claim that their credit card got stolen over the internet. Just disappeared into the anonymous aethyr ... the one without an audit trail ... but my loss is limited to $50, right?? I guess other people understand systems much, much, more than I do. I guess that the NY Times is right ... it won't change the loss rate for the card companies, at all ... nope ... won't create a new problem ... naahh ... the public wouldn't actually take advantage of holes like this in the system. Nope, no sirreee ... Give your head a shake. Alice de 'nonymous ... ...just another one of those... ...hunters... P.S. This post is in the public domain. C. S. U. M. O. C. L. U. N. E.

2 1