Practical Random Number Generation in Software

John ViegaVirginia Techviega@list.org

Abstract

There is a large gap between the theory and practicefor random number generation. For example, on mostoperating systems, using /dev/random to generate a256-bit AES key is highly likely to produce a key withno more than 160 bits of security. In this paper, wepropose solutions to many of the issues that realsoftware-based random number infrastructures haveencountered. Particularly, we demonstrate thatuniversal hash functions are a theoretically appealingand efficient mechanism for accumulating entropy, weshow how to deal with forking processes withoutusing a two-phase commit, we explore better metricsfor estimating entropy and argue that systems shouldprovide both computational security and informationtheoretic security through separate interfaces.

1. Introduction

Security-critical applications require “random”numbers. Unfortunately, there is no consensus on thebest way of obtaining such random numbers.Moreover, there is not a consistent set of requirementsor terminology between different solutions.

Ultimately, we would like generators capable ofgiving “true” random numbers, where all 2n possiblevalues for an n bit datum are equally likely from thepoint of view of an adversary. I.e., we would like arandom number generator to provide informationtheoretic security, where there is one bit of entropy perbit of generator output.

In practice, that goal often isn’t feasible due to thedifficulty of harvesting high-entropy data. Instead, it iscommon to take data that is believed to containenough entropy for cryptographic security, and use itto “seed” a cryptographic pseudo-random numbergenerator, which is an algorithm that produces a streamof values that one hopes, for all intents and purposes,is indistinguishable from random to any attacker inpractice, even if a theoretical attack were possible,given unbounded resources.

Conceptually, producing a pseudo-random streamof numbers from a seed is a well-understood problem.

There are simple, efficient cryptographic constructionsthat leak insignificant amounts of information aboutthe internal state, such as a block cipher run in CTR(counter) mode. Nonetheless, there are numerouspractical pitfalls, even when one has acryptographically sound PRNG. Many of the concernshave been addressed by other work. [15] and [6] bothlook at the range of attacks that can be launchedagainst random number infrastructures.

Nonetheless, the currently deployed solutions areunsatisfying. The more implementation-orientedsystems such as the /dev/random and /dev/urandomdevices on many modern operating systems often failto facilitate analysis, whereas research-oriented systemstend to ignore some important practical requirements.

Having a secure source of random numbers is acritical assumption of many protocols systems. Therehave been several high profile failures in randomnumber systems leading to practical problems, such asin the Netscape implementation of SSLv2[10] and amore recent exploit where several online gamblingsites had shuffles that were easy to predict[1].

The scope of the problem was shown to be vastwhen OpenSSL began checking to see whether aseeding function had been called before using itsrandom number generator. The OpenSSL mailing listwas flooded with error reports from people with brokensoftware, and similarly with broken suggestions onhow to work around the solution. According to [11],many users copy from the OpenSSL test harness, andseed with the fixed value, “string to make the randomnumber generator think it has entropy”.

In the embedded space, the problem is even worse,because there is often no access to cheap entropy.Therefore, protocols involving session keys or otherdata that needs to be random can be at great risk.

Additionally, there are a number of practical issuesthat should be reconsidered in existing infrastructures.For example, many systems provide only a PRNG,not allowing for information theoretic security. Evenamong the systems that do try to provide an “interfaceto entropy”, they do not do it in a way that is secure inthe information-theoretic sense. For example, Linux’s/dev/random implementation tries to make sure that

every bit of output contains one bit of entropy, butturns out to have a flaw that makes it unsuitable forproducing 192-bit (or higher) AES keys. We discussthis problem is section 6.In this paper, we discuss a collection of “bestpractices” for random number generation, many ofwhich are novel. Our recommendations are allimplemented in the EGADS random numbergeneration package.

2. Interfaces to Random Numbers

People tend to use pseudo-random numbers insteadof numbers that are secure in the information theoreticsense (i.e., truly random numbers with entropy to anattacker) only because pseudo-random numbers areefficient to generate, whereas data with large amountsof entropy tends to not be. One advantage of usingtruly random numbers is that the difficulty of breakingone random value (by, say, brute-force guessing) isindependent of breaking any other value. That is nottrue with a cryptographic PRNG, where an attackerwith enough output can predict future outputs with aprobability of 1, assuming enough computationalresources. A good PRNG will provide computationalsecurity, meaning that an adversary with realisticresources should not be able to distinguish PRNGoutput from truly random data. However, PRNGs areincapable of providing information theoretic security inthe way that a one-time pad can.

We believe that the gap between informationtheoretic security and computational security arguesthat systems should not only provide an interface tocryptographically secure pseudo-random numbers, theyshould also provide an interface to numbers that arebelieved to be truly random. Even though mostapplications will not be willing to expend significantresources to get truly random numbers, there areoccasions where it can be useful.

For example, there may be some high security datawhere one would like to ensure that the compromise ofone piece of data does not lead to the compromise ofother pieces of data, such as long-term, high securitykeys.

Another consideration is that a system may wish tohave more security than a pseudo-random numbergenerator has the strength to provide. For example, thePRNGs provided by most operating systems usecryptography that is based on a 128-bit symmetriccipher or a 160-bit hash function, and thus can neverhave more than 160 bits of security at any given time.But, one may wish to generate a 256-bit symmetrickey, or a public key pair where 256-bit equivalentsecurity is desired.

Note that using two 128-bit PRNGs that areindependently seeded does not solve the problem, onlydoubling an attackers workload, increasing security to129 bits instead of the desired 256.

Many systems intertwine entropy harvesting andpseudo-random number generation. Those that do notstill are generally only concerned with providing astream of pseudo-random numbers. However, webelieve that a good randomness infrastructure shouldprovide at least two interfaces, one that is fast andcryptographically strong, and one where data that ishopefully truly random, with one bit of entropy per bitof output.

There are other types of interfaces that one may wishto provide. Particularly, we see two other usefulconcepts. First, one may wish to have truly randomdata if it is available, but still be willing to fall backon pseudo-random data to fill in the rest.

Second, there are times where the state of a pseudo-random number generator need not be secret— it isonly important that the outputs be strongly collisionresistant. Particularly, the attacker who knows thealgorithm for generating outputs should not be able totake a different internal state and be able to produce thesame output. This is the case when choosing sessionIDs for TCP/IP[11], and can be the case whenchoosing public object identifiers in systems likeCOM. A cryptographic PRNG will do for thesepurposes, except when there is not enough entropyavailable. We prefer to look for other solutions to thisproblem, as such an API is likely to be misused.

