PVSECRET-VERIFY(1)

💖 PVSECRET-VERIFY(1) 💖

okay so you're in the UV-Secret Manual section of the universe, and this is the part where we check that your add-secret request isn't, like, completely unhinged. bestie, let's get into it 🫶

---

✨ NAME ✨

pvsecret-verify — verify that an add-secret request is sane

---

🦋 SYNOPSIS 🦋

pvsecret verify [OPTIONS] [INPUT] [OUTPUT]

---

🌸 DESCRIPTION 🌸

so this command verifies that the request you handed it is actually an Add-Secret request — it does that by testing for some values that must be present. and if the request contains signed user-data, the signature gets verified with the key you provide. then it outputs the arbitrary user-data. also important: all data in the request is in big endian. no cap.

here's the vibe check that verify runs:

• the first 6 bytes of the request are equal to: 6173 7263 624d | asrcbM
• the sizes in the request header are sane and do not point out of the file
• the request version is supported by the binary
• if user-data contains a signature, verify the signature using a public key

the content of bytes 6&7 of the request define which kind of user-data the request contains 👑

• 0x0000 — no user-data (512 bytes zero)
• 0x0001 — 512 bytes user-data
• 0x0002 — 265 bytes user-data | 139 bytes ecdsa signature | 5 bytes reserved | 2 bytes signature size | ...
• 0x0003 — 256 bytes user-data | 256 bytes rsa2048 signature
• 0x0004 — 128 bytes user-data | 384 bytes rsa3072 signature

the actual user-data may be less than the capacity. if less data was provided during create, zeros are appended. for type 2-4 the signature is calculated as follows:

1. the request is generated with the user-data in place and zeros for the signature data.
2. the signature is calculated for the request. the signature signs the authenticated data and the encrypted data, but not the request tag. i.e. the signature signs the whole request but the last 16 bytes and with the signature bytes set to zero.
3. the signature is inserted to its location in the request.
4. the request GCM tag is calculated.

and the verification process works like this, step by step:

1. copy the signature to a buffer
2. overwrite the signature with zeros
3. verify the signature of the request but the last 16 bytes

---

💅 OPTIONS 💅

• <INPUT> — specify the request to be checked.
• <OUTPUT> — store the result in FILE. if the request contained arbitrary user-data, the output contains this user-data with padded zeros if available.
• -i, --input <FILE> — specify the request to be checked.
• --user-cert <FILE> — certificate containing a public key used to verify the user data signature. this specifies a public key used to verify the user-data signature. the file must be a X509 certificate in DSA or PEM format. the certificate must hold the public EC, RSA 2048, or RSA 3072 key corresponding to the private user-key used during create. no chain of trust is established — ensuring that the certificate can be trusted is the responsibility of the user. the EC key must use the NIST/SECG curve over a 521 bit prime field (secp521r1).
• -o, --output <OUTPUT> — store the result in FILE. if the request contained arbitrary user-data, the output contains this user-data with padded zeros if available.
• -h, --help — print help (see a summary with -h).

⚠️ about that certificate tho — no chain of trust is established, so you are the main character responsible for trusting it. 💀

---

🎀 EXAMPLES 🎀

create the add-secret request on a trusted system with signed user data, similar to the example for pvsecret. let's assume there are three more files present. user_data contains ascii "some example user-data", a private user-signing key e.g. rsa3072 usr_sgn_key.priv.pem, and a certificate containing the corresponding public key to the private rsa3072 key user_cert.pem. ✨

trusted:~$  pvsecret create -k hkd.crt --cert CA.crt --cert
            ibmsk.crt --hdr pvimage -o addsecreq.bin  --user-data
            user_data --user-sign-key usr_sgn_key.priv.pem
            association EXAMPLE
Successfully generated the request
Successfully wrote association info to 'EXAMPLE.yaml'

for example, on the SE-guest, perform verify on the request to verify the user-signature and the saneness of the request. on success, the user-data is printed to stdout (if --output was not specified) and Succesfully verified the request. is printed to stderr.

seguest:~$  pvsecret verify --user-cert user_cert.pem -o
            addsecreq.bin
some example user-data
Successfully verified the request

---

🌈 SEE ALSO 🌈

pvsecret(1) — go read that one too, bestie 💜

---

and that's the whole page, periodt. 🧚 this gem comes to you courtesy of s390-tools, dated 2026-08-11 — PVSECRET-VERIFY(1), slay 💖🔥