[gnutls-dev] Symmetric cipher API
mrsam at courier-mta.com
Mon Nov 19 13:14:02 CET 2007
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
> 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
Size: 189 bytes
Desc: not available
More information about the Gnutls-devel