From sabra.crolleton at gmail.com Sat Oct 26 16:31:06 2013 From: sabra.crolleton at gmail.com (Sabra Crolleton) Date: Sat, 26 Oct 2013 09:31:06 -0700 Subject: create-random-string revisited Message-ID: 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From p2.edoc at gmail.com Sun Oct 27 20:10:52 2013 From: p2.edoc at gmail.com (peter) Date: Sun, 27 Oct 2013 21:10:52 +0100 Subject: Session identity vanishing In-Reply-To: References: Message-ID: *use-user-agent-for-sessions* is T (so a session will cease to be accessible if the client sends a different 'User-Agent' header) But why should the user-agent change because we're dealing with a JSON rather than HTML return? I'm dealing with the same session, same browser, etc as far as the client end is concerned (ie. two successive clicks in the same web page). Many thanks. At 6:47 PM +0100 13/10/27, Edi Weitz wrote: >Did you try to set *use-remote-addr-for-sessions* and/or >*use-user-agent-for-sessions* to NIL? > >Cheers, >Edi. > >On Sun, Oct 27, 2013 at 5:44 PM, peter wrote: >> Using Hunchentoot 1.2.7 on Clozure 1.9-r15808 >> I get cookies OK when serving HTML from any host I've tried. >> Serving JSON on Mac (DarwinX8664) works OK too. >> But I lose the cookie (session identity) when serving JSON on EC2 >> (linuxx8664). >> I expect the deficiency is in my code, but am foxed. >> Any suggestions? >> From p2.edoc at gmail.com Sun Oct 27 16:44:18 2013 From: p2.edoc at gmail.com (peter) Date: Sun, 27 Oct 2013 17:44:18 +0100 Subject: Session identity vanishing Message-ID: Using Hunchentoot 1.2.7 on Clozure 1.9-r15808 I get cookies OK when serving HTML from any host I've tried. Serving JSON on Mac (DarwinX8664) works OK too. But I lose the cookie (session identity) when serving JSON on EC2 (linuxx8664). I expect the deficiency is in my code, but am foxed. Any suggestions? From hans.huebner at gmail.com Sat Oct 26 18:09:08 2013 From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Sat, 26 Oct 2013 20:09:08 +0200 Subject: create-random-string revisited In-Reply-To: References: Message-ID: I think a dependency on ironclad would be okay. If anyone has a different opinion, please speak up. -Hans 2013/10/26 Sabra Crolleton > 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From edi at weitz.de Sun Oct 27 21:44:05 2013 From: edi at weitz.de (Edi Weitz) Date: Sun, 27 Oct 2013 22:44:05 +0100 Subject: Session identity vanishing In-Reply-To: References: Message-ID: It was just a guess. Probably won't happen with JSON, but I've seen plug-ins sending their own user agent strings. Maybe in your case it's a timing issue? Seems you'll have to debug it the hard way. On Sun, Oct 27, 2013 at 9:10 PM, peter wrote: > *use-user-agent-for-sessions* is T > > (so a session will cease to be accessible > if the client sends a different 'User-Agent' header) > > But why should the user-agent change because we're dealing with a JSON > rather than HTML return? I'm dealing with the same session, same browser, > etc as far as the client end is concerned (ie. two successive clicks in the > same web page). > > Many thanks. > > > > At 6:47 PM +0100 13/10/27, Edi Weitz wrote: >> >> Did you try to set *use-remote-addr-for-sessions* and/or >> *use-user-agent-for-sessions* to NIL? >> >> Cheers, >> Edi. >> >> On Sun, Oct 27, 2013 at 5:44 PM, peter wrote: >>> >>> Using Hunchentoot 1.2.7 on Clozure 1.9-r15808 >>> I get cookies OK when serving HTML from any host I've tried. >>> Serving JSON on Mac (DarwinX8664) works OK too. >>> But I lose the cookie (session identity) when serving JSON on EC2 >>> (linuxx8664). >>> I expect the deficiency is in my code, but am foxed. >>> Any suggestions? >>> > From edi at weitz.de Sun Oct 27 17:47:59 2013 From: edi at weitz.de (Edi Weitz) Date: Sun, 27 Oct 2013 18:47:59 +0100 Subject: Session identity vanishing In-Reply-To: References: Message-ID: Did you try to set *use-remote-addr-for-sessions* and/or *use-user-agent-for-sessions* to NIL? Cheers, Edi. On Sun, Oct 27, 2013 at 5:44 PM, peter wrote: > Using Hunchentoot 1.2.7 on Clozure 1.9-r15808 > I get cookies OK when serving HTML from any host I've tried. > Serving JSON on Mac (DarwinX8664) works OK too. > But I lose the cookie (session identity) when serving JSON on EC2 > (linuxx8664). > I expect the deficiency is in my code, but am foxed. > Any suggestions? > From billstclair at gmail.com Sun Oct 27 22:16:21 2013 From: billstclair at gmail.com (Bill St. Clair) Date: Sun, 27 Oct 2013 18:16:21 -0400 Subject: create-random-string revisited In-Reply-To: References: Message-ID: 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 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 > >> 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 >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From avodonosov at yandex.ru Mon Oct 28 01:13:38 2013 From: avodonosov at yandex.ru (Anton Vodonosov) Date: Mon, 28 Oct 2013 05:13:38 +0400 Subject: create-random-string revisited In-Reply-To: <035963EA-5CC3-43AB-89C2-B74B87C92751@flownet.com> References: <035963EA-5CC3-43AB-89C2-B74B87C92751@flownet.com> Message-ID: <15471382922818@web6g.yandex.ru> 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" : > 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 From edi at agharta.de Mon Oct 28 09:43:04 2013 From: edi at agharta.de (Edi Weitz) Date: Mon, 28 Oct 2013 10:43:04 +0100 Subject: create-random-string revisited In-Reply-To: <15471382922818@web6g.yandex.ru> References: <035963EA-5CC3-43AB-89C2-B74B87C92751@flownet.com> <15471382922818@web6g.yandex.ru> Message-ID: FWIW, I completely agree with Anton. Cheers, Edi. On Mon, Oct 28, 2013 at 2:13 AM, Anton Vodonosov 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" : >> 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 > > > From sabra.crolleton at gmail.com Wed Oct 30 05:01:51 2013 From: sabra.crolleton at gmail.com (Sabra Crolleton) Date: Tue, 29 Oct 2013 22:01:51 -0700 Subject: create-random-string revisited In-Reply-To: References: <035963EA-5CC3-43AB-89C2-B74B87C92751@flownet.com> <15471382922818@web6g.yandex.ru> Message-ID: Anton's argument seems compelling me. I agree. Sabra On Mon, Oct 28, 2013 at 2:43 AM, Edi Weitz wrote: > FWIW, I completely agree with Anton. > > Cheers, > Edi. > > On Mon, Oct 28, 2013 at 2:13 AM, Anton Vodonosov > 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" : > >> 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 > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron at flownet.com Sun Oct 27 23:06:44 2013 From: ron at flownet.com (Ron Garret) Date: Sun, 27 Oct 2013 16:06:44 -0700 Subject: create-random-string revisited In-Reply-To: References: Message-ID: <035963EA-5CC3-43AB-89C2-B74B87C92751@flownet.com> 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 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 > 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: