From: Eric Young <eay@mincom.oz.au>
To: Enzo Michelangeli <enzo@ima.com>
Message Hash: 46f668b34b3cca288469761ed8f6efa43f2ec7995fc7550738a7f28d0e5cc928
Message ID: <Pine.SOL.3.91.951121220824.2627A-100000@orb>
Reply To: <Pine.LNX.3.91.951121193458.8471B-100000@ima.net>
UTC Datetime: 1995-11-21 12:49:37 UTC
Raw Date: Tue, 21 Nov 1995 20:49:37 +0800
From: Eric Young <eay@mincom.oz.au>
Date: Tue, 21 Nov 1995 20:49:37 +0800
To: Enzo Michelangeli <enzo@ima.com>
Subject: Re: cryptl99.zip Free encryption library for DOS/UNIX/Windows (fwd)
In-Reply-To: <Pine.LNX.3.91.951121193458.8471B-100000@ima.net>
Message-ID: <Pine.SOL.3.91.951121220824.2627A-100000@orb>
MIME-Version: 1.0
Content-Type: text/plain
On Tue, 21 Nov 1995, Enzo Michelangeli wrote:
> This encryption library provides a universal interface to a number of
> conventional-key encryption algorithms. The library currently supports
> encryption algorithms and modes of MDC/SHS CFB, DES ECB, CBC, CFB, OFB, PCBC,
> triple DES ECB, CBC, CFB, OFB, IDEA ECB, CBC, CFB, OFB, RC4, SAFER ECB, CBC,
> CFB, OFB, and SAFER-SK ECB, CBC, CFB, OFB. All encryption routines are
:-) cute, the next version of SSLeay to be released will have the same
thing, good to see great minds think alike (or is that simple minds
seldom differ :-).
Currently the interface I will have is
EVP_EncryptInit(EVP_CIPHER_CTX *ctx,EVP_CIPHER *type,unsigned char *key,
unsigned char *iv);
void EVP_EncryptUpdate(EVP_CIPHER_CTX *ctx,unsigned char *out,int *outl,
unsigned char *in,int inl);
void EVP_EncryptFinal(EVP_CIPHER_CTX *ctx,unsigned char *out,int *outl);
with a string to bytes function,
int EVP_BytesToKey(EVP_CIPHER *type,EVP_MD *md,unsigned char *salt,
unsigned char *data,int datal,int count,
unsigned char *key,unsigned char *iv);
this is upward compatable with PKCS#5 and will generate a key and iv of
the correct size depending on the EVP_CIPHER for a data string (the
lengths are encoded in the EVP_CIPHER definition).
I also have all my Message digest routines using the same type of interface.
What makes this nice is that all my digital signature routines
(open, seal, sign, verify etc) all take EVP_CIPHER and EVP_MD arguments
so any cipher can be used and any MD can be used. The ASN1 object
identifiers are contained in the EVP_CIPHER/EVP_MD structures.
It also make the 'demo' program that supports all the above mentioned
encryption modes (and also does base64 encoding/decoding) only 290 lines
long :-).
Now, heres the rub, to use a cipher to encode in pkcs#7 (which is what
S/MIME is using) one needs to have an object identifier (for use in the
ASN1 encoding). I know of very few object identifiers.
type object identifier.
EVP_des_ecb 1 3 14 3 2 6
EVP_des_ede
EVP_des_ede3 1 2 840 113549 3 17 (or is this EVP_des_ede (2 keys))
EVP_des_cfb 1 3 14 3 2 9
EVP_des_ede_cfb
EVP_des_ede3_cfb
EVP_des_ofb 1 3 14 3 2 8
EVP_des_ede_ofb
EVP_des_ede3_ofb
EVP_des_cbc 1 3 14 3 2 7
EVP_des_ede_cbc
EVP_des_ede3_cbc
EVP_rc4 1 2 840 113549 3 4
EVP_idea_ecb
EVP_idea_cfb
EVP_idea_ofb
EVP_idea_cbc
MD_md2 1 2 840 113549 2 2
MD_md5 1 2 840 113549 2 5
MD_sha 1 3 14 3 2 18
Can anyone out there fill in the blanks? I also supose the new version
of SHA, SHA-1 will also have a different identifier as well which I will
also need.
In the above, I always use 'ede' to refer to encrypt-decrypt-encrypt with
2 keys and 'ede3' to refer to ede with three keys.
eric (on a quest for object identifiers... and to finish the next version
of SSLeay before he goes on a long holiday...)
Return to November 1995
Return to “Eric Young <eay@mincom.oz.au>”