[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