From: cactus@seabsd.hks.net (A Loose Affiliation of Millionaires and Billionaires and Babies)
Date: Mon, 13 Feb 95 00:22:11 PST
To: cypherpunks@toad.com
Subject: Re: standards...
Message-ID: <199502130818.DAA25598@bb.hks.net>
MIME-Version: 1.0
Content-Type: text/plain


-----BEGIN PGP SIGNED MESSAGE-----

- -----BEGIN PGP SIGNED MESSAGE-----


>Such programs should make use of encryption modules or
>libraries, and should be able to easily adapt to new
>modules as they become available.

Hmmm.  Did you come in late, or have you seen my posts about the crypto
library I'm working on ("Hastur Crypto Toolkit," nee "GUCAPI")?

>  I.  Public key encryption.
>      C.  Not limited to one public encryption scheme.

AFAIK, RSA is the only feasible PK scheme available.  There's eliptic
curves, of course, but that's patented.

> II.  Block Ciphers

Needn't be block.  Stream cipher works perfectly well for the "fast crypto"
symetric cipher part.

>      A.  Each block cipher has a committee assigned
>          identification number.

Why a number?  When you can choose between a number and a human-readable
string (and space is not a big issue), choose human-readable.

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

Hmmm.   If the session key is a hash of a password, then why on Earth
would you include it?  

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

We shouldn't be using ciphers that are vulnerable to "known plaintext"
attacks.  RSA is known to be vulnerable to "chosen plaintext" attacks
(see Schneier), but is useful enough that we work around this shortcoming
by RSA encrypting only hashes and session keys.

>III.  Compression
>      A.  Perhaps implemented in the same or similar format
>          used for block ciphers.

Naturally.  In fact, encoding, encryption, and compression are the same
thing: mapping one set of numbers into another.

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

As far I know, there are two standards: the PKCS #11 document from 
RSADSI, which I do not care to follow if I can avoid it.  The other
is the IETF GSSAPI, which should be accomodated.

In general, I very much agree with the thrust of what you're saying.
Which is why I'm folding the crypto work I already have to do for
my company into the larger "general solution" approach.

If you haven't read my postings on GUCAPI/Hastur, please go back and
take a look (send me mail if you'd like a copy).  It very much sounds
to me like you're addressing the same problem that I've been hacking
full-time for the last month or so.

If you're interested in helping, the best things that could possibly
be provided is code released to the public domain that implements:

	- Good random number generators for Macs and PCs, or
	- Implementations of the non-RSAREF symetric ciphers and hashes,
	 incl. IDEA, RC4, RC5, BLOWFISH, MD4, MD5, SAPPHIRE, GOST,
         SHA, LUC, and LOKI91.  Or any others that seem like a good idea.
	
I'll mention some miscellaneous features that will be in the library
that I haven't brought up yet:

	- It will be trivial to make the UNIX-style filter programs
	that Perry and Matt desire.
	- Specification of a format for outgoing and incoming messages
	will be trivial.  All known old formats (PGP 2.*, RIPEM, etc)
	will be supported by including format specs.

Key _management_ will *not* be supported, though public keys _will_
be imported from PGP and PEM key rings as well as X.509 certificates with
no judgement as to trust (see message from Eric Hughes from the middle
of last week).  Some key translation (x.509 --> PGP) services might be
provided.
- - --
Todd Masco     | "If we don't make utter fools of ourselves from time to time,
cactus@hks.net |  we grow smug - that is, we do not grow at all." - T. Peters
     Cactus' Homepage

- -----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBLz7c3hNhgovrPB7dAQHGdQP+Idvw/FxnPgR49z70DCMqgHV6w3UEds3f
vdm0E5P7+3evSB++iTuP/NzOP92CCnen9VTlFX+gAab61g8T9mfT5mYMu3B9iCvi
PWo3/+3XFinypShYJaYyZHWaHkYJtse7A7rFgLhoqQXNPFYdPeSh5XSJqugtfHIm
wK37TDUptS4=
=3wi6
- -----END PGP SIGNATURE-----
- ---
[This message has been signed by an auto-signing service.  A valid signature
means only that it has been received at the address corresponding to the
signature and forwarded.]

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
Comment: Gratis auto-signing service

iQBFAwUBLz8VwyoZzwIn1bdtAQHQDgGAgURmCoUB4Hop6nPRayXkK//DJ6muBORK
H8Vs6rEiDuYEezGPOT0oIxM4J1aJMuwa
=t78D
-----END PGP SIGNATURE-----