Here is our signing key — and why one copy of it proves nothing

You downloaded a hundred megabytes from the internet, double-clicked it, typed your admin password into whatever came up, and then handed it every password you own.

Somewhere in there a decision got made about trust. Most of us couldn’t say exactly where.

Probably at the padlock. That padlock is real, and it does something worth having: it proves the bytes arrived unaltered from the server that answers for vauz.sealzi.com, and that nobody rewrote them on the coffee shop Wi-Fi in between.

What it doesn’t prove is that the server was serving what we put there.

A checksum sitting next to a file is a note that says “trust me”

Our download page  shows a SHA-256 checksum of the installer, and you can compare it against your copy. That’s genuinely useful — it catches a truncated download, a bad mirror, a disk that flipped a bit.

It catches nothing deliberate. Anyone who can replace the installer on our server can replace the checksum sitting beside it, and the page will cheerfully display a matching hash. Same server, same access, same edit.

We’re not planning to lose control of our server, obviously, duh. But you never know, you know ¯(ツ)/¯

A checksum published next to the file it describes proves your download finished. It doesn’t prove the file is ours.

What a signature adds

So Vauz releases are signed, using minisign . There are two halves to it, and they live very different lives.

The secret key, passphrase-protected, in the hands of whoever cuts releases. It is never on the web server. It is never in a repository. If it were, none of this would mean anything.

The public key goes everywhere we can put it. It’s meant to be public — that’s the entire job.

When we cut a release, the secret key signs a small file listing the installer’s SHA-256 checksum. With the public key, you can then establish two separate things: that the checksum file really came from us, and that the installer on your disk matches it. Nobody can produce that signature without the secret key — not a mirror, not a CDN, not a web host, not anyone who has only ever seen the public half.

That’s the difference. The checksum tells you what the file should be. The signature tells you who said so.

The key

Here it is, in full. This is the same thing that lives at vauz.sealzi.com/download/vauz-minisign.pub :

untrusted comment: minisign public key D59E41B28D3C7ADC
RWTcejyNskGe1Xc8GvEbKjUlI2wPh8XLVcs8Xcd3EraJvmSX7LuX8QQY

The first line is minisign being pedantic in a way we appreciate: comment lines aren’t covered by any signature, so it labels them untrusted rather than letting them look official. The key is the second line.

Note

This key does not change between releases. Save it once and reuse it for every version of Vauz you ever download. That habit is what makes the check worth doing at all — the next section is about why

Three commands

First, install minisign. You only ever do this once — it’s a small command-line tool, nothing to do with Vauz itself.

brew install minisign               # macOS
winget install jedisct1.minisign    # Windows
sudo apt install minisign           # Debian, Ubuntu

Fedora wants sudo dnf install minisign, Arch — sudo pacman -S minisign. Debian needs 12 or newer and Ubuntu 24.04 or newer; older releases don’t carry a minisign package. On Windows it lands as a portable package, so open a fresh terminal afterwards or the command won’t be found yet.

Then save SHA256SUMS and SHA256SUMS.minisig from the download page next to the installer, and check the signature. This one is identical on every platform:

minisign -Vm SHA256SUMS -P RWTcejyNskGe1Xc8GvEbKjUlI2wPh8XLVcs8Xcd3EraJvmSX7LuX8QQY

One Windows trap worth heading off first. SHA256SUMS has no file extension, browsers tend to add one, and it arrives as SHA256SUMS.txt — at which point minisign goes looking for a signature next to a file by that name and complains about a missing .minisig instead of naming the real problem. This command below puts the name back, and does nothing at all if your browser left it unchanged:

if (Test-Path SHA256SUMS.txt) { Rename-Item SHA256SUMS.txt SHA256SUMS }

You want Signature and comment signature verified, followed by a trusted comment naming the release. Now that the checksum list is trustworthy, check your download against it:

shasum -a 256 --ignore-missing -c SHA256SUMS   # macOS
sha256sum --ignore-missing -c SHA256SUMS       # Linux

Windows has no equivalent flag, so the PowerShell version writes the same work out in full: take each line of SHA256SUMS, split the expected hash from the filename, hash that file on your own machine, and compare. It reads your installer and nothing else — nothing is sent anywhere, and nothing is changed on disk.

Get-Content SHA256SUMS | ForEach-Object {
    $expected, $file = $_ -split '\s+', 2
    if (-not (Test-Path $file)) { $file + ': skipped, not downloaded' }
    elseif ((Get-FileHash $file -Algorithm SHA256).Hash -eq $expected) { $file + ': OK' }
    else { $file + ': FAILED' }
}

All three read the expected hash and the filename out of SHA256SUMS itself, so there’s no version number to type and no long hex string to compare by eye. You want your installer’s own name followed by : OK. Once a release carries more than one installer, the ones you didn’t download are skipped, which is not a failure. A FAILED line means the file is incomplete or has been altered, and you shouldn’t open it.

