Computers cannot generate random numbers. A machine which works in ones and zeros is unable to magically invent its own stream of random data. However, computers can implement mathematical algorithms which produce pseudo-random numbers. They look like random numbers. They feel like random distributions. But they're fake; the same sequence of digits is generated if you run the algorithm twice.

Included in the post is code showing how to use the random functions and how to create a class (Random) that provides a few methods to help make generation easier - "seed" and "num". It first calls "seed" with a number to start the random generator off with and then "num" in a loop to pull out random values based on that.

When we talk about "random" numbers, we generally talk about two fundamental properties: Predictability and Bias. Both are closely related, but are subtly different. Predictability in reference to random numbers is the statistical problem of predicting the next value when knowing any number of previous values. Bias on the other hand is the statistical problem of predicting the next value when knowing the distribution of previous values.

He looks at how predictability can effect true random number generation and a common mistake in generation related to bias in the calculation method. He talks about some of the functions PHP includes to work with randomness, but notes that they all have their flaws. He points to the PHP-CryptLib package as a solution (adhering to the guidelines in RFC 4086 for randomness). He includes some sample code of how to use it to generate random numbers, tokens and sets of bytes. You can find the full source over on github.

My current project (BiteStats, a simple report of your google analytics data) uses a basic system where there are numbered patches, and a patch_history table with a row for every patch that was run, showing the version number and a timestamp. When I deploy the code to production, I have a script that runs automatically to apply the patches.

The script uses the number-based patch names (such as patch1.sql) and finds the latest ones that haven't been applied based on the highest values for the patch_number column in the database. This number is updated by the patches themselves when they're run to avoid any confusion in the script itself. She has it running as a part of her phing build process as a part of a Zend Framework application.

When taking Phone number as user input, we can worn users about phone number format by setting a hint/description and can validate using Regular Expression. [...] Now, if we try provide this feature in Zend Form, that's possible. We can create three individual Zend_Form_Element_Text objects and join there value together to make the phone number. But, in this case, validating them together is a hassle.

Instead of separate fields, the library they create makes it simple to handle them as a whole field. It works as a helper for Zend_Form and lets you set things like the separator between the text fields, a "format" string and a validator to apply to their fields (in the example code, it's the "digits" validator). Sample code is included to show you how it fits in your form.

Seclists.org has posted an advisory titled "Weak RNG in PHP session ID generation leads to session hijacking." RNG stands for Random Number Generation, and the advisory is warning that not enough entropy is being used to seed the RNG; this, in turn, can lead to a reduced number of possible session IDs under certain specific conditions, thus making brute force session spoofing easier, if not bringing it into the realm of feasibility.

The threat is only marked at a "medium" level of severity, but it could still cause problems if you're not careful. There are specific conditions that have to be in place for it to be a problem including using the standard PHP session generation and that the app shares the information about remote users. To protect yourself you can either install Suhosin and don't use the result of set an external source for entropy to help randomize the session ID even more.

In PHP is really no ideal way to test large integers and determine whether they are prime numbers or not. The most popular algorithm for finding prime numbers is a memory and resource hog. It is called The Sieve of Eratosthenes.

You can get more of an idea on this method in this video and in this example from Wikipedia. He includes the full source for his solution that includes methods like isInteger, isPositive, isPerfectSquare and isPalindromicPrime. The script is also available for download.

Last time we looked at text and strings in variables, in this episode we're going to continue with our exploration of PHP variables and delve deeper into math and number handling in PHP. Using numbers is not much different to using text and strings, you allocate variables and fill them in, using exactly the same techniques as you do using strings & text.

They covers some of the basic operators (+,-,*,etc), evaluation with equals, number shifting, binary and creating a "barrel shifter" to work with the binary bits of a number.

Last night I spent a couple of hours with Zend Framework and especially Zend_Form. I discovered, and now also reported as ZF-6175, a bug in Zend_Validate_Float when using a locale with a decimal point other than ".". There are unit tests but none that test Zend_Validate_Float under a different locale.

He points out that floats are locale-aware in PHP itself (code examples) and how the current Zend_Validate float package handled it. He has already proposed a fix for the problem and, until its changed in the framework, has provided the simplified code you can use.

The plan for this one is that, if you're doing a sudoku puzzle in the pub or on the train, and you get stuck, you just take a snapshot of the puzzle with your camera-phone, send the photo to a certain mobile number, and a few seconds later the solution is sent back as an SMS message. The solution costs you something small - 50 cents, maybe.

The script looks at a picture of a sudoku puzzle, converts it to b&w and tries to find the squares surrounding each position of the board. With these measurements, the next step is to grab the numbers already in the puzzle and hand those off to the puzzle solver to be processed.

PHP comes with two random number generators named rand() and mt_rand(). The first is just a wrapper around the libc rand() function and the second one is an implementation of the Mersenne Twister pseudo random number generator. Both of these algorithms are seeded by a single 32 bit dword when they are first used in a process or one of the seeding functions srand() or mt_srand() is called.

He looks at how its currently implemented, some examples of bad methods to get "random" numbers, how shared resources are a problem and an example of a cross-application attack (the application in more than once place using the same method for getting random numbers).

In the comments he recommends either grabbing from /dev/random (if you're on a unix-based system) or making the creation of your numbers a bit more complex to include things the outside world wouldn't know.