[Esapi-user] ESAPI Random Number Generation Broken

Kevin W. Wall kevin.w.wall at gmail.com
Thu Jun 26 04:07:09 UTC 2014

Sorry to send this again, but I got bounces from Jeff and the two
ESAPI lists because of the
attachment (or in the case of the lists, the size of the attachment).
So instead, I've made
the zip file available here on Google drive:


P.S.- Apologies for the top post. I'm tired.

On Wed, Jun 25, 2014 at 11:59 PM, Kevin W. Wall <kevin.w.wall at gmail.com> wrote:
> On Thu, Apr 10, 2014 at 9:58 PM, Jim Manico <jim.manico at owasp.org> wrote:
>> I think this is a code error, not a documentation error. Our random string
>> generator, which effects CSRF tokens, has poor randomness now reported by
>> two folks, in addition to several that noted it off list.
>> But I think Jeff's concearn about Burb is totally fair, I hope we are wrong
>> and that it's only Burp that is in error, but I doubt it. A bunch of bits
>> are bytes.
>> More on the Burp's random sequencer tester here
>> http://portswigger.net/burp/sequencer.html and here
>> http://www.securityninja.co.uk/application-security/burp-suite-tutorial-sequencer-tool/
>> - These are at least FIPS compliant tests (and more), and FIPS demands
>> 20,000 samples to test, which was in line with Mr. Rooks tests.
>> Kevin, can you toss us your test code when you have a chance?
> I thought that I had done this once before; if not my apologies. Old men
> are forgetful men you know.
> Anyhow, this recent uproar had me digging back through this thread and
> I saw this email.
> Don't trust me; do your own experiments and come to your own conclusion, but
> my conclusion is that we are naively in constructing the final nonce
> string. If you
> think of bae64 encoding although there are a total of 64 encoding
> characters plus '=' for
> padding, a base64 encoded string will actually encode a byte whose value is
> anything from 0 to 255 inclusive.  OTOH, the way we are doing the
> encoding we have
> only 62 characters (or in some of my experiments, 64), but we are coercing a fit
> into here so that more or less the only legal values that we are
> allowing are 0 to 61
> inclusive. That's a big difference, because when the Burp tests look
> at a given byte
> value, it is expecting the full range of values.
> Anyhow, start with the read me file, then compile (javac classname.java) and run
> (java classname) and redirect stdout and then feed that to Burb. For
> the tests that
> are base64 encoded, be sure to indicate that to Burp.
> Final disclaimer: This code is absolute crap and I would NEVER release anything
> this bad. These were personal experiments to test a hypothesis, the original of
> which was that this had nothing to do with failing to (re)seed SecureRandom and
> later, to test the hypothesis that it was the way that we were forming the nonce
> string that was the major problem.  There are also some test results
> that I saved
> in the 'test-results' directory, but to be honest, I haven't even
> checked to see if I
> named them in some sane manner. (Well, the file names made sense at the
> time back in early April. Only changes since then is I fixed up a few
> comments in
> the .java source files.) Therefore, if you are really lazy you can
> feed those to Burp--
> assuming you can tell which class produced which output based on my screwy
> naming. But since Google doesn't charge for extra baggage, I figured why no
> throw them into the zip file too.
> Have fun and happy experimenting.
> -kevin
> --
> Blog: http://off-the-wall-security.blogspot.com/
> NSA: All your crypto bit are belong to us.
Blog: http://off-the-wall-security.blogspot.com/
NSA: All your crypto bit are belong to us.

More information about the Esapi-user mailing list