3. Basics

Randomness infrastructures will generally involve aPRNG by necessity, and should always have acomponent for harvesting entropy (we will refer to datathat has the chance of being truly random as entropybecause it is a convenient and common term, even if itis a slight misusage in the information theoreticsense).

Even if entropy is only used to seed a PRNG,infrastructures should still harvest their own entropy,because experience shows that pawning theresponsibility for entropy harvesting onto clients leadsto a large number of systems with inadequately seededPRNGs.

Entropy gathering should be a separate componentfrom the PRNG. This component is responsible forproducing outputs that are believed to be truly random.We will refer to the entropy gather component as theentropy harvester.

Entropy harvesters are responsible for collectingdata that may contain entropy, estimating how muchentropy has been collected, and turning that data intooutputs that are as close to truly random values as

feasible. The last requirement demands some sort ofcryptographic post-processing (often called whitening)to try to distribute entropy evenly throughout outputvalues, and to otherwise try to remove any statisticalpatterns that might have been lingering in the data.

Randomness infrastructures should be designedwith a particular threat model in mind. In order tobuild a threat model, we must first understand thetypes of attacks that one might try to launch against asystem.

At a high level, there are few vectors of attack.First, there may be some way to guess the internalstate by observing the outputs (a cryptanalytic attack).Hopefully, such an attack will only apply to a PRNG,but can apply to an entropy harvester if data ismishandled or entropy is overestimated. Second, anattacker may have knowledge of sources that theentropy collector polls. Third, an attacker may be ableto introduce malicious data into the entropy collector.Finally, there may be some sort of side channelallowing the attacker to read some or all of the internalstate of the generator. This may be a timing channel,but it is more likely to be due to environmentalcompromise unrelated to the generator. For example, ifan attacker can look at kernel memory, she may be ableto read the state of the entire randomness infrastructuredirectly.

Generally, a threat model will assume that theattacker cannot break strong cryptographic algorithmswith 80-100 bits of security, meaning that a good,well-seeded PRNG makes the first class of attackuninteresting. For the rest of the possible threats, oneshould go through a common threat modeling exercise.For example, one should determine whether to worryabout physical threats, such as van Eck attacks[16] andshoulder surfing (both realistic physical attacks inmany circumstances). Also, one must figure outwhether other users on the same machine are a possiblethreat.

Having a concrete threat model is especiallyimportant in a randomness infrastructure, because oneneeds to have a complete understanding of an attacker’scapabilities in order to be able to estimate the amountof entropy in data. That is, while most people think ofentropy as an absolute measure of how unknowabledata is, entropy is actually relative to a particularobserver. For example, before the winner of anacademy award is announced, the auditors who stuffedthe envelope know the result. Therefore, there is noentropy in the envelope for them. Other people (suchas Hollywood insiders) may have access to pollinginformation, meaning that there may not be as muchentropy as possible in the envelope if, to the observer,some possibilities are more likely than others. Ofcourse, there may be more entropy in the envelope forthe average viewer at home.

4. PRNG Design

The two major requirements for a PRNG areefficiency, as one may wish to produce a large bulk ofnumbers in a small amount of time, and security.Particularly, one will wish to provide a particular levelof cryptographic security, where information leakage isminimized.

The security requirement is best met with a well-analyzed block cipher in CTR mode. Such a PRNGwill leak a mere one bit of information after producing2n/2 blocks of output, where n is the block size of thecipher in bits (and assuming the key length is at leastas long as the block length).

One should prefer block ciphers in CTR mode togenerators based on a dedicated stream cipher. CTRmode requires only that the block cipher be a pseudo-random permutation [2], which is widely believed tobe a reasonable assumption. Dedicated stream ciphers,on the other hand, need to be strong ciphers and alsoneed to resist related key attacks. For example, due toa related key attack, the naïve use of RC4 as a PRNGis fundamentally flawed [8], even disregarding biasesin the cipher [9].

Cryptographic hash functions can also be a goodfoundation for a PRNG. Many constructs have usedMD5 or SHA1 in this capacity, but the constructionsare often ad hoc. When using a hash function, wewould recommend HMAC in CTR mode (i.e., oneMACs counters for each successive output block).Ultimately, we prefer the use of block ciphers, as theyare generally better-studied constructs.

Depending on the threat model, one may wish toconsider protected memory, which is difficult toensure. See [11] for a good discussion of the issues.

4.1 Reseeding a PRNG

There are two primary reasons why one might wantto reseed a pseudo-random number generator. First, thegenerator may not contain as much entropy as isdesired, perhaps due to the system not having beenseeded yet, the entropy harvester being too liberal, ordue to environmental compromise. In these cases, onewould like to add additional entropy to the generatorstate, while preserving any entropy that does exist inthe current state. The other case is to provide forwardsecrecy. Consider an OS-based PRNG where theoperating system is compromised. A generator shouldensure that PRNG output requests that were fulfilledprior to the compromise cannot feasibly be recoveredalgorithmically from the current generator state.

The first type of reseed we call an external reseed,whereas the second is called a self-reseed.

Let us consider the case where one is using AES-128 in CTR mode as a PRNG. Reseeding thegenerator must involve replacing the key with a newvalue. Additionally, one should replace the value of

the counter with something unpredictable to theattacker, because randomizing the counter can preventmeet-in-the-middle attacks that would reduce theeffective strength of the PRNG to 64 bits.

For a self-reseed one can use the generator to output256 bits of data, then use the first 128 bits to rekey thecipher, and the second 128 bits to replace the countervalue. Rekeying the block cipher with its own outputis an effective one-way transformation assuming thegenerator has the desired entropy. This technique wasfirst introduced in [12].

For an external reseed, one should combine newseed material with the current generator state. Anexternal reseed can be identical to a self-reseed, exceptthat the seed would be XORed with the mixedgenerator state. For example, if the seed is limited to256 bits in length when using AES-128-CTR, onemay take 256 bits of generator output, XOR in thenew seed material, then rekey and replace the counterblock. If the generator has not previously been seeded,one would simply pad the seed material to 256 bits,then key and set the counter block.

We recommend the seed material be taken from anentropy harvester. It should also be at least 100 bits.We recommend a 256-bit seed for the initial seeding,but subsequent seeds should be no more than 128 bitsin length, as additional entropy will generally be betterapplied if it is saved for other applications.

If a seed is too long, it can be compressed with acryptographic hash function. However, the entropyharvester should deal with this issue, as it should bethe entity responsible for producing whitened datawhere the contents should be as close as random aspossible.

