[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: crypto engine

From: Nikos Mavrogiannopoulos
Subject: Re: crypto engine
Date: Mon, 14 Apr 2008 07:11:15 +0300
User-agent: Thunderbird (X11/20080227)

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

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.


  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.


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

I'll do this.

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]