Re: crypto engine

[Simon Josefsson]

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:

#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:

typedef struct gnutls_crypto_rnd {
  int (*init)( void** ctx);
  int (*rnd) ( void* ctx, int /* gnutls_rnd_level_t */ level, void* data, int 
datasize);
  void (*deinit)( void* ctx);
} gnutls_crypto_rnd_st;

int gnutls_crypto_rnd_register( int priority, gnutls_crypto_rnd_st* s);

  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);

int gnutls_crypto_rnd_register( int priority,
                                gnutls_rng_init_func init,
                                gnutls_rng_rnd_func rnd,
                                gnutls_rng_deinit_func deinit);

  Note use of gnutls_rnd_level_t as well.

#2:

  Use 'size_t' for buffer length variables instead of 'int'.

#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...

/Simon