Self-reseeds should occur after each output requestso that forward secrecy can be maintained. That is, if aclient requests any amount of data, the generatorshould provide it, and then reseed. Yarrowrecommended a configurable parameter for the amountof output between self-reseeds. The single outputrequest can be considered atomic, but we see no reasonto ever accept multiple requests between reseeds,because, with a well-selected PRNG, a reseed operationis so cheap that there should never be an excuse not touse it.

For example, if using AES in CTR mode as aPRNG, reseeding would consist of incrementing andencrypting a counter and then performing keyexpansion on the result. As shown by timing datafrom Helger Lipmaa,1 freely available AESimplementations can perform the key expansion inabout 200 cycles on a Pentium III, which is a trivialnumber. Based on Lipmaa’s data, the total cost shouldnever exceed 800 Pentium III cycles.

1 http://www.tcs.hut.fi/~helger/aes/rijndael.html

Determining when to perform an external reseed ismore complicated. The goal of the external reseed is toput the PRNG into a secure state. Once the PRNG islikely to be in a secure state, one needs to determinewhether entropy is better spent increasing assuranceabout the security of the PRNG state or serving clientswanting information theoretic security.

Many systems, such as Yarrow[12] and Fortuna[7],assume that all entropy in a system will be used toseed a PRNG, and try to assume that the PRNG iseventually secure.

Yarrow collects entropy in two pools, one that isused to reseed the generator frequently, in hopes thatany compromise can be recovered from quickly oncethe threat to the system is gone, and another that doesso rarely, saving up entropy over a long period oftime. The idea behind the slower reseed is that theentropy estimators may be broken in some way, and itshould still be possible to recover eventually, if so.

Fortuna uses 32 entropy pools. Samples from anygiven source are fed into the pools in a round robinfashion. A reseed occurs when the first pool is longenough. The first pool is always used to reseed thegenerator. The second pool is also used every othertime. The third pool is additionally used every fourthtime, and so on. The Fortuna solution will eventuallyput the system into a secure state. Fortuna is designednot to have the ability to output entropy separately.All entropy is fed into these pools, which are onlyused to reseed a PRNG. Most general-purpose systemswill find this to be an unacceptable use of entropy.

The goal of the Fortuna design is to avoid entropyestimation. One can simply specify a length at whichthe first pool reseeds, and then the system willeventually make it into a secure state. There is no wayof knowing when that will be without a goodestimator, particularly when some sources may betainted.

One cannot easily estimate whether the PRNG islikely to be secure based on the number of reseeds. Forexample, a single polluted source can feed enoughentropy to cause 100 reseeds before the first goodsource adds any entropy to the first pool. If a pollutedsource causes many reseeds, then it can ensure that thefirst few pools always have small amounts of actualentropy when they reseed, meaning that an attacker canprevent the PRNG from reaching a secure state for along time. Nonetheless, Fortuna will eventually getthere.

Either Fortuna or Yarrow could be used when notall entropy is fed to the PRNG infrastructure.However, we still do not believe Fortuna to be apractical system, because it uses its entropy way toosparingly in order to avoid the need for entropyestimators, and does not adequately protect againstshort-term compromises due to the lack of entropy

estimators. In Section 5, we will discuss best practicesfor entropy estimation.

We prefer the Yarrow approach, albeit with adifferent set of metrics. Yarrow’s conservative reseedshappen linearly. Every time two or more entropysources contribute more than 160 bits of entropytowards a conservative reseed, that reseed occurs.

We believe that entropy metrics involving trust ofmultiple sources are better placed inside the entropyharvester. Additionally, conservative reseeds shouldget more conservative over time.

The approach that we used in EGADS is similar toYarrow in that we take some of the entropy sent to thePRNG and use it for fast reseeds in order to recoverfrom compromise quickly (we discuss this problemmore below). Occasionally (usually when we havedone a fast reseed within a small window of time, say60 seconds), we take entropy fed to the PRNG andfeed it into a slow reseed pool, much like Yarrow.

The major difference is the metric for performingthe catastrophic reseed. The approach is far closer toFortuna, in that reseeds get more conservative on anexponential scale. The reseed pool is used as the seedto update the PRNG, but only after 2n updates of thereseed pool, where n is the number of previous PRNGreseeds that have occurred. Using this approach, onewould rely on entropy estimators in the harvestinginfrastructure to prevent Fortuna-like weaknesses.

Another approach that can be used in tandem forrecovering from environment compromise is to assumethat the administrator will reboot as a concluding stepin recovering from any attack. As a result, whenreseeding after machine startup, one should stretch tofind in any little shred of entropy that may beavailable, including timestamps surrounding portionsof the boot process (even though on many systems,this information is publicly leaked). Additionally, webelieve that one should always take the first 128 bitsof entropy gathered by the randomness infrastructure(using an appropriate output threshold; see below) anduse it to reseed the PRNG as soon as possible.

This solution leave open a window after boot wherethe system pseudo-random number generator ispotentially vulnerable to the attacker who originallycompromised the system. To avoid this problem, onecould have the PRNG block until the initial reseeding.However, this seems impractical for most systems(i.e., we believe it is a design decision that wouldenrage many people who count on their PRNG tonever block). We believe a more realistic solution is toleave this issue as an operational one. If theadministrator is worried about the problem, let herboot in single user mode and ensure the generator iswell seeded before putting the machine back on anetwork.

4.2 Dealing with fork()

A common error in application-level generators isthat PRNG state may be unintentionally duplicated asthe result of an operation such as fork(). If thedeveloper is fastidious when using fork(), thefollowing pseudo-C code solution will suffice in anon-threaded program (it has a race condition inthreaded programs that one would have to ensurecannot occur):if ((pid = fork())) { prng_output_seed();} else { prng_reseed(prng_output_seed());}

When forking, the parent discards the amount ofdata it needs for a reseed. The child will take the exactsame data, and use it to reseed itself. Since the reseedis effectively a one-way transformation, thecompromise of the child will not reveal the state of theparent. For the reverse to be true, the parent shouldalso reseed itself after discarding the necessary data.

This solution works as long as the developer isdiligent, which can be particularly tough in a threadedapplication. However, the PRNG implementer shouldnot expect the developer to be diligent. Instead, thePRNG should detect forks and act appropriately whenthey occur, reseeding before generating any output.

Reseeding in such a way that the parent and childend up with different states where the output does notrisk being correlated easy is non-obvious.

