[gnutls-dev] Symmetric cipher API

[Sam Varshavchik]

Nikos Mavrogiannopoulos writes:

> On Sunday 18 November 2007, Sam Varshavchik wrote:
>> Recently I converted some code that uses OpenSSL's EVP_CIPHER symmetric
>> cipher API. I wrote a wrapper that mapped the following functions to their
>> gcrypt equivalents: EVP_CIPHER_CTX_init(), EVP_CIPHER_CTX_cleanup(),
>> EVP_(Encrypt|Decrypt)Init_ex(), EVP_(Encrypt|Decrypt)Update(), and
>> EVP_(Encrypt|Decrypt)Final_ex().
> 
> We could always commit something like this to the openssl compatibility 
> interface. However I don't understand its use. Why did you need such wrapper?

Because I have existing OpenSSL-based code that uses this API, and there is 
nothing in libgcrypt that maps exactly to it.

>> If you are interested, I'll be happy to contribute this code. I also
>> thought that it's better to make this a native libgcrypt API. This should
>> be only a matter of renaming the function names and arguments to follow
>> libgcrypt's naming conventions, and all the EVP function become now just
>> some lightweight wrappers (or probably even macros).
> 
> Why do you think that it's better to have it as native libgcrypt API? What are 
> the advantages of using this api comparing to libgcrypt's? As far as I 
> understand the differences the libgcrypt's functions are safer, since you 
> don't directly access structures, and the internals can be changed without
> breaking binary compatibility.

The wrapper code also uses only the existing published libgcrypt APIs as 
well. Think of it as a higher-level API that sits on top of 
gcry_cipher_encrypt and gcry_cipher_decrypt. This OpenSSL API is for 
symmetric block ciphers, but the application does not have to have to supply 
the input as block-sized chunks. The application supplies the input 
piece-meal, as an arbitrary data stream, and the EVP functions take care of 
carving it up into block-sized chunks and feeding each chunk to the cipher 
function. Finally, the EVP functions take care of PKCS padding, so the 
application's encrypted/decrypted data stream does not have to be a multiple 
of the block size.

>From an application's standpoint, this API is much more convenient than just 
gcry_cipher_encrypt and gcry_cipher_decrypt. There's far less low-level 
detail to worry about.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: </pipermail/attachments/20071119/8552b7bb/attachment.pgp>