[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Cypher_punks standards, again.
-----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-----