Recipient’s entity

Transfers in all existing signature schemes with arbitrary or finite transferability are non-interactive. Most of them are with non-interactive authentication, too, and in the transfer, the original signature is simply passed on. Only the test carried out by the recipient s entity depends on the acceptance level i in signature schemes with finite transferability. 

Entities of recipients cannot be memory-less in the same sense as entities of signers, because they must store some information about each authenticated message they have received in case of disputes. Hence, memory-less receiving is used to denote that the actions of the recipient s entity in authentication do not depend on previous authentications and disputes. 

For Statement 3, assume that the requirement of the recipient on disputes is error-free. Thus, whenever an execution of authentication with the recipient s entity leads to acc = TRUE, the recipient will win a subsequent dispute in court. A computationally unrestricted attacker comprising the recipient s entity can search for a sequence of messages that would lead to acc = TRUE if the correct recipient s entity received them in authentication. Then this attacker can win disputes deterministically. Hence the requirement of the signer can only be fulfilled against computationally restricted attackers in this case. 

A signature is received from the recipient s entity and tested with the same algorithm test that entities of recipients use in authentication. ... 

Fixed recipient or one recipient per initialization. With all existing fail-stop signature schemes, what one gains by this restriction is efficiency in authentication, in particular, in the algorithm test, because the recipient s entity can store information from previous signatures. On the other hand, this implies that a court s entity cannot use the same test for a signature as the recipient s entity, i.e., disputes are not constructed as above. 

In the first round, the entity of the signer sends a value to the entity of the recipient. This value is called the invisible signature, and it is the only value that the recipient s entity stores. 

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

As mentioned in Section 6.1.2, more efficient constructions exist for the case of a fixed recipient, which is rather important in practice (see Section 6.2). They can be seen as special variants of tree authentication that exploit the fact that the recipient s entity can store information about the current tree. Hence only one new leaf, instead of one complete branch, has to be sent and tested during each authentication, see Section 10.6. The complexity of fail-stop signature schemes with fixed recipient is therefore comparable to that of ordinary digital signature schemes. 

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. 

First, the recipient s entity has to present a number i and the signer s ok that she authenticated the i-th message. 

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. 

The first basic idea is that the entities of all recipients and courts must have different test keys, i.e., there is no public key. Thus an unrestricted attacker does not know how a recipient s entity tests a signature, and therefore the attack by exhaustive search mentioned under Security Limits in Section 2.3 is no longer applicable. 

A recipient s entity accepts a signature if all its parts are correct, whereas... 

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 ... 

Proof sketch of Lemma 7.4. The recipient s entity only accepts m as authenticated by a signer id if test(pk, m, j) = TRUE, where pk is a public key from a successful initialization under the identity ids- The only step of a dispute where the court s entity can output a result other than TRUE or broken is Step 2, and then only if test(pk, m, s ) = FALSE, where pk and s are what tlie court s entity regards as the public key belonging to idg and the signature. This cannot happen if pk = pk and 5 = s, because test is deterministic. As s has been received directly from the recipient s entity on a reliable channel, s = j is clear. Furthermore, there is a precondition that exactly one initialization under the identity id has been carried... 

Proof sketch. Active attacks on the recipient can be omitted, because the attacker can simulate the actions of the recipient s entity on his own It applies the algorithms res and test to values known to the attacker, and in disputes, it sends a previously received signature. The risk bearer s entity can be treated as in the proof sketch of Lemma 7.6. 

For instance, the complete correct signature j on m3 consists of the encircled nodes. To test it, the recipient s entity reconstructs the nodes in squares. 

In the case with a fixed recipient, efficiency can be improved significantly, because the recipient s entity can store information from previously received signatures. 

Schemes with non-interactive authentication and no dependence on the recipient. Then, as usual, test is used by the recipient s entity in authentication, and the recipients are the testers. 

Schemes with 2-party disputes where the recipient s entity only sends a signature to the court s entity. This may also be fulfilled if authentication depends on the recipient, as in Section 10.6. Then the courts are the testers. 

---