FWIW, I completely agree with Anton.

Cheers,
Edi.

On Mon, Oct 28, 2013 at 2:13 AM, Anton Vodonosov <avodonosov@yandex.ru> wrote:
> First of all, even if you want to use ironclad for random strings,
> there is no need to hardcode this in hunchentoot.
>
> Hunchentoot is designed to work with any random string generator.
>
> There is a variable hunchentoot:*session-secret*.
>
> You can initialize it to a random string, like this:
>   (setf hunchentoot:*session-secret* (format nil "~A" (ironclad:strong-random cl:most-positive-fixnum))
> Or, if you want to use the SSL number generator:
>   (setf hunchentoot:*session-secret* (format nil "~A" (secure-random:number cl:most-positive-fixnum))
>
> Only if you left hunchentoot:*session-secret* uninitialized,
> hunchentoot will initialize it using hunchentoot::create-random-string,
> which is based on cl:random. And hunchentoot issues a warning in this case.
>
> 28.10.2013, 03:09, "Ron Garret" <ron@flownet.com>:
>> The best pseudo-random number generator in the world might be completely unacceptable in a crypto application if you don't seed it with enough entropy.
>
> Exactly. Ironclad today uses /dev/random or /dev/urandom to seed the
> random number generator with initial entropy.
>
> But on Windows, ironclad only has this:
>
>   ;; FIXME: this is _untested_!
>   #+(and win32 sb-dynamic-core)(sb-win32:crypt-gen-random num-bytes)
>
> Otherwise, an error is signaled:
>   #-(or unix (and win32 sb-dynamic-core))(error "OS-RANDOM-SEED is not supported on your platform.")
>
> Also, not all unix-like systems have /dev/random.
>
> OpenSSL has more ways to gather initial enthropy, for example
> it knows how to interact with Entropy Gathering Daemon.
>
> That's why I think hardcoding Ironclad is not desirable today - it will be too limiting.
>
> Probably, hunchentoot documentation about hunchentoot:*session-secret*
> may be improved, so that users don't have these questions.
>
> Best regards,
> - Anton
>
>
>