[Esapi-user] ESAPI Random Number Generation Broken

Bruno Girin bruno at energydeck.com
Wed Apr 9 12:24:05 UTC 2014


Hi,

I'm a newby on this list so apologies if the comments below are out of
place but I thought I would contribute to the discussion.

On 9 April 2014 05:17, Kevin W. Wall <kevin.w.wall at gmail.com> wrote:

>   BTW, I figured out a way to do that without
> using the potentially biased [Secure]Random.nextInt(int) call. It's just:
>
>     byte[] nonce = new byte[ n ];
>     secureRandom.nextBytes(nonce);
>     StringBuilder result = new StringBuilder(length);
>     for( int i = 0; i < nonce.length; i++ ) {
>         char c = characterSet[ Math.abs( (nonce[i] % characterSet.length)
> ) ];
>         result.append( c );
>     }
>     return result.toString();
>
> I added two characters ('_' and '.', but any additional 2 unreserved
> characters from RFC 3986 - Section 2.3 would do) to the 62 characters
> (A-Z, a-z, and 0-9) that ESAPI was using just to get rid of potential bias
> (since 64 divides 256).


[Secure]Random.nextBytes(byte[])  is the most efficient way I know to do
this in Java. With regards to base 64, RFC 2045 [1] specifies that the 2
additional characters are + and / and that = is used for padding.

Having said this, rather than code the base 64 algorithm in ESAPI (and
having to maintain that code), what about using one that already exists,
namely the Apache Commons Codec one? [2]

[1] http://www.ietf.org/rfc/rfc2045.txt
[2]
http://commons.apache.org/proper/commons-codec/apidocs/org/apache/commons/codec/binary/Base64.html

Cheers,

Bruno
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.owasp.org/pipermail/esapi-user/attachments/20140409/888b4677/attachment.html>


More information about the Esapi-user mailing list