1995-02-13 - standards…

Header Data

From: M00012@kanga.stcloud.msus.edu
To: cypherpunks@toad.com
Message Hash: 71def5ec7187579a9d7d86dfcb7c52e4799c0b4da34533aceeda3e17004d2075
Message ID: <950213011700.34a5@kanga.stcloud.msus.edu>
Reply To: N/A
UTC Datetime: 1995-02-13 07:17:00 UTC
Raw Date: Sun, 12 Feb 95 23:17:00 PST

Raw message

From: M00012@kanga.stcloud.msus.edu
Date: Sun, 12 Feb 95 23:17:00 PST
To: cypherpunks@toad.com
Subject: standards...
Message-ID: <950213011700.34a5@kanga.stcloud.msus.edu>
MIME-Version: 1.0
Content-Type: text/plain


-----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-----





Thread