Proof of forgery

The congruence of the handwritten notes on the photocopy of the original letter and on the carbon copy suggests that these notes were added photo-mechanically or in some other way. If this is correct, it would be another proof of forgery. 

So-called tranrfers of proofs of forgery are considered in the subsection on the fail-stop property. 

First, in the service of fail-stop signature schemes, the fact that a proof of forgery has occurred in the system is represented at the interface by acc= broken . 

If one wants to stop the whole system after an output broken and convince many people that this was necessary, it should be possible to transfer the knowledge that the scheme has been broken. (Otherwise, the signer and the recipient would have to repeat the dispute in front of everybody.) This property is called transferability of proofs of forgery. There is an additional transaction called transfer of a proof of forgery between two courts. The court that wants to transfer the knowledge enters transfer proof, and the other court enters test proof and obtains an output acc 6 broken , not broken There are two additional requirements ... 

Effectiveness of transfers of proofs of forgery. If a court has once obtained an output broken , either in a dispute or after entering test proof, and now carries out a transfer of a proof of forgery with another court, that court obtains the output acc = broken , too. The interest group consists of the two courts in the transfer. 

Correctness of broken. Part 2. The value acc = broken never occurs in transfers of proofs of forgery. The interest group consists of the receiving court in that transfer, or, if special risk bearers are considered, that court together with any risk bearer. 

Transfers of proofs of forgery are non-interactive, i.e., explicit proofs of forgery exist. 

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 same algorithm verify is used to verify transferred proofs of forgery. 

This will be sufficient for a proof of forgery. The pair of two signatures on the same message can either immediately count as a proof of forgery, as illustrated in Figure 6.8, or there can be a procedure that constructs a simpler proof from such a pair. For instance, such a proof could be a factor of a number that the signer should not have been able to factor (see Section 6.1.2, Number of Risk Bearers. .. ). 

One basic idea for these constructions is tree authentication. If one starts with the type sketched in Section 2.4, the same addition is needed as with message hashing The hash functions used must be collision-intractable, and their collisions count as proofs of forgery. 

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. 

Security parameters. As some requirements on a fail-stop signature scheme have to be fulfilled information-theoretically and others only computationally, it is natural to consider two security parameters. They are called a and k, where a measures the information-theoretic security and k the computational security. The primary role of cr is that the error probability in the fail-back requirement of the signer on disputes decreases exponentially with a. In other words, a determines the probability that the signer is cheated with unprovable forgeries. The primary role of k is to ensure the correctness of broken , i.e., the larger k is, the harder it should be to compute valid proofs of forgeries (and thus forgeries in the first place). 

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

To see why this is necessary, consider the basic construction idea from Section 6.1.2, and in particular. Figures 6.7 and 6.8 A proof of forgery shows the attacker the correct signature on a message. He could use it in a future dispute. The signer would lose that dispute if her entity had not stored the forged signature from the first dispute. Formally, this condition is used in the proof sketch of Lemma 7.5. 

Otherwise it tries to compute a new proof of forgery. If the computation succeeds, it sends the resulting proof and stores it for future disputes. 

The only parts of these protocols one sees in the conventional definition are two nonrinteractive algorithms, prove for the computation of proofs of forgery and verify for their verification. In particular, storing and retrieving a proof of forgery are only implicitly assumed, because the proof of forgery is not a part of skjemp. 

Transfers of proofs of forgery were required to be non-interactive, and their structure is very simple One entity sends the proof of forgery, and the other verifies it with verify. 

In the transfer of a proof of forgery, the message and the signature have to be transferred, too, because the proof cannot be verified without them. Hence, not the output proof of the algorithm prove, but the triple proof = m, s, proof) would be the proof of forgery in the sense of Section 5.3.2. 

One has to be careful with future disputes after the one where the first proof of forgery was computed. There are two possibilities ... 

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. 

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. 

Correctness of broken means that a correct entity of a court should not produce the output broken in a dispute or a transfer of a proof of forgery. With the structure assumed for standard fail-stop signature schemes, this output depends on an application of verify, hence the requirement means that no valid proofs of forgery should occur. This requirement is fulfilled computationally only, and if there are special risk bearers, one of their entities is assumed to be correct. 

---