Part 1: An introduction
Part 2: The ROM formalized, a scheme and a proof sketch
Part 3: How we abuse the ROM to make our security proofs work
Part 4: Some more examples of where the ROM is used
About eight years ago I set out to write a very informal piece on a specific cryptanalytic model proficiency called the “ random oracle model ”. This was way back in the good old days of 2011, which was a more innocent and gentle era of cryptanalysis. Back then cipher foresaw that all of our standard cryptanalysis would turn out to be riddled with bugs ; you didn ’ t have to be reminded that “ crypto means cryptography “. People even used Bitcoin to actually buy things .
That first random oracle post somehow sprouted three sequels, each more farcical than the last. I guess at some compass point I got embarrassed about the whole thing — it ’ mho reasonably bum, to be honest — so I kind of abandoned it bare. And that ’ s been a major generator of sorrow for me, since I had always planned a fifth, and final post, to cap the whole messy thing off. This was going to be the best of the crowd : the one I wanted to write all along.
To give you some context, let me briefly remind you what the random oracle model is, and why you should care about it. ( Though you ’ vitamin d do good just to read the series. )
The random oracle mannequin is a bonkers way to model ( argue about ) hash functions, in which we assume that these are actually random functions and use this assumption to prove things about cryptanalytic protocols that are way more unmanageable to prove without such a model. Just about all the “ demonstrable ” cryptography we use today depends on this model, which means that many of these proofs would be called into interrogate if it was “ false ” .
And to tease the lie of this post, I ’ ll quote the final examination paragraph of Part 4, which ends with this :
You see, we always knew that this ride wouldn ’ t end forever, we merely thought we had more time. unfortunately, the end is near. Just like the complex number city that Leonardo de Caprio explored during the boring share of Inception, the random prophet model is collapsing under the weight of its own contradictions .
As promised, this post will be about that break down, and what it means for cryptographers, security professionals, and the rest of us .
first base, to make this post a bite more collected I ’ d like to recap a few of the basics that I covered earlier in the series. You can feel free to skip this contribution if you ’ ve good come from there .
In which we (very quickly) remind the reader what hash functions are, what random functions are, and what a random oracle is.
As discussed in the early sections of this series, hash functions ( or hashing algorithm ) are a standard crude that ’ randomness used in many areas of calculator science. They take in some stimulation, typically a string of variable duration, and repeatably output a short and fixed-length “ digest ”. We much denote these functions as follows :
cryptanalytic hashing takes this basic template and tacks on some important security properties that we need for cryptanalytic applications. Most famously these provide well-known properties like collision resistance, which is needed for applications like digital signatures. But hash functions turn up all over cryptography, sometimes in unexpected places — ranging from encoding to zero-knowledge protocols — and sometimes these systems demand stronger properties. Those can sometimes be challenging to put into formal terms : for exercise, many protocols require a hash function to produce output that is extremely “ random-looking ”. *
In the earliest days of demonstrably security, cryptographers realized that the ideal hash serve would behave like a “ random function ”. This term refers to a function that is uniformly sampled from the set of all possible functions that have the appropriate input/output specification ( domain and compass ). In a perfect populace your protocol could, for example, randomly sample one of huge number of possible functions at apparatus, bake the identifier of that function into a populace cardinal or something, and then you ’ d be adept to go .
unfortunately it ’ s not possible to actually use random functions ( of reasonably-sized domain and range ) in substantial protocols. That ’ second because sampling and evaluating those functions is far excessively much work .
For case, the count of distinct functions that consume a piddly 256-bit stimulation and produce a 256-bit digest is a mind-boggling ( 2^ { 256 } ) ^ { 2^ { 256 } }. Simply “ writing down ” the identity of the function you chose would require memory that ’ s exponential in the function ’ second input signal length. Since we want our cryptanalytic algorithm to be effective ( entail, slightly more formally, they run in polynomial time ), using random functions is pretty much impracticable .
So we don ’ metric ton use random functions to implement our hash. Out in “ the real number worldly concern ” we use weird functions developed by Belgians or the National Security Agency, things like like SHA256 and SHA3 and Blake2. These functions come with blazingly flying and bantam algorithm for computing them, most of which occupy few twelve lines of code or less. They surely aren ’ thymine random, but as best we can tell, the output signal looks reasonably jumbled up .
still, protocol designers continue to long for the security that using truly random affair could give their protocol. What if, they asked, we tried to split the remainder. How about we model our hashish functions using random functions — precisely for the sake of writing our security proof — and then when we go to implement ( or “ instantiate ” ) our protocols, we ’ ll go use effective hash functions like SHA3 ? naturally these proofs wouldn ’ deoxythymidine monophosphate precisely apply to the real number protocol as instantiate, but they might silent be reasonably good .
A proof that uses this paradigm is called a proof in the random oracle exemplary, or ROM. For the full mechanics of how the ROM works you ’ ll have to go back and read the series from the begin. What you do need to know veracious nowadays is that proof in this model must somehow hack around the fact that evaluating a random function takes exponential prison term. The way the model handles this is simple : rather of giving the individual protocol participants a description of the hash serve itself — it ’ second direction excessively big for anyone to deal with — they give each party ( including the adversary ) access to a charming “ oracle ” that can evaluate the random function H efficiently, and hand them back a result .
This means that any clock one of the parties wants to compute the routine 
Since all parties in the system “ talk ” to the same oracle, they all get the lapp hashish result when they ask it to hash a given message. This is a pretty good standin for what happens with a real number hash affair. The use of an outside prophet allows us to “ bury ” the costs of evaluating a random function, so that cipher else needs to spend exponential clock time evaluating one. Inside this artificial model, we get ideal hashish functions with none of the pain .
This seems pretty ridiculous already…
It absolutely is !
however — I think there are several identical crucial things you should know about the random oracle model before you write it off as obviously asinine :
1. Of course everyone knows random oracle proofs aren’t “real”. Most conscientious protocol designers will admit that proving something batten in the random oracle model does not actually mean it ’ ll be secure “ in the real populace ”. In other words, the fact that random prophet model proof are kind of bogus is not some deeply secret I ’ thousand letting you in on .
2. And anyway: ROM proofs are generally considered a useful heuristic. For those who aren ’ deoxythymidine monophosphate familiar with the term, “ heuristic ” is a news that grownups use when they ’ re about to secure your life ’ mho savings using cryptography they can ’ thyroxine prove anything about .
I ’ m joke ! In fact, random prophet proof are silent quite valuable. This is chiefly because they often help us detect bugs in our schemes. That is, while a random prophet proof doesn ’ metric ton imply security in the real universe, the inability to write one is normally a bolshevik iris for protocols. furthermore, the universe of a ROM validation is hopefully an indicator that the “ guts ” of the protocol are very well, and that any real-world issues that crop up will have something to do with the hash routine .
3. ROM-validated schemes have a pretty decent track record in practice. If ROM proof were kicking out absurdly break schemes every other day, we would credibly have abandoned this technique. Yet we use cryptanalysis that ’ sulfur test ( only ) in the ROM just about always day — and largely it works very well .
This is not to say that no ROM-proven scheme has ever been broken, when instantiated with a specific hashish routine. But normally these breaks happen because the hashish function itself is obvious break ( as happened when MD4 and MD5 both cracked up a while back. ) still, those flaws are generally fixed by merely switching to a better function. furthermore, the practical attacks are historically more probably to come from obvious flaws, like the discovery of hash collisions screwing up touch schemes, preferably than from some alien mathematical flaw. Which brings us to a final, critical note…
4. For years, many people believed that the ROM could actually be saved. This hope was driven by the fact that ROM schemes generally seemed to work pretty well when implemented with strong hash functions, and so possibly all we needed to do was to find a hash officiate that was “ good enough ” to make ROM proof meaningful. Some theoreticians hoped that fancy techniques like cryptanalytic bewilderment could somehow be used to make concrete hashing algorithm that behaved well enough to make ( some ) ROM proofread instantiable. **
so that ’ s kind of the state of the ROM, or at least — it was the state up until the belated 1990s. We knew this model was artificial, and however it stubbornly refused to explode or produce wholly nonsense results .
And then, in 1998, everything went south .
CGH98: an “uninstantiable” scheme
For theoretical cryptographers, the real break point for the random oracle model came in the form of a 1998 STOC paper by Canetti, Goldreich and Halevi ( henceforth CGH ). I ’ meter going to devote the rest of this ( farseeing ! ) military post to explaining the effect of what they found .
What CGH proved was that, in fact, there exist cryptanalytic schemes that can be proven absolutely fasten in the random prophet model, but that — terrifyingly — become catastrophically insecure the minute you instantiate the hash serve with any concrete function .
This is a very chilling resultant role, at least from the point of view of the demonstrable security community. It ’ s one thing to know in theory that your proof might not be that solid. It ’ s a different matter wholly to know that in practice there are schemes that can walk correct past your proof like a Terminator infiltrating the Resistance, and then explode all over you in the most good way .
Before we get to the details of CGH and its relate results, a few caveats .
inaugural, CGH is very much a theory resultant role. The cryptanalytic “ counterexample ” schemes that trip this problem by and large do not look like real cryptosystems that we would use in commit, although by and by authors have offered some more “ realistic ” variants. They are, in fact, designed to do very artificial things that no “ veridical ” outline would ever do. This might lead readers to dismiss them on the grounds of artificiality .
The trouble with this view is that looks aren ’ t a particularly scientific way to judge a system. Both “ real looking ” and “ artificial ” schemes are, if proven correct, valid cryptosystems. The point of these specific counterexamples is to do measuredly artificial things in order to highlight the problems with the ROM. But that does not mean that “ realistic ” looking schemes won ’ deoxythymidine monophosphate do them .
A foster advantage of these “ artificial ” schemes is that they make the basic ideas relatively comfortable to explain. As a far note on this luff : rather than explaining CGH itseld, I ’ megabyte going to use a formulation of the like basic consequence that was proposed by Maurer, Renner and Holenstein ( MRH ) .
A signature scheme
The basic idea of CGH-style counterexamples is to construct a “ contrived ” schema that ’ s fasten in the ROM, but wholly blows up when we “ instantiate ” the hash function using any concrete routine, meaning a function that has a real description and can be efficiently evaluated by the participants in the protocol .
While the CGH techniques can apply with lots of different types of cryptosystem, in this explanation, we ’ ra going to start our case using a relatively bare type of system : a digital signature scheme .
You may recall from earlier episodes of this series that a normal touch schema consists of three algorithms : key generation, signing, and verification. The keystone generation algorithm outputs a public and mysterious winder. Signing uses the secret key to sign a message, and outputs a signature. Verification takes the leave signature, the public key and the message, and determines whether the touch is valid : it outputs “ True ” if the touch checks out, and “ False ” otherwise .
traditionally, we demand that signature schemes be ( at least ) existentially unforgeable under chosen message attack, or UF-CMA. This means that that we consider an effective ( polynomial-time bounded ) attacker who can ask for signatures on chosen messages, which are produced by a “ sign oracle ” that contains the clandestine sign key. Our expectation of a impregnable scheme is that, even given this entree, no attacker will be able to come up with a signature on some newly message that she didn ’ t ask the sign oracle to sign for her, except with negligible probability. ****
Having explained these basics, let ’ s spill about what we ’ re going to do with it. This will involve several steps :
Step 1: Start with some existing, secure signature scheme. It doesn ’ thymine actually matter what signature scheme we start with, a farseeing as we can assume that it ’ randomness secure ( under the UF-CMA definition described above. ) This existing signature outline will be used as a build obstruct for the new dodge we want to build. *** We ’ ll call this scheme S.
Step 2: We’ll use the existing scheme S as a building block to build a “new” signature scheme, which we’ll call 
Step 3: Having described the working of in detail, we’ll argue that it’s totally secure in the ROM. Since we started with an ( assumed ) guarantee signature scheme S, this argument by and large comes gloomy to showing that in the random oracle model the weird extra features we added in the former mistreat don ’ t actually make the dodge exploitable .
Step 4: Finally, we’ll demonstrate that is totally broken when you instantiate the random oracle with any concrete hash function, no matter how “secure” it looks. In short, we ’ ll show that one you replace the random oracle with a real hash serve, there ’ s a simple approach that constantly succeeds in forging signatures .
We ’ ll startle by explaining how works .
Building a broken scheme
To build our plan scheme, we begin with the existing batten ( in the UF-CMA sense ) signature scheme S. That schema comprises the three algorithms mentioned above : key genesis, signing and verification .
We need to build the equivalent three algorithm for our new system .
To make life easier, our new scheme will merely “ borrow ” two of the algorithm from S, making no further changes at all. These two algorithms will be the key generation and signature verification algorithms so two-thirds of our undertaking of designing the new system is already done .
Each of the novel elements that shows up in will therefore appear in the signing algorithm. Like all sign algorithm, this algorithm takes in a secret sign key and some message to be signed. It will output a signature .
At the highest degree, our new sign algorithm will have two subcases, chosen by a branch that depends on the remark message to be signed. These two cases are given as follows :
The “normal” case: for most messages M, the bless algorithm will merely run the original sign algorithm from the original ( plug ) scheme S. This will output a absolutely nice signature that we can expect to work merely very well.
Read more: A Few Thoughts on Cryptographic Engineering
The “evil” case: for a subset of ( reasonably-sized ) messages that have a unlike ( and very highly specific ) phase, our signing algorithm will not output a touch. It will rather output the privy key for the entire touch system. This is an consequence that cryptographers will sometimes call “ identical, identical badly. ”
so far this description inactive hides all of the in truth authoritative details, but at least it gives us an outline of where we ’ re trying to go .
Recall that under the UF-CMA definition I described above, our attacker is allowed to ask for signatures on arbitrary messages. When we consider using this definition with our modify bless algorithm, it ’ randomness easy to see that the presence of these two cases could make things exciting .
specifically : if any attacker can construct a message that triggers the “ evil ” case, her request to sign a message will actually result in her obtaining the scheme ’ sulfur secret key. From that point on she ’ ll be able to sign any message that she wants — something that obviously breaks the UF-CMA security system of the system. If this is excessively theoretical for you : imagine requesting a sign certificate from LetsEncrypt, and alternatively obtaining a copy of LetsEncrypt ’ s signing keys. immediately you excessively are a certificate agency. That ’ s the situation we ’ ra describe .
The only room this system could ever be proved batten is if we could somehow rule out the “ malefic ” case happening at all .
More concretely : we would have to show that no attacker can construct a message that triggers the “ evil font ” — or at least, that their probability of coming up with such a message is very, identical low ( negligible ). If we could prove this, then our schema basically just reduces to being the master guarantee scheme . Which means our new scheme would be secure .
In short-circuit : what we ’ ve accomplished is to build a kind of “ master password ” back door into our fresh outline. Anyone who knows the password can break the scheme. Everything now depends on whether an attacker can figure out that password .
So what is the “backdoor”?
The message that breaks the dodge international relations and security network ’ t a password at all, of course. Because this is calculator science and nothing is always comfortable, the message will actually be a calculator program. We ’ ll shout it P.
More concretely, it will be some kind of program that can decoded within our newfangled sign algorithm, and then evaluated ( on some remark ) by an spokesperson that we will besides place within that algorithm .
If we ’ re being formal about this, we ’ d say the message contains an encoding of a plan for a universal Turing machine ( UTM ), along with a unary-encoded integer triiodothyronine that represents the number of timesteps that the machine should be allowed to run for. however, it ’ south perfectly fine with me if you prefer to think of the message as containing a hunk of Javascript, an Ethereum VM blob combined with some maximal “ gas ” prize to run on, a .tgz encoding of a Docker container, or any other feasible format you fancy .
What very matters is the serve of the plan P .
A course of study P that successfully triggers the “ evil shell ” is one that contains an effective ( for example, polynomial-sized ) execution of a hash officiate. And not just any hash function. To actually trigger the back door, the algorithm P must a function that is identical to, or at least highly like to, the random oracle function H .
There are respective ways that the sign algorithm can verify this similarity. The MRH newspaper gives a very elegant one, which I ’ ll discus far below. But for the purposes of this contiguous intuition, let ’ s assume that our signing algorithm verifies this similarity probabilistically. specifically : to check that P matches H, it won ’ thyroxine verify the agreement at every potential remark. It might, for exercise, merely verify that P ( x ) = H ( x ) for some big ( but polynomial ) number of random remark values x .
so that ’ s the back door .
Let ’ s think briefly about what this means for security, both inside and outside of the random prophet mode .
Case 1: in the random oracle model
recall that in the random oracle model, the “ hash function ” H is modeled as a random routine. cipher in the protocol actually has a copy of that function, they merely have access to a third party ( the “ random oracle ” ) who can evaluate it for them .
If an attacker wishes to trigger the “ evil case ” in our bless scheme, they will somehow need to download a description of the random function from the oracle. then encode it into a broadcast P, and send it to the sign prophet. This seems basically intemperate .
To do this precisely — mean that P would match H on every input — the attacker would need to query the random oracle on every possible stimulation, and then design a course of study P that encodes all of these results. It suffices to say that this strategy would not be hardheaded : it would require an exponential sum of time to do any of these, and the size of P would besides be exponential in the input signal distance of the function. So this attacker would seem about guaranteed to fail .
Of course the attacker could try to cheat : make a small function P that only matches H on a small of inputs, and hope that the signer doesn ’ metric ton notice. however, even this seems pretty challenging to get away with. For example, to perform a probabilistic see, the sign algorithm can simply verify that P ( x ) = H ( x ) for a boastfully count of random remark points x. This overture will catch a adulterous attacker with very eminent probability .
( We will end up using a slightly more elegant access to checking the function and arguing this detail further below. )
The above is hardly an exhaustive security analysis. But at a high level our argument should nowadays be open : in the random oracle model, the schema is secure because the attacker can ’ thymine know a short enough back door “ password ” that breaks the system. Having eliminated the “ evil case ”, the dodge merely devolves to the master, fasten scheme S .
Case 2: In the “real world”
Out in the real world, we don ’ thymine manipulation random oracles. When we want to implement a system that has a proof in the ROM, we must first “ instantiate ” the scheme by substituting in some real hashish function in locate of the random oracle H.
This instantiate hash affair must, by definition, be efficient to evaluate and describe. This means implicitly that it possesses a polynomial-size description and can be evaluated in expected polynomial time. If we did not require this, our schemes would never work. furthermore, we must far assume that all parties, including the attacker, possess a description of the hashish affair. That ’ s a standard assumption in cryptography, and is merely a argument of Kerckhoff ’ second principle .
With these facts stipulated, the problem with our newfangled touch scheme becomes obvious .
In this place, the attacker actually does have access to a short-change, efficient broadcast P that matches the hashish affair H. In exercise, this officiate will credibly be something like SHA2 or Blake2. But even in a wyrd case where it ’ s some crazy obfuscate function, the attacker is still expected to have a program that they can efficiently evaluate. Since the attacker possesses this program, they can well encode it into a brusque enough message and send it to the sign oracle .
When the sign algorithm receives this program, it will perform some kind of test of this function P against its own implementation of H, and — when it inevitably finds a catch between the two functions with high probability — it will output the scheme ’ s privy key .
Hence, out in the very earth our dodge is constantly and forever, wholly break .
A few boring technical details (that you can feel free to skip)
If you ’ re comfortable with the imprecise technical intuition I ’ ve given above, feel release to skip this department. You can jump on to the adjacent separate, which tries to grapple with hood philosophical questions like “ what does this mean for the random oracle exemplar ” and “ I think this is all folderal ” and “ why do we drive on a drive, and park in a driveway ? ”
All I ’ meter going to do hera is clean up a few technical details .
One of the biggest pieces that ’ mho missing from the intuition above is a specification of how the sign algorithm verifies that the program P it receives from the attacker actually “ matches ” the random oracle officiate H. The obvious way is to just evaluate P( x ) = H( x ) on every possible input x, and output the outline ’ sulfur secret samara if every comparison succeeds. But doing this thoroughly requires exponential fourth dimension .
The MRH paper proposes a very neat alternative way to tackle this. They propose to test the functions on a few remark values, and not even random ones. More concretely, they propose checking that P( x ) = H( x ) for values of 
What this means is that to trigger the back door, the attacker must come up with a program P that can be described in some phone number of bits ( let ’ s call it n ), and yet will be able to correctly match the outputs of H at for example, q=2n+128 different input points. If we conservatively assume that H produces ( at least ) a 1-bit digest, that means we ’ re efficaciously encoding at least 2n+128 bits of data into a string of length normality .
If the function H is a actual hash function like SHA256, then it should be sanely easy for the attacker to find some n-bit broadcast that matches H at, say, q=2n+128 unlike points. For case, here ’ s a Javascript execution of SHA256 that fits into fewer than 8,192 bits. If we embed a Javascript spokesperson into our sign algorithm, then it merely needs to evaluate this given program on q = 2 ( 8,192 ) +128 = 16,512 unlike input points, compare each result to its own copy of SHA256, and if they all match, output the confidential key .
however, if H is a random prophet, this is vastly harder for the attacker to exploit. The leave of evaluating a random oracle at q distinct points should be a random string of ( at minimum ) q bits in length. Yet in order for the back door to be triggered, we require the encoding of program P to be less than half that size. You can therefore think of the procedure by which the attacker compresses a random string into that course of study P to be a very effective compaction algorithm, one takes in a random string, and compresses it into a string of less than half the size .
Despite what you may have seen on Silicon Valley ( NSFW ), compression algorithms do not succeed in compressing random strings that a lot with high probability. indeed, for a given string of bits, this is so improbable to occur that the attacker succeeds with at probability that is at most negligible in the schema ’ s security argument k. This effectively neutralizes the back door when H is a random oracle .
Phew .
So what does this all mean?
Judging by actions, and not words, the cryptographers of the worldly concern have been largely split on this wonder .
Theoretical cryptographers, for their part, gently chuckled at the punch-drunk practitioners who had been hoping to use random functions as hash functions. Brushing pipe ash from their lapels, they returned to more authoritative tasks, like finding ways to kill off cryptanalytic mystification .
Applied academic cryptographers greeted the newfangled results with gladden — and promptly authored 10,000 new papers, each of which found some new way to remove random oracles from an existing construction — while at the lapp time draw said construction vastly slower, more complicate, and/or based on entirely novel made-up and unconvincing number-theoretic assumptions. ( Speaking from personal experience, this was a fantastic time. )
Practitioners went right on trusting the random oracle exemplary. Because very, why not ?
And if I ’ molarity being honest, it ’ s a bite hard to argue with the practitioners on this one .
That ’ s because a very reasonable position to take is that these “ counterexample ” schemes are absurd and artificial. Ok, I ’ meter equitable being nice. They ’ rhenium entire BS, to be honest. cipher would ever design a scheme that looks thus absurd .
specifically, you need a scheme that explicitly parses an stimulation as a broadcast, runs that program, and then checks to see whether the program ’ s output matches a different hash function. What real-world protocol would do something so dazed ? Can ’ thymine we still trust the random oracle exemplary for schemes that aren ’ deoxythymidine monophosphate stupid like that ?
well, possibly and possibly not .
One childlike response to this argument is that there are examples of schemes that are significantly less artificial, and yet calm have random prophet problems. But even if one still views those results as artificial — the fact remains that while we only know of random prophet counterexamples that seem artificial, there ’ s no principled direction for us to prove that the bad will only affect “ artificial-looking ” protocols. In fact, the concept of “ artificial-looking ” is largely a human judgment, not something one can realiably think about mathematically .
In fact, at any given here and now person could unintentionally ( or on function ) propose a absolutely “ convention looking ” system that passes muster in the random prophet model, and then blows to pieces when it gets actually deployed with a standard hashish routine. By that point, the scheme may be powering our certificate authority infrastructure, or Bitcoin, or our nuclear weapons systems ( if one wants to be dramatic. )
The probability of this happening incidentally seems low, but it gets higher as deploy cryptanalytic schemes get more complex. For case, people at Google are now starting to deploy complex multi-party calculation and others are launching zero-knowledge protocols that are actually capable of running ( or proving things about the execution of ) arbitrary programs in a cryptanalytic way. We can ’ t absolutely rule out the possibility that the CGH and MRH-type counterexamples could actually be made to happen in these weird settings, if person is a just a little morsel careless .
It ’ sulfur ultimately a weird and thwart situation, and honestly, I expect it all to end in tears .
photograph by Flickr user joyosity .
Notes :
* intuitively, this definition sounds a distribute like “ pseudorandomness ”. Pseudorandom functions are required to be indistinguishable from random functions only in a arrange where the attacker does not know some “ secret key ” used for the function. Whereas hashish functions are frequently used in protocols where there is no opporunity to use a clandestine key, such as in public key encoding protocols.
Read more: A Few Thoughts on Cryptographic Engineering
** One particular hope was that we could find a way to obfuscate pseudorandom routine families ( PRFs ). The theme would be to wrap up a identify PRF that could be evaluated by anyone, even if they didn ’ thymine actually know the key. The leave would be identical from a random function, without actually being one .
*** It might seem like “ assume the universe of a secure key signature system ” drags in an extra premise. however : if we ’ ra going to make statements in the random oracle model it turns out there ’ sulfur no extra premise. This is because in the ROM we have access to “ dependable ” ( at least collision-resistant, [ second ] pre-image repellent ) hash function, which means that we can build hash-based signatures. So the universe of signature schemes comes “ barren ” with the random oracle model .
**** The “ except with negligible probability [ in the adjustable security parameter of the system ] ” caveat is important for two reasons. First, a dedicated attacker can always try to forge a signature precisely by brute-force guess values one at a clock until she gets one that satisfies the verification algorithm. If the attacker can run for an boundless number of time steps, she ’ ll always win this game finally. This is why modern complexity-theoretic cryptography assumes that our attackers must run in some reasonable measure of prison term — typically a number of time steps that is polynomial in the outline ’ s security parameter. however, tied a polynomial-time bounded adversary can inactive try to brute force the signature. Her probability of future may be relatively little, but it ’ randomness non-zero : for case, she might succeed after the first gear estimate. so in commit what we ask for in security definitions like UF-CMA is not “ no attacker can ever forge a signature ”, but preferably “ all attackers succeed with at most negligible probability [ in the security parameter of the scheme ] ”, where negligible has a very specific think of .