Does hotbits hate me ... or is something else wrong here?

[blazedaces]

Hey guys, how's it going today? So basically I have a program that uses hotbits (a real online random number generator based off radioactive decay) to produce truly random alphanumeric codes (Note: the program is the package randomX from their website).

Since I needed many codes I ran the program last night and then all of a sudden it spit out the following error:

Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 256
    at randomX.randomHotBits.fillBuffer(randomHotBits.java:43)
    at randomX.randomHotBits.nextByte(randomHotBits.java:58)
    at randomX.randomX.nextShort(randomX.java:170)
    at randomX.randomX.nextInt(randomX.java:73)
    at randomX.randomX.nextLong(randomX.java:80)
    at randomX.randomX.nextDouble(randomX.java:94)
    at MakeRandomAlphaNumerics.randomNumber(MakeRandomAlphaNumerics.java:22)
    at MakeRandomAlphaNumerics.randomAlphaNumeric(MakeRandomAlphaNumerics.java:33)
    at MakeRandomAlphaNumerics.main(MakeRandomAlphaNumerics.java:44)
 

Note: this error was recorded when I ran the program to get just 10 random codes and it didn't spit one out. So another words, since I ran the program to get thousands, it has been producing this error. So my suspicion is that the website/program has been written with a defense mechanism against someone requesting too much data too many times in a row (does this make any sense at all?).

Now, I'm going to post the code for the program where the error finally occurs (in the method fillBuffer()). See, the funny thing is, this error occurred only after the percentage out of 3217 random codes was about .01 (my calculation of this number could possibly be wrong I guess) which amounts to only approximately 32 codes, but I've ran this program previously to produce a hundred alphanumeric codes to test it out when I needed to produce some demo sheets for approval.

My question is should this be happening? Is this indeed some kind of security measure taken by the website? If so, can I get thousands of codes somehow from this same source by simply setting up my program to take so many codes, then wait (using a timer perhaps) and then take more (maybe you can give me an alternative solution)?

Here's the codes for the randomX.hotBits program and I've marked where the error occurs:

package randomX;
 
import java.net.*;
import java.io.*;
import randomX.*;
 
/**
    Implementation of a <b>randomX</b>-compliant class which obtains
    genuine random data from <a href="http://www.fourmilab.ch/">John
    Walker</a>'s <a href="http://www.fourmilab.ch/hotbits/">HotBits</a>
    radioactive decay random sequence generator.
 
    <p>
    Designed and implemented in July 1996 by
    <a href="http://www.fourmilab.ch/">John Walker</a>.
*/
 
public class randomHotBits extends randomX {
    long state;
    int nuflen = 256, buflen = 0;
    byte[] buffer;
    int bufptr = -1;
 
    //  Constructors
 
    /** Creates a new random sequence generator.  */
 
    public randomHotBits() {
        buffer = new byte[nuflen];
    }
 
    /*  Private method to fill buffer from HotBits server.  */
 
    private void fillBuffer()
        throws java.io.IOException
    {
        URL u = new URL("http://www.fourmilab.ch/cgi-bin/uncgi/Hotbits?nbytes=128&fmt=bin");
        InputStream s = u.openStream();
        int l;
 
        buflen = 0;
        while ((l = s.read()) != -1) {
            buffer[buflen++] = (byte) l;  //Error occurs on this line, which implies s.read() is reading more then 256 times?
        }
        s.close();
        bufptr = 0;
    }
 
    /** Get next byte from generator.
 
@return the next byte from the generator.
    */
 
    public byte nextByte()  {
        try {
            synchronized (buffer) {
                if (bufptr < 0 || bufptr >= buflen) {
                    fillBuffer();
                }
                return buffer[bufptr++];
            }
        } catch (IOException e) {
            throw new RuntimeException("Cannot obtain HotBits");
        }
    }
};
 

