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