The birthday problem (also called the birthday paradox) deals with the probability that in a set of randomly selected people, at least two people share the same birthday.
Though it is not technically a paradox, it is often referred to as such because the probability is counter-intuitively high.
The birthday problem is an answer to the following question:
In a set of randomly selected people, what is the probability that at least two people share the same birthday?
What is the smallest value of where the probability is at least % or %?
Let be the probability that at least two of a group of randomly selected people share the same birthday. By the pigeonhole principle, since there are 366 possibilities for birthdays (including February 29), it follows that when , %. The counterintuitive part of the answer is that for smaller the relationship between and is (very) non-linear.
In fact, the thresholds to surpass % and % are quite small: % probability is reached with just people and % with just people.
For simplicity, ignore leap years. Then the probability that two people will share the same birthday out of is
As in the introduction, let be the probability that in a set of randomly chosen people at least two people share the same birthday. Then is the probability that every single one of them has distinct birthdays.
The number of ways to pick distinct birthdays from a set of days (when the order in which you pick the birthdays matters) is this is because each successive birthday has one fewer choice of days left. This is the numerator of
The number of possibilities for the birthdays for people (again the order matters) is . This is the denominator of
The formula follows immediately:
One intuitive explanation of the phenomenon that is large for small is that there are pairs of people, all of whom can share a birthday. So the probability of at least one pair matching increases more rapidly than the number of people. (This is only a crude approximation of the true behavior of because the probability of multiple matches grows rapidly as well, and must be taken into account.)
The probability should be not confused with the probability that there is at least one person with a fixed birthday, which is much lower. That is, if I go to a party, the probability that two people at the party share a birthday is much higher than the probability that someone at the party shares a birthday with me. The latter probability is computed in the following example.
Suppose that (ignoring leap years) the probability that a person's birthday is any given day is (This does not match the real world, as certain birthdays are more common than others, but it is a useful simplification.) What is the probability that at least one of randomly chosen people was born on April 23? How large does have to be before this probability exceeds %?
The probability that no one has that birthday is so the answer to the first question is The smallest for which is (Intuitively, this is larger than because people in the room may share the same birthday; if everyone was guaranteed to have a different birthday, the answer would be
Note that this is not hard to obtain approximately, using the Taylor series approximation for small : if then so
Most cryptosystems use some kind of hash function to process messages. A hash function is not injective, but is created so that collisions, or instances where but are hard to discover. An attacker who can find collisions can access information or messages that are not meant to be public. The birthday attack is a restatement of the birthday paradox that measures how collision-resistant a well-chosen hash function is. For instance, suppose that a hash function is chosen with a 64-bit range; that is, its image is a nonnegative integer less than How many values does an attacker need to compute before the probability of a collision is greater than %?
Just as with the birthday paradox, the probability of a collision from random samples is where
It turns out that when is on the order of This represents a significant improvement on the sizes involved: for instance, is roughly while is greater than This vulnerability necessitates the use of a large hash range in practical applications.