[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
standards...
-----BEGIN PGP SIGNED MESSAGE-----
Cypherpunks,
Secure encryption programs should be / have (imo):
1. Dynamic, allowing the user to select types of encryption
on a per session basis, and to allow them to add crypto
modules as they are developed in the future.
2. Easy to use.
3. All source code availible--allowing users to fully
compile (and examine) the source code.
Such programs should make use of encryption modules or
libraries, and should be able to easily adapt to new
modules as they become available.
An encryption module standard will help facilitate the
creation of the type of programs decsribed above.
Some feateres...
I. Public key encryption.
A. Uses slower public key encryption to encrypt one or
more session keys for one or more block ciphers.
B. Be used alone on larger blocks of data. (The future
may hold public key encryption algorithms that
make this practical.)
C. Not limited to one public encryption scheme.
C. Function/format standards that allow user
interfaces to implement various public key
crypto functions.
II. Block Ciphers
A. Each block cipher has a committee assigned
identification number.
B. Uses of random session key for encrypton for
non-public key encryption.
1.) Random session key is encrypted with
hash of user supplied password.
2.) Encrypted session key is appended to
ciphertext.
C. Functrion/format standards for easier chaining
of multiple block ciphers in user interfaces
that implement these functions.
1.) Minimize/mitigate/eliminate use of layer
headers that would serve as known plaintext.
III. Compression
A. Perhaps implemented in the same or similar format
used for block ciphers.
B. Compression with a session key/random buffer
source? (Used to alter any tables and/or
mitigate known plaintext attacks, e.g., if
5 bits of a header are unused...fill these
with unpredictible bits to be masked off
latter during decompression.)
C. Function/format standards, even though this will
be, if a compression function is selected, the
first function called)
1.) Minimize/mitigate/eliminate use of layer
headers that would serve as known plaintext.
IV. Hash functions...
V. Validation (password and sig.s)
VI. Unpredictible (true random) number generation/distribution.
VII. Variable key lengths.
Of course, this requires _STANDARDS_. The cypherpunks are
the ideal people to define these standards (and start writing
such modules). If others are working on this, I'd like to get
a copy of the standards so that I can contribute some code,
otherwise I am willing to help draft the standards--although
the significance of my contributions might amount to an
occasional unoriginal idea.
Some of the qualities listed above, it seems to me, might call
for the use of C++, although C is preferable.
Mike
- -----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.6
mQCRAi8v0bMAAAEEAPd2Gn0tnUbEpituh2XrgtHBzSWg7joLHIFXLIQ2vFOcAlE2
9MxS/XuX0sl+Mm6Ix8Vc7gg0Jutb35PvXHy+TaHk9OuOOGGIWMUspd0GmZFTEdhv
nE49BltVmJpEXOU4vVxtVEMZAeewndRCfypYDRYbG1TpCCtvVrwEeVpjJyiBACEB
AAAAAbQmTWljaGFlbCBTLiBNb3JnYW4gPG1tb3JnYW5AZGlnaWJkLmNvbT6JAJUC
BRAvL9SKvAR5WmMnKIEBATQ5A/9h14BcFvpMX2O98iBOlrNlXvppMdQ8KnOfruBH
usg2tvZmynlajFItfTtaVxHQrQNAeQ+P1Ju846wqx+Y/IYHegvS7u7LvPpXIbPHo
Ko8DOgQkH2I3ko2QcNwDsBQvDxGtmx6wVZa0TXt/mmgHTeU6blhsXmyWvIqkeiah
xLn897QYRE8gTk9UIFVTRSBBRlRFUiAzLTE1LTk1tBFFeHBpcmVzOiAgMy0xNS05
NbQaUGVyc29uYWwgVXNlIG9ubHksIHBsZWFzZS4=
=eO8G
- -----END PGP PUBLIC KEY BLOCK-----
-----BEGIN PGP SIGNATURE-----
Version: 2.6
iQCVAgUBLy/ZbbwEeVpjJyiBAQGClQP9FK4Er+WzSe4uAZNxJdqciXlX3XTFGeh2
WDXHF8yAfyPEmKOxnbgdD50sWoTJXf+ZQqcxKiBASn8HNmegPHy7NUFqJnU5+/Ma
oV6TK27doKf06l8B7Q0hLywQgRIWBeRuJqjD2FVr7pynLBYRjnRhHZPt8fHSkGYq
KJ4ui9mBcOA=
=/37d
-----END PGP SIGNATURE-----