Birthday Paradox Calculations and Approximation

Transcription

1 Birthday Paradox Calculations and Approxiation Joshua E. Hill InfoGard Laboratories -March- v. Birthday Proble In the birthday proble, we have a group of n randoly selected people. If we assue that birthdays are uniforly distributed aong the 365 days of the year (which we ll later call buckets ), then what is the chance that any people in the group share a birthday with each other? Directly calculating this probability is obnoxious, but we can calculate the probability of this event using the probability of the copleent of this event; naely, we calculate the probability of no two people sharing the sae birthday (which is the copleent of the situation we care about) and subtract this probability fro 1. This (under the appropriate convention for the binoial coefficient) is 1 n1 365 k 365 D n nš 365 n. It s fairly clear that if you have 366 people in the roo, then (by the pigeonhole principle) you are guaranteed to have at least one shared birthday (and, indeed, the above forula captures this behavior!) The surprising thing is that the likelihood grows quite quickly: for n D 47, the probability of a shared birthday is slightly greater than 95%, and n D 23 is the first to ake a shared birthday ore likely than not. Figure shows how quickly this probability grows. The Birthday Paradox in Cryptography In cryptography, we are oen interested in the instance where soe rando process (which is either a deterinistic process that we are odeling as rando, or a literal rando process) happens to produce the sae output as soe prior output, which in this setting is called a collision. This is another application of the classic birthday paradox, but generally with ore possible buckets. We ll ignore the vulgarities of the actual calendar such as leap years, leap seconds, various conventions for the calendar, etc. We further assue that cows are spherical, and of unifor density. Making use of the laws of noncontradiction and excluded iddle.

2 Probability of a Shared Birthday n Figure : Probability of a Shared Birthday If we consider the case where there are buckets and n outputs, we can slightly abstract the above calculation and find that the probability of at least one collision is Pr.collision/ D 1 D1 n1 n1 k 1 k. () If we need to actually do calculations, then large quantities for n or ake the above calculation ipractical, but this gives us a hint as to how to proceed. Approxiation We develop a standard approxiation for the above by first reebering that e x D X j 0.1/ j x j j Š D 1 x C X.1/ j x j. () j Š j 2 For ease of notation, we ll denote " x D X.1/ j x j, j Š j 2 which (by the above) tells us that " x D e x C x 1. Soe calculus shows us that " x is non-negative, and is an increasing function when x > 0. One way of interpreting Equation () is that 1 x D e x " x, () The analogous closed for 1. n/nš n is also true, but it is generally ipractical to ake calculations based on this for of the equation.

3 and so for values of x very close to 0 we see that " x 0, so we can approxiate 1 x e x. If we apply this approxiation to Equation (), we arrive at Pr.collision/ 1 n1 e k D 1 exp 0 C 1 C C n 1 D 1 exp.n 1/.n/ 2. () For ease of notation, we ll denote.n 1/.n/ A D exp, 2 which is our approxiation of the probability of there not being a collision. We were operating under the assuption that our approxiation is reasonable, but we d like soe better idea as to how good the approxiation is for actual values of and n. For this, denote x k D k=: " D j.1 A/ Pr.collision/j D jpr.no collision/ Aj n1 D.1 x ˇ k / A ˇ n1 D e x k " ˇ xk Aˇˇˇˇˇ n1 D A 1 e x k " ˇ xk 1!ˇˇˇˇˇ D A 1 A 1 0 n1 e x k x k e x k! e n= n en= n n 2 D A B1 exp 1 n n A ƒ D exp.n 1/.n/ 2 M 1 exp 1 n 2 1 n n () () The step yielding Equation () is based on soe calculus, and the behavior of the ters being ultiplied together, given the possible values of x k. The sign change in Equation () tells us that the Pr.collision/ 1 A; in order to properly bound the probability of collision, we need to include the contribution of ".

4 Together, Equations () and () allow us to bound the probability of a collision given arbitrary input paraeters, naely Pr.collision/ D 1 A C " 1 A C A.1 M / 1 AM.n 1/.n/ D 1 exp 2 n.n C 1/ D 1 exp 2 exp 1 n n 2 n 1 n n We could bound the probability of collision as being less than p by bounding which is true if n.n C 1/ Pr.collision/ 1 exp 1 n n < p, 2 n.n C 1/ 1 p < exp 1 n n. 2 () Taking the log of both sides, we find n.n C 1/ log.1 p/ < C n log 1 n. () 2 Equation () is readily verified for various paraeter settings using a coputer algebra syste. Collision of Blocks In soe circustances, we have the case where collisions are in soe sense binned, that each choice could collide with soe fixed nuber of other choices. Conceptually, apping a rando output through any non-injective function could elicit such a situation, but we also encounter this situation in ore natural settings. In this case, we ll describe the bin size as b. Happily, this proceeds in uch the sae way as the above. First note that in ters of exact calculation, we have Pr.collision/ D 1 D1 D1 n1 n1 n1 bk 1 bk () 1 k. ().=b/ Equation () gives the equivalent forulation as Equation (), but perhaps Equation () gives a better intuitive notion of what is going on. This shows us that in the case that we are concerned with block

