In response to everyones comments: I am overwhelmed with all this response that came though during the times I was absent from the Nets. At this time, I am evaluating other approaches to this problem then using the Newbridge system's inflated pricey hybred circuit. It is clear that a simple reversed diode circuit may not be enough to produce truly random data bits unless care is taken to prevent periodic signals from being "injected" into the circuit. Although I don't have access to a "clean lab", I do have access to Techtronix scopes, and a general HW lab, but not sure if that is adequate to completly test out the circuit to determine that things are truly random. An easy test I often devise is to generate a pair of random bytes, and display them as X, Y pairs and plot them on the screen as pixels. First, I start with a clean screen, then plot the dots as they come in. As these dots are plotted on the screen, the dots should be evenly distributed over the screen without "bunching" or "patterns" developing. I know that this is not the best way to determine true randomness, but it is cheap and inexpensive to do. I also agree that we should all check out and determine if there are other random generators currently available, and we should compile a list of them to share with the group as proposed by Tim May. Although I haven't yet visited the crypt newsgroups, I suspect that I should post a query there to see if any such puppie exists. Then, there is the speed of generating these random numbers, and how we will want to deal with the possibility of inadequate speed. I suspect that serial transmission at 9500 baud might be easily obtained, but going much faster withoug "drift" might be problematic as Tim May pointed out. At this point, I would now like to get some other feedback from the group on what Zener noise source to use, and kick around some design ideas. It would be nice to be able to exchange schematic diagrams and pass them around. I have a Mac, but not everyone in this group uses them. So what mechasim can we imploy to send schematics around? My next visit to the Nets will be this weekend, so if anyone wants to contact me, they can try me at (510) 769-1268, and it will refer to the number where I'm staying at that time. I still have NO permenent home (after long period of unemployment), so getting on the Nets daily will be problematic for me. I usually hang out in South San Jose, at my friends VCR Repair lab (where this hardware equipment is located), but have no computer set up there until we can set up proper physical security. That number is (408) 377-2382. I am usually there early in the week, because I can make calls to find work from there on Mondays. As I converge into a workable design and if the lab results are encouraging, and acceptable to the group, I would like to build 2 or 3 prototypes and pass them around to volunteers for Beta testing before making them available to the group as a whole. I can get PC boards made via Douglas Electronics fairly inexpensivly, and plan on making them as orders come in, and initial setup costs would be about $350. I already have people set up to invest this much already. Perhaps it would be prudent to set up a group of other HW designers and meet physically somewhere to hammer out a design and make this a group effort. Do I have any volunteers? I think only one meeting would be necessary to determine a rough approach to take. John D.
From: crunch@netcom.com (John Draper)
Then, there is the speed of generating these random numbers, and how we will want to deal with the possibility of inadequate speed. I suspect that serial transmission at 9500 baud might be easily obtained, but going much faster withoug "drift" might be problematic as Tim May pointed out.
I'd like to point out that higher data rates are very very desirable. One would like to be able to cut a pair of CD's for use as one time pads in a reasonable amount of time -- at 9600 baud its going to take a LONG time to do. You can always run multiple units in parallel, but its probably good to get the cost/bitrate ratio as low as possible. Perry
I'd like to point out that higher data rates are very very desirable.
And higher data rates are more expensive. If you're making one time pads, you need high bit rates, but otherwise you don't. 10Kbps is overcapacity for personal use. Let's do an estimate. Suppose all you use your random numbers for is to create session keys for socket connections. Now lets say you need to open a socket about once a minute. Since you need, say, 500 bits for a DH key exchange, that's a bit rate of about 10 bits per second. One can cache bits coming in from the random number generator in a ring buffer. You can make this ring buffer arbitarily large, or even virtualize it to disk and make it appear as infinite in size. Then you could run your generator continuously and always have enough bits available for use. If you're using a generator for making session keys, then you just don't need that high a bandwidth. Now the $/bps for the Newbridge chip is much lower, but for personal use you throw away too many of its bits to make it worthwhile. This higher bandwidth chip would be useful in a server of some sort, where you are making session keys more than once per second. Proposal: Make this random number generator operate at 100 bps. If higher bit rates are the same price, fine. But a specific design criterion of 100 bps should be a practical and economical goal. Eric
participants (3)
-
crunch@netcom.com
-
Eric Hughes
-
pmetzger@shearson.com