Broadcast channel

However, in practice, the identity is present in the entity under an access point in the form of access to a broadcast channel under this previously known identity (for the time of initialization). For instance, with an ordinary digital signature scheme, the public key is broadcast on this channel inside the system during such an initialization. Similarly, if the system contained an authority that issues key certificates, the entity would need access to a secure channel to the authority under this identity, e.g., via the user who makes a handwritten signature. Note that the entities of all signers still use the same program e.g., they use a particular port for broadcast outputs. 

If each initialization is for a newly created identity, it is unrealistic to assume a particular access point for each future identity. For instance, a person will have only one device, which can be connected to an anonymous broadcast channel. Each time she wants an initialization for a newly created identity, she behaves in exactly the same way. Hence she should have a special access point just for initialization, and each initialization should yield a new access point, which handles the newly created identity. (The new access point should appear in the same environment where the access point used in the initialization is, so that the same user has access to it, for instance physically or with a password. However, this cannot be represented formally in the current model.) Hence the following events happen at the interface ... 

Here it is required that initialization ends at the same time for all participants. Otherwise the connections would be more complicated to handle. As initialization without centres usually works on broadcast channels, this is no serious restriction. However, it is not required here that all the recipients and courts of the interest group are in this can be left to the... 

For initialization, the switch usually connects the broadcast ports of the participants with broadcast channels. However, the number and types of channels used in initialization are not restricted, i.e., this part of the mapping must be defined in the scheme. Moreover, each new type of transaction must be represented in the switch program. 

The type of connections, e.g., if broadcast channels or only point-to-point channels are available. 

As to initialization, it had been assumed in Section 5.2 that no signature scheme could exist without it and that a broadcast channel would be needed. One might ask if this is true. 

If external verifiability of the behaviour of participants is required (see Section 5.2.11), a structural requirement is usually made, too The entities of the observers should only observe the messages between the original entities, and not send any messages themselves. For this purpose, the channels used in the normal implementation of the transaction are extended to broadcast channels including the observers entities as receivers. Moreover, it is required that the decisions of the observers are deterministic. This ensures the consistency of observations. 

In particular, broadcast channels are assumed to be reliable even if some of the entities connected to them are corrupted. Thus, if a correct entity sends a message, all receivers receive exactly this message and know that it comes from this entity, and even if the sender is corrupted, it cannot trick the recipients into receiving different messages. One often speaks of the broadcast assumption if a broadcast channel is present in the structure of a system. 

Authentic channels. Sometimes, point-to-point channels are needed in initialization where integrity and availability are not sufficient — the receiver must also be able to recognize the identity of the sender. This means that the identity of the sender is appended to the message on the channel, as with a broadcast channel. 

Initialization is very complex All entities of recipients and courts play an active role in a protocol in several rounds over a broadcast channel. Each entity has its own specific test key at the end. 

There exists a distributed variant of authentication for this scheme (see Section 5.2.11), i.e., a protocol where either all the recipients accept a signature or none does [PfWa92b]. This is not trivial, even if reliable broadcast channels are given, because the entities of the recipients have different test keys. 

There is a two-party protocol for entities of one signer and one risk bearer with additional reliable broadcast channels where any number of entities of courts and recipients may listen, too. The interactive algorithm for the signer s entity is called A (for Alice, as usual) and that for the entity of the risk bearer B (because he is often the recipient. Bob). Both A and B may be — and will be — probabilistic. The random bit strings used by A and B are called and rg, respectively. 

The execution of the complete protocol Gen is defined by an execution of A, B, and res, combined as in Figure 7.1 The 2-party ports of A and B are connected with a point-to-point channel and the broadcast ports with broadcast channels, which also lead to the input ports of res. Hence Gen defines probabilistic assignments of the form... 

Execution In an execution of Gen, one entity executing A and R entities executing B are connected with both point-to-point channels (not necessarily private) and broadcast channels (and the algorithms A and B must have the appropriate ports), res is still a deterministic polynomial-time interactive algorithm with input ports only, and those input ports are connected to the broadcast channels. Note that one can still define all outputs with only one instance of res. 

External verifiability of authentication is easy to achieve because authentication is non-interactive, public keys exist, and test is deterministic and memory-less restr If the message exchange during authentication, i.e., sending the signature, takes place on a reliable broadcast channel (as it is standard when external verifiability is considered), all entities that took part in initialization can test the signature with the same public key. 

A correct execution of all the three algorithms, where P and V are connected with reliable broadcast channels that also lead to the input ports of Obs, and where the inputs par and K are the same for all three (see Figure 7.2), is denoted by a probabilistic assignment... 

A first expects to receive a value prek from the risk bearer s entity on the broadcast channel and tests it with all test par, prek). If the result is FALSE, it stops. Otherwise, it carries out the verifier s part, V, of the zero-knowledge proof scheme on input (par, prek), using the broadcast channel for all messages. This gives a result acc. If acc = FALSE, it stops. Otherwise, it executes gen (par, prek) to obtain values sk temp and mk. It broadcasts mk, the main public key, and outputs sk temp. 

B first carries out gengipar ) to obtain values prek and aux. Then it carries out the prover s part, P, of the zero-knowledge proof scheme on input (par, prek, aux), using the broadcast channel for all messages. 

If accjobserved = TRUE, i.e., the observer thinks, that the proof was ok, it expects a value mk from the signer s entity on the broadcast channel. If none arrives, or if mk test(par, prek, mk) = FALSE, the output is (FALSE, , ) again. Otherwise, the output is... 

Remark 7.32. The use of the broadcast channel in the correct case (which should be the most common case) and the involvement of recipients and courts can be reduced as follows After prek has been published, and if it passes all Jest, the entities of the signer and the risk bearer first try to execute their algorithms P and V on the point-to-point channel. The signer s entity broadcasts its result acc. If it is TRUE, i.e., there is no disagreement between the signer and the risk bearer, it immediately publishes mk, too. Otherwise, the proof must be repeated on the broadcast channel as in Definition 7.31. ... 

An algorithm res is needed that the entities of recipients and courts can execute, too. They do not take part in the multi-party function evaluation actively, but they observe the complete protocol execution, which is performed on broadcast channels anyway. (The following means that the protocol from [ChDG88] can easily be equipped with external verifiability as defined in Section 5.2.11.)... 

Gen, the key-generation protocol, is a multi-party protocol defined by a pair of probabilistic interactive functions, (A, B ) (where is supposed to be executed by the signer s entity and by each entity of a tester), and arbitrary types of channels. (For concreteness, one can assume that in any execution, there is a private point-to-point channel between each pair of entities and a reliable broadcast channel for each one.)... 

---