# Digital Signatures Protocol

To explain how digital signatures work, let’s imagine two parties:

* **Alice** (the signer)
* **Bob** (the verifier)

The process follows three main steps: **Key Generation, Signing, and Verification**.

***

### Step 1 – Generating a Key Pair

Alice begins by creating an **asymmetric key pair**:

* A **private key (k**<sub>**pr**</sub>**)** – kept secret, used for signing.
* A **public key (k**<sub>**pub**</sub>**)** – shared openly, used for verification.

**Key properties:**

1. The keys are **mathematically related**. Bob can verify a signature created with k<sub>pr</sub> using k<sub>pub</sub>.
2. It is **easy** to derive k<sub>pub</sub> from k<sub>pr</sub>, but **computationally infeasible** to derive k<sub>pr</sub> from k<sub>pub</sub>.
3. Keeping kₚᵣ secret ensures **authentication** and **non-repudiation**.
4. Public keys can be published in **registries** (e.g., websites) to link them with an identity.

***

### Step 2 – Signing

When Alice wants to sign a document:

* Inputs: the **message (x)** and Alice’s **private key (kₚᵣ)**.
* The signing algorithm outputs the **digital signature (y)**.

<figure><img src="/files/AGOtpm1xCjJ3L8ZigIGH" alt=""><figcaption></figcaption></figure>

**Notes:**

* A “message” can be text, bytes, or hex.
* In practice, the message is first processed with a **hash function**. This produces a fixed-length digest, making signing more efficient and secure.
* Some digital signature schemes automatically include hashing in the signing process.

***

### Step 3 – Verification

&#x20;

When Bob receives Alice’s message and signature:

* Inputs: **message (x)**, **signature (y)**, and Alice’s **public key (k**<sub>**pub**</sub>**)**.

<figure><img src="/files/dlY7wKkPvnX10gUXmDeG" alt=""><figcaption></figcaption></figure>

* The verification algorithm checks the signature’s validity.
* Output:
  * **True (1)** if valid
  * **False (0)** if invalid

***

### End-to-End Protocol

<figure><img src="/files/08di3yXfgXKWArTbJmJg" alt=""><figcaption></figcaption></figure>

1. Alice generates kₚᵣ and kₚᵤb.
2. She shares **k**<sub>**pub**</sub> with Bob (via a registry or direct communication).
3. Alice signs the **message (x)** with **k**<sub>**pr**</sub>, producing signature **(y)**.
4. She sends **x** and **y** to Bob.
5. Bob verifies them using **k**<sub>**pub**</sub>.
6. The algorithm returns **True/False**.

***

### What Happens Behind the Scenes

The specific details of key generation, signing, and verification depend on the cryptographic scheme used, such as:

* **RSA**
* **ECDSA**

These define the mathematics behind how k<sub>pr</sub> and kₚᵤᵦ are created and applied.

***

### Key Takeaway

The **Digital Signatures Protocol** enables Alice to prove authorship of a message with her **private key (k**<sub>**pr**</sub>**)**, while Bob—or anyone with access to her **public key (k**<sub>**pub**</sub>**.)**—can verify it, ensuring trust without ever exposing the private key.

&#x20;


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://hub.bsvblockchain.org/higher-learning/bsv-academy/bitcoin-primitives-digital-signatures/what-are-digital-signatures/digital-signatures-protocol.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
