#32 Implementation of dtls_prng and dtls_prng_init

[Sachin]

Existing code in tinydtls provides default implementation of dtls_prng()/dtls_prng_init() and suggests users to adopt a better prng for specific platform. For Linux like platforms which provides /dev/urandom support, I can see that there is scope to improve upon existing implementation:
1)The length of the seed which is provided to dtls_prng_init is sizeof(unsigned long) which can be from 2 to 8 bytes long depending upon compiler and the system. Wouldn't it be advisable to mandate at least 16 byte long seed for prng?

2)For sensitive random numbers which are used for keys etc, should we use random numbers directly from /dev/urandom or should we trust the PRNG provided by 'C' library (rand)? I assume by preferring 'rand' over '/dev/urandom' there is a performance benefit of avoiding a system call.

Any thoughts?

Thanks
Sachin

[Olaf Bergmann]

Hi Sachin,

Thanks for starting discussion on this. In fact, dtls_prng_init() currently takes unsigned short, which is ... kinda short :-(

1) With the current default PRNG implementation in tinydtls for POSIX-systems, the seed is passed to srand(), so there would be no point in using anything else but unsigned int. I agree that it might be good to be able to pass more entropy here. So, how about dtls_prng_init(const unsigned integer *buf, size_t len), i.e. providing means to pass more than one unsigned int for initialization?

2) Using rand() to generate input for dtls_prng_init() is not a good idea because dtls_prng_init() uses this value to seed the underlying PRNG (i.e. rand()). If that has been done before, there is no need to do this again in dtls_prng_init(). If not, there will be no additional entropy by letting the PRNG bootstrap itself.

[Sachin]

Thanks for responding Olaf.

1) Would it be more appropriate that all prng functionality can be moved to prng.h and just have a explicit call to dtls_prng_init(void) from 'dtls_new_context'.
In prng.h, user can generate random seed as per his platform requirements with a bunch of #ifdef.
Isn't this you and Julien have been discussing in Ticket #21?

2)I think you misunderstood me here. For POSIX like environments, I was trying to encourage the use of /dev/urandom instead of rand() for any random needs of tinydtls library.

[Olaf Bergmann]

Sachin,

1) I agree with you that dtls_prng_init(void) with platform-specific implementations might be the best solution here. According to ticket #21, the question is indeed if this should use callbacks instead of macro magic as the latter can easily break when a binary distribution of the library is used.

2) Oh, I see. Okay, if we go for option #1, I do not mind using /dev/urandom for POSIX-systems.