One thing that frustrates me is the difficulty of easily providing implementations of cryptographic algorithms that would be useful on a wide range of machines. A lot of these algorithms are really simple, almost trivial. Yet to write programs to implement them takes pages and pages of code, and making them portable so that people on PC's, Mac's, and Unix machines can use them is almost impossible. Take the simple Chaum cash we have discussed here a few times. The user picks a random x and a random r, calculates r^3*f(x) where f is some one-way function, and sends it to the bank. The bank takes the cube root and sends it back, then the user divides by r. That's pretty simple. Yet to actually implement software to perform these steps raises a host of complications. First, we want to choose a "random" x and r in the range 0..m-1, where m is the bank's public key modulus. But we want these to be strong, unguessable random numbers. We need an unpredictable RNG, and we need to seed it. There are various URNG's that are provably as strong as breaking factoring, discrete logarithms, and such, so these would have to be implemented (as before, most are conceptually trivial). Or you could run DES or IDEA in a feedback mode and take bits from there, for a little less security but more speed. For seeding the RNG you could do like PGP does and retain random numbers from earlier runs, mixing in new randomness when feasible; you could do like RIPEM and scan disk partitions hoping for randomness (I think RIPEM has a lot of other ways of looking for entropy); you could use hardware features like /dev/audio or the free-running, high-speed timers some PC's have; you can get the user to click the mouse or type keys at random. OK, we've got our random numbers. Now we want a one-way function. Again, there are several choices: MD4 and MD5 from RSA; the Secure Hash Standard NIST is pushing; Ralph Merkle's (I forget the name); others based on conventional ciphers like DES or IDEA. Implementations of these are probably available, but portability is a question mark. Now we need a multi-precision math package. We may have needed one for the URNG, too. There are a lot of libraries available in source code for these, but not many of them will work with 16-bit ints, and are tested on DOS and Mac's as well as Unix. Finally, to send the data around, we may want to convert to and from ASCII, and once again there are a lot of choices, but perhaps not too many portable libraries. I suppose RFC1113 and MIME, which are similar but not quite identical, would be the encodings of choice. The point I'm getting to is that it would be nice if all this were done ONCE, and a library made and tested which would work on a wide range of machines. Entry points for one-way functions, multi-precision arithmetic, unpredictable random numbers, conventional encryption, and ascii conversions could all be provided. Multiple alternatives would be supported as much as possible and it should not be difficult to add more as time goes on. Once you had such a library, it would be possible to add a user interface to allow interactive use of the routines. It could be as simple as the Unix "bc" program where you can say "x = y*z" to do arithmetic, or perhaps "x = md5(y)" to call a one-way function. Or the library could perhaps be linked into perl or some other high-level program (does mathematica have hooks for compiled user code?). The nice thing is that since most of the compute time is spent doing the MP arithmetic in these algorithms, an interpreted system which calls compiled libraries can be as efficient as a purely compiled program. I know that others here have made similar proposals in the past, but I have not heard of many results. I'd like to hear more about whether these efforts have produced anything that could be incorporated. It would also be good to hear suggestions for specific existing packages that would meet the portability requirements. I've looked at a couple of MP packages from ripem.msu.edu but so far I haven't had much luck running them under DOS. Perhaps a project like this could allow progress to be made more easily toward cypherpunk goals. By providing a toolkit to programers newly interested in cryptography people will be able to try out ideas more easily without having to re-invent the wheel each time. Let me know if you would be interested in participating in this effort. Hopefully a lot of the pieces already exist and it will just be a matter of pulling them together. Hal Finney hfinney@shell.portal.com