Previously, [11] stated that using a database-styletwo-phase commit was the only way to solve thisproblem. Here is a much simpler solution, expressedin the following pseudo-C code:prng_output(numbytes) { my_pid = getpid(); time = time(); val = concatenate(my_pid, time); if (saved_pid != my_pid) { seed = MAC(seed, ctr, val); saved_pid = my_pid; } increment_counter(); /* Assume that the counter is properly */ /* incremented after any blk cipher op . */ ret = ctr_keystrm(seed, ctr, numbytes); prng_reseed(); return ret;}

In the above code, we assume that we’re using ablock cipher in counter mode. If not, ctr can beeffectively ignored. We also assume a MAC that takesthree parameters, a key, a nonce and data to MAC. Ifthere is no nonce, then concatenate the secondparameter to the plaintext (or ignore it totally if notusing a block cipher in counter mode).

By MACing the current PID and mixing in thetime, we are effectively randomizing the seed in a way

that is unique to that child (the time is mixed inbecause a child could eventually fork off a secondprocess with the same pid as an old process). Even ifwe fork multiple children at the same time, they willeach end up with a different seed.

Once the parent finally reseeds (either by someonerequesting a PRNG output, by a timed reseed or by amessage from the child asking the parent to reseed),the child PRNGs cannot be compromised as a result ofa compromise in the parent. To decrease the riskinvolved with any such window of vulnerability, thechild can try to gather its own entropy and reseed itselfusing that entropy.

4.3 The Initial Seeding Problem

One of the biggest practical problems for operatingsystem vendors is how to bootstrap a system-widePRNG. Generally, several processes that run early on amachine need strong pseudo-random numbers. Once asystem-wide generator has reached a secure state asingle time, the system can maintain a seed file acrossreboots (where a seed file would stash enough data toreseed the PRNG using an algorithm such as the onediscussed earlier). As long as the seed file is properlyprotected through operational means, and assuming nofundamental flaws with the randomness infrastructure,then this approach is sound.

However, it still leaves the question of obtainingentropy the first time a machine boots. Developers ofrandom devices for common operating systems are yetto address this problem. Instead, they generally ignorethe issue, allowing the PRNG to output withoutsufficient entropy.

For desktop or server-based OSes, collectingentropy during the install process addresses thisproblem well, since most installs are interactive. Werecommend explicitly prompting the user to introduceentropy into the system, such as by shaking a mouseor pounding on a keyboard.

Getting that initial entropy can be a lot moredifficult in embedded devices. Under NDA, we haveheard horror stories of such devices rolling off the lineswith every device producing identical randomnumbers, or highly correlated numbers. In this space,one generally has far less opportunity to collectentropy and is greatly concerned about manufacturingcost.

Often, devices need to be individualized in order tohold a unique secret key. In such a case, it should bereasonable to generate a secure seed on another devicewhere entropy is readily available, and then put it intodevices at manufacture time (the individualized keyitself should be high entropy and can be used as aPRNG seed itself). However, sometimesindividualizing a device at manufacture time is tooexpensive.

For some devices, it may be possible to use asimilar trick when the device is first deployed. Forexample, if a device has external buttons, the usercould be asked to push the buttons randomly until thedevice beeps as a part of setup.

Often, such a trick will not be feasible. In such acase, the device must necessarily try to do someentropy collection on its own. Hardware solutionsexist, but increase costs.

If a pure software solution is an absoluterequirement, one is stuck trying to find the bestavailable entropy. Often, this is going to be whateverclock is available. In such a device, it may bereasonable to assume that mixing in tiny bits ofentropy as it becomes available is better than collectingentropy until a threshold is reached, and then reseedingall at once (which requires more overhead). Ongoingcompromise of the physical device (i.e., an iterativeattack on the system) is often not in the threat model,in which case, both approaches will have the same endeffect. Executing on this assumption ensures that,when a device finally does collect enough entropy tobe in a secure state, it will be in a secure state at itsearliest opportunity. Additionally, it helps protect theseed used at time of manufacture.

5. Entropy Harvester Design

Design of a secure PRNG is a relativelystraightforward matter under the assumption thatoccasionally there are external seeds available, where anentropy harvester is responsible for assurance as to theamount of entropy in those seeds.

All of the real challenges lie in building a goodentropy harvester. Such an infrastructure needs togather, compress and store data from its surroundingenvironment that may contain entropy, estimate howmuch entropy it is holding, whiten the entropy toremove any lingering patterns and output high-entropydata using metrics based on its estimates. All of thesethings are a challenge in their own right, but it is alsoimportant to do each of these things quickly.

One important design principle that should beapplied to entropy harvesting infrastructures is defensein depth. In particular, if entropy harvester outputs turnout not to be secure in the information theoretic sense,then the system should be able to fall back tocomputational security if at all possible. Datawhitening is using cryptography to remove statisticalcorrelations between bits, effectively spreading entropyevenly throughout data. This is commonly done witha cryptographic hash function, but can be done with ablock cipher. In fact, it should be a requirement of anypublic random number interface, though is notnecessary when keying a cryptographic PRNG). Notethat the output of the hash function must be truncatedto a size that corresponds with the amount of entropybelieved to be in the input.

5.1 Accumulating and yielding entropy

In many systems, entropy samples may beprocessed frequently, such as when there is a flurry ofactivity on the machine. The developers of OS-levelPRNGs have strived to minimize the cost ofprocessing entropy samples. Generally, such generatorsare only willing to keep fixed-size internal buffers.

Yarrow and Fortuna both recommend keeping oneor more cryptographic hash contexts. Most operatingsystems have rejected this approach because theybelieve it is too slow. We have done timing tests,comparing the LFSR used to collect entropy inLinux’s implementation of /dev/random to MD5,SHA1 and SHA256 contexts being used to process thesame samples. We also considered hash127[3], a non-cryptographic hash function we will discuss below.

We measured the average time to process a 16-bytesample, over 10,000 samples, using the fastestimplementations of the algorithms we could find.Testing was done on a Pentium III. The results areshown in Table 1.

Algorithm Speed (cycles per byte)SHA256 116 cpbSHA1 24.5 cpbMD5 18.4 cpbLinux LFSR 13.3 cpbHash127 4.0 cpbTable 1: P3 speed for entropy sample processing

Note that we did not consider initialization costsfor any of the above algorithms. SHA256, SHA1 andMD5 are significantly more expensive at startup thanthe other two algorithms (by hundreds of cycles).However, the Linux /dev/random implementation runsa cryptographic hash function in its entirety over theLFSR every time entropy is output. What OSdevelopers are more concerned with is minimizing theoverhead when entropy is being gathered, not when itis being requested.

