From: "Ray Cromwell" <s5cromw@watson.ibm.com>
Date: Tue, 15 Aug 95 13:51:27 PDT
To: hfinney@shell.portal.com (Hal)
Subject: Re: Object Oriented Crypto API
In-Reply-To: <199508031625.JAA11761@jobe.shell.portal.com>
Message-ID: <9508152050.AA21250@play.watson.ibm.com>
MIME-Version: 1.0
Content-Type: text/plain



Sorry I took so long to respond.

Hal wrote:
> I enjoyed Ray's message about the crypto library interface.  I haven't
> had time to study it closely, but I have a couple of quick comments:
>
> I thought Wei's library looked pretty easy to use already.  Maybe Ray
> could show an example of what would be needed with Wei's library to do
> some "typical" crypto function, say encrypting a message with someone
> else's RSA key.  Then we could compare it with how the same function
> would look with Ray's proposed interface.

  Wei's library is easy to use from a certain standpoint. It depends
on a ASN.1 stream paradigm to stack cryptographic layers. However, I
think it is lacking in certain areas which makes it difficult
to use, and it is completely missing many functions such as
key distribution and management.

To RSA encrypt with Wei's library, you have to open the key file
(or read it into memory somehow), and instantiate a "BufferedTransformation"
which is a sort of internal stream library. Then you construct
a RSAPublicKey object around the BufferedTransformation, then you
generate a random blockcipher key, and tell the RSAPublicKey object
to encrypt it. Next, you encode your plaintext with the block cipher
separately using the blockcipher key. I'm going to ignore the
actual syntax of Wei's library for the moment (because I don't remember
it) and use pseudo code.

key_data_stream = FileSource("publickey.data") /* like ifstream() */
RSAPublicKey rsa_object(key_data_stream);
random_blockcipher_key = /* generate the key somehow, note, key generation
	                    is not standardized across all encryption
                            algorithms, so the application writer
                            must know how to generate the session key
                            manually */
rsa_object.Encrypt(random_blockcipher_key, encryptedkey);
DESEncryption desenc(random_blockcipher_key);
desenc.ProcessBlock(plaintext, ciphertext);
/* write "encryptedkey" and "ciphertext" somewhere */






Under my scheme, it would look something like this

/* we are given PlainText p, a KeyID which is of the format
   KeyID ::= identifier ['::' keyserver]
   identifier ::= RFC822_EMAIL_ADDR | HEX_STRING;
   keyserver ::= FULLY_QUALIFIED_DOMAIN_NAME;

   example: "Ray Cromwell" <rjc@clark.net>::keyserver.com
   we are doing RSA encryption with DES
*/

DESEncryptionAlgorithm des;
RSAEncryptionAlgorithm rsa(des);

Encrypt(rsa, KeyId, p, c);




Here's the explaination of what's going on underneath (refer to
my OO Crypto API article if needed)

DES is a BlockCipherEncryptionAlgorithm (child of EncryptionAlgorithm)
RSA is a PublicKeyEncryptionAlgorithm (also a child of EncryptionAlgorithm)
that expects to be constructed with a BlockCipherEncryptionAlgorithm
because it uses a blockcipher as the underlying encryption technique
and only encrypts the session key. Any old BlockCipherEncryptionAlgorithm
will do, DES, IDEA, etc. RSA doesn't care.

Encrypt() is a global function which takes as its first argument
an EncryptionAlgorithm, second, a KeyID, and third/fourth a plaintext
and ciphertext tokenized stream (to be explained later). Encrypt()
doesn't care what the cryptosystem is, it's a single entry point
for the application developer.

Encrypt's pseudocode looks like this

Encrypt(EncryptionAlgorithm encalg, KeyID kid, Plaintext p, Ciphertext c)
{
    KeyDomain kdom=encalg.GetKeyDomain(kid);
    EncryptionKey ek = GetKey(kdom, kid);
    encalg.encrypt(ek, p, c);
}

Line 1 asks the EncryptionAlgorithm (whatever type it really is), to
return a KeyDomain for that cryptosystem. A KeyDomain is an abstract
universal object for fetching any key type from any place. It could
for instance, be fetching the key from a disk file, from an email
signature, or am internet key server.

Line 2 calls a global key management function GetKey which queries
a KeyDomain with the KeyID to return an EncryptionKey.

Line 3 calls the encrypt function on the EncryptionAlgorithm.

I have toyed with other interfaces. For instance, since we want to
support the definition of new KeyDomain types, we really should allow
an overloaded Encrypt where the EncryptionKey is passed as an argument,
so that the application developer can use third party KeyDomains.

Every EncryptionAlgorithm (hereafter abbreviated EA, where DA is
a DecryptionAlgorithm) knows how to generate a KeyPair which
contains an encryption and decryption key such that
DA(keypair.decryption_key, EA(keypair.encryption_key, plaintext)) == plaintext
Whether the cipher is symmetric or not is irrevelent. The RSAEncryptionAlgorithm
encrypt() function basically calls generate_key() on the block cipher
and uses that as the session key. Application developers are shielded
from the representation of keys and the generation of them.


The real dream is to have a generic crypto library which can encrypt
anything using any algorithm fetching keys from any medium and
reading and writing any valid crypto file format. Application developers
could write code to operate on PGP file formats, RSAREF, PEM, or
anything without having to know anything about those formats at all.
The only thing that is standardized is the KeyID format. Sort of
a Universal Resource Name (URN) for key identification. Perhaps
"key://keyserver.domain/keyid" would be better.


Reading and Writing any file format
-----------------------------------
  How would an application be able to operate on a RIPEM message, and a
PGP file without knowing about the format of either?

  The general scheme is to use a tokenized stream which records
what has been done to the plaintext, and then some stream encoding
objects which "map" the stream to the local format as long as the
stream is consistent with the algorithms the file format supports. Think
of the stream as a string in a regular language (in the sense of automata
theory). The stream "mapper" is a deterministic finite automaton
which processes the "string" (the stream tokens) and determines
1) whether the string is acceptable by the language (file format)
it's mapping to, and 2) generates side effects which write out the
format to a buffer or file.

Consider the following symbol set,
S={ RSA_ENCRYPTION, PUBLICKEY_REF, DES_ENCRYPTION, IDEA_ENCRYPTION }

A tokenized stream might look like

RSA_ENCRYPTION PUBLICKEY_REF [pkey data] [encrypted session key]
DES_ENCRYPTION [ciphertext]

A PGPEncoder would reject this stream because it doesn't use IDEA.


Encoders would have the job of verifying consistency of the
stream with the underlying file format, and also whether or not
the stream was encoded properly in the first place. If the
stream is invalid, exceptions are thrown. If some tokens are
missing (such as a timestamp), the Encoder can supply them.

> The other point is that there needs to be the ability to encrypt only
> a bit of a message at a time.  Particularly with public key the first
> message may be special in that it generates a session key which is used
> for the remainder.  So an interface for piecewise encryption and
> decryption is necessary.

The way to do this is to provide secondary interfaces across all
Algorithms which allow the operations of Init, Update, and Finalize,
much like RSA's MD5 interface operates.

-Ray



From owner-cypherpunks  Tue Aug 15 15:06:28 1995