A truly random source of data ?

[Perica]

..

[CESS.tk]

Maybe this is a bit of a silly sollution, but why not take the system time and add/substract a couple of years. You could even randomly generate the number of years to be added/substracted.

[dh]

When I think of random I think:

Code: Select all

' In basic, sorry
private function randDouble() as double
   dim seedA as double
   dim seedB as double
   dim seedC as double
   seedA = val(format$(time$,"hhmmssmmhh") / _
      format$(date$, "mmddyyddmmyy"))
   seedB = 1 / (rnd(3245) + 897) * 194
   seedC = val(app.threadid & asc("wissiwigggggg")) / 156 + _
      seedA + (seeb / 15))
   randDouble = (1 / cos(45)) + seedA * (seedB / (seedC * _
      seed A)) - seedB

end function

This could be said to be virtually impossibe to figure out without the day, time, whatever "wissiwigggggg" repersents, the thread id (it's a VB specific value that tells what windows thread it's working under). This code is untested so it may not work EXACTLY like it should but it should (in theory) present a very random number that beats *cough* win....*cough* encoding. ;P
The only downside I see is that darn thread id because I dont know any C version or one for any other language.

I hope this helps you!!!!

Cheers, DH.

[Solar]

SECURITY ALERT! SECURITY ALERT! SECURITY ALERT!

Do not attempt yourself at randomness, or encryption algorithms. Ever. Unless you studied the matter, at an university.

No matter how "random" your seed is, the best you can hope for is that Mallory (the one trying to break your code) will die from laughter.

Chapter 7.20.2 of the C Standard, regarding random sequence generator functions, contains the following code as an example implementation, i.e. fully valid:

Code: Select all

static unsigned long int next = 1;
int rand(void) // RAND_MAX assumed to be 32767
{
   next = next * 1103515245 + 12345;
   return (unsigned int)(next/65536) % 32768;
}
void srand(unsigned int seed)
{
   next = seed;
}

You don't have to be a genius to see that your seed merely gives a starting point into a limited and constant sequence of not-so-random numbers.

Today, the accepted state-of-the-art is to collect entropy, i.e. measuring the time between keyboard events or keeping track of mouse movements. Both approaches, as should be obvious, aren't exactly random either: A ten-finger typist writing an English language text will be in a very predictable "pattern" of keyboard events. Letters aren't equally frequent, certain sequences of letters are more frequent than others, and every ten-finger typist will follow the laws of physics and the distribution of keys across the keyboard.

There are libraries out there that specialize on this kind of stuff. Better yet, there are expansion boards available that generate true randomness (at a premium, and probably classified too).

But don't believe that any homebrewn trickery you come up with would be sufficient for strong cryptographic. You might be able to hide your diary from your mom, but that's about it. You'd be utterly surprised to see how quick cryptanalysts can break anything homegrown. Doesn't even make them blink.

If you want to do strong crypto, you have to delve into appropriate literature. It's among the best-payed computer sciences around, and for a reason.

[Curufir]

The Linux /dev/random is based around an entropy pool, but as with all pools it doesn't get really random until a sufficient amount of events have been taken (Which is why the pool is stored over boots on most Linux systems).

One possibility (If you have the sensors) would be to use fluctuations in system voltages (Which will be pretty unique to your system) combined with a timestamp and maybe some network pings (Again fairly unique to your system). Then throw all that at a random number generator (Knuth provides some nice examples that pass most maths tests) to generate short sequences. However you're still winding up with a predictable sequence of numbers, only the start point of the sequence is random.

Add-on boards that produce truly random numbers are available that use detection of particles from low-emission radioactive sources. Chances of you ever coming across one are truly remote.

[Perica]

..

[Schol-R-LEA]

The good news is, many motherboards today have a hardware RNG device (usually based on thermal flux). The bad news is, you can't rely on any given system having one, and you need motherboard-specific drivers to access the device. AFAIK, you can set Linux up to use it to feed random numbers through [tt]dev/random[/tt]. I don't know offhand what you'd need to do in Windows to access the HRNG.

[mystran]

You can also collect entropy from things like hardware interrupts. Say, on each interrupt take the lowest-bit of CPU's cyclecounter. One needs to correct for bias too (in case we get more 0 than 1 or the other way), but that can be done by taking pairs of bits, and discarding any 00 or 11, and taking 1 for 01 and 0 for 10 (or the other way). The downside is that the result is slow.

IIRC Linux does something similar when it doesn't have a hardware RNG to use. Linux also has /dev/urandom which is like /dev/random but starts giving you pseudo-randoms (seeded with real randomness) when it runs out of true random numbers; /rev/random would block if you need more than is available.

