Protocol engineering is the application of systematic methods to the development of communication protocols. It uses many of the principles of software engineering, but it is specific to the development of distributed systems. == History == When the first experimental and commercial computer networks were developed in the 1970s, the concept of protocols was not yet well developed. These were the first distributed systems. In the context of the newly adopted layered protocol architecture (see OSI model), the definition of the protocol of a specific layer should be such that any entity implementing that specification in one computer would be compatible with any other computer containing an entity implementing the same specification, and their interactions should be such that the desired communication service would be obtained. On the other hand, the protocol specification should be abstract enough to allow different choices for the implementation on different computers. It was recognized that a precise specification of the expected service provided by the given layer was important. It is important for the verification of the protocol, which should demonstrate that the communication service is provided if both protocol entities implement the protocol specification correctly. This principle was later followed during the standardization of the OSI protocol stack, in particular for the transport layer. It was also recognized that some kind of formalized protocol specification would be useful for the verification of the protocol and for developing implementations, as well as test cases for checking the conformance of an implementation against the specification. While initially mainly finite-state machine were used as (simplified) models of a protocol entity, in the 1980s three formal specification languages were standardized, two by ISO and one by ITU. The latter, called SDL, was later used in industry and has been merged with UML state machines. == Principles == The following are the most important principles for the development of protocols: Layered architecture: A protocol layer at the level n consists of two (or more) entities that have a service interface through which the service of the layer is provided to the users of the protocol, and which uses the service provided by a local entity of level (n-1). The service specification of a layer describes, in an abstract and global view, the behavior of the layer as visible at the service interfaces of the layer. The protocol specification defines the requirements that should be satisfied by each entity implementation. Protocol verification consists of showing that two (or more) entities satisfying the protocol specification will provide at their service interfaces the specified service of that layer. The (verified) protocol specification is used mainly for the following two activities: The development of an entity implementation. Note that the abstract properties of the service interface are defined by the service specification (and also used by the protocol specification), but the detailed nature of the interface can be chosen during the implementation process, separately for each entity. Test suite development for conformance testing. Protocol conformance testing checks that a given entity implementation conforms to the protocol specification. The conformance test cases are developed based on the protocol specification and are applicable to all entity implementations. Therefore standard conformance test suites have been developed for certain protocol standards. == Methods and tools == Tools for the activities of protocol verification, entity implementation and test suite development can be developed when the protocol specification is written in a formalized language which can be understood by the tool. As mentioned, formal specification languages have been proposed for protocol specification, and the first methods and tools where based on finite-state machine models. Reachability analysis was proposed to understand all possible behaviors of a distributed system, which is essential for protocol verification. This was later complemented with model checking. However, finite-state descriptions are not powerful enough to describe constraints between message parameters and the local variables in the entities. Such constraints can be described by the standardized formal specification languages mentioned above, for which powerful tools have been developed. It is in the field of protocol engineering that model-based development was used very early. These methods and tools have later been used for software engineering as well as hardware design, especially for distributed and real-time systems. On the other hand, many methods and tools developed in the more general context of software engineering can also be used of the development of protocols, for instance model checking for protocol verification, and agile methods for entity implementations. == Constructive methods for protocol design == Most protocols are designed by human intuition and discussions during the standardization process. However, some methods have been proposed for using constructive methods possibly supported by tools to automatically derive protocols that satisfy certain properties. The following are a few examples: Semi-automatic protocol synthesis: The user defines all message sending actions of the entities, and the tool derives all necessary reception actions (even if several messages are in transit). Synchronizing protocol: The state transitions of one protocol entity are given by the user, and the method derives the behavior of the other entity such that it remains in states that correspond to the former entity. Protocol derived from service specification: The service specification is given by the user and the method derives a suitable protocol for all entities. Protocol for control applications: The specification of one entity (called the plant - which must be controlled) is given, and the method derives a specification of the other entity such that certain fail states of the plant are never reached and certain given properties of the plant's service interactions are satisfied. This is a case of supervisory control. == Books == Ming T. Liu, Protocol Engineering, Advances in Computers, Volume 29, 1989, Pages 79–195. G.J. Holzmann, Design and Validation of Computer Protocols, Prentice Hall, 1991. H. König, Protocol Engineering, Springer, 2012. M. Popovic, Communication Protocol Engineering, CRC Press, 2nd Ed. 2018. P. Venkataram, S.S. Manvi, B.S. Babu, Communication Protocol Engineering, 2014.
Contract management software
Contract management software constitutes software and associated data management used to support contract management, contract lifecycle management, and contractor management on projects in the procurement of goods and services. It may be used together with project management software. == History == Historically, contract management was seen as a "paper-intensive" process. Early steps from the early 2000's reported by the Aberdeen Group required extensive data conversion work to enable documents to be handled electronically. With the adoption of the European Union's General Data Protection Regulation (GDPR) in 2016, companies needed to take additional steps in regards to contract management. Each data responsible entity was obliged to sign data processing agreements (DPAs) with the various vendors, who treat personal data on behalf of the data responsible. DPAs need to be regularly controlled, adjusted and renewed, which adds an extra agreement to such vendors or at least an extra DPA addendum to each agreement. By 2018, Ardent Partner's research had found that software used for automating contract management activities was being more extensively used among major companies or businesses with "Best-in-Class" procurement teams. Contract management process automation was found to be closely linked with more effective internal business collaboration, standardization and risk management. == Advantages and key functions == Using contract management software can have multiple benefits compared to manually managing paper contracts. This software can help keep track of multiple activities and can have features for automating administration, ensuring compliance, monitoring risk, running reports and triggering alerts. In addition to these types of features, contract management software systems provide a centralized repository for employees to quickly access all contracts worldwide in one place. Contract management software is produced by many companies, working on a range of scales and offering varying degrees of customizability. Basic functions should include the ability to store contract documents, track changes to contract documents, search documents for a particular criterion, send key date alerts and to report required aspects of the contract. Other functions include managing a new contract request, capturing related data, following a document through a review and approval process, and collecting digital signatures. Contract management software may also be an aid to project portfolio management and spend analysis, and may also monitor KPIs. Leading contract management software provides contract visibility, monitoring, and compliance to automate and streamline the contract lifecycle process. Contract management software which uses artificial intelligence (AI) can identify contract types based on pattern recognition. AI contracting software trains its algorithms on a set of contract data to recognize patterns and extract variables such as clauses, dates, and parties. It also offers simple prediction capabilities, by sorting through a large volume of contracts and flagging individual contracts based on specified criteria. AI software can also read contracts in multiple formats and languages, extract contract data, and provide analytics. It can reduce the risk of human error in contract drafting and review. A centralized repository provides a critical advantage allowing for all contract documents to be stored within one location. Having contracts stored in multiple locations can delay and interrupt the contracting process. == Contract risk management software (CRMS) for capital projects == Very large enterprises, such as capital expenditure (capex) projects, involve multiple parties and high risk and uncertainty. They are unlike traditional operating contracts in that they are subject to shared deadlines in unique situations. As the complexity of these unique projects increases, the relationships between parties become more important. This requires contract management software, or contract risk management software (CRMS), to become more dynamic and responsive. The terms of these capex contracts necessarily involve assumptions at the start of the process and are likely to change over the lifetime of the project lifecycle. For this reason, CRMS must be capable of recording one single instance of agreed changes to contract terms and incorporating these changes in an auditable and legally robust way. With multiple decision makers involved, CRMS should also make accountability more transparent and enable faster decisions about variation proposals.
Eduroam
eduroam (a portmanteau of education and roaming) is an international Wi-Fi internet access roaming service for users in research, higher education and further education. It provides researchers, teachers, and students network access when visiting an institution other than their own. Users are authenticated with credentials from their home institution, regardless of the location of the eduroam access point. Authorization to access the Internet and other resources are handled by the visited institution. Users do not have to pay to use eduroam. In some countries, Internet access via eduroam is also available at other locations than the participating institutions, e.g. in libraries, public buildings, railway stations, city centres and airports. It is also available at many primary and secondary education institutions in Brazil and the US. == History == The eduroam initiative started in 2002 when during the preparations for the creation of TERENA's task force TF-Mobility, Klaas Wierenga of SURFnet shared the idea of combining a RADIUS-based infrastructure with IEEE 802.1X technology to provide roaming network access across research and education networks. Initially, the service was joined by institutions in the Netherlands, Germany, Finland, Portugal, Croatia and the United Kingdom. Later, other NRENs in Europe embraced the idea and started joining the infrastructure, which was then called eduroam. Since 2004, the European Union co-funded further research and development work related to the eduroam service through the GN2 and GN3 projects. From September 2007, the European Union also funded through these projects the continued operation and maintenance of the eduroam service at the European level. The first non-European country to join eduroam was Australia, in December 2004. In Canada, eduroam started as an initiative of the University of British Columbia, which was later taken over by CANARIE as a service of its Canadian Access Federation. In the United States, eduroam was initially a pilot project between the National Science Foundation and the University of Tennessee (UTK). In 2012, Internet2 announced the addition of eduroam to its NET+ service offerings. AnyRoam LLC, a private company, was formed by former UTK staff to serve as an Internet2 active corporate member administering the US top-level servers. In 2021, Internet2 assumed direct management of the eduroam service for US-based organizations. == Technology == The eduroam service uses IEEE 802.1X as the authentication method and a hierarchical system of RADIUS servers. The hierarchy typically consists of RADIUS servers at the participating institutions, national RADIUS servers run by the National Roaming Operators, and regional top-level RADIUS servers for individual world regions. In some cases, institutions contact each other directly via DNS lookups () When a user visits a remote institution, the user's device presents their credentials to the local RADIUS server. That RADIUS server discovers that it is not responsible for the realm of the user's home institution and proxies the access request to another RADIUS server, typically the national RADIUS server. If the visited institution is in a different country than the home institution, the request is in turn proxied to the regional top-level RADIUS server, and then to the national RADIUS server of the user's home country. That national server forwards the credentials to the home institution, where they are verified. The RADIUS response travels back over the proxy-hierarchy to the visited institution and the user is granted access. In eduroam, the user credentials are always presented in the form of an EAP method (). The EAP method is responsible for ensuring that the users credentials are secure, and private. The users credentials can then travel via a number of intermediate servers, not under the control of the home institution of the user. This requirement limits the types of EAP methods that can be used. EAP methods which do not provide for security or privacy of user credentials cannot be used in eduroam. The most commonly used EAP methods in eduroam are EAP-TLS, PEAP, and EAP-TTLS. The methods used generally fall into two broad categories: those that use credentials in the form of some public-key mechanism with certificates and those that use so-called tunnelled authentication with "inner" passwords or other credentials. Most institutions use a tunnelled authentication method that requires a server certificate. These server certificates are used to set up a secure tunnel between the mobile device and the authentication server, through which the user credentials (e.g. name and password) are securely transported. A complication arises if the user's home institution does not use a two-letter country-code top-level domain as part of its realm, but a generic top-level domain such as .edu or .org. By inspection of such realms, it is not possible to determine which national RADIUS server the request should be routed to. Such domains will thus, by default, fail to work in international roaming. The workaround for this problem involves the creation of exceptions in the international RADIUS request routing tables; however, this workaround does not scale as the number of exception entries grows. Several solutions have been proposed to eliminate this workaround in the future, the most promising of which is RADIUS over TLS with Dynamic Discovery, which does not rely on static routing tables inside a RADIUS server configuration to route requests to their proper destination. Instead, the participating institution adds one NAPTR DNS resource record to its own domain's DNS zone, which states by which server eduroam authentication for the domain is handled. == Governance == GÉANT has established a lightweight global governance structure. Recognising the large variety in the organisation and funding of research and education (networking) in different countries and regions, rules imposed on the operations of eduroam are limited to technical and administrative requirements that are necessary to ensure the smooth and secure operations of eduroam worldwide. Moreover, the eduroam operators have the leading role in creating and maintaining the rules of the global eduroam governance. The Global eduroam Governance Committee (GeGC) has the central role in the global eduroam governance structure. While its structure has evolved over time, it presently has three representatives from each of five regions — mirroring those used by the Regional Internet registries — serving a two-year term. In addition, GÉANT may appoint one or more experts as non-voting members of the GeGC. == Geographical deployment == eduroam is available at selected locations in countries with a National Roaming Operator that has signed the eduroam Compliance Statement. Those sixty-seven countries are listed below. In addition, there may be pilot deployments in countries that are in the process of joining eduroam. === Middle East === eduroam is deployed in: === Europe === The NRENs that are members of the consortium of the GN3 project have joined the European eduroam confederation by signing the confederation's policy that requires its members to comply with a set of technical and organisational requirements, which are more specific than those in the global eduroam Compliance Statement. As a consequence, eduroam is deployed in the following countries: In addition, three NRENs that are associate members of the consortium of the GN3 project without voting rights joined the European eduroam confederation; they represent Belarus (UIIP), Moldova (RENAM) and Russia (Joint Supercomputer Center of the Russian Academy of Sciences). Finally, five NRENs not involved in the GN3 project joined the European eduroam confederation on a voluntary basis, enabling the deployment of the service in: The European top-level RADIUS servers are operated by SURFnet and Forskningsnettet. === Asia-Pacific === eduroam is deployed in the following countries and economies: The Asia-Pacific top-level RADIUS servers are operated by AARNet and by the University of Hong Kong. === North America === eduroam is deployed in: === Latin America === eduroam is deployed in: === Africa === eduroam is deployed in: The inter-African RADIUS servers are operated by West-African research and education network WACREN, the UbuntuNet Alliance and TENET.
Codebook
A codebook is a type of document used for gathering and storing cryptography codes. Originally, codebooks were often literally books, but today "codebook" is a byword for the complete record of a series of codes, regardless of physical format. == Cryptography == In cryptography, a codebook is a document used for implementing a code. A codebook contains a lookup table for coding and decoding; each word or phrase has one or more strings which replace it. To decipher messages written in code, corresponding copies of the codebook must be available at either end. The distribution and physical security of codebooks presents a special difficulty in the use of codes compared to the secret information used in ciphers, the key, which is typically much shorter. The United States National Security Agency documents sometimes use codebook to refer to block ciphers; compare their use of combiner-type algorithm to refer to stream ciphers. Codebooks come in two forms, one-part or two-part: In one-part codes, the plaintext words and phrases and the corresponding code words are in the same alphabetical order. They are organized similar to a standard dictionary. Such codes are half the size of two-part codes but are more vulnerable since an attacker who recovers some code word meanings can often infer the meaning of nearby code words. One-part codes may be used simply to shorten messages for transmission or have their security enhanced with superencryption methods, such as adding a secret number to numeric code words. In two-part codes, one part is for converting plaintext to ciphertext, the other for the opposite purpose. They are usually organized similarly to a language translation dictionary, with plaintext words (in the first part) and ciphertext words (in the second part) presented like dictionary headwords. The earliest known use of a codebook system was by Gabriele de Lavinde in 1379 working for the Antipope Clement VII. Two-part codebooks go back as least as far as Antoine Rossignol in the 1800s. From the 15th century until the middle of the 19th century, nomenclators (named after nomenclator) were the most used cryptographic method. Codebooks with superencryption were the most used cryptographic method of World War I. The JN-25 code used in World War II used a codebook of 30,000 code groups superencrypted with 30,000 random additives. The book used in a book cipher or the book used in a running key cipher can be any book shared by sender and receiver and is different from a cryptographic codebook. == Social sciences == In social sciences, a codebook is a document containing a list of the codes used in a set of data to refer to variables and their values, for example locations, occupations, or clinical diagnoses. == Data compression == Codebooks were also used in 19th- and 20th-century commercial codes for the non-cryptographic purpose of data compression. Codebooks are used in relation to precoding and beamforming in mobile networks such as 5G and LTE. The usage is standardized by 3GPP, for example in the document TS 38.331, NR; Radio Resource Control (RRC); Protocol specification.
Social bot
A social bot, refers to fully or partially automated social media accounts designed to perform most regular users’ actions, such as liking, posting content, and chatting with other users. Although their levels of autonomy vary, and often include a human-in-the-loop, social bots can use artificial intelligence to perform social media actions and can use large language models to mimic human dialogue. Social bots can operate alone or in groups that coordinate messaging as part of a network of coordinated inauthentic behavior. Social bots are often used to perform ad fraud by artificially boosting viewership and engagement metrics and to spread disinformation on social media. == Uses == Social bots are used for a large number of purposes on a variety of social media platforms, including Twitter, Instagram, Facebook, and YouTube. One common use of social bots is to inflate a social media user's apparent popularity, usually by artificially manipulating their engagement metrics with large volumes of fake likes, reposts, or replies. Social bots can similarly be used to artificially inflate a user's follower count with fake followers, creating a false perception of a larger and more influential online following than is the case. The use of social bots to create the impression of a large social media influence allows individuals, brands, and organizations to attract a higher number of human followers and boost their online presence. Fake engagement can be bought and sold in the black market of social media engagement. Corporations typically use automated customer service agents on social media to affordably manage high levels of support requests. Social bots are used to send automated responses to users’ questions, sometimes prompting the user to private message the support account with additional information. The increased use of automated support bots and virtual assistants has led to some companies laying off customer-service staff. Social bots are also often used to influence public opinion. Autonomous bot accounts can flood social media with large numbers of posts expressing support for certain products, companies, or political campaigns, creating the impression of organic grassroots support. This can create a false perception of the number of people who support a certain position, which may also have effects on the direction of stock prices or on elections. Messages with similar content can also influence fads or trends. Many social bots are also used to amplify phishing attacks. These malicious bots are used to trick a social media user into giving up their passwords or other personal data. This is usually accomplished by posting links claiming to direct users to news articles that would in actuality direct to malicious websites containing malware. Scammers often use URL shortening services such as TinyURL and bit.ly to disguise a link's domain address, increasing the likelihood of a user clicking the malicious link. The presence of fake social media followers and high levels of engagement help convince the victim that the scammer is in fact a trusted user. Social bots can be a tool for computational propaganda. Bots can also be used for algorithmic curation, algorithmic radicalization, and/or influence-for-hire, a term that refers to the selling of an account on social media platforms. == History == Bots have coexisted with computer technology since the earliest days of computing. Social bots have their roots in the 1950s with Alan Turing, whose work focused on machine intelligence with the development of the Turing Test. The following decades saw further progress made towards the goal of creating programs capable of mimicking human behavior, notably with Joseph Weizenbaum’s creation of ELIZA. Considered to be one of the first Chatbots, ELIZA could simulate natural conversations with human users through pattern matching. Its most famous script was DOCTOR, a simulation of a Rogerian psychotherapist that was programmed to chat with patients and respond to questions. With the growth of social media platforms in the early 2000s, these bots could be used to interact with much larger user groups in an inconspicuous manner. Early instances of autonomous agents on social media could be found on sites like MySpace, with social bots being used by marketing firms to inflate activity on a user’s page in an effort to make them appear more popular. Social bots have been observed on a large variety of social media websites, with Twitter being one of the most widely observed examples. The creation of Twitter bots is generally against the site’s terms of service when used to post spam or to automatically like and follow other users, but some degree of automation using Twitter’s API may be permitted if used for “entertainment, informational, or novelty purposes.” Other platforms such as Reddit and Discord also allow for the use of social bots as long as they are not used to violate policies regarding harmful content and abusive behavior. Social media platforms have developed their own automated tools to filter out messages that come from bots, although they cannot detect all bot messages. == Legal regulation == Due to the difficulty of recognizing social bots and separating them from "eligible" automation via social media APIs, it is unclear how legal regulation can be enforced. Social bots are expected to play a role in shaping public opinion by autonomously acting as influencers. Some social bots have been used to rapidly spread misinformation, manipulate stock markets, influence opinion on companies and brands, promote political campaigns, and engage in malicious phishing campaigns. In the United States, some states have started to implement legislation in an attempt to regulate the use of social bots. In 2019, California passed the Bolstering Online Transparency Act (the B.O.T. Act) to make it unlawful to use automated software to appear indistinguishable from humans for the purpose of influencing a social media user's purchasing and voting decisions. Other states such as Utah and Colorado have passed similar bills to restrict the use of social bots. The Artificial Intelligence Act (AI Act) in the European Union is the first comprehensive law governing the use of Artificial Intelligence. The law requires transparency in AI to prevent users from being tricked into believing they are communicating with another human. AI-generated content on social media must be clearly marked as such, preventing social bots from using AI in a manner that mimics human behavior. == Detection == The first generation of bots could sometimes be distinguished from real users by their often superhuman capacities to post messages. Later developments have succeeded in imprinting more "human" activity and behavioral patterns in the agent. With enough bots, it might be even possible to achieve artificial social proof. To unambiguously detect social bots as what they are, a variety of criteria must be applied together using pattern detection techniques, some of which are: cartoon figures as user pictures sometimes also random real user pictures are captured (identity fraud) reposting rate temporal patterns sentiment expression followers-to-friends ratio length of user names variability in (re)posted messages engagement rate (like/followers rate) analysis of the time series of social media posts Social bots are always becoming increasingly difficult to detect and understand. The bots' human-like behavior, ever-changing behavior of the bots, and the sheer volume of bots covering every platform may have been a factor in the challenges of removing them. Social media sites, like Twitter, are among the most affected, with CNBC reporting up to 48 million of the 319 million users (roughly 15%) were bots in 2017. Botometer (formerly BotOrNot) is a public Web service that checks the activity of a Twitter account and gives it a score based on how likely the account is to be a bot. The system leverages over a thousand features. An active method for detecting early spam bots was to set up honeypot accounts that post nonsensical content, which may get reposted (retweeted) by the bots. However, bots evolve quickly, and detection methods have to be updated constantly, because otherwise they may get useless after a few years. One method is the use of Benford's Law for predicting the frequency distribution of significant leading digits to detect malicious bots online. This study was first introduced at the University of Pretoria in 2020. Another method is artificial-intelligence-driven detection. Some of the sub-categories of this type of detection would be active learning loop flow, feature engineering, unsupervised learning, supervised learning, and correlation discovery. Some operations of bots work together in a synchronized way. For example, ISIS used Twitter to amplify its Islamic content by numerous orchestrated accounts which further pushed an item to the Hot List news, thus further a
CAMeL-View TestRig
CAMeL-View is a software application, which is used for the model based design of mechatronic systems (multi-body simulation, block diagrams, pneumatic systems, hydraulic systems, general simulation, linear analysis and Hardware-in-the-Loop). CAMeL-View enables object-oriented model creation of mechatronic systems through the use of graphic blocks. The basic elements of multi-body system dynamics, control technology, hydraulics and hardware connectivity support the modeling process. The user’s proprietary C-Code can also be integrated into the models, which allows CAMeL-View TestRig to be implemented in all phases of the model based design process ( modeling, physical testing and prototyping), and lends itself especially well to mechatronic system design. The model’s structure is described and displayed with the help of directional connectors. Physical connections (such as mechanical or hydraulic linkages) as well as input and output connections (signal flow) are also available. The input of equations is done via mathematical expressions, e.g. the input of constitutive differential equations in vector and matrix form. Based on the model’s structure, the descriptive equations are converted into non-linear state space representations and converted into executable C-Code. CAMeL-View supports the simulation process with a configurable “experiment environment” (for simulator and instrumentation components) which allows the user to apply simulation models to supported targets (MPC5200, TriCore, X86, etc.) without the need for additional software tools for Hardware-in-the-Loop applications. In addition, the generation of so-called S-Functions for use in Simulink and the generation of ANSI C-Code for use in stand-alone simulators is also supported. A particularly noteworthy feature in CAMeL-View TestRig is the way in which the descriptive equations for multi-body system models are created. All multi-body simulation formalisms used for code generation create their equations in the form of typical explicit differential equations (ODE). This is especially important in Hardware-in-the-Loop applications where the calculation of simulation results within a specific, defined time frame must be assured. Only then is it possible to implement complex multi-body simulation models for Hardware-in-the-Loop applications under stringent real-time conditions. These constraints cannot be met when using DAE-based methods. Additional Toolboxes are available for linear analysis (Eigenvalues, pole-zero analysis, frequency response, etc.) of VRML-based animation. Development of CAMeL-View began in 1991 in the Paderborn Mechatronic Laboratory of Professor Dr. Ing. J. Lückel. The software was based on predecessors that had been developed there since 1986. The name stands for Computer Aided Mechatronic Laboratory – Virtual Engineering Workbench and describes the basic intent of one of the specific demands placed on development engineers in the computer lab.
Forking lemma
The forking lemma is any of a number of related lemmas in cryptography research. The lemma states that if an adversary (typically a probabilistic Turing machine), on inputs drawn from some distribution, produces an output that has some property with non-negligible probability, then with non-negligible probability, if the adversary is re-run on new inputs but with the same random tape, its second output will also have the property. This concept was first used by David Pointcheval and Jacques Stern in "Security proofs for signature schemes," published in the proceedings of Eurocrypt 1996. In their paper, the forking lemma is specified in terms of an adversary that attacks a digital signature scheme instantiated in the random oracle model. They show that if an adversary can forge a signature with non-negligible probability, then there is a non-negligible probability that the same adversary with the same random tape can create a second forgery in an attack with a different random oracle. The forking lemma was later generalized by Mihir Bellare and Gregory Neven. The forking lemma has been used and further generalized to prove the security of a variety of digital signature schemes and other random-oracle based cryptographic constructions. == Statement of the lemma == The generalized version of the lemma is stated as follows. Let A be a probabilistic algorithm, with inputs (x, h1, ..., hq; r) that outputs a pair (J, y), where r refers to the random tape of A (that is, the random choices A will make). Suppose further that IG is a probability distribution from which x is drawn, and that H is a set of size h from which each of the hi values are drawn according to the uniform distribution. Let acc be the probability that on inputs distributed as described, the J output by A is greater than or equal to 1. We can then define a "forking algorithm" FA that proceeds as follows, on input x: Pick a random tape r for A. Pick h1, ..., hq uniformly from H. Run A on input (x, h1, ..., hq; r) to produce (J, y). If J = 0, then return (0, 0, 0). Pick h'J, ..., h'q uniformly from H. Run A on input (x, h1, ..., hJ−1, h'J, ..., h'q; r) to produce (J', y'). If J' = J and hJ ≠ h'J then return (1, y, y'), otherwise, return (0, 0, 0). Let frk be the probability that FA outputs a triple starting with 1, given an input x chosen randomly from IG. Then frk ≥ acc ⋅ ( acc q − 1 h ) . {\displaystyle {\text{frk}}\geq {\text{acc}}\cdot \left({\frac {\text{acc}}{q}}-{\frac {1}{h}}\right).} === Intuition === The idea here is to think of A as running two times in related executions, where the process "forks" at a certain point, when some but not all of the input has been examined. In the alternate version, the remaining inputs are re-generated but are generated in the normal way. The point at which the process forks may be something we only want to decide later, possibly based on the behavior of A the first time around: this is why the lemma statement chooses the branching point (J) based on the output of A. The requirement that hJ ≠ h'J is a technical one required by many uses of the lemma. (Note that since both hJ and h'J are chosen randomly from H, then if h is large, as is usually the case, the probability of the two values not being distinct is extremely small.) === Example === For example, let A be an algorithm for breaking a digital signature scheme in the random oracle model. Then x would be the public parameters (including the public key) A is attacking, and hi would be the output of the random oracle on its ith distinct input. The forking lemma is of use when it would be possible, given two different random signatures of the same message, to solve some underlying hard problem. An adversary that forges once, however, gives rise to one that forges twice on the same message with non-negligible probability through the forking lemma. When A attempts to forge on a message m, we consider the output of A to be (J, y) where y is the forgery, and J is such that m was the Jth unique query to the random oracle (it may be assumed that A will query m at some point, if A is to be successful with non-negligible probability). (If A outputs an incorrect forgery, we consider the output to be (0, y).) By the forking lemma, the probability (frk) of obtaining two good forgeries y and y' on the same message but with different random oracle outputs (that is, with hJ ≠ h'J) is non-negligible when acc is also non-negligible. This allows us to prove that if the underlying hard problem is indeed hard, then no adversary can forge signatures. This is the essence of the proof given by Pointcheval and Stern for a modified ElGamal signature scheme against an adaptive adversary. == Known issues with application of forking lemma == The reduction provided by the forking lemma is not tight. Pointcheval and Stern proposed security arguments for Digital Signatures and Blind Signature using Forking Lemma. Claus P. Schnorr provided an attack on blind Schnorr signatures schemes, with more than p o l y l o g ( n ) {\displaystyle polylog(n)} concurrent executions (the case studied and proven secure by Pointcheval and Stern). A polynomial-time attack, for Ω ( n ) {\displaystyle \Omega (n)} concurrent executions, was shown in 2020 by Benhamouda, Lepoint, Raykova, and Orrù. Schnorr also suggested enhancements for securing blind signatures schemes based on discrete logarithm problem.