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