Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: tomcat-dev@jakarta.apache.org
From: "Marc Saegesser" <marc.saegesser@apropos.com>
To: <tomcat-dev@jakarta.apache.org>
Subject: RE: cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/util
 SessionIdGenerator.java
Date: Wed, 5 Sep 2001 08:48:45 -0500
Message-ID: <JFEMIAGAMJPJFLEODNEEKEKAEMAA.marc.saegesser@apropos.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
In-Reply-To: <999667861.3b95b895989f1@www.mhsoftware.com>
Importance: Normal

I went back and forth several times last night about removing the
get/setEntropy() methods.  They were added with the code to set the seed and
they did serve a valid purpose at that time, but they don't serve much use
now.

I can't remove them because people might actually be using the methods (I
really doubt it, but they might) and that would break they code.  What I'll
do is make them deprecated in this release to discourage people from
starting to use them.


Marc Saegesser

> -----Original Message-----
> From: Christopher Cain [mailto:ccain@mhsoftware.com]
> Sent: Wednesday, September 05, 2001 12:31 AM
> To: tomcat-dev@jakarta.apache.org
> Subject: Re: cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/util
> SessionIdGenerator.java
[snip]
>
>
> First off, let me say that the above patch is a _really_ good
> idea, as far as
> letting the PRNG default to its own entropy-collection routine, so that
> definitely need to be done IMO.
>
> Now I know that what I am about to suggest falls under the
> category of a trying-
> to-save-users-from-themselves enhancement, and not an actual bug
> fix as would
> be appropriate for the 3.2 branch, but it never hurts to offer, right? =)
>
> The problem (which has nothing to do with the above patch other
> than having
> brought the existing algorithm to my attention :-) is that the
> for{} loop here
> serves no real purpose. If the user passes an insecure seed
> value, this for{}
> loop provides absolutely no additional security value. Now it
> doesn't really
> degrade security either, which is why it's not really a "bug" per
> se. My only
> concern is this: It's probably not patently obvious to someone
> without prior
> cryptography experience that this additional pass is merely
> smoke-and-mirrors
> with no practical benefit. I also know that users are _always_
> trying to find
> shortcuts around the delay in Java's PRNG initalization (in fact,
> that alone
> accounts for at least 50% of the security flaws in Java crypto
> based on my
> experience). My concern is that people will start investigating
> startup delays,
> track it down to this, see that the internal Tomcat code is doing
> some kind of
> mumbo-jumbo with a user-provided seed value, try it (to find that
> they shaved
> ~10 seconds off their startup), and assume that whatever Tocmat
> is doing is
> probably "sufficient for my application". IMHO, it's much safer
> to just remove
> this for{} loop voodoo in order to avoid the implication that it
> does anything
> meaningful.
>
> Anyway, that's my take. Usually, bad crypto is worse than no
> crypto at all. In
> this case, it will probably result in a few less people trying to
> outsmart the
> PRNG.
>
> - Christopher
>
> /**
>  * Pleurez, pleurez, mes yeux, et fondez vous en eau!
>  * La moiti� de ma vie a mis l'autre au tombeau.
>  *    ---Cornelle
>  */