If you are not the kernel, then you can still use hardware based entropy. Some windows SSH clients (that don't seem to trust Windows for their standard numbers) give you a window when generating random numbers, were you are supposed to move your mouse around. I don't know what exactly they do, but I suppose at least collecting the (least significant bits of) exact moments the mouse-events arrive in the application would work.

But indeed, if you are going to use your random numbers for encryption, then you definitely need to either study the subject very well, or at least get someone skilled in the art to validate your design (and implementation).

[Solar]

One possibility (If you have the sensors) would be to use fluctuations in system voltages (Which will be pretty unique to your system) combined with a timestamp and maybe some network pings (Again fairly unique to your system).

A timestamp is not random...

However you're still winding up with a predictable sequence of numbers, only the start point of the sequence is random.

You have to cleanly distinguish:

* pseudo-random sequences are the "standard" way of "randomness", but no matter how random the seed is, the sequence is not (their reproducability considered a feature, not a bug); and

* "true" randomness, which can be approached by some of the stuff mentioned here (usually least-significant-bit of some non-deterministic source like temperature, a webcam pixel, rpm's of your cooling fan etc.).

If you have "true" randomness, you don't have to put it through any of Knuth's algorithms. You have a "random" sequence of 0's and 1's, that's all you need.

[dh]

I suppose your right Solar. Add that to my "research" list. Solar, you appear to know what your talking about, what would you consider a very strong encryption and what (in the bounds of software) you think to be a good source of random number generation.

[Curufir]

A timestamp is not random...

A timestamp itself isn't, but the point at which you choose to take it is and will be unique to that particular event. Just how far it fails any test of true randomness will depend on the resolution of the timestamp and if the events producing a random number are cyclic (Which is why I said to use it in conjunction with other sources). If you have a high resolution timer and random events you end up with a similar mechanism to the entropy pool.

[Candy]

A timestamp itself isn't, but the point at which you choose to take it is and will be unique to that particular event. Just how far it fails any test of true randomness will depend on the resolution of the timestamp and if the events producing a random number are cyclic (Which is why I said to use it in conjunction with other sources). If you have a high resolution timer and random events you end up with a similar mechanism to the entropy pool.

Which bits of it do you take?

Are most events within milliseconds from each other (networkserver, source=networkcard), seconds (keyboard for a slow typist) or hours (crack attempts to your network) ? Which bits change a lot, in particular?

Is it so that some bits never change (bad choice), are predictable (as in, always in the morning, evening or night), or above the actual resolution (millisecond timing from a PIT). Lots of these combined mean that you can not trust the timestamp for true randomness.

As an aside, you can probably use it for non very critical stuff, such as your webbrowser connection and encrypting your files. If you're designing military grade encryption however, you must know where you get your bits.

For a way to get more bits from a single key, try something like RC4. It generates a long list of semirandom numbers depending on one key.

[Solar]

Solar, you appear to know what your talking about, what would you consider a very strong encryption and what (in the bounds of software) you think to be a good source of random number generation.

"Very strong" encryption depends on what you intend to do with it. Consider how long the information you encrypt must remain confidential, then find an encryption that can resist determined cryptanalysis for at least that time. Of course, that requires you to have an idea of how long decryption will approximately take - which means you not only must be sure your crypt has no applicable weaknesses, but you must also know the ressources of your Mallory.

As for your crypt not having weaknesses... I am a strong believer in that there's no security in obscurity. If your code relies on being obscure, you have already lost, as data theft is always a possibility if the data is sensible enough. (And unless you're doing encryption just for your own, you have to tell Bob - the target of your communication - how to decrypt. Voila, you just created a possible security leak.

There are several publically available cyphers out there. Unfortunate that the DES-successor AES proved to be flawed so quickly, but that just shows the strongest advantage of public cyphers: There are so many really smart people working at constantly checking them for weaknesses that you stand a fighting chance of learning of a weakness rather quickly, instead of being ignorant of possible vulnerabilities.

As for random data source, if you can't get true randomness from dedicated hardware, there are several good approaches here. LSB of mouse movements for example. The trick is to "smell" when something isn't entirely random.

A timestamp is an event on a linear scale. Today is larger than tomorrow, and today is 365 days larger than last year. Unless you go for LSB again, timestamps are much too deterministic to provide randomness. (A session key, for example, could be attacked if Mallory knew the age of your session, obviously. Same goes for PGP keys etc., which usually carry a "date of creation", giving Mallory part of your "randomness" on a silver platter.)

If you're interested in the subject, I suggest "Applied Cryptography" for reading. And never underestimate the amount of research and ressources available to cryptanalysts. After all, this is about espionage, the most profitable endeavour imaginable, and the NSA and their ilk have huge ressources making even a brute-force attack on many "strong" cyphers conceivable if the data is worth the effort.

[Curufir]

I wasn't speaking about a unix timestamp I was speaking about a timestamp (Maybe my terminology is wrong *shrug*), most likely the last byte of a 10[sup]-6[/sup] resolution time source (The RDTSC instruction seems reasonable on a fast x86, actual timing accuracy would be a hindrance not a help). I'm not moron enough to believe that a second resolution stamp counting from the Epoch is going to give a random number, I hoped that was obvious...apparently not.

[Solar]

@ Curufir:

Sorry, no offense intended. It's just that I've seen the funniest notions of "randomness" put forward by people elsewhere that seemed to be completely sane otherwise. I just wanted to make sure.