Re: [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.

pgp0edBggjbKH.pgp
Description: PGP signature