> For the complete documentation index, see [llms.txt](https://docs.sealsecurity.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.sealsecurity.io/trust/signing.md).

# Cryptographic signing and hash verification

Every sealed artifact Seal publishes is cryptographically signed. The Seal CLI verifies the signature on every fetch.

## How Seal signs artifacts

The signing scheme:

* **ECDSA over the NIST P-256 curve**, with **SHA-256** as the signing hash.
* The artifact bytes are first hashed with **SHA-512**; the digest is what the signature covers.
* Signatures are **ASN.1**-encoded.

## Seal's public key

Seal's signing public key is **embedded in the Seal CLI binary as a constant**. The same key is used to sign every sealed iteration Seal publishes, including all prior iterations. **The key is not rotated**, so signatures on older sealed iterations remain verifiable indefinitely.

The key (base64-encoded ECDSA P-256 public key in PKIX format):

```
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEi0BRwnEStCPSWz6vpyv7lz8N1NOXTiUlwvVscU7cUqmnC6tM1thDpAoKX+wkPUrrxBbjok+mYgDoH/FSDm1LKw==
```

Anyone validating a sealed artifact uses this same key. There is no per-tenant key, no key fetch at run time, and no key rotation.

## The CLI's automatic validation

Every `seal fix` invocation runs a signature-verification step after downloading sealed artifacts and before installing them. The verification is automatic; you do not need to enable it.

For each downloaded artifact, the CLI:

1. Loads the embedded public key.
2. Computes the SHA-512 digest of the artifact bytes the CLI just downloaded.
3. Verifies the signature against the digest with ECDSA-P256 using the public key.

If any artifact fails verification or is missing a signature, the CLI fails the run with `failed validating package signatures` and the build does not proceed.

## Verifying signatures yourself

The CLI verifies automatically; in almost all cases, no customer-side action is needed. Customers who want to run an independent verification (for instance, against an artifact that took a path the CLI did not handle) use the same primitives:

* The public key above.
* The artifact bytes.
* The signature on the artifact.

The verification is a standard ECDSA-P256 / SHA-256 verify over the SHA-512 of the artifact bytes. Any ECDSA-aware tooling can run it: Python's `cryptography` module, `openssl dgst -verify`, Go's `crypto/ecdsa`, and so on. Contact [your Seal account team](/introduction/audience-guides/security-leader.md) for current verification helpers if you want to wire this into an internal audit pipeline.

## Verifying published hashes

Each sealed artifact also publishes a **SHA-256 hash** of its bytes. The hash is a lighter integrity check: if the SHA-256 of the artifact on your disk matches the SHA-256 Seal publishes, the bytes were not corrupted in transit or at rest.

Hash verification is weaker than signature verification: it confirms the bytes match what Seal published, but not, by itself, that the published bytes came from Seal. Use the signature for authenticity; use the hash for quick integrity.

The hash is shown in three places:

* On the [Repository page](/discovering/repository-page.md) for the sealed package version.
* In the package's drawer on the Protection page.
* In the [PDF attestation](/trust/attestations.md) for the artifact.

Compute the local hash with `sha256sum <file>` (Linux) or `shasum -a 256 <file>` (macOS) and compare against the published value.

## Related

* [Attestations](/trust/attestations.md): the signed records that complement artifact signing.
* [The CLI fix mode](/setup-apps-os/cli-in-cicd/cli-fix-mode.md): when the automatic validation runs.