Both steps are load-bearing, and skipping either one quietly wastes the other. A valid signature says nothing about the file you actually downloaded. A matching checksum says nothing about who wrote the checksum.

The download page carries the same commands with copy buttons, under How do I verify?, and Support has the full walkthrough for each platform .

Who gave you the key?

Suppose a public key is only ever published on the same page that serves the file.

Then whatever can change the file can change the checksums beside it, and the key beside those. All three commands still pass. What they establish is that the download matches a key from the same source as the download — which is a fact about consistency, not about origin. The check didn’t fail. It just never asked the question you thought it was asking.

This is the uncomfortable centre of the whole business: a signature is only worth something if you can get the key from somewhere the attacker doesn’t control. Publishing a key next to the thing it verifies is a closed loop, and a closed loop will happily reassure you forever.

Which is the honest reason this article exists. It’s another place to get the key.

It is not, in fairness, a fully independent one. This journal is a different application, deployed a different way, from a different repository than the Vauz site — so an attacker needs two things instead of one. That isn’t nothing. It also isn’t independence, because it’s still Sealzi: once you’re theorising about someone who can reach one of our systems, you can just as easily theorise about someone who reaches two.

The copy that isn’t a web page

So the key is published somewhere that isn’t a web page at all. There’s a TXT record on _minisign.vauz.sealzi.com, and you can read it in one command:

dig +short TXT _minisign.vauz.sealzi.com

You should get back a string in this shape, with the same public key we posted:

"v=minisign1; k=RWTcejyNskGe1Xc8GvEbKjUlI2wPh8XLVcs8Xcd3EraJvmSX7LuX8QQY"

Windows doesn’t ship dig, but nslookup -type=TXT _minisign.vauz.sealzi.com asks the same question and gets the same answer.

That record is served by our DNS provider — a different company, on different systems, with different credentials from the web server that hands you the installer.

Which means nothing served from vauz.sealzi.com can influence it. The download page, the checksums, and the key printed in that panel all come from one machine; the TXT record comes from somewhere else entirely, and no edit on the first can reach the second. Read the key both ways and you are no longer leaning on a single source.

One honest limit on that: sealzi.com isn’t DNSSEC-signed, so the record isn’t sealed cryptographically the way the release signature is. A DNS answer can be interfered with in transit, and nothing in the answer itself would show it. That’s a narrower problem than the one this record exists to solve, but it isn’t nothing — querying through a resolver you trust is worth doing.

It’s on our support site as well, in the step-by-step version of this article , and it’s going on the changelog  too — which is where people tend to look when they’re already reading what a release changed. More copies on more sites is better than fewer. But they are all still web pages, so treat them as convenience rather than corroboration: DNS is the one that’s genuinely somewhere else.

What gets you furthest out of the loop, though, is time.

Save the key today — from DNS, ideally — and put it somewhere of your own. When the next release comes out, check it against your copy rather than against whatever the page is showing that day. For that check to be fooled, the wrong key would have to have been in place before you first looked, and stayed wrong quietly ever since. Every release you verify against your own saved copy makes that story harder to tell.

That’s also why we treat the key as close to permanent, and why we won’t rotate it because it feels tidy. A changed key produces exactly the same error on your machine as a real attack does. If we start crying wolf, we’ve destroyed the one signal we were trying to give you.

What this key is not

It’s worth being precise, because “key” is an overloaded word and the overloading usually flatters the company doing it.

This is not an encryption key. It protects nothing in your vault, it can’t decrypt anything, and it has no relationship to your V-Key. Your entries are encrypted regardless, with a key held by your operating system and bound to your machine — that’s a separate piece of the design entirely.

The signing key does exactly one thing: it proves a download came from us. Publishing it costs us nothing, which is precisely what makes it publishable. If a company ever seems reluctant to hand you a public key, something has gone sideways with either their security or their vocabulary.

If a check fails

Don’t open the file, and please tell us at security@vauz.sealzi.com

A mismatch means one of two things: we botched a release, or our server isn’t serving what we put on it. The first is embarrassing and the second is serious, and both need looking at the same day. We’d much rather hear about it from you than find out later.

And the other direction, which matters more:

Caution

We will never ask you to accept a new signing key. Not by email, not in a support ticket, not in a chat window, however convincingly it’s written. If this key ever legitimately changes, it will change in the places we’ve published it, and there will be a post here explaining why. A message urging you to trust a new key is what an attack looks like from the inside

Most people will never run these commands

That’s fine. Honestly, it’s expected. Verifying a download is a chore, and the people who do it routinely are a small and specific crowd.

But the point was never that everyone checks. It’s that checking is possible — by anyone, at any time, without asking us for permission, without an account, and without taking a single word on this page on faith.

That’s the same instinct behind keeping your vault on your own device and behind not hiding privacy in a settings menu: fewer things you have to believe, more things you can simply look at.

The key is above. It’ll be the same one next year.