Clearly, the SHA256 implementation (therecommended cryptographic hash function to use withFortuna) does not look like a good choice for speed-critical environments.

While SHA1 and MD5 are slower than the currentLinux solution, they do have the advantage that theyare believed to be functions that are, for the most part,entropy preserving. That is, if one puts data of anarbitrary length containing 128 bits of entropy into aSHA1 context, the 160-bit output should have nearly128 bits of entropy. If that property does not hold,then the cryptographic hash function is not doing itsjob. Currently, SHA1 is higher assurance than MD5,due to collisions found in the MD5 compressionfunction. However, both have been better analyzed fortheir ability to preserve entropy than has the non-cryptographic LFSR used by Linux.

A cryptographic hash function is certainly notnecessary for entropy accumulation. However, anygood function must be mostly entropy preserving,even if the attacker controls part of the input. Anotherpossibility not considered in previous systems is touse a good universal hash function[18], which wouldallow one to bound the probability of significantentropy loss to something miniscule, under theassumption that the input contains enough entropy.

The hash function we examined, hash127 consistsof multiplications in the Galois Field of 2127-1, whichare trivial to implement. The reference implementationis incredibly fast due to several performance tricks, themost effective involving precomputation. The overheadof the precomputation should be acceptable for anydesktop OS (particularly since the amount ofprecomputation performed can be reduced arbitrarily, ifnecessary, trading off a bit of speed). We estimate thata well-optimized version that uses no precomputationwould run, at worst, 100% slower than the hash127reference implementation, which is still significantlyfaster than the Linux solution, where there is noconcrete analysis on entropy loss during compression.See [14] for a more detailed discussion of softwareperformance for this class of hash functions.

There are some considerations in using a universalhash function in this role. First, hash127 and its ilkare keyed hash functions, meaning that a key(traditionally secret) is used as part of the computation.The more entropy in the key, the better (though one isprotected if the inputs contain the estimated amount ofentropy). If one has a cryptographic PRNG that wasseeded with some amount of entropy, then the hashfunction should be keyed with output from that PRNG(and periodically rekeyin as the PRNG reseeds is a fineidea). Otherwise, the function should be keyed withany available entropy (e.g., the system clock). Theoutput of the hash function should be used to key acryptographic PRNG that will be used in keying anyfuture hash contexts.

Second, as is the case with the Linux LFSR, theoutput of a universal hash function should never beexposed directly to an untrusted user. To prevent anysort of correlation attack, the output must be passedthrough a pseudo-random (whitening) function. Post-processing hash127 outputs with AES is quicker thanusing either SHA1 or MD5 due to the fixed-costoverhead of those two algorithms.

If using AES in counter mode for a PRNG, onecould reuse the PRNG’s keyed AES context. However,to prevent theoretical reductions in strength, oneshould ensure that inputs from the hash function andcounter blocks cannot collide.

When using hash127, this is easily done. That hashfunction produces a 128-bit output, but the 97th bit isalways set to 1 (hash127’s output can never hold morethan 127 bits of entropy). One simply must fix the

corresponding bit of the PRNG counter block to 0.This must even be done after replacing the counterblock with a random value (such as when reseeding thePRNG).

Note that you can also use cryptographic streamciphers to postprocess universal hash functions, whichis useful when using such a construct as the systemPRNG. In such a situation, the postprocessing is doneby taking a value of sufficient size from the generator,and then using it in a way dictated by the nature of thehash function. For example, when using hash127, thevalue would be added to the hash result modulo 2127-1.

After applying cryptographic post-processing to anysort of entropy “pool” (accumulator), one must truncatethe result to the number of bits of entropy that wasbelieved to be in the pool (securely discarding thetruncated portion). We recommend slicing off anadditional bit to account for the loss that one shouldexpect from the cryptographic post-processing.

For example, one might use hash127 to collect anestimated 121 bits of entropy at a time (where theestimate is believed to be sufficiently conservativeagainst any threat in the threat model), AES-encryptthe result, then ignore one byte of the AES output.

5.2 Entropy estimation

Perhaps the biggest shortcoming in most practicalrandom number generation systems is the lack ofquality entropy estimation. For example, EGD, apopular user-space daemon for harvesting entropyestimates .1 bits of entropy per byte of output anytime it calls the ps command. That means a 6,000byte ps output will be estimated to have 600 bits ofentropy. We have found through empirical testing thatthis is a gross overestimate. Even if the threat model isthat an attacker got to see the ps output a single time,and then must guess any changes based on externalbehavior, we’ve seen many situations where the anoutput of that size would contain no more than twobits of entropy. Particularly, machines withoutinteractive users often have a fairly fixed set ofprocesses, and the information about those processesthat the command displays tends to change slowly.The only thing that changes frequently is CPU timeelapsed, which tends to grow at an easily predictablerate.

Of course, from the point of view of a remoteattacker who must guess the state of the entire processtable, there may be a bit more entropy. It’s difficult tosay how much, because an attacker might be able tomake incredibly educated guesses about the state of asystem, particularly considering that the nmap tool canoften give the system uptime of a remote host(depending on the operating system and the firewallconfiguration of the host being targeted). In short, ifwe were only concerned about collecting data thatcontains entropy with respect to remote attackers, we

might be inclined to assume some amount of entropyper process (probably a fraction of a bit). Certainly, wewould not expect to gain much additional entropy astime goes on (and, any additional entropy is likely tocome primarily from new processed being added andpossibly old processes going away—entropy is not aslikely to appear in the output simply from oldprocesses continuing to exist).

When considering threat models where local usersare a threat, one must consider the risk of an attackermeasuring the same data as the process that doesentropy gathering. Even if the entropy gathering isdone in-kernel, the end user can often makemeasurements that can help reveal data that is generallyexpected to be private to the kernel. For example, anOS that measures timestamps associated withkeystrokes may be able to hide key press informationbetween users, but the same user should be able to addher own keystrokes, which the operating system willgenerally assume is entropy. Unfortunately, theattacker can generally collect timestamps in user spaceassociated with those keystrokes that are highlycorrelated with the timestamps of the kernel.

