cryptl99.zip Free encryption library for DOS/UNIX/Windows (fwd)
Found on sci.crypt, apparently not yet posted on this list. I haven't examined it at all, caveat emptor. The size of the ZIP file is about 148 Kb. Enzo ---------- Forwarded message ---------- Path: news.hklink.net!hpg30a.csc.cuhk.hk!cuhknntp!news.uoregon.edu!cs.uoregon.edu!reuter.cse.ogi.edu!hp-cv!hp-pcd!sdd.hp.com!swrinde!newsfeed.internetmci.com!in1.uu.net!brighton.openmarket.com!decwrl!waikato!auckland.ac.nz!news From: pgut01@cs.auckland.ac.nz (Peter Gutmann) Newsgroups: alt.security,comp.security.misc,sci.crypt Subject: cryptl99.zip Free encryption library for DOS/UNIX/Windows Date: 20 Nov 1995 09:57:45 GMT Organization: University of Auckland Lines: 45 Sender: pgut01@cs.auckland.ac.nz (Peter Gutmann) Message-ID: <48pjep$7ge@net.auckland.ac.nz> NNTP-Posting-Host: cs26.cs.auckland.ac.nz X-Newsreader: NN version 6.5.0 #3 (NOV) Xref: news.hklink.net alt.security:6498 comp.security.misc:5814 sci.crypt:6827 [This was announced a few days ago, I've reposted it to a few crypto and security groups for people who don't read the archives groups] File name: ftp://garbo.uwasa.fi/pc/security/cryptl99.zip One line description: Free encryption library for Unix/DOS/Windows 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 accessed through a single standardised interface with parameters such as algorithm, mode and key size being selectable by the user. The library is supplied as source code for Unix, DOS, and the Amiga, and as dynamic link libraries for Windows and Windows NT. The design goal for the library was to create an easy-to-use, standardised interface to a number of popular encryption algorithms. Like the standard C file I/O libraries which work with FILE objects, this library works with an "encryption context" of type CRYPT_INFO. To encrypt data, you create an encryption context, load a user key into it, en/decrypt data, and destroy it when you've finished. This concept lends itself to implementation either as a C++ class or as C routines. The library has been written to be as idiot-proof as possible. On initialization it performs extensive self-testing against test data from encryption standards documents, and the API's check each parameter and function call for errors before any actions are performed, with error reporting down to the level of individual parameters. The library API serves as an interface to a range of plug-in encryption modules which allow encryption algorithms to be added in a fairly transparent manner. The standardised API allows any of the algorithms and modes supported by the library to be used with a minimum of coding effort. As such the main function of the library is to provide a standard, portable, easy-to-use interface between the underlying encryption routines and the user software. All code is plain ANSI C, with no machine or OS-specific functions or calls being used. Peter.
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...)
participants (2)
-
Enzo Michelangeli -
Eric Young