5 collisions, we have exactly the sae situation as the non-block case, but the nuber of buckets is the ratio =b. As the exact calculation takes this for, we can naturally use the sae approxiation that we have already developed by replacing the ter with the ratio =b. A Note on Conditional Probability We occasionally encounter situations where we have already done the work necessary to calculate the probability of a birthday collision aer n outputs into two collections of buckets (where each collection has a possibly different nuber of buckets) and we then want to consider a setting where these are cobinatorially cobined. For exaple, iagine that we have two rando processes, the first of which outputs a 16-bit value and the second of which outputs an 8-bit value. Using the above developent, it s easy to calculate the probability of collision for each aer 2 6 outputs (indeed, this can be accoplished with no need to approxiate, given a odern coputer). One can directly do the sae for a 24-bit value. Table : Independent Events: A Non-Exaple (n D 2 6 ) Pr.collision/ 2 8 p 8 D 0: p 16 D 0: p 24 D 0: We know that the axio of conditional probability tells us that if we have two events A and B, then Pr.A \ B/ D Pr.AjB/ Pr.B/, which, in the case that A and B are independent, gives the very useful Pr.A \ B/ D Pr.A/ Pr.B/ (when A and B are independent.) Observe that p 24 p 8 p 16, so the probability of collisions are not independent. The reason for this is soewhat clearer once one considers the exaple of two single-bit quantities. Aer three outputs, each single-bit quantity is guaranteed to collide with soe past output (there are, aer all, only two possible buckets!), but a single two-bit quantity only has a 62:5% chance of colliding aer 3 outputs. We need ore than both collisions happening for soe output, they ust collide on the sae output. The conclusion we should draw fro this is that we can t siply ultiply chances of collision together and expect to get soething sensible out, because these events are not independent. We ll try to avoid including the tie easureent fortnights in any calculations featuring this ratio of buckets per bin.

6 Motivating Exaples In each of the following exaples, we use Equation () to find the axial integer value of ` so that if, for a given value of, aer n D 2` outputs, the probability for a collision is less than soe given axiu probability bound for a collision, p.. CBC or OFB Modes With AES and DES In ode, inforation about the underlying plaintext leaks in the event that the cipher outputs a previously output value. In ode, such a collision causes the coplete coproise of all data encrypted aer that collision. If we odel and as rando aps, then we can directly apply the aterial we have just developed to find out how any ciphertexts can be output before the probability of producing a collision becoes higher than soe bound. For (which has a -bit block size), we let D 2 64 and for (which has a -bit block size), we let D Table : Maxiu Nuber of Encryptions for and in or ode Algorith p IPSec with GCM provides a way of using ode within ec s Encapsulating Security Payload (), so long as key agreeent is handled using an autoated key anageent syste, coonly or v. For this section, we assue that or v are being used. In Special Publication -, there ust be a chance of less than 2 32 that any particular is re-used with a particular key. For all calculations that follow in this section, we thus set p D 2 32, unless otherwise explicitly stated. In this use, the is always a -octet (-bit) value. The first part of the is the salt, a - octet value that is created using the sae process that produces the session keys for the security association; for this analysis, the salt and the session key are odeled as randoly distributed. We refer to each set of independent (or v) security associations as a key context; each key context has a particular (fixed) key and salt. The last part of the is an -octet, which is set in one of three ways:. A counter with a fixed starting point.. A counter with a randoly generated starting point.. A randoly generated value for each essage.