One general principle for entropy gathering that iswidely practices is mixing a timestamp into theentropy accumulator when adding a sample. Thisseems like it would be an effective measure, especiallyconsidering the high-resolution timers available onmodern architectures, which tend to be tied to theclock speed of the processor. However, the end usergenerally does not see anywhere near the maximumresolution from a timer, because most events will beregulated by the bus clock, which is generally muchslower than the processor clock. Making mattersworse, peripheral clocks tend to be even slower still.For example, keyboards and mice generally use a1KHz clock, a far cry from the 3 GHz clock availableon some x86 processors. As a result, when estimatingentropy from a source, we recommend assuming thatthe associated timestamp has no better granularity thanthat of the slowest clock to which the entropy samplemay be tied.

A related issue is a “back-to-back” attack where,depending on the details of entropy events, an attackermay be able to force events to happen at particularmoments. For example, back-to-back short networkpackets can keep a machine from processing keyboardor mouse interrupts until the time when it is doneservicing a packet, which a remote attacker can measureby observing the change in response in the packets hesends. In this particular situation, one can thwart theproblem by assuming there is no entropy when thedelta between two events is close to the interruptlatency time. This works because both network packetsand keystrokes cause interrupts.2

2 Some OSes can mitigate this problem if supported by the

network card.

One significant problem is a lack of methodologyfor deriving reasonable estimates. The most practicalmethodology to date has been Yarrow’s approach,which consists of applying three estimators to eachinput sample, and choosing the lowest estimate. Thefirst is a programmer driven estimate. Themethodology with which the programmer shouldderive such estimates is unspecified. The secondestimator is a statistical estimator that “is gearedtowards detecting abnormal situations in which thesamples have very low entropy”. Again, themethodology for deriving such estimators isunspecified, and this estimator is not clearlydifferentiated from the first. The third estimator ismultiplying the input length of a sample by a fixedsystem-wide value. The recommended value is 0.5. Nojustification for this value is given.

Information theory does provide ways to measureentropy, but they are not practical, because one canonly model how much entropy is in data if one has acomplete understanding of how the data is producedand all possible channels an attacker may use tomeasure information about the data. Considering thatthere are a broad range of possible threat models, andconsidering that machines behave deterministically yetare still incredibly complex in practice, one shouldexpect data to tend to be predictable (the only timeswhere significant new entropy can really added be to asystem are when the machine receives external input),yet it is incredibly difficult to figure out just howpredictable.

The most useful way to think about the maximumentropy that data can have is by looking at how muchthe ordered samples could be compressed (this value isclearly an upper bound on the amount of entropy in apiece of data).

[11] discusses how to use a general-purposecompression function for getting an upper bound onthe amount of entropy in the data. Essentially, onecompresses the first sample padded out to the internalblock length of the compression function. Then, onecompresses subsequent samples, and measures theupper bound on the entropy in the second sample bylooking at the compressed size of that sample. Thefirst sample is never credited for any entropy (at least,not through compression-based techniques).

The problem with this approach is that “generalpurpose” compression functions are not optimized forcompressing specific types of data. Hand-tailoredcompression functions can generally do better.

We recommend one builds hand-tailoredcompression functions, and then attempting furthercompression on the output of the hand-tailored outputby using a conventional compression algorithm. If thecompression output does not usually grow, then thehand-tailored algorithm is clearly poor, but thecombined algorithm is better.

When combining compression algorithms, theupper bound on entropy is the minimum compressedsize of the sample at any point in the process. Inpractice, one should assume that smarter compressioncould do a better job, even with a hand-tailoredcompression function.

Our recommendation is that one should try to findas compact a representation as possible for expressingthe differences between any two successive samples.This type of compression function does not take intoaccount long-term trends on data. However, if onefinds an optimal function of this type, it is rare thatone will see better than a 50% improvement incompression rates by using long-term information.Also, when longer-term patterns would producemassive improvements in compression, it is likely tobe obvious to the person writing the compressionfunction. When building such a compression function,one should conservatively assume that data thatchanges predictably (such as CPU time in the outputof ps) is constant. Additionally, one should ignore anydata that an attacker might be able to measure(assuming a particular threat model).

With any compression function that one uses thatseems to give good results, we recommendconservatively dividing the entropy estimates derivedfrom such a function by four. This helps hedge againstthe existence of better compression algorithms as wellas the presence of unanticipated channels of attack.

The next question that arises is whether entropymeasurement should be done “on the fly”, or whether astatic estimator should be used.

While dynamic estimators certainly have moreoverhead, there is a big danger in a static estimator, inthat one may end up with entropy samples that haveless entropy than the estimate. For example, no matterwhat estimate one were to derive for keyboard entropy,it would not be low enough for the case when a key isbeing held down (assuming a highly conservativethreat model).

FIPS-style statistical tests (see Section 5.4) providea solution, but such tests are not satisfying becausethey are easily fooled. One option is to derive a set ofconditions where the estimate used is believed to betoo liberal, and then detect those conditions,estimating no entropy for them. For example, onemight fail to credit entropy any time the same key ispressed twice in a row, or any time an interrupt-basedevent occurs back-to-back with another such event.

Another thing we recommend is to set a maximumentropy estimate per sample for any given source. Werecommend examining a source in a variety ofoperational environments and calculating a mediancompression rate, then basing a maximum off thatvalue (for example, divide by four).

These guidelines should lead to per-source entropyestimators that are reasonable if a high-quality

compression function is found and if the channels overwhich an attacker might get data are well understood.We would recommend this approach over the moreambiguous guidelines required by Yarrow.

A per-source, per-sample maximum that is carefullycalculated seems more appropriate than a Yarrow-likeglobal factor based on the length of the input.Otherwise, the spirit of the Yarrow estimators ispresent in the above recommendations.

5.3 Metrics for yielding entropy

Even if all entropy estimators in an entropyharvesting system are believed to be adequatelypessimistic under a particular threat model, a goodconservative approach would assume that at least oneentropy source has an unanticipated side channel. Thiswas first done in Yarrow, where a catastrophic reseedoccurred when the appropriate entropy pool had builtup at least 160 bits of entropy from k different sources,where k was expected to be two in practice.

Such an approach was only used for catastrophicreseeds. We feel that a similar approach should be usedfor any entropy harvester output, even if not beingused for catastrophic reseed, since the goal of anentropy harvester is to provide information theoreticsecurity.

However, the Yarrow metric is somewhat wastefulin this capacity, in that it eats at least 320 bits ofentropy to produce a single 160-bit output, and willoften eat quite a bit more, particularly when there is asingle, fast source (the metric is more appropriate forthe context in which it is used).

