Re: crypto engine

[Nikos Mavrogiannopoulos]

Simon Josefsson wrote:
> Nikos Mavrogiannopoulos <address@hidden> 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