Pieter Hintjens <p...@imatix.com> writes:
> Sounds like you've identified a problem. There are two classes that
> use libsodium; best would be to call sodium_init() in either of these,
> the first time they're used, under control of a mutex to prevent
> races.
>
> Do you want to try making this change and sending us a pull request?
Hi Pieter,
I started working on that and got distracted shortly afterwards :)
Basically I looked into sodium_init() and did not like it at all.
static int initialized;
int sodium_init(void)
{
if (initialized != 0) {
return 1;
}
...
/* init some stuff here */
initialized = 1;
return 0;
}
The fix would require a class inside libzmq holding both the sodium
server class instance and the client class instance and providing the
mutex to be used while initializing. Or even worse some sort of global
variable as mutex.
Additionally I am not sure what kind of problem this part of libsodium
solves. It allows dynamic reconfigurations of the random source. Then
it seems to shape the random stream in randombytes_sysrandom_uniform()
Do we really want uniform(ly) shaped secret keys? I tried to answer this
question myself, but did not find good answers.
The NaCL library itself does not seem to do this, instead has some
really strange code which seems to chunk the stream from /dev/urandom
into blocks of size 1048576.
void randombytes(unsigned char *x,unsigned long long xlen)
{
int i;
...
/* opening dev urandom */
while (xlen > 0) {
if (xlen < 1048576) i = xlen; else i = 1048576;
i = read(fd,x,i);
if (i < 1) {
sleep(1);
continue;
}
x += i;
xlen -= i;
}
}
Clearly some case of stuff above my head. More reading just gives more
questions.
Currently I have downloaded the latest tweetnacl library and am busy
integrating it into libzmq. I hope on learning by doing :)
regards
Frank
_______________________________________________
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
