-----BEGIN PGP SIGNED MESSAGE----- Cypherpunks, Q. What do I mean, standards? A. A set of specifications that will allow encryption modules to be incorperated into receptacle encryption interface programs easily. The advantages of programs that comply with the CP standard might be illustrated with an example. Suppose Alice wants to use an interface program, say, GENPGP.EXE, to encrypt a message to Bob. Suppose that GENPGP is an interface encryption receptacle program that allows users to add and use their own encryption modules of choice. If Alice were a command line freak, she could type: GENPGP -RSA_encrypt_the_session_key \ -random_session_key_source ISA_Johnson_Noise_ADC \ -chainsession \ -blowfish -rounds 18 -keylength 2048 \ -idea \ -3descfb \ -compress pkzip \ -plain_text_file topsec.doc -receipient bob Or, suppose Alice is a GUI freak. In this case she could use her entcrypt_lab schematic interface to design and save her encryption scheme for topsec.doc, and simply drop the icon for the doc into her block diagram's input icon. Bob, in either case, is still able to use his own program of choise, GNU_safe_mail, to automatically decrypt Alice's message to him, so long as Bob has incorperated all of the latest modules availible. Q. What are some advantages? A. There are numerous advantages. Some programmers are good at writing user interfaces, and others are better at implementing algorithms. Currently, many programmers of the second type make all sorts of encryption algorithms available, but these are not always easily understood by programmers of the first type, and more importantly, coded algorithms are not easily incorperated into existing programs. Another problem that may arise is that existing programs, and programs that may come out in the next year or two, may gain widespread use (e.g. PGP.EXE), but may at some time in the future become practically worthless, for example, if widely used interface programs rely on encryption algorithms that are discovered or perceived to be weak. If a standard such as the one I am proposing is released and gains acceptance, more programmers will comply, and this will allow the users of their interfaces to painlessly adapt the interface programs. More importantly, such interface programs that make use of CP complient encryption modules will allow users to encrypt as insecurely or securely as their parinoia dictates. Also, as new encryption algorithms are invented and coded, hackers who like to optimize may take the extra step and make their code CP complient. And command line Alice will be able to type: GENPGP -add_module BlowFish.mod Q. What are the disadvantages? A. At first blush, one disadvantage is options, like PGP's -m, (for your eyes only) are not practical for a standard such as the one I am proposing. But then again, even using the command: PGP -em susan.doc is little more than a suggestion to the recepient of the letter to not keep the plaintext around. Q. Why should we? A. If we don't, IEEE or some other organization is bound to, and IEEE seems to be getting more politically correct as the years pass, and this doesn't seem to be compatible with the purpose of an encryption module standard. Consequently, I believe that such a task should be initiated and taken to completion by a renegade group such as the cypherpunks, by committe if possible, with the hopes that government moles will not weaken our effort. Mike Morgan -----BEGIN PGP SIGNATURE----- Version: 2.6 iQCVAgUBMNBuvbwEeVpjJyiBAQEi5QP/T9FmRS2nwWq0lr9iT+cQWMEMV1++Hpf3 u0OWnYYFlRjgJPxTa5vT549tgGeRGV+CB+TI6N3Aj96+LTWb34qS5Y0W2x7R5FEg +XnACQRs9G5qIK4Zn114KlWXyx7Mj0QQCeo4h86gISdrWkfSJiYkwEoGgzcf6ocF gp45YZLznnk= =cMFk -----END PGP SIGNATURE-----