Is it possible to check the MAC of an encrypted file without being able to decrypt it?

[klaernie]

Hi y'all!

I recently botched up one of my files by changing an unencrypted value. I keep these values unencrypted, since it can be helpful to our 24/7 teams to be able to understand e.g. which component is talking to which other component and which hostname is used precisely.
However, I changed the domain of a hostname, but didn't really think and used plain vim instead of sops edit. Since the value I was changing was unencrypted, I didn't notice until our pipeline rolled the secret out and alerts started piling up.

Since I already do an automatic integrity check of great portions of the other repo content before commit (as part of the pre-commit hook) I was wondering if there is a way to verify the MAC without decrypting the file.

The caveat of "without being able to decrypt the file" comes from the point, that the 24/7 team is allowed to make trivial changes (to the rest of the repo), but are not allowed to know all the secrets stored in the file. So the pre-commit hook runs a verification so errors are caught before actually committing them, but for maybe 30% of the changes there is no secret around that would allow decryption.

Best regards,
Andre

---

PS: I'm aware that my particular problem could have been prevented by omitting cleartext values from the MAC, but I would like to prevent accidental changes in unencrypted values as well (we store certificates in plaintext and only encrypt the private key, so if someone would generate a new cert and write it to the file, they would be unable to update the private key, and might simply skip this step - causing the keypair to mismatch. In this case the MAC failure would prevent them from making any change.)

[mohammadrezwankhan]

No—not cryptographically with current SOPS. The component verifying the MAC must be able to recover the file's data key, which also gives it the capability to decrypt the secrets.

sops.mac is not a public-key signature. The verification path is:

1. unwrap the per-file data key;
2. decrypt the protected values and recompute the hash of the cleartext tree;
3. decrypt the stored sops.mac with that data key;
4. compare the two values.

Because mac_only_encrypted is false in your intended setup, the cleartext hostname/certificate values are included in that hash too. That is why the raw vim edit becomes a MAC mismatch—but detecting that mismatch requires the key.

sops filestatus does not help here: it only checks that the file parses as a SOPS document and has version/MAC metadata. It does not validate the MAC. A separate keyless sops --verify has been requested in #437, but it does not exist today, and the current MAC format could not provide cryptographic keyless verification by itself.

For an actual integrity check, run normal decryption in a tightly scoped CI job that has the key and discard the output:

if ! sops decrypt "$file" >/dev/null; then
    echo "SOPS decryption/integrity check failed: $file" >&2
    exit 1
fi

Do not pass --ignore-mac. This still decrypts internally—the job must be treated as secret-capable—but it avoids printing plaintext. In v3.13.3, a cleartext-value MAC mismatch exits 51; failure to obtain the data key exits 128. In a hook, treat every nonzero exit as failure rather than depending only on those two codes.

For machines that intentionally have no key, the safe pre-commit rule is policy rather than verification. If those operators should only edit the rest of the repository, reject a staged change to the SOPS file:

if ! git diff --cached --quiet -- path/to/secrets.enc.yaml; then
    echo "secrets.enc.yaml must be changed via the key-bearing SOPS workflow" >&2
    exit 1
fi

That catches this accidental vim edit without claiming to authenticate the file.

If no-key users must legitimately edit the cleartext fields, the choices are the trade-off you already identified—mac_only_encrypted, so those fields are deliberately not protected—or splitting the public data from the SOPS document and protecting/checking it separately. For the certificate/private-key example, keep a key-bearing CI check that decrypts the private key and compares its public key to the certificate; a no-key local hook cannot prove that relationship.

This matches the project's earlier guidance for the same constraint: the whole-file MAC is an intentional integrity boundary, so editing protected cleartext without access to update/verify it requires changing the document or trust boundary, not another SOPS flag.

[klaernie]

Thank you very much for the comprehensive answer and insight! That was exactly the information I was looking for!

I'll now build my pre-commit hook to check if my encrypted file has staged modifications, and if so, require a sops decrypt to succeed, with probably a quick pre check if there is a valid gpg installation or age key present like on our servers, so users get a better error message than just plainly dumping the sops decrypt output.