Fair Exchange of Digital Signatures using RSA-based CEMBS and Offline STTP

One of the essential security services needed to safeguard online transactions is fair exchange. In fair exchange protocols two parties can exchange their signatures in a fair manner, so that either each party gain the other’s signature or no one obtain anything useful. This paper examines security solutions for achieving fair exchange. It proposes new security protocols based on the “Certified Encrypted Message Being Signature” (CEMBS) by using RSA signature scheme. This protocol relies on the help of an “off-line Semi-Trusted Third Party” (STTP) to achieve fairness. They provide with confidential protection from the STTP for the exchanged items by limiting the role and power of the STTP. Three different protocols have been proposed. In the first protocol, the two main parties exchange their signatures on a common message. In the second protocol, the signatures are exchanged on two different messages. While in the third one, the exchange is between confidential data and signature.

💡 Research Summary

**
The paper addresses the classic problem of fair exchange of digital signatures, where two mutually distrustful parties must obtain each other’s signatures in a way that either both succeed or neither does. Existing solutions based on Certified Encrypted Message Being Signature (CEMBS) have suffered from various drawbacks: GQ‑based CEMBS encrypts only part of the signature and is vulnerable to a recovery attack; DSA‑based CEMBS incurs heavy computational overhead and inherits the perceived “trapdoor” risk of DSA; RSA‑based CEMBS proposed earlier relies on an online trusted third party (TTP), which creates a bottleneck and raises trust‑placement concerns.

To overcome these limitations, the authors propose a new RSA‑based CEMBS that combines RSA signatures with ElGamal encryption and introduces an offline semi‑trusted third party (STTP). The STTP is only invoked when a problem occurs (e.g., a party aborts or sends an invalid value). Moreover, the STTP is “semi‑trusted”: it can assist in decryption but never learns the actual signature, thanks to a blind decryption technique.

Core Construction

1. RSA Signature: For a public message m, a party computes s = m^d mod n using its RSA private exponent d.
2. ElGamal Encryption of the Signature: The signature s is encrypted under the STTP’s public ElGamal key PK_T producing a ciphertext (W, V) where W = g^w mod P and V = s·PK_T^w mod P (random w).
3. CEMBS Certificate: A non‑interactive proof (r, c) is generated using a hash c = H(g‖W‖C‖a‖A) where C = g^V, a = G^u, A = (G^PK_T)^u, and r = u – c·w. The verifier can recompute the hash using the received values and accept the ciphertext as a genuine RSA signature without learning s.

Blind Decryption
The receiver, who does not possess the STTP’s secret key, sends only W to the STTP. The STTP computes W^SK_T and returns it. The receiver then multiplies this value with V to recover the original signature s. Because the STTP never sees V, it cannot reconstruct s.

Three Protocol Variants

1. Protocol 1 – Exchange of Signatures on a Common Message

   • Party A creates s_A, encrypts it under PK_T, builds CEMBS (r_A, c_A), and sends (W_A, V_A, c_A, r_A) to B.
   • B verifies the CEMBS; if valid, B sends its own RSA signature s_B on the same message m.
   • A checks s_B; if correct, A sends s_A to B.
   • B verifies s_A. If any step fails, B invokes the STTP: it sends W_A (blind) together with its own ciphertext and CEMBS; the STTP blindly decrypts W_A and forwards the result to B, while also forwarding B’s ciphertext to A. Both parties then recover the missing signatures.

2. Protocol 2 – Exchange of Signatures on Two Different Files

   • Each party signs a concatenation of its own file and the hash of the other’s file (e.g., m_A = M_A‖H(M_B)). The rest of the protocol mirrors Protocol 1, ensuring that the exchanged signatures are bound to distinct files.

3. Protocol 3 – Exchange of Confidential Data and a Signature

   • B wishes to obtain A’s signature on the hash of a confidential payload M. B first sends M (after verifying A’s CEMBS). A signs H(M), encrypts the signature, builds CEMBS, and sends the encrypted signature to B. B verifies the CEMBS and, if valid, accepts the signature. If A aborts or sends an invalid value, B again uses the STTP’s blind decryption to retrieve the signature.

Security Discussion
The authors analyze all possible misbehaviors:

• Dishonest B: B could send an incorrect s_B or attempt to obtain s_A without providing s_B. The CEMBS verification step prevents B from learning s_A unless it supplies a valid ciphertext of its own signature, because the STTP will only perform blind decryption when it receives a matching pair of ciphertexts and CEMBS from both parties.
• Dishonest A: A could send a malformed ciphertext or an invalid CEMBS. B will detect the failure during verification and invoke the STTP, which again requires a correct ciphertext from A to release s_A. Thus A cannot force B to obtain a signature without revealing its own.
• Semi‑trusted STTP: The STTP never sees the full ElGamal ciphertext (V component) and therefore cannot reconstruct the RSA signature. It only sees W and performs a partial decryption, preserving confidentiality.

The protocol guarantees fairness (no party can obtain the other’s signature without providing its own) and privacy (the STTP cannot learn the signatures). Moreover, because the STTP is offline, normal exchanges incur no third‑party communication overhead, improving scalability.

Performance Evaluation

• RSA signing and verification are computationally cheaper than DSA, especially for 1024‑bit keys.
• ElGamal blind decryption requires a single exponentiation on the STTP side and a simple multiplication on the receiver side.
• Communication overhead consists of two ElGamal ciphertext components and a short CEMBS (≈ 2 hash values), far smaller than the multi‑component certificates used in GQ‑based schemes.
• The offline nature of the STTP eliminates a constant‑time bottleneck present in online‑TTP designs.

Conclusion
The paper presents a well‑structured, theoretically sound, and practically efficient solution for fair exchange of digital signatures. By integrating RSA signatures, ElGamal encryption, and blind decryption, it resolves the security flaws of earlier CEMBS constructions while keeping computational and communication costs low. The three protocol variants demonstrate the flexibility of the approach for common‑message signing, cross‑file signing, and confidential data exchange. The offline semi‑trusted third party model strikes a good balance between trust assumptions and operational efficiency, making the scheme attractive for real‑world e‑commerce, contract signing, and secure data sharing applications.