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
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
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
Whether or not ironclad is necessary, or even acceptable, really depends on what your requirements are. 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. Likewise, a quantum-mechanical source of true randomness might be completely unacceptable for a monte-carlo simulation if the bandwidth isn't high enough.
On Oct 27, 2013, at 3:16 PM, Bill St. Clair wrote:
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
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
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
-
Anton Vodonosov -
Bill St. Clair -
Edi Weitz -
Hans Hübner -
Ron Garret -
Sabra Crolleton