Seems like a mighty big hammer for something that for most of us will be a few READ-BYTEs from /dev/urandom. Windows is harder than that (calls to a couple of foreign functions in the advapi32 library), but still nowhere near as much as all of Ironclad. Bill On Sat, Oct 26, 2013 at 2:09 PM, Hans Hübner <hans.huebner@gmail.com> wrote:

I think a dependency on ironclad would be okay. If anyone has a different opinion, please speak up.

-Hans

2013/10/26 Sabra Crolleton <sabra.crolleton@gmail.com>

...

Quite awhile ago I proposed strengthening create-random-string with something that required cl-ssl as a dependency and it was correctly pointed out that some implementations do not play well with cl-ssl. Would using the strong-random function from ironclad be acceptable? E.g.

(defun create-random-string (&optional (n 10) (base 16))

"Creates a random string using ironclad's strong-random function with base BASE and N digits" (setf crypto:*prng* (crypto:make-prng :fortuna))

(subseq (with-output-to-string (s) (loop for i to n do

(format s "~VR" base (ironclad:strong-random 100000000000))))

0 n))

Sabra

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

Anton's argument seems compelling me. I agree. Sabra On Mon, Oct 28, 2013 at 2:43 AM, Edi Weitz <edi@agharta.de> wrote:

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