Signer’s entity

In signature schemes with non-interactive authentication, the message that the signer s entity sends during authentication can be called the signature. 

Informally, initialization is needed because authentication is completely digital and carried out over an insecure channel. Hence the signer s entity must possess digital information that enables it to act differently from any potential forger, at least on average. This information must be related to some information the recipient has in connection with the identity of this signer. Hence a secure channel under this identity must have existed at some time. 

So far, the only case where a clear notion of public keys exists is the least complex form of initialization If the signer s entity just broadcasts one message to all other entities, this message is called a public key. More generally, a public key can be defined if... 

In particular, a constraction exists that transforms any fail-stop signature scheme for a fixed risk bearer with 2-message initialization into one for many risk bearers where initialization only needs two rounds In the first round, the entity of each risk bearer broadcasts a separate prekey in the second round, the signer s entity broadcasts a public key. More generally, one can use parallel replications of the initialization of any fail-stop signature scheme for a fixed risk bearer, see Section 7.5.1. This soimds quite efficient however, it has so far implied that the complexity of the other transactions grows linearly with the number of risk bearers. In contrast, versions with more complex initialization exist where the complexity of the other transactions is not larger than in the case with one risk bearer, see Section 7.5.2. 

If the signature does not pass this test, the court s entity outputs acc = FALSE and stops. Otherwise, it forwards the signature to the signer s entity. 

If it receives an answer from the signer s entity, it uses an algorithm verify to verify that the answer is a valid proof of forgery. If yes, the output is acc = broken otherwise acc = TRUE. 

The recipient s entity sends the invisible signature to the court s entity, who passes it on to the signer s entity. 

One principle is common to all these constractions Even in the information-theoretic sense, the secret information in a signer s entity cannot be uniquely determined from public information. 

The correct secret key is defined as the one that the signer s entity actually has. 

Then the correct secret key, i.e., the one that the signer s entity actually has, can only be guessed with a probability of... 

Similar relations hold in schemes with a more complex structure. Furthermore, the term public information can be extended to all the information that an attacker may know . In particular, this includes all the signatures that the signer s entity has already produced. 

Ok. If the transaction description is correct, the signer s entity signs one single bit, which can be interpreted as ok , with its i-th fail-stop signature, and sends this signature to the recipient s entity. 

If the signer s entity can compute a proof of forgery for this fail-stop signature, the result is acc = FALSE. Otherwise, it must present the transaction description for the f-th message with the signature of the recipient s entity. If this transaction description contains a different message m the result is acc = FALSE, otherwise acc = TRUE. 

To prevent mischief, one can add a preliminary step where the signer s entity sends an ordinary digital signature on the transaction description to the recipient s entity. The mischief would be that an attacker starts authentication in the name of a signer. The attacker cannot really gain anything by this, but it reduces the availability of service, because the recipient can only use each value i once. 

As an additional result of initialization, the signer s entity obtains a secret value. It is called skjemp, a temporary secret key, because it may change later. (That is, it is not necessarily a secret key in the sense of Section 5.3.2.) If initialization is not successful, skjemp = e is assumed for simplicity. 

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. 

Functional notation. The secret value sk temp is exactly the secret information that the signer s entity stores at the end of initialization. However, more secret random bits may be generated later. (Formally, they are read from a random tape.) It is sometimes useful to have a notation for all the secret information that a signer s entity ever uses. Hence let be a sufficiently long string of random bits, and let... 

The structure of disputes in standard fail-stop signature schemes was almost completely described in Section 6.1.2 (Subsection Number of Recipients and Complexity of Tests ) by the actions of the court s entity In Step 1, the court s entity tests the signature with the algorithm test defined above. (Now test is memory-less anyway, i.e., no special case is needed.) In Step 2, this signature is sent to the signer s entity, which can answer with a string called a proof of forgery. In Step 3, the court s entity verifies this proof... 

The corresponding action of the recipient s entity is simple It sends a stored signature to the court s entity. The signer s entity acts as follows ... 

One could allow the signer s entity to use the old proof of forgery and the old message and signature to show that the scheme has already been broken. Thus it transfers proof = (m, s, proof) to the court s entity, and proof can be verified given only the public key. Hence this possibility is equivalent to the chosen one. 

Note that the functional notation does not treat the case i > N. The following formal security definitions implicitly take Property c) from Definition 7.1 for granted, i.e., they do not treat what a signer s entity might do in authentications after the message bound has been reached, because it does not do anything. 

For disputes of Type b), it has to be shown that B does not lose anything by stopping afterwards. There are only two cases If the court s entity outputs TRUE, both B and B have succeeded, and there is no need to continue. If the court s entity outputs broken , the signer s entity must have computed a valid proof of forgery and will reuse it in all future disputes. Hence B can never succeed later, and B can just as well stop. 

In previous definitions, the only active attacks were that the attacker makes the signer s entity sign messages. 

Active attacks on the recipient are useless, as before, and active attacks on the signer do not make much difference here either An attacker can only influence the value sk temp that the signer s entity will ise by choosing the messages to be signed, but skjtemp will be universally quantified anyway. Hence no active attack will be seen in the conventional definition. Definition 7.10. 

Inside the signature scheme The signer s entity consists of two parts. One part acts like the original signer s entity, the other like a risk bearer s entity, and there is a little administration so that both parts can share the same ports. 

---