Greetings fellow cypherpunks: A lot has happened since I got on here last Friday. My previous message contains my public key, Pse use it if you want to send me private mail. I bet the NSA boys are tearing the hair out of their heads by now, but it's about time we do something to preserve our privacy. It is my plan to help "organize" the Mac implementation of PGP, by putting together a Mac Implementation team of programmers to beef up MacPGP, by added better GUI, such as cutting and pasting of keys DIRECTLY into key rings without having to go through a file (makes for added security). My plans also call for tight coordination with the other platform development teams. I've been getting good support for my ideas on implementing machine independent modules or "Libraries" of PGP routines that don't include I/O portions, but after looking at the code, I see this is going to take a lot of work, both in organizing the effort, and in implementing the code. Just how this is going to be done, I'm not sure, but this is what cypherpunks is all about. To hash these things over, flame on each other's ideas, etc. So far, the Mac inplementaion team consists of the following individuals, and are (or soon will be) working closly with Eric Hughs, Phil Zimmerman, and the other PGP folks Mac PGP team: Richard Outerbridge [71755.204] Jim Clausing internet: jac@cis.ohio-state.edu Zbigniew Fiedorowicz internet: fiedorow@function.mps.ohio-state.edu INTERNET:crunch@netcom.com INTERNET:crunch@netcom.com Doug McNaught internet: doug@midget.towson.edu Philip Zimmermann internet: prz@sage.cgd.ucar.edu I talked with another individual last evening who also wants to be added to the team, but the others haven't yet been introduced to him yet. It is my plan to propose this idea to the PGP meeting at Sygnus this upcoming Saturday at noon. Then, I'll report to those that couldn't make it, due to their location. The progress on the Rander box is as follows: I am currently evaluating several proposed designs, and have sent out queries for data sheets on devices I plan on checking out for use, prices, etc. I have been studying the PGP code, and can see it's going to take a lot of work to get it into a form where true machine portability can be realized. As a Mac purist, a abhore the idea if translating Mac GUI actions into ascii text and sending it to the current PGP "engine". Although it would take a lot of work, I propose that we develop PGP to have the following form. a) Encryption engine library - Main set of routines currently in the PGP program dealing with encryption of data. These would be a set of "support" routines that would permit encryption of data in files, as well as data in memory. These would be totally machine independent, and only ONE set of sources should exist and contain compiler options for platform specific code. These functions would then return error codes instead of console output. Needed "key phrases" can be passed in as "char *", and sucessful operations would return NULL or if error, an appropriate code be returned. Other routines would be necessary, such as telling it where the random ring buffer is located, and how long it is. These routines would maintain their own pointers into this buffer. This library would call routines in the Random number manager and pass information such as where the buffer is located. See below: b) Key management library - Main set of routines that know how to manage the keyring files, it would have functions designed to extract keys, add and remove them, and work on the keyring files directly. Again, these would be machine independent routines. This would also call routines in the Random number manager below. c) Random number management - Main set of routines to manage a "circular buffer" of random numbers used to generate keys. This would work with both software and hardware random number generators, and would provide externally machine independent functions, but internally they would be machine specific. d) GUI's for the various PGP application programs. Mail management, file management, network applications, etc, all calling the routines in a,b, and c. Also includes Hypercard Xcmds, etc. Items a and b should have only ONE set of source code, and be maintained and managed by existing people. Items c would also be same source code, but have conditional compiler statements to "switch in" the machine dependent portions as apppropriate. I think it's possible to design the code in a and b to have very few machine dependent conditional compiler #ifdef statements, by forming the main PGP guts portion to operate on textual input in the form of "char *" instead of console input, and let the calling code pass "char *" to PGP library routines. Machine dependent stuff is in (d) and might include existing UNIX PGP "main()", Mac PGP main application, and lower level "utilities" such as Hypercar XCMD's etc. In fact, it is even possible to build these libraries to use NO global variables, and use structures instead. But me, being Mac biased, will probably get a lot of resistance to this proposal, but it is just that, a PROPOSAL. At any rate, I think that portability issues would be better solved if we were to adopt C code portability and to assume that not ALL platforms work well with console type input, and that Console I/O should be "factored out" of the machine independent portions of the existing PGP code. So, what way folks, has anyone got a better idea or proposal? Cheers JD
crunch@netcom.com (John Draper) writes:
Greetings fellow cypherpunks:
I've been getting good support for my ideas on implementing machine independent modules or "Libraries" of PGP routines that don't include I/O portions, but after looking at the code, I see this is going to take a lot of work, both in organizing the effort, and in implementing the code. Just how this is going to be done, I'm not sure, but this is what cypherpunks is all about. To hash these things over, flame on each other's ideas, etc.
It would be very nice if PGP behaved better as a UNIX filter. For example, I'd like it to return an exit code if it fails. I'd also like it to have a flag that disables any access to the tty for prompts. For example, if I have an automatic filter that tries to decrypt all incoming messages, I don't want it to prompt for a secret ring file when it can't decrypt something. A very important addition to PGP would be multi-recipient encryption. RIPEM implements this nicely, by having one private key (PGP has this too - it uses IDEA) and encrypting this key with each recipient's key. We could then run this list encrypted, in order to excercise PGP and to see what user interface issues become important with heavy use. (Not much security is afforded because of the public nature of the list.) -- Miron Cuperman <miron@extropia.wimsey.com> | NeXTmail/mime ok <miron@cs.sfu.ca> | Public key avail AMIX: MCuperman | immortalcybercomputinglaissezfaire |
participants (2)
-
crunch@netcom.com
-
miron@extropia.wimsey.com