Edit: One solution I did try earlier was to change the inside of the while loop to break if it read more than 256 times (did not work), so the while loop looked like this:

        while ((l = s.read()) != -1) {
            if (buflen >= nuflen)
                break;
            buffer[buflen++] = (byte) l;
        }
 

But that did not work. It was a bit odd. It would produce a few alphanumeric codes that were unique (about 3) and then spit out like 7 that were the same. Which seems a little odd to me, because that would mean it's repeating itself not in every 256 bytes, but rather in every 8 double's I request from it (to produce an alphanumeric random letter/number I multiply random.double(), not random from java, but random from the hotbits package, by 35 and then get either a number or a letter depending on the produced and then afterwards rounded number.

Don't know if that information helped you guys at all.

Thank you for all and any of your help,

-blazed

[JosAH]

.
        int l;
 
        buflen = 0;
        while ((l = s.read()) != -1) {
            buffer[buflen++] = (byte) l;  //Error occurs on this line, which implies s.read() is reading more then 256 times?
        }
        s.close();
        bufptr = 0;
    }
 

You gave the answer yourself (read your own comment). Take care of it by
checking the buflen variable in your while condition.

kind regards,

Jos

[BigDaddyLH]

Hot damn! How can I get me a radioactive decay device for my computer! And here I was, using a pseudo-random number generator like some fresh-from-out-of-town Jasper.

[blazedaces]

You gave the answer yourself (read your own comment). Take care of it by
checking the buflen variable in your while condition.

kind regards,

Jos

But I mentioned in my edit that I tried that didn't I? If I write an if statement that breaks out of the while loop after buflen has reached the maximum length it starts to repeat the code it produces for me...

Or was that not "checking the buflen variable"?

Just so you all know I went to random.org (an alternative to hotbits that uses the concept of "white noise" if you will to produce real random numbers) and they can produce so many random alphanumeric codes for you. So I simply copied and pasted so many to a notepad file and I'll read it from there. I'd still like to figure out how to fix this problem though...

Again, thanks for your help.

-blazed

[JosAH]

But I mentioned in my edit that I tried that didn't I? If I write an if statement that breaks out of the while loop after buflen has reached the maximum length it starts to repeat the code it produces for me...

No matter what, that stream is definitely giving you more than 256 values, too
many for your array. You have to deal with it one way or another. True random
number generators can very well generate identical values one after another;
that's what being 'random' is all about.

kind regards,

Jos

[blazedaces]

No matter what, that stream is definitely giving you more than 256 values, too
many for your array. You have to deal with it one way or another. True random
number generators can very well generate identical values one after another;
that's what being 'random' is all about.

kind regards,

Jos

The odds of producing the same 8 random alphanumeric characters in a row 10 times is 1/(35^8)^10 ...

I know something else must be wrong then. It's probably somewhere else, like where the program tells it to fillBuffer() again. Perhaps if they are associated and this no longer works properly it keeps using the same series of bytes every time it asks for a double? I don't know...

By the way, the program is already completed (using the alternative website). I had to learn how to write to excel files and write rtf documents to produce and organize lots of test packages... It was quite an effort, but I think I learned a lot from the experience so it was probably worth it...

Thanks again for the help. I may come back to tackling this problem, but in all honesty it may not happen today since there's other work to get done now that the test packages are all prepared (they need to be printed and all that)...

Thanks again for your helpful input,
-blazed

[JosAH]

ps. I tried that http address (http://www.fourmilab.ch/cgi-bin/uncgi/Hotbits?
nbytes=128&fmt=bin) and it gave me 128 bytes for a little test I ran 10,000
times. I did the same with nbytes=256 also 10,000 times and all went fine too.

kind regards,

Jos

[blazedaces]

ps. I tried that http address (http://www.fourmilab.ch/cgi-bin/uncgi/Hotbits?
nbytes=128&fmt=bin) and it gave me 128 bytes for a little test I ran 10,000
times. I did the same with nbytes=256 also 10,000 times and all went fine too.

kind regards,

Jos

Then... what did I do wrong?

*sigh*