7 For copleteness, we also provide an analysis for the case where four of the octets of the are fixed to soe ID associated with the sender (e.g., the sender s IP) in order to coply with - IG A. (dated //)... Fixed Starting Point With a fixed starting point, one necessarily collides in the event that the key and salt collide, so the size of the colliding bitstring is the key length plus bits for the salt. As such, we have the results in Table. Table : Allowable Key Contexts (Fixed Starting Point Bounds) Key Length Key Contexts In this case, the size of the counter does not affect the collision bounds but does liit the nuber of possible essages within a single key context. As such, encoding the device s ID into the doesn t affect the nuber of allowable key contexts that can be used for the given collision probability bound, but does ake it so that the nuber of allowable key contexts applies only on a per-odule basis. The resulting nuber of essages per key context liits here are at ost 2 64 essages for ipleentations that use the full -octet as a counter, and 2 32 essages for ipleentations using 4 of the octets to encode an ID (leaving the reaining 4 octets to encode the counter.).. Randoly Generated Starting Point With a randoly generated starting point, you get the benefit of being able to guarantee no collision of the within a fixed key context, along with soe added resistance to collision provided by the rando starting index. To establish how uch added collision resistance we get, we need to first liit the nuber of essages that can be encrypted within a particular key context; this is a tunable paraeter, so we exaine a few reasonable settings for the nuber of essages per key context, which we ll call T. When you choose a starting point for the, x, you not only exclude all the selections up to x C T (which could be used within this key context) but also those starting aer x T (as selecting one of these could eventually cause a collision). We thus exclude at ost 2T selections for each choice (thus b D 2T ). As a special case, if there is effectively no liit on the nuber of essages, then T D 2 64 in the case where 8 octets are used for the counter, and T D 2 32 in the instance where 4 octets are used for the counter. (In this no liit case, we have ade it so that when a key and salt collision happen, then there will be a full collision). In order for the tuple (Key, ) to collide, we ust have a siultaneous collision of the key and salt, then additionally encounter a block collision. As a saple calculation of the nuber of buckets for a

8 128-bit key and a axiu of 2 32 essages per key context, we have D key ƒ (Binned) Counter Salt ƒ ƒ D 2 128C32C31 D Table : Allowable Key Contexts (Rando Starting Point Bounds) Key Length Max Encrypts per Key Context (T) If we effectively do not liit the nuber of essages per key context (and allow the full 2 64 distinct encryptions), this approach is equivalent to the case where we have a fixed starting point (this colun has the sae results as in Table ). If, in response to - IG A., we fixed octets of our by setting the to a device-specific identifier (e.g. the device IP), then there are only thirty-two bits of counter le to be randoly assigned. As such, we surely couldn t encrypt ore than 2 32 essages, and we are le with the bounds described in Table. Table : Allowable Key Contexts (Rando Starting Point Bounds, Copliance with IG A.) Key Length Max Encrypts per Key Context (T) This odification results in a reduction of both the allowable key contexts, and the total essages that can be encrypted within a single key context. The advantage of this approach is that it akes each device specific... Randoly Generated Per-Message ESP IVs In ec, the first four octets of the are fixed within a key context, so there are only eight octets available to be randoly set within a fixed key context. In order to aintain the desired per-key-context collision bound of 2 32, we ust restrict to at ost 2 16 essages within a fixed key context. In the event that a key-context collision has occurred (i.e., a particular key and salt cobination have been used again), the total collision probability would surely rise above our bound, so we are then again le with the situation addressed already in Table.

9 .. Attacker Model An attacker who wants to be prepared to attack a syste using in this way will be forced to dedicate soe aount of coputational and storage resources in order to notice that a collision has occurred. There are two basic approaches: an attacker can onitor within a particular key context, or an attacker can onitor across ultiple key contexts which (in the case where the address is not encoded into the ) could take place over any device capable of counicating using with ec. Attackers onitoring for collisions within a fixed key context need to store all the data within that particular key context. As the only approach outlined above susceptible to this style of attack is the rando per-essage approach, the attacker would have to store at ost 2 16 essages, each of which requires storage of at least octets (a -octet and a -octet ciphertext ust both be stored) and at ost roughly 2 32 octets (for IPv) or 2 16 octets (for IPv). Within a key context, duplication of the sent iplies a full (Key, ) collision, so an attacker just needs to copare the on at ost 2 16 essages. For an attacker to have a 2 32 chance of success, they ust then be willing to store 2 19 to 2 48 octets (roughly. MB to TB), with a practical axiu being approxiately GB (for attackers not dealing with IPv ipleentations that support jubogras). Looking for collisions within this data set requires at ost 2 16 operations, so this is an overall odest effort. Attackers onitoring for collisions across ultiple key contexts have a harder tie. They can again watch for collisions within the -octet, but this reveals relatively little. In practice, coparison of these s ay require substantial coputation (given the scale of the nubers involved), but for the purpose of this analysis, we assue that establishing if a particular has been seen before is a coputation that can occur in O.1/ operations (e.g., using the odel, a table lookup or optial hash table lookup). We also assue that the attacker can establish if there has indeed been a (Key, ) collision in O.1/ operations once the atches. Iportantly, the nuber of operations an attacker needs to perfor is never less than the nuber of essages gathered for an attack, as each additional essage requires soe processing to check if the has re-occurred, and if so then to check if this is an exaple of a (Key, ) collision. For exaple, if an attacker onitors 2 64 distinct key contexts, each with 2 16 essages in the, then the attack has a work factor of 2 80 coputations. These results are suarized in Table. All the attacks suarized in Table have a probability of success of 2 32 ; for coparison, the key exhaustion attacks with this probability of success have a coputational work factor of 2 96 for a 128-bit key, for a 192-bit key, and for a 256-bit key. A ore reasonable estiation of the effort required for an attack would be the the attacker s expected resource use for a successful attack; for this, we exaine the case of a probability bound of p D 1 2. These results are suarized in Table. All the attacks suarized in Table have a probability of success of 2 1 ; for coparison, the key exhaustion attacks with this probability of success have a coputational work factor of for a 128- bit key, for a 192-bit key, and for a 256-bit key. For Tables and, attacks with no coputational advantage over the relevant key exhaustion attacks are greyed out. Within these tables, the stated coputational bounds can be converted to storage bounds (in octets) by adding a storage factor to each exponent; this storage factor is between 3 (associated with

10 attacks on data streas containing only the sallest possible essages) to 32 (associated with attacks on data streas containing only the largest possible essages). Table : Attack Coputational Cost (p D 2 32 ) Key Length Max Encrypts per Key Context Fixed Starting Point Rando Starting Point Rando Starting Point (A.) N/A N/A N/A N/A N/A N/A Randoly Generated Per-Message N/A N/A N/A N/A N/A N/A N/A N/A N/A If an attacker is interested in finding a collision for one particular key context (and can thus discard data when it is found not to be related to the desired key context), then the aount of storage is draatically reduced, but so is the attacker s chance of success. In order to benefit fro a birthday style collision, the attacker ust be able to in soe sense retain all the data they have seen, which (as seen above) iposes a assive storage and coputational cost... Standards Details Soe of the above apparent options run afoul of various requireents or guidance. For what follows, we adopt the language of -. This docuent provides for two ways of constructing the, a deterinistic construction (specified in Section..) and a -based Construction (specified in Section..). Deterinistic Construction Setting a fixed starting point for the ust be considered a deterinistic construction of the. Setting a randoly generated starting point for the and then increenting fro there ay also be considered a deterinistic construction of the. In this setting, the salt can be considered In fact, the average cost per octet is best for the attacker when each essage is largest!

11 Table : Attack Expected Coputational Cost (p D 2 1 ) Key Length Max Encrypts per Key Context Fixed Starting Point Rando Starting Point Rando Starting Point (A.) N/A N/A N/A N/A N/A N/A Randoly Generated Per-Message N/A N/A N/A N/A N/A N/A N/A N/A N/A as part of the fixed field. The salt does not uniquely identify the device, so to satisfy the requireents of - IG A., an additional bits of the ust be fixed to soe identifying inforation (e.g., the device IP). This results in the invocation field being at ost bits. The above analysis suggests that requiring this fixed identifier within the does not substantially affect the difficulty of launching an attack fro a coputational perspective (indeed, it akes it worse in the randoly-set case); it does ake it so that an attacker ust gather a ridiculous aount of data fro one target, but this doesn t see wildly less practical than an attacker gathering an even ore ridiculous aount of data fro a possibly vast nuber of targets. Fundaentally, the attacker ust store all this data soewhere, and the aount of data involved is several orders of agnitude beyond anything available to all of huanity (the iniu storage for any of these attacks is on the order of yottabytes, or bytes), to say nothing of single (even well funded) attackers. -based Construction Starting with a randoly generated value (and then increenting fro there) and setting the randoly for each essage can both alost be considered a -based Construction of the. In this construction, the salt value ust be considered part of the free field, as it is not generated using an approved with a sufficient security strength, does not get increented along with the rest of the rando field as described in Paragraph of Section.., and is fundaentally associated with the Note that - does not appear to require encoding the address in case of ec with, as use of in ec assures that (as in paragraph of Section..) a fresh key is liited to a single session of a counication protocol, with probability bound vastly better than 2 32.

12 key context, not the particular essage. The reaining 64-bits of the (that is, the ) is thus categorized as the rando field. Unfortunately, even if this rando field is generated by an approved, it is not sufficiently large to eet the requireents of - Section.. (the rando field is required to be at least 96 bits by Paragraph of Section..). If the is considered suitably strong to be allowed to produce the session keys used in the ec security associations, then it sees reasonable to consider its output as rando-looking enough to ake up a portion of the rando field. Siilarly, though fixing a -octet portion of the rando field does ake the discussed 2 32 essage axiu the wrong bound for per-essage randoly generated rando fields, we saw above that a essage axiu of 2 16 yields the correct collision bound. In the instance that rando field is initially set randoly and then increented, this axiu nuber of essages has less significance.