Verifying Reports
Every report published by HubSec includes two cryptographic verification mechanisms: a content hash for integrity and a detached PGP signature for authenticity. This page explains what they are, why they matter, and how to use them.
Why This Matters
Security research is only valuable if you can trust it hasn't been altered. A post-mortem that gets subtly modified after publication (a severity rating changed, a recommendation removed, a finding added retroactively) is worse than no report at all, because it creates false confidence.
Content hashing and PGP signing solve this. They let you independently verify two things: that the report you're reading is identical to what HubSec originally published, and that it was actually published by HubSec and not someone else.
Integrity: Content Hash
Every HubSec report displays a SHA-256 content hash in its footer. This hash is a cryptographic fingerprint of the report's source file at the time of publication. If even a single character changes, the hash will be completely different.
How to Verify
Download the report source file and compute the hash yourself. If your result matches the hash in the report footer, the content is identical to what was originally published.
# Download the report source
curl -O https://hubsec.net/reports/hyperbridge-2026-04.mdx
# Compute the SHA-256 hash
shasum -a 256 hyperbridge-2026-04.mdx | awk '{print $1}'
# Compare the output to the hash in the report footerIf the hashes match, the report has not been modified since publication. If they don't, either the report was altered or you're looking at a cached version. Either way, contact us at security@hubsec.net.
On Linux, use sha256sum instead of shasum -a 256. Same output.
Authenticity: PGP Signature
The content hash proves the report hasn't changed, but not who published it. Someone could create a fake report, hash it, and claim it's from HubSec. PGP signatures solve this.
Every report is accompanied by a detached PGP signature file, created using HubSec's private key. Anyone can verify the signature using our public key.
Step 1: Import HubSec's Public Key
One-time setup.
curl https://hubsec.net/pgp-key.asc | gpg --importYou should see:
gpg: key [KEY_ID]: public key "HubSec <security@hubsec.net>" importedVerify the fingerprint matches what's displayed in our site footer and on this page. If it doesn't, do not trust the key. Contact us through an independent channel.
Step 2: Download the Report and Signature
# Download the report source
curl -O https://hubsec.net/reports/hyperbridge-2026-04.mdx
# Download the detached signature
curl -O https://hubsec.net/signatures/hyperbridge-2026-04.sigStep 3: Verify
gpg --verify hyperbridge-2026-04.sig hyperbridge-2026-04.mdxIf authentic and unmodified:
gpg: Signature made [date]
gpg: using RSA key [KEY_ID]
gpg: Good signature from "HubSec <security@hubsec.net>"“Good signature” means two things: the report was signed by HubSec's private key (authenticity), and the report has not been modified since signing (integrity).
If you see BAD signature, the file has been tampered with. Do not trust it.
Without GPG Installed
If you don't have GPG and don't want to install it, the content hash alone still gives you integrity verification. SHA-256 hashes can be computed with built-in OS utilities:
shasum -a 256 filenameGet-FileHash filename -Algorithm SHA256For maximum security, use a local tool rather than uploading report files to third-party websites.
HubSec's PGP Key
If you need to send us sensitive information (vulnerability disclosures, incident details, confidential correspondence), encrypt your message with this public key. Only HubSec can decrypt it.
# Encrypt a message to HubSec
gpg --armor --encrypt --recipient security@hubsec.net your-message.txt
# Send the resulting your-message.txt.asc fileQuestions
Why not just use HTTPS?
HTTPS protects data in transit. It ensures nobody intercepts the report between our server and your browser. But it doesn't protect against modification at the source. If our hosting provider is compromised, or if someone gains access to our deployment pipeline, HTTPS would faithfully serve the tampered content. Content hashing and PGP signing protect against that scenario.
What if I get a "key not found" error?
You need to import our public key first (Step 1 above). If you've already imported it and still get errors, the key may have expired. Check our website for an updated key.
What if the key has been revoked?
If our key is ever compromised, we will revoke it and publish a new one. GPG will warn you if you try to verify with a revoked key. Check our website for the current key and re-import.
Do you sign every report?
Yes. Every post-mortem, vulnerability advisory, and research publication is hashed and signed before deployment. If a report on our site does not have a content hash and signature, treat it as unverified and contact us.