Interface event

How are inputs and outputs handled that represent interface events, if one has the notion of an interface ... 

A usual alternative in cryptology is to represent them as the initial and final state of the entity. This is possible because in usual 2- and multi-party protocols, entities have only one input and one output that would be interpreted as interface events here. 

Idea 2 now means that this interface is placed very high , so that signatures and keys are only handled within the system, but do not appear in interface events. 

Figure 5.1. Example of interface events and entities if an ordinary digital signature scheme is modeled (incomplete).

Details about the interface events are discussed in Section 5.2.4. 

In a formal definition, a model of time is needed, both for the interface events and for message exchange within the system. For concreteness, the following simple, provisional model is assumed. 

Note that it is realistic, but perhaps too much so for some types of specification, that the same model of time is used for interface events and for message exchange within the system, i.e., that one can see in the sequence of interface events how many rounds of internal operations occur between two interface events. Alternatively, one could abstract from such differences at the interface. ... 

Transactions are not made explicit in the formalization They are only used in didactic comments, whereas formal statements deal with interface events individually. However, if one defined more than only signature schemes, formalizing transactions might save some work. 

The specification is descriptive. It consists of several individual requirements describing properties that any sequence of interface events should have. In other words Each requirement is a predicate on the set of sequences over the domain of die interface events, i.e., it characterizes some sequences as permitted and others as undesirable see Figure 5.3P... 

Each requirement only deals with interface events at the access points of the interest group (and events at the connection-control access point). 

Authentication is a transaction between one signer and one recipient, where the signer wants to authenticate a message for the recipient, and the recipient wants to know if this authentication is correct. (Figure 5.1 showed a slightly simplified version of the interface events.)... 

Additional transactions (i.e., extensions of the domains of interface events) and corresponding requirements. The following examples are considered ... 

The following sections elaborate on this overview. The goal was to present enough details and formalism to guarantee that the type of specification cannot be misunderstood and that the classification is clear. Thus the interface events have been worked out completely and the two most important requirements, those on disputes. 

Before the standard transactions can be performed, initialization must take place at the corresponding access points. Initialization at the interface represents key generation and key distribution within the system. Roughly, each user who takes part inputs a command init , and everybody obtains an output that denotes whether initialization was successful. The main parameters of the interface events are identities, in particular, that of the future signer however, several variants are conceivable as to which of the interface events have this parameter and whether more identities occur explicitly. 

Figure 5.6. Interface events of initialization for a previously known identity.

The description of interface events in Section 5.2.4 contained several free variables, mostly denoting sets used as domains for parameters. This section discusses how these variables are bound. All the sets must be coimtable and non-empty, and for some of them, a restriction of the values they can assume is already known. Here is the complete list of them with some new restrictions. 

The requirements deal with sequences of sets of interface events sets are used because several events may occur in the same round. An event at the user interface is represented as a triple... 

This subsection defines abbreviations of frequently used formulas. Most of them correspond to the informal grouping of interface events into transactions. Two basic predicates denote that any input or output, respectively, occurs at a certain access point in the current round ... 

If one wanted more specific notions of what has been broken, the interface events could have parameters, such as the parameter which assumption or the identity of the signer from the original dispute. 

As mentioned in Section 5.2.2, several signature schemes offer more than the three common transactions. The interface events and corresponding requirements of important ones occurring in practice are now presented. 

In this case, the transaction transfer is a combination of previously known interface events The first recipient enters showim, id ), and the second recipient enters tesl(m, idg) and obtains an output acc. The first recipient also obtains an output, usually eot . More generally, new interface events transfer m, idg) and obtain(m, idg) could be introduced, but they are not needed in the existing schemes. 

An interface port, which is used for the interface events. In figures, it is drawn on top of the entities. Each interface port yields an access point. 

Equivalence for integrity requirements. For requirements in the sense of Section 5.2.1, where sequences of interface events are classified into permitted ones and undesirable ones, one can easily see that the two models are equivalent (both with and without computational restrictions on honest users and attackers) ... 

First consider a situation in the first model. It is described by an attacker strategy Aj. Then an attacker can achieve exactly the same sequences of interface events in the second model by using the strategy A2 = Aj, if the honest users only pass messages on between the attacker and the interface and these particular honest users... 

Information-theoretic security without error probability. For the simplest case, the definition can now be completed The scheme Scheme fulfils the given requirement Req information-theoretically without error probability if for all attackers A e Attackerjlass(Scheme, Req), all system parameters sys jars e Sys jars Scheme), and all interest groups i group I groups Req), all sequences of interface events at the interest group fulfil Req, i.e.,... 

---