We believe more liberal metrics are appropriate,particularly because previous designs favored byimplementers, such as the Linux design, are widelybelieved to do a good enough job in practice. We haveheard no reports of someone breaking the Linuxsystem by polluting an entropy source (either/dev/random or /dev/urandom). Considering thatsuch a design seems to be good enough, if entropyoutputs are a requirement of a system, then a Fortuna-style design seems like overkill (particularly when afast, polluted source can stall a secure PRNG seed forquite a long time).

There are plenty of more liberal metrics that can bemore effective. One example would be, for an n-bitaccumulator, to mark as ready for output when itcontains an estimated n bits of entropy, disregardingthe contributions of the fastest k entropy sources(where k will generally be 1 in most practicalsystems).

In such a scenario, any single source would stopadding entropy to a particular accumulator aftercontributing n bits. The source could then move on toanother accumulator (when all accumulators are full,

one should be emptied into the PRNG, as discussedabove).

A more liberal metric still is possible if one iswilling to fall back on the computational securityprovided by the whitening process. For example, let usassume that n=128 bits. A metric could be that, eitherthe accumulator has 128 bits of entropy ignoring themost prolific source, or that at least two sources havecontributed 64 bits of entropy. In this way, the systemshould approximate information theoretic security,unless one of the sources is tainted, in which case the64 bits of entropy should still provide reasonableprotection in practice.

Other metrics can be designed that are tailored tothe needs of a particular environment. One mightassign trust rankings to each source, and output whenthe entropy buffer achieves a particular level of trust.That way, a fast, trusted source (such as a hardwarepseudo-random number generator) can still be used togenerate entropy outputs quickly. Or, one couldsimply grant an exception to trusted sources.

Another issue in entropy estimation that has neverbeen addressed previously is the possibility of partiallytainted sources on multi-user machines. For example,on a multi-user system, measuring entropy forkeyboard interrupts can be partially tainted if there is asingle malicious user. If multiple sources can betainted in this way at the same time, the above metricscan easily fail.

One could solve this problem by keeping track ofeach entropy source on a per-user basis, treating each asa logical source. However, that technique has theproblem in practice that it requires dynamic allocationof entropy estimation information, which mayconceivably pose a problem.

5.4 Other Considerations

Much like a PRNG, an entropy infrastructureshould be able to provide forward secrecy in the case ofenvironmental compromise. Such a goal is easilyachieved by zeroing out entropy accumulators securelyafter they are used for output. This can also help ensurethat outputs derived from the same accumulator aresufficiently independent that information-theoreticsecurity levels can still be approximated, which isparticularly important when using an accumulatorwithout theoretically proven bounds for entropy loss(such as the construct used with Linux’ /dev/random).

Besides the Linux solution not having provableinformation theoretic security, its methodology ofhashing its entropy pool to get (hopefully) entropicoutput, stirring the pool and then reducing the entropyestimate by the number of bytes output is a waste fromthe perspective of cryptographic security, since thereare constructs where information leakage is bothminiscule and well bounded.

Recovering from an environmental attack issomewhat more problematic. If computational securityis an acceptable fallback for outputs, then thewhitening process can involve PRNG output, so thatonce the PRNG returns to a computationally securestate, entropy harvester outputs will do so as well. Forexample, one might take a 128-bit key from the PRNGand then encrypt a 128-bit accumulator using that keybefore outputting.

If computational security is not a desirable fallback,then we recommend assuming that a machine will berebooted after recovering from a compromise, and thenbeing sure not to save the state of entropyaccumulators across a reboot (instead, we would mixthe accumulators into the PRNG state before shuttingdown).

FIPS 140-1 tests[21] are worthwhile to perform inan entropy harvester, despite the fact that there may below-entropy output streams they will not fail. Suchtests should be applied to the output of each source, inthe hopes of detecting when the source has acatastrophic failure. If they do not pose significantoverhead, we recommend one run them continuouslyon compressed entropy streams before they are placedin an accumulation buffer (at that point, the FIPS testsare unlikely to be overly useful). Otherwise, oneshould run them whenever cycles to do so areavailable.

As with PRNGs, the memory used to hold all thestate of an entropy harvester should be protected usingthe best available means.

Timing and power-based side channels can beextremely difficult to avoid, considering the widedisparity in entropy sources (in the rest of theinfrastructure, it should be fairly simple to avoidconditional branches and loops of indefinite size).Such problems argue for using a general-purposecompression function that may be less accurate, butalso less susceptible to side channel attacks. This areais in need of additional research.

For user-space entropy accumulators, the PRNGfork() issue also applies to entropy accumulators.Here, the state problem is easy to solve, as the childshould simply zero out all of its entropy buffers.However, one should note that there is significant riskof parent and child measuring redundant entropy, inwhich case estimates may be significantly off. Thisargues for system-wide entropy accumulators.In the situation where a user-space collector is believedto be higher assurance than an existing kernel-basedgenerator, then the user-space generator should be sureto estimate under the assumption that the kernelgenerator is leaking significant amounts of informationas to the date that the user-space collector is gathering.

6. Related Work

Traditionally, design of randomness architectures

focused on the PRNG, and not the collection andmanagement of entropy. Many systems exist where thePRNG itself is cryptographically strong (or is believedto be), where the responsibility for providing a secureseed is left to the client of the PRNG, including theANSI X9.17 PRNG[20] and the Blum-Blum-Shubgenerator[4], which is based on public keycryptography, but is no more secure and is far slowerin practice than PRNGs based on a block cipher inCTR mode (both constructs are provably secure togood bounds with reasonable assumptions). Even [9],which recognizes the fundamental difference betweeninformation theoretic security and computationalsecurity, assumes that clients will only ever wantcomputational security. Even so, it misses PRNGrequirements we believe to be important, such asforward secrecy. Yarrow[12] and Fortuna[7] are theonly published PRNGs to recognize forward secrecy asa requirement.

[6] famously discusses ways to harvest entropy, andexplicitly talks about stretching random numbers witha pseudo-random number generator when “true”random numbers cannot be obtained quickly enough.[11] discusses specific considerations in polling forentropy and discusses using compression for entropyestimation, but totally ignores conservative Yarrow-style metrics. [17] analyzes common sources forentropy in software, and provides lower-bound metricsthat are probably suitably conservative for general-purpose operating systems.

