[cl-plus-ssl-devel] init-prng - unsecure random number generator initialization

Anton Vodonosov avodonosov at yandex.ru
Tue Nov 4 00:36:11 UTC 2008


on Friday, October 24, 2008, 12:14:28 AM Anton wrote:

> Hello.

> Currently cl+ssl uses the following function in initialization:

>   (defun init-prng ()
>     ;; this initialization of random entropy is not necessary on
>     ;; Linux, since the OpenSSL library automatically reads from
>     ;; /dev/urandom if it exists. On Solaris it is necessary.
>     (let ((buf (cffi-sys::make-shareable-byte-vector +random-entropy+)))
>       (dotimes (i +random-entropy+)
>         (setf (elt buf i) (random 256)))
>       (cffi-sys::with-pointer-to-vector-data (ptr buf)
>         (rand-seed ptr +random-entropy+))))

> The problem here is that RANDOM function is usually deterministic.
> Moreover, at least in two implementations, CLISP and SBCL,
> *RANDOM-STATE* has always the same value after lisp startup,
> and therefore our initialization code always produce the
> same values in the BUF. This is of course unsecure.

> IMHO it is better to remove INIT-PRNG from initialization
> and allow OpenSSL to initialize itself from /dev/random on
> Linux and from CryptoAPI on Windows.

> For Solaris users it is better to use some passphrase for
> RAND-SEED (I also saw links to /dev/random drivers for Solaris,
> but I do not know, whether OpenSSL will use it on that platform).

Fixed as follows.

cl+ssl does not create PRNG seed anymore. For many platforms OpenSSL does
it itself using platform specific service.

For the platforms where OpenSSL can not do this, CL+SSL:ENSURE-INITIALIZED
public function is changed to accept keyword argument RAND-SEED, which
must be octet sequence. User must call this function prior to calling any
other CL+SSL functions and provide unpredictable RAND-SEED.

Best regards,
- Anton





More information about the cl-plus-ssl-devel mailing list