To Cypherpunks: I think I have a rough description of the hardware serial random generator I want to build. I want to call it the "Rander box" for lack of a better name. It will have two serial connectors, one an input, and other the output, and connect to a modem or serial port. Physically, it should have dip switch to select baud rate, and an on-off switch. When switched on, and a "cr" (or some other character) is sent to it, random bytes will stream out continiously. Another "cr" will stop the byte stream. At least this is ONE approach. If anyone can think of a better way, Pse speak up. Next week, I plan on consulting with another hardware guru and formulate an initial design. I already know what components need to go into it, and now I want to try and eliminate an extra UART if I can figure out how to turn on and off the random stream via software. The internal code of PGP (I am told) uses an internal buffer to hold the random bytes, generated my environmental changes such as key strokes, mouse movements, or other external actions. Some of the Mac implementors are discussing the feasability of not maintaining 100% portability. I suggested that we break up the PGP program into four parts. a) Incryption engine b) Key management engine. c) GUI interface (DOS, MacOS, UNIX, Windows, etc) d) Random number generator (machine dependent, possibly hardware) Parts (a) and (b) are the "portable" parts, and (c) and (d) are the machine dependent parts. Because the Mac is not multi-tasking, we can get around that problem by implementing a random number generator as a driver. Mac drivers provide for "periodic" code to be called as often as possible, and there are plenty of places where this driver can "look for" environmental changes to generate random numbers using the hashing stuff that Phil implemented. Naturally, the IBM-PC and UNIX versions of software random number generation would be different. But as far as the Incryption and Key generators are concerned, all they need to do, is to look into the random "seed" buffer. Implementing the random number generation as a driver also affords the possibility of having total independence of a hardware device, and if one is desired, no changes to the code will be necessary to have one. We just drop an appropriate INIT into the system folder which will contain the appropriate driver. This is the Mac way of doing things. One other problem I am having in participating in this group is the extra phone expenses I will have. I cannot get on Netcom's local lines from here anymore because they are always busy, and there is a lot of other unconsiderate people that hog up all the local lines for many hours at a time, so mail responses to and from me, may take days. For instance, I cannot participate in any IRC chats unless I get local access, as I am unemployed and cannot afford to call out of my area. So please excuse any slow responses you might get from me. John D.
It will have two serial connectors, one an input, and other the output, and connect to a modem or serial port. Physically, it should have dip switch to select baud rate, and an on-off switch.
Some simplifications I might suggest: I only think you need an output connector. See below. If you can power it off the RS-232 line, you won't need a power switch. You should be able to draw enough power off, say, the DTR line to power a simple thing like this. For a dedicated random number generator with low bandwidth, there's not much reason for variable baud rate. I'd use a fixed baud rate of, say 1200, or even 300. If you make it low enough you could just kludge together a serial interface, but with the low cost of UART's, it's probably not worth it. You might also consider using a PIC, which has built-in serial.
When switched on, and a "cr" (or some other character) is sent to it, random bytes will stream out continiously.
I'd just make the thing spew continuously. It's not like you're losing real, er, information if you ignore a few random bits. This way you don't need the added circuitry for switching on and off. The actual use of this thing is going to require a device driver to buffer up random bits for later use. So all the flow control to the higher layer happens there anyway. And if the UART buffer overflows, so what? Eric
From: crunch@netcom.com (John Draper)
I think I have a rough description of the hardware serial random generator I want to build. I want to call it the "Rander box" for lack of a better name.
It will have two serial connectors, one an input, and other the output, and connect to a modem or serial port. Physically, it should have dip switch to select baud rate, and an on-off switch.
When switched on, and a "cr" (or some other character) is sent to it, random bytes will stream out continiously. Another "cr" will stop the byte stream. At least this is ONE approach. If anyone can think of a better way, Pse speak up.
Why two serial connectors? RS232 is bidirectional, so you could send control signals down the same pipe the output comes off of. Also, why bother decoding the CRs? Seems like overkill. You could just have CTS/RTS or other lines on the connector control whether bits are clocked out or not. Perry
From: Eric Hughes
Some simplifications I might suggest:
For a dedicated random number generator with low bandwidth, there's not much reason for variable baud rate. I'd use a fixed baud rate of, say 1200, or even 300.
I strongly disagree -- you really want to be able to do as high a bandwidth as possible. You might think we don't need one time pads ever anymore, but they are still the one and only provably absolutely secure method out there -- thus, sources of large numbers of random bits are going to be of use.
When switched on, and a "cr" (or some other character) is sent to it, random bytes will stream out continiously.
I'd just make the thing spew continuously. It's not like you're losing real, er, information if you ignore a few random bits. This way you don't need the added circuitry for switching on and off.
Bad idea. If I hooked it up to my workstation, I'd end up spending lots of CPU on the thing and possibly get nasty problems with buffers filling. Not everything on earth is a PC that will ignore the interrupts if the port isn't in use, you know. Perry
Perry on random bit rates:
I strongly disagree -- you really want to be able to do as high a bandwidth as possible.
Cryptography is all economics. The economics here is that John Draper is going to try to market this thing, not play with it in the lab. I don't know what experience you have with electronic design, so pardon me if I condescend. You don't sell features that most people don't need. You don't add parts when only a few people are going to use the feature. You make another version if there is sufficient demand for higher performance. One-time pads are expensive to make relative to other forms of security. Period. No argument. George Gleason and I had a long conversation via email over a period of weeks about this. He was convinced. If you don't believe me, ask him. The largest need for random bits right now is for key material. If you want to use one-time pads, fine. They are secure, no problem. The random number generator we are discussing here is not suitable for making one-time pads. If you want one, build it. It's not what most people need right now. In fact, if one-time pads are economical to use, then surely there is a market for one-time pad systems. Of course, if such a market does not exist, then one-time pads don't provide economical protection for the market as a whole. Which do you think? Re: continuous spewing of bits. Perry thinks this is a bad idea because it won't work with workstations well with respect to interrupts. In my previous post, I mentioned powering the device from DTR. DTR, for those of you not familiar with RS-232, is a device control line which is separately assertable. To turn the device off, toggle DTR. Presto! No more power, no more bits. Simple, when you know what DTR does. My original point remains, though: you don't need a power switch. Eric
Some of the Mac implementors are discussing the feasability of not maintaining 100% portability.
If portability was a problem, the Mac would certainly be an answer. Howabout actually trying to be Real Programmers and writing Real Software, like the folks who did all the work that you are now benefiting from? Instead of writing dead-end software that will only live on one platform? I know it isn't the Macintosh Way, but you might learn something. The last thing PGP needs is an installed base of Mac users who are always stuck three revs back because they forked off their own wierd version and couldn't upgrade when the rest of us do. John Gilmore
participants (4)
-
crunch＠netcom.com -
Eric Hughes -
gnu＠cygnus.com -
pmetzger＠shearson.com