# Introduction to Designated Verifier Signatures (DVS)
The Designated Verifier Signature (DVS) is an advanced cryptographic method that allows a signer to generate a digital signature verifiable only by a specific designated verifier, ensuring privacy and secure authentication.
In a traditional digital signature scheme, anyone with access to the public key (and the signature) can verify that a signer created a signature. In contrast, a Designated Verifier Signature (DVS) is a variant of a signature scheme in which only a specific verifier (the designated verifier) can check the signature’s validity. Other parties, even with full knowledge of the signature, cannot meaningfully verify its validity. The DVS concept is especially useful when the signer wants to ensure privacy or confidentiality of the signature, preventing the verifier from transferring that proof to others.
## Comparison: Classic Digital Signature vs. Designated Verifier Signature
The table below illustrates the differences between a classic digital signature scheme and a designated verifier signature scheme:
| Classic Digital Signature Scheme | Designated Verifier Signature (DVS) Scheme |
|---|---|
| Anyone can verify using the signer’s public key | Only the designated verifier can verify the signature |
| Verification is public | The signer designates the verifier |
| Non-repudiation is fully supported | Typically not supported |
| Typically software-based or may require hardware tokens | Software-based, no hardware tokens required |
| Public authentication | Privacy-preserving, verifier-specific authentication |
# Designated Verifier Signature in the Context of MIRACL Trust
MIRACL Trust’s Designated Verifier Signature (DVS) framework redefines digital signature verification by empowering a Trusted Authority (TA), rather than the signer, to designate the verifier and issue a unique secret to enable verification. MIRACL Trust DVS integrates multi-factor authentication (MFA) to produce non-repudiative digital signatures, maintaining transaction and data integrity. The transaction or data is first hashed, the end user provides a PIN to recreate the Client Secret, and the hash is digitally signed using this secret. Next, the signature and original transaction or data are transmitted to the client’s infrastructure for storage. For signature validation, the back-end infrastructure calls the MIRACL Trust DVS TA endpoint providing signature. This approach combines selective verification, MFA, and cryptographic security, enabling secure and verifiable interactions without requiring hardware tokens.
## Comparison: DVS vs. MIRACL Trust DVS
The table below illustrates the differences between a standard DVS scheme and the MIRACL Trust DVS framework:
| Feature | Standard DVS | MIRACL Trust DVS |
|---|---|---|
| Verifier Designation | Signer designates verifier | Trusted Authority (TA) designates verifier |
| Verifier Secret | Managed by signer | Issued directly by TA |
| Non-repudiation | Not supported by design | Supported via MFA |
| Multi-factor Authentication (MFA) | Not inherently supported | Hardware-free MFA capability |
| Signature Generation | Signer uses a computation of their secret key and verifier’s public key | Client Secret is used to sign hashed transaction/data |
| Signature Verification | Verifier validates using own key and signer’s public key to re-calculate | MIRACL Trust validates signature and identity |
| End-user Interaction | Signer signs directly | End-user enters PIN to recreate Client Secret for signing |
# MIRACL Trust DVS Flow
sequenceDiagram
actor User as User Agent
participant RPA as Relying Party Application
participant MIRACL as MIRACL Trust
User->>RPA: Create and submit transaction
RPA->>RPA: Validate and create digital transaction
RPA-->>User: Return transaction and hash
User->>User: Validate hash
User->>User: Prompt for PIN
End user enters PIN
User->>RPA: Generate and submit signature
RPA->>MIRACL: Validate signature and request verification
MIRACL-->>RPA: Return verification result
RPA-->>User: Return verification result
Relying Party Application is your application’s back end.
- The end user creates a transaction or generates data, which is sent to the your back-end application.
- The back-end application validates the transaction and creates the corresponding digital transaction, document, or data record.
- The back-end sends the following to the client application: the data/transaction and a hash of the data.
- The client application validates the received hash, displays the data/transaction to the end user, and prompts them to enter their PIN. The PIN is used to complete the Client Secret, which is then used to digitally sign the transaction/data hash.
- The client application sends the signature to the back-end application.
- The back-end application validates the signature and verifies the signature with MIRACL Trust.
- MIRACL Trust returns the verification result to the back end.
- The back end communicates the verification result to the client application. If the verification fails, the end user is prompted to enter their PIN again. After three consecutive failed attempts, the Client Secret is revoked.
- The back-end application persists the transaction/data and the signature, as appropriate.
# Example
When the bank requests a digital signature through its mobile app, the document is sent to the app for verification. The app checks that the document content is authentic and unmodified. After the end-user reviews the document and enters their PIN, the app creates a secure digital key (Client Secret) that is used to generate a cryptographic signature. The signed document is returned to the bank, which verifies the signature and, upon successful validation, securely stores the completed document. This process enables secure, efficient, and convenient digital signing.