crypto engine

[Nikos Mavrogiannopoulos]

Simon Josefsson wrote:
> Nikos Mavrogiannopoulos <nmav at gnutls.org> writes:
> 
>> About the new crypto engine I think it should be included as is in the
>> new release. It is not tested but API-wise I don't expect changes. I
>> could add the mpi interface after the release in the development
>> branch.
> 
> Ok, I looked over the API, and I think we need to do at least #1/#2
> before we can release it:

I'm still working on it so let's disable it for the release. I'll put 
today an #if 0 on this code.

> #1:
> 
>   I think that avoiding struct's in the public API would be a good idea
>   (struct alignment always seem to cause problems on weirder platforms),

>   so how about instead of doing something like this:
>   do this instead:
> 
> typedef int (*gnutls_rng_init_func)( void** ctx);
> typedef int (*gnutls_rng_rnd_func) ( void* ctx, gnutls_rnd_level_t level, void* data, int datasize);
> typedef void (*gnutls_rng_deinit_func)( void* ctx);

Although not using structures is better for the API, the whole crypto.c 
will be inconsistent with some functions taking pointers to structures 
as arguments and others functions. I don't like the idea so much.

> #2:
> 
>   Use 'size_t' for buffer length variables instead of 'int'.

I'll do this.

> #3:
>   Couldn't we align the GNUTLS_RND_* symbols to match the libgcrypt
>   values?  In other words, change the order and values of the symbols.
>   Not important, but might simplify libgcrypt mapping...

Also.

regards,
Nikos