The original Linux infrastructure for /dev/randomand /dev/urandom was the first interface to separatethe notion of high-assurance randomness (i.e., dataobtained from /dev/random) and random data thatmay not be secure (but generally is in practice; the/dev/random interface). The original system workedby pooling entropy in a LFSR, and estimating thenumber of bits in that LFSR. When output wasrequested, the pool was “stirred” (the LFSR is clocked)and then hashed with MD5, which was used for up to128 bits of output, then 128 was subtracted from theentropy count of the pool. If output was requested overthe /dev/random interface, yet not enough entropywas estimated to be in the pool, then output blockeduntil that condition was true.

This general system persists to this day (though ithas evolved a bit, even incorporating a Yarrow-inspiredslow pool), and has been widely copied, with minormodifications. Unfortunately, while it might seem togive information theoretic security due to limitingoutput to the amount of entropy believed to be in thepool, it does not do so, because subsequent outputs are

not generated using independent entropy. The samepiece of data is rotated and rehashed each time, untilthe entropy estimate reaches zero. As a result, if anattacker could invert the hash function, then she couldcalculate the next output with high probability byrotating the pool and rehashing. The only time thiswould fail is if new entropy gets added to the pool inthe meantime.

One consequence of this design is that the/dev/random device is not suitable for producing keyslarger than the output size of the hash function usedinternally, as the only case where such a key couldpossibly have more than 160 bits of entropy would bewhen enough new entropy got added to the pool in-between blocks of output.

Because /dev/random on Linux does not provideinformation theoretic security, we see no reason to useit compared to /dev/urandom, as long as one canensure that the entropy pool has ever received aminimum amount of entropy. The entropy lossthrough /dev/urandom is miniscule, and thereforethere is no good reason to ever block for more entropyif information-theoretic levels of security cannot beensured.

In the original Linux random number infrastructure,malicious applications could starve /dev/random bycontinually reading from /dev/urandom. Of course,malicious applications could also try to readcontinually from /dev/random. A partial solution tothat problem is to provide data on the /dev/randominterface in a round-robin manner in fixed-sizeincrements. This way, legitimate users will eventuallyget served.

There are other problems with this infrastructure.For example /dev/random output bits are notnecessarily likely to be secure in the information-theoretic sense, partially due to the lack of proofsattached to the LFSR and partially due to the fact thatthe LFSR is not zeroed out after each output. Also,the way /dev/random was designed made it difficult toanalyze. The LFSR appears to be a reasonableconstruct for accumulating entropy, but it may not be.

Yarrow is criticized for being too complex andunder-specified, particularly with regard to its entropyhandling. Several implementations intended fordeployment have been so slow to provide an initialseed that they were shelved.

Fortuna is even more reticent to use its entropyeffectively, and completely foregoes entropyestimation, which we believe is theoreticallyappealing, but a drawback in practice. Neither Fortunanor Yarrow allow for an interface to data with

information-theoretic security levels.The ideas presented in this paper are implemented

in the EGADS software package. This work extends aprevious, unpublished algorithm called Tiny,developed in conjunction with John Kelsey.

7. References[1] B. Arkin, F. Hill et al. “How we learned to cheat in online

poker”, developer.com, Sep. 1999.[2] M. Bellare, A. Desai, E. Jokipii and P. Rogaway, “A concrete

security treatment of symmetric encryption: analysis of theDES modes of operation”, In Proc. 38th Annual Symposium onFoundations of Computer Science, 1997.

[3] D. Bernstein, “Floating-point arithmetic and messageauthentication”, at http://cr.yp.to/papers.html#hash127, 2000.

[4 ] L. Blum, M. Blum, and M. Shub. “A simple unpredictablepseudo-random number generator”. In SIAM Journal onComputing , 15, May 1986.

[5 ] A. Desai, A. Hevia and Y. Yin, “A practice-orientedtreatment of pseudorandom number generators”, In Proc.Eurocrypt 2002, Springer-Verlag, 2002.

[ 6 ] D. Eastlake, S. Crocker and J. Schiller, “Randomnessrecommendations for security”, RFC 1750, InternetEngineering Task Force, Dec. 1994.

[ 7 ] N. Ferguson and B. Schneier, Practical Cryptography.Indianapolis: John Wiley & Sons, 2003.

[8] S. Fluhrer, I. Mantin and A. Shamir, “Weaknesses in the keyscheduling algorithm of RC4”, in Proc. Eighth AnnualWorkshop on Selected Areas in Cryptography, Aug. 2001.

[9] S. Fluhrer and D. McGrew, “Statistical analysis of the allegedRC4 stream cipher”, in Proc. Fast Software EncryptionSeventh International Workshop, Springer-Verlag, Mar. 2000.

[10] I. Goldberg and D. Wagner, “Randomness and the Netscapebrowser”, Dr. Dobbs’ Journal, Jan. 1996.

[11] P. Gutmann, “The design and verification of a cryptographicsecurity architecture,” Ph.D. dissertation, Dept. Comp. Sci.,Univ. of Auckland, Aug. 2000.

[12] J. Kelsey, B. Schneier and N. Ferguson, “Yarrow-160: Noteson the design and analysis of the Yarrow cryptographicpseudorandom number generator”, in Proc. Sixth AnnualWorkshop on Selected Areas in Cryptography, SpringerVerlag, Aug. 1999.

[13] J. Kelsey, B. Schneier, et al., “Cryptanalytic attacks onpseudorandom number generators”, in Proc. Fast SoftwareEncryption, Fifth International Workshop, Mar. 1998.

[14] T. Kohno, J. Viega and D. Whiting, “The CWC AuthenticatedEncryption (Associated Data) Mode”, ePrint Archives, 2003.

[15] B. Moeller, “OpenSSL security advisory: PRNG weakness inversion up to 0.9.6a”, posting to bugtraq, Jul. 2001, message-ID 20010710130317.A1949@openssl.org.

[16] W. van Eck, “Electromagnetic radiation from video displayunits: an eavesdropping risk?” in Computers & Security, 1985Vol. 4.

[17] J. Viega and M. Messier, The Secure Programming Cookbookfor C and C++, Sebestpool: O’Reilly and Associates, 2003.

[18] M. Wegmen and L. Carter, “New hash functions and their usein authentication and set equality”, Journal of Computer andSystem Sciences, 22, 1981.

[19] J. Ziv and A. Lempel, “A universal algorithm for sequentialdata-compression”, IEEE Transactions on InformationTheory, 23(3), May 1977.

[20] “American National Standard for financial institution keymanagement (wholesale)”, American Bankers Association,1985.

[21] “Security requirements for cryptographic modules”, NIST,FIPS pub. 140-1, Jan. 1994.

[22] “Security requirements for cryptographic modules”, NIST, FIPS pub. 140-2, Dec. 2002.