I'm confused. I'll look at this again later... Thanks again for your help and effort.

-blazed

[JosAH]

Then... what did I do wrong?

The only thing I can find now is that you're asking for 128 bytes from that server
while the rest of your code anticipates for 256 bytes ...

kind regards,

Jos

[blazedaces]

The only thing I can find now is that you're asking for 128 bytes from that server
while the rest of your code anticipates for 256 bytes ...

kind regards,

Jos

How am I asking for only 128 bytes? I don't even see 128 being written down as a number in the program...

Thanks,

-blazed

[JosAH]

How am I asking for only 128 bytes? I don't even see 128 being written down as a number in the program...

Thanks,

-blazed

It's in your url fragment "nbytes=128". Try "fmt=ascii" instead of "fmt=bin" as
the last fragment value so you can see what comes in using your browser.

kind regards,

Jos

[JosAH]

A little update: that server doesn't want you to request too many bytes; I looked at
what I got in and it happened to be this after a couple of requests:

< h t m l > \n < h e a d > \n < t i t l e > H o t B i t s E r r o r < g t i t l e > \n < g h e a d > \n < b o d y > \n < h 1 > E r r o r G e n e r a t i n g H o t B i t s < h 1 > \n < h r > \n < p > \n T h e f o l l o w i n g e r r o r : \n < p > \n < b l o c k q u o t e > \n < b > Y o u h a v e e x c e e d e d y o u r 2 4 - h o u r q u o t a f o r H o t B i t s . < / b > \n < / b l o c k q u o t e > \n < p > \n o c c u r r e d w h i l e p r o c e s s i n g y o u r H o t B i t s r e q u e s t . T h e s e r v e r m a y b e \n t e m p o r a r i l y d o w n ; p l e a s e t r y a g a i n i n a f e w h o u r s . \n < p > \n < h 2 > < a h r e f = " / h o t b i t s / " " > B a c k t o H o t B i t s < / a > < / h 2 > \n < / b o d y > \n < / h t m l > \n

I think this basically implies that the server wants to protect itself from DOS attacks.
It's a bit strange that I didn't see this yesterday ...

kind regards,

Jos

[blazedaces]

A little update: that server doesn't want you to request too many bytes; I looked at
what I got in and it happened to be this after a couple of requests:

< h t m l > \n < h e a d > \n < t i t l e > H o t B i t s E r r o r < g t i t l e > \n < g h e a d > \n < b o d y > \n < h 1 > E r r o r G e n e r a t i n g H o t B i t s < h 1 > \n < h r > \n < p > \n T h e f o l l o w i n g e r r o r : \n < p > \n < b l o c k q u o t e > \n < b > Y o u h a v e e x c e e d e d y o u r 2 4 - h o u r q u o t a f o r H o t B i t s . < / b > \n < / b l o c k q u o t e > \n < p > \n o c c u r r e d w h i l e p r o c e s s i n g y o u r H o t B i t s r e q u e s t . T h e s e r v e r m a y b e \n t e m p o r a r i l y d o w n ; p l e a s e t r y a g a i n i n a f e w h o u r s . \n < p > \n < h 2 > < a h r e f = " / h o t b i t s / " " > B a c k t o H o t B i t s < / a > < / h 2 > \n < / b o d y > \n < / h t m l > \n

I think this basically implies that the server wants to protect itself from DOS attacks.
It's a bit strange that I didn't see this yesterday ...

kind regards,

Jos

Well... it's good to know what the problem may have been. Thank you. May I ask exactly what DOS stands for in this case?

Like I said I found an alternative solution to the problem so it's all good now.

Thanks again,

-blazed

[JosAH]

Well... it's good to know what the problem may have been. Thank you. May I ask exactly what DOS stands for in this case?

Like I said I found an alternative solution to the problem so it's all good now.

Thanks again,

-blazed

DOS == Denial Of Service attack: by burrying the server under your requests
it can't find any time/resources to service anything else.

kind regards,

Jos